diff --git a/skill/arc42-authoring/SKILL.md b/skill/arc42-authoring/SKILL.md
new file mode 100644
index 0000000..c9663ee
--- /dev/null
+++ b/skill/arc42-authoring/SKILL.md
@@ -0,0 +1,44 @@
+---
+name: arc42-authoring
+description: Produce and maintain arc42 architecture documentation with cross-section traceability, structured quality scenarios, and decision–risk wiring. Use when scaffolding a new arc42 document, extending an existing one, or verifying traceability between chapters.
+metadata:
+  author: LLM-Coding
+  version: "0.1"
+  source: https://github.com/LLM-Coding/Semantic-Anchors
+license: MIT
+---
+
+# arc42 Authoring
+
+Procedural guidance for producing arc42 architecture documentation that goes beyond the template's built-in help text.
+
+## On invocation
+
+When this skill is invoked:
+
+1. **Check whether an arc42 document already exists.** Look for `src/docs/` or `docs/arc42/` in the project. If found, work incrementally — do not re-scaffold.
+
+2. **If no arc42 exists, scaffold first.** Use docToolchain `downloadTemplate` to create the "with-help" template into `src/docs/`. Each chapter's help text is its structural spec — fill and then replace it.
+
+3. **Apply the traceability rules** from [references/traceability-rules.md](references/traceability-rules.md) as you produce or review each chapter. These rules are the project's value-add over plain arc42.
+
+4. **For Chapter 10 quality scenarios**, use the six-part Quality Attribute Scenario format from [references/chapter-10-quality-scenarios.md](references/chapter-10-quality-scenarios.md).
+
+5. **For Chapter 11 Risks and Technical Debt**, follow [references/chapter-11-structure.md](references/chapter-11-structure.md).
+
+6. **For Chapter 8 Crosscutting Concepts**, follow [references/chapter-8-baseline.md](references/chapter-8-baseline.md).
+
+7. **For ADR–Risk wiring**, apply the rules in [references/adr-risk-wiring.md](references/adr-risk-wiring.md).
+
+## When to use this skill
+
+- Scaffolding a new arc42 document for a greenfield project
+- Extending an arc42 document after architecture decisions change
+- Reviewing arc42 documentation for completeness and cross-section traceability
+- Producing Chapter 10 quality scenarios in the six-part form
+- Structuring Chapter 11 with the Risks/Technical-Debt split
+
+## When NOT to use this skill
+
+- For reverse-engineering existing code into documentation — use `socratic-code-theory-recovery` instead (Phase 2 of that skill produces arc42 from an answered Question Tree)
+- For the vocabulary of what arc42, ADRs, C4, and QAS *are* — that is the `architecture-documentation` contract (always-on)
diff --git a/skill/arc42-authoring/references/adr-risk-wiring.md b/skill/arc42-authoring/references/adr-risk-wiring.md
new file mode 100644
index 0000000..54c857a
--- /dev/null
+++ b/skill/arc42-authoring/references/adr-risk-wiring.md
@@ -0,0 +1,47 @@
+# ADR–Risk Wiring
+
+## Rule
+
+Each ADR's **Consequences** section names the risks the decision creates:
+
+- If the risk is already tracked in Chapter 11: reference its ID (e.g., "introduces R-003").
+- If the risk is new: either add it to Chapter 11 with a new R-NNN ID, or record the consequence as "explicitly accepted without a tracked risk" (for trivial consequences).
+
+## Inverse direction
+
+Conversely, Chapter 11 risks that are *caused by* a decision reference the ADR that introduced them.
+
+## Unconfirmed decisions
+
+When the rationale behind a decision is inferred (not confirmed by the team):
+
+- ADR Status: **"Accepted (inferred)"**
+- Pugh Matrix cells needing team judgment: marked `?` rather than guessed
+
+This preserves honesty — the documentation records what is known vs. what is assumed.
+
+## Scaffolding
+
+When creating a new ADR, use this template:
+
+```
+# ADR-NNN: <Title>
+
+## Status
+Accepted | Accepted (inferred) | Proposed | Superseded by ADR-NNN
+
+## Context
+<Why this decision is needed>
+
+## Decision
+<What was decided>
+
+## Pugh Matrix
+| Criterion | Option A | Option B (Baseline) | Option C |
+|-----------|----------|---------------------|----------|
+| ...       | +1       | 0                   | -1       |
+
+## Consequences
+- <Positive consequence>
+- <Negative consequence → R-NNN>
+```
diff --git a/skill/arc42-authoring/references/chapter-10-quality-scenarios.md b/skill/arc42-authoring/references/chapter-10-quality-scenarios.md
new file mode 100644
index 0000000..bb8a26a
--- /dev/null
+++ b/skill/arc42-authoring/references/chapter-10-quality-scenarios.md
@@ -0,0 +1,28 @@
+# Chapter 10 — Quality Scenarios
+
+## Format: Six-Part Quality Attribute Scenario (Bass/Clements/Kazman)
+
+Every Chapter 10 quality scenario is written in this form:
+
+| Part | Description | Example |
+|------|-------------|---------|
+| **Source** | Who or what triggers the stimulus | End user, CI pipeline, attacker |
+| **Stimulus** | The event or condition | 1000 concurrent requests, node failure, SQL injection attempt |
+| **Artifact** | What is affected | Order Service, API Gateway, Database |
+| **Environment** | Under what conditions | Normal operation, peak load, degraded mode |
+| **Response** | What the system does | Queues excess requests, fails over, rejects input |
+| **Response Measure** | Literal, testable figure | p99 < 200ms, failover < 30s, zero data exposure |
+
+The **Response Measure** carries a literal figure, so the requirement is testable rather than an adjective ("fast", "secure", "available").
+
+## Chapter 1.2 vs. Chapter 10
+
+- **Chapter 1.2** lists only the top 3–5 quality goals — the ones that drive architecture decisions.
+- **Chapter 10** may elaborate further quality characteristics beyond those top goals.
+- Each Chapter 10 scenario is marked as either:
+  - **Concretising** a Chapter 1.2 top goal (cross-link which one), or
+  - **Derived** — a quality requirement that does not trace to a top goal but matters for the system.
+
+## Deriving scenarios from code
+
+When evidence exists in code (timeouts, budgets, SLOs, test thresholds), derive scenarios as `[ANSWERED]` with `file:line` evidence. Never invent target numbers — only the quality-goal *ranking* is a team decision.
diff --git a/skill/arc42-authoring/references/chapter-11-structure.md b/skill/arc42-authoring/references/chapter-11-structure.md
new file mode 100644
index 0000000..c5cb917
--- /dev/null
+++ b/skill/arc42-authoring/references/chapter-11-structure.md
@@ -0,0 +1,36 @@
+# Chapter 11 — Risks and Technical Debt
+
+## Structure
+
+Chapter 11 separates into two subsections:
+
+### 11.1 Risks
+
+Each risk carries:
+
+| Column | Description |
+|--------|-------------|
+| **ID** | R-NNN (stable identifier for cross-referencing from ADRs) |
+| **Risk** | What could go wrong |
+| **Probability** | Low / Medium / High |
+| **Impact** | Low / Medium / High |
+| **Priority** | Derived from probability × impact |
+| **Mitigation** | Cross-reference to Chapter 8 concept or quality scenario that mitigates it |
+
+Risks are ordered by priority (highest first).
+
+### 11.2 Technical Debt
+
+Each debt item:
+
+| Column | Description |
+|--------|-------------|
+| **ID** | TD-NNN |
+| **Debt** | What the shortcut is |
+| **Building Block** | Cross-reference to specific Chapter 5 building block it burdens |
+| **Impact** | What happens if not addressed |
+| **Effort** | Estimated effort to resolve |
+
+## ADR ↔ Risk wiring
+
+See [adr-risk-wiring.md](adr-risk-wiring.md) for how ADR Consequences connect to Risk IDs.
diff --git a/skill/arc42-authoring/references/chapter-8-baseline.md b/skill/arc42-authoring/references/chapter-8-baseline.md
new file mode 100644
index 0000000..5fadc4d
--- /dev/null
+++ b/skill/arc42-authoring/references/chapter-8-baseline.md
@@ -0,0 +1,21 @@
+# Chapter 8 — Crosscutting Concepts Baseline
+
+## Required baseline concepts
+
+arc42 leaves Chapter 8 open. This skill requires five baseline crosscutting concepts, in this order:
+
+| Section | Concept | Key rule |
+|---------|---------|----------|
+| 8.1 | **Threat Model** | STRIDE; threats get IDs (T-001…) |
+| 8.2 | **Security** | Every mitigation references the T-IDs it closes |
+| 8.3 | **Test** | Testing pyramid; tests trace to Use Cases and Business Rules |
+| 8.4 | **Observability** | Logs, metrics, traces, audit trails |
+| 8.5 | **Error Handling** | Retry, circuit breaker, fallback, recovery |
+
+## Extension rule
+
+Add further Chapter 8.x concepts (persistence, i18n, accessibility, configuration, performance) **only when the system actually has that concern**. Do not add empty sections.
+
+## Back-referencing
+
+Chapter 8 concepts back-reference the Chapter 9 ADR that decided them. If no ADR exists for a concept, either create one or note the concept as "established practice, no decision required."
diff --git a/skill/arc42-authoring/references/scaffolding.md b/skill/arc42-authoring/references/scaffolding.md
new file mode 100644
index 0000000..c10fa94
--- /dev/null
+++ b/skill/arc42-authoring/references/scaffolding.md
@@ -0,0 +1,19 @@
+# Scaffolding
+
+## Initial setup with docToolchain
+
+Scaffold the arc42 "with-help" template into the project's `src/docs/` directory:
+
+```bash
+docToolchain downloadTemplate
+```
+
+Each chapter's help text is its structural spec — fill and then replace the help text as the documentation matures.
+
+## Diagram conventions
+
+- **Format**: PlantUML, not Mermaid
+- **Building blocks**: C4 via PlantUML's bundled C4-PlantUML standard library
+- **Include form**: `!include <C4/...>` (angle brackets = stdlib), never the remote `https://` URL, never vendored file copies
+- **Style**: C4 containers and components, not generic boxes
+- **Coverage**: Every context, building-block, and runtime chapter carries at least one diagram
diff --git a/skill/arc42-authoring/references/traceability-rules.md b/skill/arc42-authoring/references/traceability-rules.md
new file mode 100644
index 0000000..6a892f3
--- /dev/null
+++ b/skill/arc42-authoring/references/traceability-rules.md
@@ -0,0 +1,26 @@
+# Cross-Section Traceability Rules
+
+arc42 templates do not enforce these connections between chapters. This skill does.
+
+## The five rules
+
+1. **Quality Goal → Strategy**: Every Chapter 1.2 quality goal maps to a named approach in Chapter 4 (Solution Strategy).
+
+2. **Context ↔ Building Blocks**: The external systems in Chapter 3 (System Scope and Context) and the Chapter 5 Level-1 building-block view are the same set — one system boundary in both.
+
+3. **Building Block → Runtime**: Every Chapter 5 building block appears in at least one Chapter 6 runtime scenario. Chapter 6 includes at least one error/recovery scenario, not only the happy path.
+
+4. **ADR Index**: Chapter 9 carries an in-document ADR index (ADR | Title | Status), even when the ADRs live in a separate register.
+
+5. **Building Block Completeness**: Each Chapter 5 building block states responsibility, interface, and source location.
+
+## Verification checklist
+
+After producing or updating chapters, verify:
+
+- [ ] Every Chapter 1.2 goal appears by name in Chapter 4
+- [ ] Chapter 3 external systems = Chapter 5 Level-1 boundary elements
+- [ ] No Chapter 5 building block is absent from Chapter 6
+- [ ] Chapter 6 contains ≥1 error/recovery scenario
+- [ ] Chapter 9 index is up to date
+- [ ] Every Chapter 5 block has: responsibility, interface, source location
diff --git a/website/public/data/contracts.json b/website/public/data/contracts.json
index 2f52963..27f1b77 100644
--- a/website/public/data/contracts.json
+++ b/website/public/data/contracts.json
@@ -5,7 +5,12 @@
     "titleDe": "Spezifikation",
     "description": "What we mean when we say 'spec'",
     "descriptionDe": "Was wir meinen, wenn wir 'Spec' sagen",
