Neue Skills, Referenzen & OpenWiki-Doku integriert

Umfangreiche Erweiterung der Skill-Bibliothek: Neue Skills für Humanisierung (Englisch/PT-BR), Design-Validierung, AI-SEO und Coolify-Deployment inkl. Regelwerke, Presets, Pattern-Referenzen, Testfälle und Automatisierungsskripte. Zusätzliche Skills für Revenue-Centric Design, Pier Cloud, OKF, Lebenslauf- und LinkedIn-Optimierung sowie zahlreiche Referenzdateien, Checklisten und YAML/JSON/Markdown-Templates. Einführung einer vollständigen OpenWiki-Dokumentation mit Architektur-, Domain- und Workflow-Beschreibungen, zentralem Index und automatisierten Updates. Modularer Aufbau, restriktive Lizenzen und umfassende Qualitäts- und Evaluationsmechanismen für alle neuen Inhalte.

.github/skills/loop-architect/references/control-rubric.md

@@ -0,0 +1,60 @@
+# Control Rubric
+
+Use this when setting gates, iteration caps, budgets, and stop conditions.
+
+## Required Guards
+
+- `loop_control.max_iterations`
+- `gates.*.max_revisions`
+- `loop_control.no_progress.max_stalled_iterations`
+- At least one wall-clock, token, or USD budget cap when external models run.
+  The generated Python runner enforces wall-clock caps directly; token and USD
+  caps are advisory unless the chosen model CLI exposes accounting that the
+  loop operator wires in separately.
+- A stop condition that describes success.
+- A stop condition that describes no-progress or repeated failure.
+
+## Good Gate Design
+
+- Plan gate runs before delivery work.
+- Delivery gate runs after each delivery artifact.
+- Programmatic checks run before judge calls when possible.
+- Human checkpoints sit at high-leverage points, usually after plan approval or
+  before external egress.
+- Resume happens at gate boundaries unless the user explicitly needs finer
+  granularity.
+
+## Execution Boundary
+
+- Name where the loop is allowed to modify files: current workspace, branch,
+  worktree, throwaway directory, or an external orchestrator workspace.
+- Identify actions with side effects: pushes, PR comments, Slack messages,
+  deploys, file deletes, database writes, or vendor sends.
+- Decide whether side-effecting actions require approval, idempotency notes, or
+  duplicate-action checks.
+- If the loop may run on a schedule or in parallel, call out the need for an
+  external orchestrator with concurrency controls.
+
+## Failure Behavior
+
+- Stop immediately when a hard cap is reached.
+- Write the latest state to `loop-workspace/state.json`.
+- Append each meaningful step, decision, check result, and blocker to
+  `loop-workspace/run-log.md`.
+- Preserve review notes even when the gate fails.
+- Stop or ask the human when the same blocker repeats for the configured
+  no-progress window.
+- Do not let the host keep revising forever.
+
+## Anti-Patterns
+
+- No maximum iteration count.
+- A judge gate with no judge.
+- A budget cap in prose but not in `loop_control`.
+- No no-progress detector.
+- A loop that can send duplicate external notifications or repeat destructive
+  actions after restart.
+- Scheduled or multi-agent work with no durable orchestrator or concurrency
+  story.
+- Human signoff required but no checkpoint.
+- Stop conditions that require subjective self-satisfaction.

.github/skills/loop-architect/references/council-rubric.md

@@ -0,0 +1,43 @@
+# Council Rubric
+
+Use this when selecting reviewers and judges.
+
+## Roles
+
+`reviewer`
+: Gives notes only. It may improve quality, but it cannot declare a gate clean.
+
+`judge`
+: Gives a structured verdict. It can be used as a gate `verdict_source`.
+
+## Selection Guidance
+
+- Prefer a different model family from the host for blind-spot coverage.
+- Prefer local models such as `ollama` when privacy matters more than judgment
+  quality.
+- Prefer a judge for gates that must block progress.
+- Prefer a reviewer for brainstorming, adversarial notes, or tone critique
+  where a deterministic pass/fail would be fake precision.
+- Keep council scope small: `plan`, `delivery`, or specific paths.
+
+## Gate Rule
+
+`verdict_policy: revise_until_clean` requires `verdict_source` to be either a
+judge member or `human`. A reviewer-only gate can use `fixed_passes`, but it
+cannot honestly claim clean.
+
+## Judge Rubric Tips
+
+- Name the artifact being judged.
+- Name the exact criteria IDs.
+- Ask for blocking issues, not general commentary.
+- Require the fenced JSON verdict first or last.
+- Keep the judge prompt short enough that the artifact, not the instruction
+  wrapper, dominates the context.
+
+## Privacy Notes
+
+Cross-vendor review can send project context to another CLI and vendor account.
+Always name the destination, scope what it receives, apply redaction globs, and
+require consent before the first send.
+

.github/skills/loop-architect/references/goal-rubric.md

@@ -0,0 +1,42 @@
+# Goal Rubric
+
+Use this when shaping the user's loop goal.
+
+## Good Goal Shape
+
+- Names the concrete outcome, not only the activity.
+- Defines the artifact or state that proves the loop finished.
+- Sets scope boundaries: included work, excluded work, and maximum depth.
+- Names context sources the host must gather instead of assumptions it may make.
+- Identifies the user, customer, system, or reviewer who will consume the result.
+
+## Critique Prompts
+
+- What would count as done if two competent agents disagreed?
+- Which terms are subjective and need a measurable proxy?
+- What context must be read before the host drafts a plan?
+- What is explicitly out of scope for this loop?
+- Can the goal be split into plan, delivery, and verification artifacts?
+
+## Anti-Patterns
+
+- "Improve the project" without a target artifact.
+- "Make it good" without criteria.
+- "Research X" without the decision the research supports.
+- Goals where success depends on information the loop never gathers.
+- Goals that require endless polishing with no stop condition.
+
+## Better Examples
+
+Weak: "Make our onboarding better."
+
+Better: "Produce a 5-step onboarding workflow map for new enterprise users,
+with each step assigned to a product surface, email, human owner, or missing
+capability, and with no unresolved TBDs."
+
+Weak: "Fix the flaky tests."
+
+Better: "Identify and patch the root cause of the checkout test flake, prove it
+with 20 local repeats or a CI rerun, and leave a short note explaining the
+failure mode and the verification evidence."
+