-    "anchors": ["cockburn-use-cases", "gherkin", "bdd-given-when-then", "ears-requirements"],
+    "anchors": [
+      "cockburn-use-cases",
+      "gherkin",
+      "bdd-given-when-then",
+      "ears-requirements"
+    ],
     "template": "When we talk about a \"specification\" or \"spec\", we mean:\n- Persona Use Cases in Cockburn's Fully Dressed format (Primary Actor, Trigger, Main Success Scenario, Extensions, Postconditions) at User Goal level, with Business Rules (BR-IDs)\n- System Use Cases for each technical interface (API endpoint, CLI command, event, file format): input/validation, processing, output/status codes, error responses\n- Activity Diagrams for all flows (not just the happy path)\n- Acceptance criteria in Gherkin format (Given/When/Then)\n- Individual requirements in EARS syntax where applicable (When/While/If/Shall)\n- Supplementary Specifications as needed: Entity Model, State Machines, Interface Contracts, Validation Rules",
     "templateDe": "Wenn wir von einer \"Spezifikation\" oder \"Spec\" sprechen, meinen wir:\n- Persona Use Cases im Cockburn Fully Dressed Format (Primary Actor, Trigger, Main Success Scenario, Extensions, Nachbedingungen) auf User-Goal-Ebene, mit Geschäftsregeln (BR-IDs)\n- System Use Cases für jede technische Schnittstelle (API-Endpunkt, CLI-Befehl, Event, Dateiformat): Input/Validierung, Verarbeitung, Output/Statuscodes, Fehlerantworten\n- Activity Diagrams für alle Abläufe (nicht nur der Happy Path)\n- Akzeptanzkriterien im Gherkin-Format (Given/When/Then)\n- Einzelanforderungen in EARS-Syntax wo passend (When/While/If/Shall)\n- Ergänzende Spezifikationen nach Bedarf: Entity Model, State Machines, Interface Contracts, Validierungsregeln",
     "category": "requirements"
@@ -16,7 +21,13 @@
     "titleDe": "Anforderungsermittlung",
     "description": "How we clarify requirements before writing specs",
     "descriptionDe": "Wie wir Anforderungen klären, bevor wir Specs schreiben",
-    "anchors": ["socratic-method", "mece", "prd", "impact-mapping", "user-story-mapping"],
+    "anchors": [
+      "socratic-method",
+      "mece",
+      "prd",
+      "impact-mapping",
+      "user-story-mapping"
+    ],
     "template": "Clarify requirements using the Socratic Method:\n- Ask at most 3 questions at a time, challenge assumptions\n- Use MECE to ensure questions cover all areas without overlap\n- Keep asking until you fully understand the requirements\n\nFrame the scope before writing it down:\n- Impact Mapping connects deliverables to business goals and actors — so you build what moves a goal, not just what was asked.\n- User Story Mapping lays stories along the user's journey and exposes a coherent first slice.\n\nDocument the result as a PRD (problem, goals, personas, success criteria, scope).",
     "templateDe": "Anforderungen mit der Sokratischen Methode klären:\n- Höchstens 3 Fragen gleichzeitig, Annahmen hinterfragen\n- MECE nutzen, um alle Bereiche überlappungsfrei abzudecken\n- Weiterfragen bis die Anforderungen vollständig verstanden sind\n\nDen Scope rahmen, bevor er aufgeschrieben wird:\n- Impact Mapping verbindet Lieferobjekte mit Geschäftszielen und Akteuren — damit man baut, was ein Ziel bewegt, nicht nur was gefragt wurde.\n- User Story Mapping ordnet Stories entlang der Nutzerreise an und legt eine sinnvolle erste Scheibe offen.\n\nDas Ergebnis als PRD dokumentieren (Problem, Ziele, Personas, Erfolgskriterien, Scope).",
     "category": "requirements"
@@ -27,20 +38,15 @@
     "titleDe": "Architekturdokumentation",
     "description": "How we document architecture with diagrams, ADRs, and decision evaluation",
     "descriptionDe": "Wie wir Architektur mit Diagrammen, ADRs und Entscheidungsbewertung dokumentieren",