.github/skills/loop-architect/references/model-detection.md

@@ -0,0 +1,98 @@
+# Model Detection and Privacy Notes
+
+Loop-architect detection is intentionally dumb and transparent. It stores
+invocation metadata only, never credentials.
+
+## Registry
+
+Default registry path:
+
+```text
+~/.loop-architect/models.json
+```
+
+Registry entries should look like:
+
+```json
+{
+  "kiro": {
+    "cli": "kiro-cli",
+    "invoke": ["kiro-cli", "chat", "--trust-all-tools", "-p"],
+    "probe": ["kiro-cli", "--version"],
+    "available": true,
+    "authed": true,
+    "local": false,
+    "capabilities": {
+      "headless": true,
+      "goal": true,
+      "subagent": true,
+      "review_loop": true
+    }
+  },
+  "claude": {
+    "cli": "claude",
+    "invoke": ["claude", "-p"],
+    "probe": ["claude", "--version"],
+    "available": true,
+    "authed": true,
+    "local": false,
+    "capabilities": {
+      "headless": true,
+      "goal": true,
+      "subagent": false,
+      "review_loop": false
+    }
+  }
+}
+```
+
+## Capabilities
+
+`headless`
+: The CLI accepts a prompt via stdin/argument and returns output via stdout
+  without interactive prompts. Required for use as host or judge in the
+  external Python runner.
+
+`goal`
+: The CLI supports a `/goal` command that runs an autonomous loop with
+  self-verification. When present, RUN_IN_SESSION.md can emit a `/goal`
+  one-liner as an alternative execution path.
+
+`subagent`
+: The CLI can spawn isolated sub-agents with their own context. When present,
+  the council can use native subagent review loops instead of shelling out.
+
+`review_loop`
+: The CLI supports iterative review loops with trigger-based feedback (e.g.
+  Kiro's `loop_to` with `NEEDS_CHANGES` trigger). Enables native cross-model
+  review without the external runner.
+
+## Kiro CLI Specifics
+
+- Headless mode requires `--trust-all-tools` or the session halts waiting for
+  tool approval.
+- Full invoke pattern: `["kiro-cli", "chat", "--trust-all-tools", "-p"]`
+- The `/goal --max N` command provides native loop execution with configurable
+  iteration limits (default 5).
+- Subagent review loops use a `trigger` string (e.g. `NEEDS_CHANGES`) and
+  `max_iterations` cap.
+
+## `authed` Semantics
+
+`authed` means the basic probe command exited cleanly. It is a convenience
+signal, not a guarantee that a future paid model call will succeed.
+
+## Default Redactions
+
+- `.env`
+- `.env.*`
+- `secrets/**`
+- `**/*.key`
+
+Add project-specific globs for customer data, private transcripts, or internal
+design docs before sending anything to a non-local council member.
+
+## Local Model UX
+
+Surface `ollama` as the privacy-preserving option when present. It may be lower
+quality than frontier hosted models, but it keeps council review in-house.

.github/skills/loop-architect/references/verification-rubric.md

@@ -0,0 +1,59 @@
+# Verification Rubric
+
+Use this when converting the user's definition of done into typed criteria.
+
+## Taxonomy
+
+`programmatic`
+: A command or deterministic check returns pass/fail. Use this whenever
+possible. Examples: tests, build, lint, schema validation, snapshot comparison,
+or an extraction script that checks required headings.
+
+`judge`
+: A model scores a rubric and returns a structured verdict. Use this for
+semantic quality that cannot be cheaply checked by code. The rubric must be
+specific enough that a different model can apply it consistently.
+
+`human`
+: A person must sign off. Use this for taste, business judgment, private
+knowledge, legal risk, or decisions where the user is the true authority.
+
+## Required Fields
+
+- Every criterion needs `id` and `type`.
+- `programmatic` needs `check` as an argv array and `expect`.
+- `judge` needs `rubric`.
+- `human` needs `prompt`.
+
+## Strong Criteria
+
+- Check one thing at a time.
+- Say what failure means.
+- Prefer deterministic checks before model judgment.
+- Make judge rubrics observable against artifacts the judge receives.
+- Avoid relying on the host model to grade its own work.
+
+## Anti-Patterns
+
+- All criteria are judge or human criteria when tests or schema checks exist.
+- "No errors thrown" as the only success criterion.
+- Criteria that require hidden context not sent to the judge.
+- Rubrics like "high quality" or "comprehensive" without dimensions.
+- Programmatic checks written as shell strings instead of argv arrays.
+
+## Structured Judge Contract
+
+Judges should return a fenced JSON object:
+
+```json
+{
+  "verdict": "pass",
+  "blocking_issues": [],
+  "confidence": 0.86,
+  "notes": "The artifact satisfies the rubric."
+}
+```
+
+Valid verdicts are `pass` and `revise`. If output cannot be parsed, the runner
+will treat it as `revise` with a warning.
+