-    "anchors": ["arc42", "c4-diagrams", "adr-according-to-nygard", "pugh-matrix", "quality-attribute-scenario"],
-    "template": "Architecture documentation follows arc42. Scaffold the arc42 \"with-help\" template into the project's `src/docs/` via docToolchain `downloadTemplate` rather than restating chapter structure here — each chapter's help text is its structural spec, which the process fills and then replaces.\n\nEvery context, building-block and runtime chapter carries at least one diagram. Diagrams are PlantUML, not Mermaid; building blocks use C4 via PlantUML's bundled C4-PlantUML standard library — the `!include <C4/...>` stdlib form (angle brackets), never the remote `https://` URL and never vendored file copies. Not generic boxes.\n\nDecisions are ADRs (Nygard) with a 3-point Pugh Matrix (-1/0/+1). When the rationale is unconfirmed, ADR Status is \"Accepted (inferred)\" and Pugh cells needing team judgment are marked `?` rather than guessed. Each ADR's Consequences name the risks the decision creates, referencing the Chapter 11 risk IDs (R-NNN); a decision that creates a risk not yet in Chapter 11 either adds it there or records the consequence as explicitly accepted without a tracked risk. Conversely, Chapter 8 concepts back-reference the ADR that decided them.\n\nCross-section traceability — arc42 templates do not enforce these, so the contract does:\n- Every Chapter 1.2 quality goal maps to a named approach in Chapter 4.\n- The external systems in Chapter 3 (context) and the Chapter 5 Level-1 building-block view are the same set — one system boundary in both.\n- Every Chapter 5 building block appears in at least one Chapter 6 runtime scenario; Chapter 6 includes at least one error/recovery scenario, not only the happy path.\n- Chapter 9 carries an in-document ADR index (ADR | Title | Status), even when the ADRs live in a separate register.\n- Each Chapter 5 building block states responsibility, interface, and source location.\n\nChapter 1.2 lists only the top 3-5 quality goals — the ones that drive architecture decisions. Chapter 10 may elaborate further quality characteristics beyond those top goals; that is correct arc42, not a defect. The Chapter 10 quality tree marks each characteristic as either concretising a Chapter 1.2 top goal or as a derived quality requirement, and each Chapter 10 quality scenario cross-links back to the Chapter 1.2 goal it concretises (or is marked \"derived\"). Each Chapter 10 scenario is written in the six-part quality attribute scenario form (Source, Stimulus, Artifact, Environment, Response, Response Measure); the Response Measure carries a literal figure, so the requirement is testable rather than an adjective.\n\nChapter 11 separates Risks from Technical Debt into two subsections. Each Risk carries probability, impact, a derived priority, and a mitigation/action cross-referencing an existing mitigation in Chapter 8 or a quality scenario where one exists; risks are ordered by priority. Each Technical Debt item references the specific Chapter 5 building block it burdens.",
-    "templateDe": "Architekturdokumentation folgt arc42. Das arc42-\"with-help\"-Template per docToolchain `downloadTemplate` in das `src/docs/`-Verzeichnis des Projekts scaffolden, statt die Kapitelstruktur hier zu wiederholen — der Hilfetext jedes Kapitels ist seine Struktur-Spezifikation, die der Prozess füllt und dann ersetzt.\n\nJedes Kontext-, Baustein- und Laufzeit-Kapitel enthält mindestens ein Diagramm. Diagramme sind PlantUML, nicht Mermaid; Bausteine als C4 über PlantUMLs gebündelte C4-PlantUML Standard Library — die `!include <C4/...>`-stdlib-Form (spitze Klammern), nie die Remote-`https://`-URL und nie ins Repo kopierte Dateien. Keine generischen Kästen.\n\nEntscheidungen sind ADRs (Nygard) mit einer 3-Punkt-Pugh-Matrix (-1/0/+1). Wenn die Begründung unbestätigt ist, lautet der ADR-Status \"Accepted (inferred)\", und Pugh-Zellen, die Team-Urteil erfordern, werden mit `?` markiert statt geraten. Die Consequences jedes ADR benennen die Risiken, die die Entscheidung erzeugt, mit Verweis auf die Risiko-IDs aus Kapitel 11 (R-NNN); erzeugt eine Entscheidung ein Risiko, das noch nicht in Kapitel 11 steht, wird es dort ergänzt oder die Konsequenz ausdrücklich als akzeptiert ohne verfolgtes Risiko vermerkt. Umgekehrt verweisen Kapitel-8-Konzepte zurück auf das ADR, das sie entschieden hat.\n\nQuerschnitts-Traceability — arc42-Templates erzwingen das nicht, der Contract tut es:\n- Jedes Qualitätsziel aus Kapitel 1.2 wird auf einen benannten Ansatz in Kapitel 4 abgebildet.\n- Die externen Systeme in Kapitel 3 (Kontext) und die Level-1-Bausteinsicht in Kapitel 5 sind dieselbe Menge — eine Systemgrenze in beiden.\n- Jeder Baustein aus Kapitel 5 erscheint in mindestens einem Laufzeitszenario in Kapitel 6; Kapitel 6 enthält mindestens ein Fehler-/Recovery-Szenario, nicht nur den Happy Path.\n- Kapitel 9 trägt ein dokumentinternes ADR-Verzeichnis (ADR | Titel | Status), auch wenn die ADRs in einem separaten Register liegen.\n- Jeder Baustein aus Kapitel 5 nennt Verantwortlichkeit, Schnittstelle und Quellort.\n\nKapitel 1.2 listet nur die obersten 3-5 Qualitätsziele — die, die Architekturentscheidungen treiben. Kapitel 10 darf weitere Qualitätsmerkmale über diese Top-Ziele hinaus ausführen; das ist korrektes arc42, kein Mangel. Der Qualitätsbaum in Kapitel 10 markiert jedes Merkmal entweder als Konkretisierung eines Kapitel-1.2-Top-Ziels oder als abgeleitete Qualitätsanforderung, und jedes Qualitätsszenario in Kapitel 10 verweist zurück auf das Kapitel-1.2-Ziel, das es konkretisiert (oder ist als \"abgeleitet\" markiert). Jedes Kapitel-10-Szenario wird in der sechsteiligen Quality-Attribute-Scenario-Form geschrieben (Source, Stimulus, Artifact, Environment, Response, Response Measure); das Response Measure trägt einen literalen Wert, sodass die Anforderung testbar ist statt ein Adjektiv.\n\nKapitel 11 trennt Risiken und technische Schuld in zwei Unterabschnitte. Jedes Risiko trägt Eintrittswahrscheinlichkeit, Auswirkung, eine abgeleitete Priorität und eine Mitigation/Maßnahme mit Verweis auf eine bestehende Mitigation in Kapitel 8 oder ein Qualitätsszenario, sofern vorhanden; Risiken sind nach Priorität geordnet. Jeder Posten technischer Schuld verweist auf den konkreten Baustein aus Kapitel 5, den er belastet.",
-    "category": "architecture"
-  },
-  {
-    "id": "crosscutting-concepts",
-    "title": "Crosscutting Concepts",
-    "titleDe": "Querschnittliche Konzepte",
-    "description": "Baseline arc42 Chapter 8 concepts every system documents: threat model, security, test, observability, error handling",
-    "descriptionDe": "Basis-Konzepte für arc42 Kapitel 8, die jedes System dokumentiert: Threat Model, Security, Test, Observability, Error Handling",
-    "anchors": ["arc42", "stride", "testing-pyramid"],
-    "template": "arc42 leaves Chapter 8 open. We require five baseline crosscutting concepts, in this order:\n\n- 8.1 Threat Model — STRIDE; threats get IDs (T-001…).\n- 8.2 Security — every mitigation references the T-IDs it closes.\n- 8.3 Test — testing pyramid; tests trace to Use Cases and Business Rules.\n- 8.4 Observability — logs, metrics, traces, audit trails.\n- 8.5 Error Handling — retry, circuit breaker, fallback, recovery.\n\nAdd further Chapter 8.x concepts (persistence, i18n, accessibility, configuration, performance) only when the system actually has that concern.",
-    "templateDe": "arc42 lässt Kapitel 8 offen. Wir verlangen fünf querschnittliche Basis-Konzepte, in dieser Reihenfolge:\n\n- 8.1 Threat Model — STRIDE; Bedrohungen erhalten IDs (T-001…).\n- 8.2 Security — jede Mitigation referenziert die T-IDs, die sie schließt.\n- 8.3 Test — Testpyramide; Tests verweisen auf Use Cases und Business Rules.\n- 8.4 Observability — Logs, Metriken, Traces, Audit-Trails.\n- 8.5 Error Handling — Retry, Circuit Breaker, Fallback, Recovery.\n\nWeitere Kapitel-8.x-Konzepte (Persistenz, i18n, Barrierefreiheit, Konfiguration, Performance) nur aufnehmen, wenn das System diesen Belang tatsächlich hat.",
+    "anchors": [
+      "arc42",
+      "c4-diagrams",
+      "adr-according-to-nygard",
+      "pugh-matrix",
+      "quality-attribute-scenario"
+    ],
+    "template": "Architecture documentation follows arc42. Diagrams are C4 via PlantUML's bundled C4-PlantUML stdlib (`!include <C4/...>`). Decisions are Nygard ADRs with a 3-point Pugh Matrix (-1/0/+1). Quality requirements are six-part Quality Attribute Scenarios (Bass/Clements/Kazman). For procedural detail — traceability rules, chapter structure, scaffolding — invoke the `arc42-authoring` skill.",
+    "templateDe": "Architekturdokumentation folgt arc42. Diagramme sind C4 über PlantUMLs gebundelte C4-PlantUML-Stdlib (`!include <C4/...>`). Entscheidungen sind Nygard-ADRs mit einer 3-Punkte Pugh-Matrix (-1/0/+1). Qualitätsanforderungen sind sechsteilige Quality Attribute Scenarios (Bass/Clements/Kazman). Für prozedurale Details — Traceability-Regeln, Kapitelstruktur, Scaffolding — den `arc42-authoring`-Skill aufrufen.",
     "category": "architecture"
   },
   {
@@ -66,7 +72,10 @@
     "titleDe": "Backlog-Verwaltung",
     "description": "How we create and prioritize implementation tasks",
     "descriptionDe": "Wie wir Implementierungsaufgaben erstellen und priorisieren",
-    "anchors": ["invest", "moscow"],
+    "anchors": [
+      "invest",
+      "moscow"
+    ],
     "template": "Create EPICs and User Stories as GitHub issues from the specification.\n- User Stories follow INVEST criteria (Independent, Negotiable, Valuable, Estimable, Small, Testable)\n- Prioritize with MoSCoW (Must/Should/Could/Won't)\n- Mark dependencies between issues\n- Groom the backlog regularly as the project evolves",
     "templateDe": "EPICs und User Stories als GitHub Issues aus der Spezifikation erstellen.\n- User Stories folgen den INVEST-Kriterien (Independent, Negotiable, Valuable, Estimable, Small, Testable)\n- Priorisierung mit MoSCoW (Must/Should/Could/Won't)\n- Abhängigkeiten zwischen Issues markieren\n- Backlog regelmäßig groomen",
     "category": "development"
@@ -77,7 +86,12 @@
     "titleDe": "Vertikale Schnitte",
     "description": "How we build the first increment and grow the system in thin end-to-end slices",
     "descriptionDe": "Wie wir das erste Inkrement bauen und das System in dünnen End-to-End-Scheiben wachsen lassen",
-    "anchors": ["walking-skeleton", "tracer-bullet", "thin-vertical-slice", "spike-solution"],
+    "anchors": [
+      "walking-skeleton",
+      "tracer-bullet",
+      "thin-vertical-slice",
+      "spike-solution"
+    ],
     "template": "Build the first increment as a walking skeleton: a deployable end-to-end slice that wires every architectural layer together and does almost nothing else.\n\nGrow the system as thin vertical slices — each slice cuts through all layers and delivers one small piece of user value. Slices are tracer bullets: kept and refined, never thrown away.\n\nWhen a technical unknown blocks a slice, run a spike solution first — a timeboxed, throwaway experiment that removes the risk. Spike code is discarded; only its lesson carries into the slice.",
     "templateDe": "Das erste Inkrement als Walking Skeleton bauen: eine deploybare End-to-End-Scheibe, die alle Architekturschichten verbindet und sonst fast nichts tut.\n\nDas System in dünnen vertikalen Scheiben wachsen lassen — jede Scheibe geht durch alle Schichten und liefert ein kleines Stück Nutzerwert. Scheiben sind Tracer Bullets: behalten und verfeinert, nie weggeworfen.\n\nWenn ein technisches Unbekanntes eine Scheibe blockiert, zuerst eine Spike Solution durchführen — ein zeitlich begrenztes Wegwerf-Experiment, das das Risiko beseitigt. Spike-Code wird verworfen; nur seine Erkenntnis fließt in die Scheibe ein.",
     "category": "development"
@@ -104,7 +118,10 @@
     "titleDe": "Refactoring",
     "description": "How we identify and execute refactorings safely",
     "descriptionDe": "Wie wir Refactorings sicher identifizieren und durchführen",
-    "anchors": ["code-smells", "mikado-method"],
+    "anchors": [
+      "code-smells",
+      "mikado-method"
+    ],
     "template": "Refactoring targets are named code smells, not a vague urge to \"clean up\".\n\nFor any refactoring that does not complete in one step, use the Mikado Method: attempt the change, note what breaks, revert, and do the prerequisites first — never leave the build broken while you dig.\n\nRefactoring commits change structure only. Behaviour changes go in separate commits, and the test suite stays green at every commit.",
     "templateDe": "Refactoring-Ziele sind benannte Code Smells, kein vager Drang \"aufzuräumen\".\n\nFür jedes Refactoring, das nicht in einem Schritt fertig wird, die Mikado-Methode nutzen: die Änderung versuchen, notieren was bricht, zurücksetzen und zuerst die Voraussetzungen erledigen — den Build nie kaputt lassen, während man gräbt.\n\nRefactoring-Commits ändern nur Struktur. Verhaltensänderungen kommen in separate Commits, und die Testsuite bleibt bei jedem Commit grün.",
     "category": "development"
@@ -115,7 +132,12 @@
     "titleDe": "Code-Qualität",
     "description": "Coding conventions and design principles",
     "descriptionDe": "Coding-Konventionen und Design-Prinzipien",
-    "anchors": ["solid-principles", "dry", "kiss-principle", "domain-driven-design"],
+    "anchors": [
+      "solid-principles",
+      "dry",
+      "kiss-principle",
+      "domain-driven-design"
+    ],
     "template": "Our code follows:\n- SOLID principles\n- DRY, KISS\n- Ubiquitous Language from Domain-Driven Design (same terms in code as in the specification)",
     "templateDe": "Unser Code folgt:\n- SOLID-Prinzipien\n- DRY, KISS\n- Ubiquitous Language aus Domain-Driven Design (gleiche Begriffe im Code wie in der Spezifikation)",
     "category": "development"
@@ -126,7 +148,11 @@
     "titleDe": "Qualitätsprüfung",
     "description": "How we review code and check for security issues",
     "descriptionDe": "Wie wir Code reviewen und Sicherheitsprobleme prüfen",
-    "anchors": ["fagan-inspection", "owasp-top-10", "atam"],
+    "anchors": [
+      "fagan-inspection",
+      "owasp-top-10",
+      "atam"
+    ],
     "template": "Quality assurance follows three layers:\n- Code review using Fagan Inspection (structured, systematic, with defined phases)\n- Security review based on OWASP Top 10\n- Architecture review using ATAM (scenario-based tradeoff analysis against quality goals)\n- Use a different AI model or fresh session for reviews to avoid blind spots",
     "templateDe": "Qualitätssicherung folgt drei Schichten:\n- Code-Review mit Fagan Inspection (strukturiert, systematisch, mit definierten Phasen)\n- Security-Review basierend auf OWASP Top 10\n- Architektur-Review mit ATAM (szenariobasierte Tradeoff-Analyse gegen Qualitätsziele)\n- Anderes KI-Modell oder frische Session für Reviews nutzen, um blinde Flecken zu vermeiden",
     "category": "quality"
@@ -137,7 +163,11 @@
     "titleDe": "Docs-as-Code",
     "description": "How we write and build documentation",
     "descriptionDe": "Wie wir Dokumentation schreiben und bauen",
-    "anchors": ["docs-as-code", "plain-english-strunk-white", "gutes-deutsch-wolf-schneider"],
+    "anchors": [
+      "docs-as-code",
+      "plain-english-strunk-white",
+      "gutes-deutsch-wolf-schneider"
+    ],
     "template": "Documentation follows Docs-as-Code according to Ralf D. Müller:\n- AsciiDoc as format, PlantUML for inline diagrams, built by docToolchain\n- Version-controlled, peer-reviewed, and built automatically\n- Plain English according to Strunk & White (or Gutes Deutsch nach Wolf Schneider)\n- Projects following this contract include the `dtcw` wrapper and `docToolchainConfig.groovy` so PlantUML / AsciiDoc actually render.",
     "templateDe": "Dokumentation folgt Docs-as-Code nach Ralf D. Müller:\n- AsciiDoc als Format, PlantUML für Inline-Diagramme, gebaut von docToolchain\n- Versioniert, reviewt und automatisch gebaut\n- Gutes Deutsch nach Wolf Schneider (oder Plain English nach Strunk & White)\n- Projekte, die diesem Contract folgen, enthalten den `dtcw`-Wrapper und `docToolchainConfig.groovy`, damit PlantUML / AsciiDoc tatsächlich gerendert werden.",
     "category": "documentation"
@@ -165,7 +195,10 @@
     "titleDe": "Knappe Antwort (TLDR)",
     "description": "How responses should be structured for brevity",
     "descriptionDe": "Wie Antworten für Kürze strukturiert sein sollen",
-    "anchors": ["bluf", "plain-english-strunk-white"],
+    "anchors": [
+      "bluf",
+      "plain-english-strunk-white"
+    ],
     "template": "Responses lead with the conclusion first (BLUF). Keep to essential points. No filler, no preamble. Use short sentences, active voice, and no unnecessary words (Strunk & White).",
     "templateDe": "Antworten beginnen mit der Schlussfolgerung (BLUF). Nur das Wesentliche. Kein Fülltext, keine Einleitung. Kurze Sätze, aktive Sprache, keine überflüssigen Wörter (Wolf Schneider).",
     "category": "communication"
@@ -176,7 +209,9 @@
     "titleDe": "Einfache Erklärung (ELI5)",
     "description": "How to explain complex concepts simply",
     "descriptionDe": "Wie man komplexe Konzepte einfach erklärt",
-    "anchors": ["feynman-technique"],
+    "anchors": [
+      "feynman-technique"
+    ],
     "template": "Explain complex concepts using simple language and everyday analogies. When the explanation feels hard to write, that reveals gaps in understanding — study those areas first (Feynman Technique).",
     "templateDe": "Komplexe Konzepte mit einfacher Sprache und Alltagsanalogien erklären. Wenn die Erklärung schwerfällt, zeigt das Wissenslücken — diese zuerst vertiefen (Feynman-Technik).",
     "category": "communication"
@@ -187,7 +222,14 @@
     "titleDe": "Erklären und Lehren",
     "description": "How to teach a topic until understanding is verified, not just explained",
     "descriptionDe": "Wie man ein Thema lehrt, bis das Verständnis geprüft ist — nicht nur erklärt",
-    "anchors": ["4mat", "mental-model-according-to-naur", "socratic-method", "feynman-technique", "blooms-taxonomy", "definition-of-done"],
+    "anchors": [
+      "4mat",
+      "mental-model-according-to-naur",
+      "socratic-method",
+      "feynman-technique",
+      "blooms-taxonomy",
+      "definition-of-done"
+    ],
     "template": "Teach until the learner genuinely understands — don't just explain.\n\nSequence each unit Why → What → How → What-If (4MAT): motivation before detail. Treat the Why as Naur's program theory — the reasoning, trade-offs, and branches not taken behind the design, not merely what the code does; drill recursively into why.\n\nDiagnose first (Socratic Method): have the learner restate their current understanding, then fill the gaps with questions, not answers, adjusting depth on request (ELI5 / ELI-intern). The sharpest check is having them explain it back in plain words (Feynman Technique) — where they stall is the gap.\n\nKeep a running, written checklist of what must be grasped — high level (why it matters, what it impacts) and low level (logic, edge cases, design decisions) — a Definition of Done for understanding.\n\nThe loop:\n- After each point, verify by active recall — an open or multiple-choice question, a code walkthrough, the debugger — never \"makes sense?\".\n- \"Understood\" means Bloom's Apply/Analyze level (use it on a new case, trace the edge cases), not recall.\n- Don't advance until the current point is demonstrated, and don't end until the whole checklist is.\n\nScale the ceremony to the size of the question.",
     "templateDe": "Lehren, bis die lernende Person es wirklich versteht — nicht nur erklären.\n\nJede Einheit in der Reihenfolge Why → What → How → What-If aufbauen (4MAT): Motivation vor Detail. Das Why als Naurs Programm-Theory behandeln — die Begründung, die Trade-offs und die nicht gewählten Alternativen hinter dem Design, nicht bloß was der Code tut; rekursiv ins Warum bohren.\n\nErst diagnostizieren (Socratic Method): die Person ihr aktuelles Verständnis zurückgeben lassen, dann die Lücken mit Fragen statt Antworten füllen und die Tiefe auf Wunsch anpassen (ELI5 / ELI-intern). Die schärfste Probe ist das Zurückerklären in einfachen Worten (Feynman Technique) — wo sie stockt, ist die Lücke.\n\nEine laufende, schriftliche Checkliste führen, was verstanden sein muss — high level (warum es zählt, was es beeinflusst) und low level (Logik, Edge Cases, Design-Entscheidungen) — eine Definition of Done fürs Verständnis.\n\nDie Schleife:\n- Nach jedem Punkt durch active recall prüfen — eine offene oder Multiple-Choice-Frage, ein Code-Walkthrough, der Debugger — nie \"passt das?\".\n- \"Verstanden\" heißt Blooms Apply/Analyze-Stufe (auf einen neuen Fall anwenden, Edge Cases durchspielen), nicht Abrufen.\n- Nicht weitergehen, bis der aktuelle Punkt demonstriert ist, und nicht enden, bis die ganze Checkliste es ist.\n\nDie Zeremonie an die Größe der Frage anpassen.",
     "category": "communication"
@@ -198,7 +240,10 @@
     "titleDe": "Schreibstil",
     "description": "How we write technical texts — language, tone, and structure",
     "descriptionDe": "Wie wir technische Texte schreiben — Sprache, Ton und Struktur",
-    "anchors": ["gutes-deutsch-wolf-schneider", "plain-english-strunk-white"],
+    "anchors": [
+      "gutes-deutsch-wolf-schneider",
+      "plain-english-strunk-white"
+    ],
     "template": "Writing follows Gutes Deutsch nach Wolf Schneider (or Plain English according to Strunk & White).\n\nAdditionally:\n- Technical terms stay in English (LLM, Prompt, Token, Spec, etc.)\n- Address the reader directly, use first person sparingly but deliberately\n- Use analogies to human thinking to explain technical concepts\n- One thought per paragraph (5-8 sentences is fine)\n- Section headings are statements, not topic announcements\n- First sentence says what the paragraph is about\n- Show code and prompts, don't just claim things work\n- Conclusions make a clear statement — never end with 'it remains exciting'",
     "templateDe": "Schreibstil folgt Gutes Deutsch nach Wolf Schneider (oder Plain English nach Strunk & White).\n\nZusätzlich:\n- Fachbegriffe auf Englisch lassen (LLM, Prompt, Token, Spec, etc.)\n- Leser direkt ansprechen, Ich-Perspektive sparsam aber gezielt\n- Analogien zum menschlichen Denken für technische Konzepte\n- Ein Gedanke pro Absatz (5-8 Sätze OK)\n- Zwischenüberschriften als Aussagen, nicht Themenankündigungen\n- Erster Satz sagt sofort worum es geht\n- Code/Prompts zeigen, nicht nur behaupten\n- Fazit: klare Aussage, kein 'es bleibt spannend'",
     "category": "communication"
@@ -209,9 +254,14 @@
     "titleDe": "TDD, Hamburg Style",
     "description": "Design-led TDD recipe by Ralf Westphal — close the requirements/logic gap before writing code, then test at service boundaries with minimal mocking",
     "descriptionDe": "Design-geführtes TDD-Rezept nach Ralf Westphal — die Lücke zwischen Anforderungen und Logik vor dem Codieren schließen, dann an Servicegrenzen mit minimalem Mocking testen",
-    "anchors": ["red-green-tdd", "tdd-london-school", "tdd-chicago-school", "iosp"],
+    "anchors": [
+      "red-green-tdd",
+      "tdd-london-school",
+      "tdd-chicago-school",
+      "iosp"
+    ],
     "template": "Design-led TDD recipe by Ralf Westphal — close the requirements/logic gap before writing code, then test at service boundaries with minimal mocking. Use it when the problem is too complex for pure micro-step Red-Green-Refactor.\n\n- **ACD cycle (Analyze → Design → Code)** precedes the test loop: first model the solution to close the gap between requirements and logic, only then code.\n- **\"Right from the start\" philosophy** — implement correctly the first time so refactoring is a correction, not routine cleanup.\n- **Service-level testing** — test behind the public API, independent of API technology.\n- **Minimal mocking** — closer to *TDD, Chicago School* than *London School*.\n- **IOSP (Integration Operation Segregation Principle)** — a function is either composition (Integration) or logic (Operation), never both; structural support for simple unit tests.\n- **Deep Work over Small Steps** — accept that some problems can't be sliced into tiny green increments; stay red longer when the design demands it.\n\nComposes: *TDD, London School*, *TDD, Chicago School*, *Red-Green-Refactor*, *IOSP*.\nSources: https://ralfw.de/hamburg-style-tdd/, https://ralfw.de/tdd-how-it-can-be-done-right/",
     "templateDe": "Design-geführtes TDD-Rezept nach Ralf Westphal — die Lücke zwischen Anforderungen und Logik vor dem Codieren schließen, dann an Servicegrenzen mit minimalem Mocking testen. Anwenden, wenn das Problem zu komplex für reines micro-step Red-Green-Refactor ist.\n\n- **ACD-Zyklus (Analyze → Design → Code)** geht dem Test-Loop voraus: zuerst die Lösung modellieren, um die Lücke zwischen Anforderungen und Logik zu schließen, erst dann codieren.\n- **\"Right from the start\"-Philosophie** — beim ersten Mal korrekt implementieren, sodass Refactoring eine Korrektur ist, keine Routinebereinigung.\n- **Service-Level-Testing** — hinter der öffentlichen API testen, unabhängig von der API-Technologie.\n- **Minimales Mocking** — näher an *TDD, Chicago School* als an *London School*.\n- **IOSP (Integration Operation Segregation Principle)** — eine Funktion ist entweder Komposition (Integration) oder Logik (Operation), niemals beides; strukturelle Unterstützung für einfache Unit-Tests.\n- **Deep Work statt Small Steps** — akzeptieren, dass manche Probleme nicht in kleine grüne Inkremente zerlegt werden können; länger rot bleiben, wenn das Design es erfordert.\n\nKomponiert: *TDD, London School*, *TDD, Chicago School*, *Red-Green-Refactor*, *IOSP*.\nQuellen: https://ralfw.de/hamburg-style-tdd/, https://ralfw.de/tdd-how-it-can-be-done-right/",
     "category": "development"
   }
-]
+]
\ No newline at end of file