ejklock/living-docs-skill

Living Docs

Behandle Dokumentation als lebendiges System, das mit dem Code synchron bleibt, nicht als einmal geschriebenes Artefakt, das veraltet. Die Disziplin hat eine Wirbelsäule — jedes Wissen hat genau eine Heimat, diese Heimat ist indiziert, und nichts Strukturelles wird ohne seine Dokumentation ausgeliefert — und mehrere Dokumenttypen, die daran hängen: eine Verfassung, ADRs, BDRs, PRDs, Issues, Recherche, Architekturdiagramme und ein semantischer Kontextindex.

Diese Fertigkeit ist Stack-agnostisch. Sie regelt wie Dokumente organisiert und gepflegt werden, niemals welche Technologie ein Projekt verwendet.

---

Kerninvarianten (die Wirbelsäule)

Diese gelten für jeden Dokumenttyp. Alles andere ist Detail.

1. Dokumente zuerst. Erstelle den Inhalt im Repository (docs/…) bevor du ihn extern veröffentlichst (Tracker, Wiki). Die Repository-Datei ist die Quelle der Wahrheit; die externe Kopie ist ein Spiegel.
2. Eine Heimat pro Fakt. Jedes Konzept, jede Entscheidung oder Anforderung lebt in genau einer Datei. Keine Duplikate — verweise stattdessen durch Querverweise. Duplizierter Text ist Drift, der nur darauf wartet, zu passieren.
3. Indiziert oder es existiert nicht. Jedes Dokument ist von einem Index aus erreichbar (einer index.md-Auflistung in seinem Verzeichnis und dem Bundle-Stamm docs/index.md, den der Projektleitfaden verlinkt). Keine verwaisten Dateien.
4. Überschreiben, niemals Geschichte umschreiben. Entscheidungen und Anforderungen sind Append-Only-Aufzeichnungen. Wenn sich etwas ändert, markiere die alte Aufzeichnung als ersetzt und schreibe eine neue — bearbeite niemals stillschweigend die Vergangenheit.
5. Keine strukturelle Änderung ohne ihre Dokumentation. Neues Modul, verschobene Dateien, Schemaänderung, neuer Datenfluss → aktualisiere das entsprechende Dokument und sein Diagramm in derselben Änderung. Kein "Ich dokumentiere es später."

Im Zweifelsfall leite die richtige Handlung aus diesen fünf Regeln ab. Die folgenden Regeln sind nur diese Invarianten, angewendet auf jeden Dokumenttyp.

---

Format: OKF-konform

Die fünf Invarianten regeln Organisation und Lebenszyklus; das Open Knowledge Format regelt das Dateiformat, damit der Korpus portabel und von Agenten parsebar bleibt. Jedes Dokument im System ist auch ein OKF-Konzept. Lade die Fertigkeit okf-knowledge-format (die die Spezifikation bereitstellt), wenn du ein Dokument erstellst oder das Format prüfst.

OKF ist eine dünne, austauschbare Abhängigkeit – kein Fundament (Versionsrisiko). OKF ist v0.1 von einem einzelnen Anbieter; eine abwärtsinkompatible v0.2 ist eine reale Möglichkeit. Die obigen Invarianten hängen nicht von OKF ab – sie hängen nur von einer kleinen Menge von Frontmatter-Feldern ab, sodass ein OKF-Bruch nicht die Governance-Ebene mit sich reißen kann. Halte die Grenze explizit:

• Erforderlich von Living Docs (der Faktenvertrag, den scripts/lint-docs.sh durchsetzt): ein nicht leeres type und status + superseded_by auf ersetzten Aufzeichnungen. Diese sind unsere; sie überleben unabhängig von OKF.
• Von OKF geerbt (Formatkonventionen): reservierte index.md/log.md, das Bundle-Stamm-okf_version, bundle-relative Links, die Überschrift # References (§8). Wenn sich OKF ändert, bewegt sich nur diese Zeile – pinne die Version in der Fertigkeit okf-knowledge-format neu und passe sie an.

Zwei Regeln gelten für jede Konzeptdatei:

1. Frontmatter mit einem erforderlichen type. Jede nicht reservierte .md-Datei beginnt mit einem YAML-Frontmatter-Block, dessen type die Dokumentart benennt (Constitution, PRD, ADR, BDR, Issue, Context, Architecture View, Research, Reference). Empfohlen: title, description, tags, timestamp. Living-Docs fügt Produzentenschlüssel hinzu: status, supersedes, superseded_by. Status wandert in das Frontmatter – keine **Status:**-Körperzeile.
2. Reservierte Dateien + bundle-relative Links. Das Bundle-Stamm ist docs/. Verzeichnisauflistungen sind index.md (OKF §6, kein Frontmatter – außer dem Bundle-Stamm-docs/index.md, das okf_version: "0.1" trägt). Optionale log.md zeichnet die Verzeichnisgeschichte auf (§7). Querverweise mit /-präfixierten bundle-relativen Pfaden (/adr/0007-slug.md); liste Quellen unter einer # References-Überschrift auf (§8), jeder Eintrag formatiert gemäß rules/citation-conventions.md – ABNT NBR 6023-Struktur, immer mit dem Link, mit verbindenden Bezeichnungen in der Projektdokumentationssprache (Standard Englisch: Available at: . Accessed on: ) gemäß rules/doc-language.md.

---

Dokumentenpfad

Jede Änderung folgt dieser Kette, von der grundlegenden Quelle der Wahrheit bis zum Code:

flowchart LR
  C[Verfassung] --> P[PRD]
  P --> A[ADR]
  P --> B[BDR]
  A --> I[Issues]
  B --> I
  I --> K[Code]

Artefakt	Rolle
Verfassung	Grundlegende Quelle der Wahrheit: was das Produkt ist, Kern datenmodell, unverhandelbare Dinge. Alle anderen Dokumente stehen darunter.
PRD	Was das System tun muss und warum – Funktions-/Produktanforderungsspezifikation.
ADR	Wie das System strukturiert ist – Architektur-/Implementierungsentscheidung und Begründung.
BDR	Was das System beobachtbar tun muss – Eingaben, Ausgaben, Nebeneffekte, Given/When/Then-Szenarien – und wie jedes getestet wird (die Testentwurfsmatrix; einzige Heimat für "wie testen", ein Ausführungs-Issue verlinkt es).
Issues	Ausführungsschnitte – diskrete Arbeitseinheiten, die auf ADRs/BDRs zurückgehen.
Code	Implementierung – jedes oben spezifizierte Verhalten, jede Struktur und Schnittstelle, realisiert.

---

Wann diese Fertigkeit aufrufen

• Aufsetzen der Dokumentation für ein Projekt (Erstellen der docs/-Struktur, des Dokumentenindex, der ADR-/Issue-/BDR-/Verfassungsverzeichnisse).
• Erstmalige Ausführung von Living-Docs in einem Projekt (kein ## Living Docs-Block im Projektleitfaden) → stelle die Durchsetzungsmodus-Frage und speichere die Antwort → siehe Durchsetzungsmodi.
• Übernahme von Living-Docs in ein bestehendes/Brownfield-Projekt (Entscheidungen bereits getroffen, aber nicht dokumentiert) → folge Vorgehen → Übernahme von Living-Docs in ein bestehendes Projekt: inventarisiere die Entscheidungen, bestätige jede mit dem Benutzer, bevor du ein ADR aufzeichnest, fülle niemals nur durch Rückschlüsse nach.
• Schreiben oder Bearbeiten eines ADR (einer Architektur-/Implementierungsentscheidung) → lade rules/adr-conventions.md + templates/adr.md.
• Schreiben oder Bearbeiten eines PRD (einer Produkt-/Funktionsanforderungsspezifikation) → lade rules/prd-conventions.md + templates/prd.md.
• Schreiben oder Bearbeiten einer BDR (beobachtbares Verhalten – Eingaben, Ausgaben, Given/When/Then-Szenarien, und der Testentwurfsmatrix für die Testmethode) → lade rules/bdr-conventions.md + templates/bdr.md. Eine Teststrategieentscheidung (nicht standardmäßige Ebene/Technik, Balkenabweichung) ist ein ADR tags: [testing], kein neuer Aufzeichnungstyp (kein "TDR").
• Spezifizieren einer nicht-funktionalen Anforderung (Leistung, Verfügbarkeit, Sicherheit, Skalierung) → ein Qualitätsattribut-Szenario, gebunden an ein Instrument im PRD (rules/prd-conventions.md Regel 9 + templates/prd.md); die Entscheidung + Fitnessfunktion gehen in ein ADR. Kein neuer Dokumenttyp.
• Aufstellen oder Ändern der Verfassung (grundlegender Umfang, Datenmodell, unverhandelbare Dinge) → lade rules/constitution-conventions.md + templates/constitution.md.
• Erstellen oder Bearbeiten eines Issues/Tickets → lade rules/issue-workflow.md + templates/issue.md.
• Aufzeichnen von Recherche (Technologiebewertung, externe Kompromisse) → lade die Fertigkeit research-artifacts. Sie besitzt das OKF-Recherchenotiz-Format (eine Datei pro Notiz, kein Unterordner pro Recherche), die Quellendisziplin und die nachvollziehbare Kette von Recherche → Entscheidung → Issue und verweist hierher für die ADR-/BDR-/Issue-Artefakte. Arbeitet mit der Fertigkeit deep-research zusammen.
• Zeichnen oder Aktualisieren eines Architektur-, Datenfluss- oder Tool-Calling-Diagramms → lade rules/architecture-diagrams.md + templates/architecture-index.md.
• Definieren eines Begriffs oder Akronyms, das die Dokumente verwenden → füge ihn zum Glossar hinzu (docs/context/glossary.md), eine Heimat pro Begriff → lade rules/glossary-conventions.md + templates/glossary.md.
• Ein Dokument ist zu groß geworden oder vermischt Belange → in einen semantischen Index aufteilen → lade rules/semantic-index.md + templates/context-index.md.
• Durchsetzen der No-Drift-Wartungsregel nach jeder strukturellen Änderung → lade rules/maintenance-invariant.md.
• Erstellen oder Überprüfen des OKF-Formats eines Dokuments (Frontmatter type, reservierte index.md/log.md, bundle-relative Links, # References) → lade die Fertigkeit okf-knowledge-format.
• Entscheiden, welche Sprache die Dokumente in geschrieben sind (Standard Englisch; Benutzer kann zu Sitzungsbeginn überschreiben und festlegen) → lade rules/doc-language.md.

---

Dokumentenübersicht

Typ	Lebt in	Zweck	Änderbarkeit
Projektleitfaden	CLAUDE.md / README.md (Stamm)	Einstiegspunkt: Umfang, Stack, Dokumentenverzeichnis, obligatorische Arbeitsabläufe	Live – frei bearbeitbar
Verfassung	docs/constitution.md	Grundlegende Quelle der Wahrheit: Produktumfang, Datenmodell, unverhandelbare Dinge	Append-Only nach Ratifizierung (Änderungsprotokoll)
Kontextindex	docs/context/index.md + Gruppendateien	Domänen- und Modulvokabular, semantisch gruppiert	Live – frei bearbeitbar
Glossar	docs/context/glossary.md	Einmal definierte Begriffe und Akronyme in der Dokumentsprache (Akronym-Stichwörter unverändert)	Live – frei bearbeitbar
Architektur	docs/architecture.md oder docs/architecture/ + Index	Lebendige Mermaid-Diagramme: Struktur, Datenmodell, Flüsse, Tool-Calling	Live – muss mit Code übereinstimmen
ADR	docs/adr/NNNN-slug.md	Eine Architektur-/Implementierungsentscheidung	Append-Only (ersetzen)
BDR	docs/bdr/NNNN-slug.md	Eine Entscheidung über beobachtbares Verhalten	Append-Only (ersetzen oder ändern)
PRD	docs/prd/NNNN-slug.md	Eine Spezifikation für Funktion/Produktanforderung	Append-Only nach Annahme
Issue	docs/issues/NNNN-slug.md	Tracker-Spiegel (Körper), eines pro Ticket	Körper bearbeitbar; veröffentlichte Kopie folgt
Recherche	docs/research/NNNN-<slug>.md (eine Datei, kein Unterordner; fortlaufende Nummer führt, Datum im Frontmatter timestamp; endet mit # References)	Externe Beweise mit belegten Behauptungen	Append-Only (Beweise sind datiert)

Jedes Verzeichnis trägt seine eigene index.md-Auflistung (OKF §6, kein Frontmatter). Der "Dokumentenindex" des Projektleitfadens verlinkt zum Bundle-Stamm docs/index.md. Siehe rules/semantic-index.md für den Indizierungsvertrag.

---

Vorgehen

Einrichten von Living-Docs in einem neuen Projekt

1. Stelle die Frage zum Durchsetzungsmodus (siehe Durchsetzungsmodi → Erstausführungsfrage) vor allem anderen, da noch keine Präferenz gespeichert ist. Notiere die Antwort als den ## Living Docs-Block im Projektleitfaden; standardmäßig strict, wenn der Benutzer keine Präferenz hat.
2. Erstelle den Projektleitfaden (CLAUDE.md oder Äquivalent) mit einem Abschnitt Dokumentenindex und einem Abschnitt Wartungsregel (kopiere den Wortlaut aus rules/maintenance-invariant.md). Verwende templates/claude-hard-rules.md als Ausgangspunkt für den Abschnitt mit harten Regeln des Projektleitfadens – er enthält bereits den ## Living Docs-Durchsetzungsblock; fülle die Platzhalter aus, bevor du festschreibst.
3. Erstelle docs/ mit den Verzeichnissen, die das Projekt benötigt (adr/, bdr/, issues/, prd/, research/, context/). Initialisiere docs/constitution.md aus templates/constitution.md. Füge das Bundle-Stamm-docs/index.md hinzu (mit okf_version: "0.1"), und gib jedem Verzeichnis von Tag eins an seine eigene index.md-Auflistung – selbst wenn sie fast leer ist.
4. Initialisiere den Kontextindex (docs/context/index.md) mit dem vorhandenen Domänenvokabular und das Glossar (docs/context/glossary.md) mit den Begriffen und Akronymen, die die Dokumente bereits voraussetzen (rules/glossary-conventions.md). Erweitere beide, wenn Konzepte benannt werden.
5. Initialisiere das Architekturdokument (docs/architecture.md) mit den Mermaid-Ansichten auf hoher Ebene, die das System bereits hat. Fördere zu einem docs/architecture/-Verzeichnis + Index, sobald es wächst (rules/architecture-diagrams.md).
6. Zeichne bereits getroffene Entscheidungen als ADRs auf, damit sie nicht erneut diskutiert werden – bestätige jedoch jede mit dem Benutzer, bevor du aufzeichnest (siehe Übernahme von Living-Docs in ein bestehendes Projekt, Schritte 3–5); fülle niemals ein ADR nur durch Rückschlüsse nach.

Übernahme von Living-Docs in ein bestehendes Projekt (Brownfield)

Ein bestehender Codebestand enthält bereits Entscheidungen, die nie aufgeschrieben wurden. Der Fehlermodus hier ist, dass der Agent ADRs durch Rückschlüsse nachfüllt und sie als endgültig präsentiert – Entscheidungen aufzeichnet, die der Benutzer nie bestätigen musste. Die Übernahme ist daher eine Ermittlungsübung, keine Transkriptionsübung.

1. Stelle die Frage zum Durchsetzungsmodus (Erstausführung) und speichere den ## Living Docs-Block, genau wie für ein neues Projekt.
2. Gerüst erstellen, ohne zu entscheiden. Erstelle docs/ + das index.md jedes Verzeichnisses, das Bundle-Stamm-docs/index.md, und initialisiere das Glossar/den Kontextindex aus Vokabular, das bereits im Code, der README und den Agentenleitfäden (CLAUDE.md / AGENTS.md) vorhanden ist. Dies ist mechanisch – hier werden keine Entscheidungen getroffen.
3. Lies zuerst den vorhandenen Kontext, dann inventarisiere die Entscheidungen – als Kandidaten, nicht als Aufzeichnungen. Sammle, was das Projekt bereits trägt: den Code selbst, plus die README, die Agentenleitfäden (CLAUDE.md / AGENTS.md), Paketmanifeste und alle Konstruktionsnotizen oder Kommentare. Erstelle daraus eine Liste der tragenden Entscheidungen, die das Projekt zu verkörpern scheint (Stack, Grenzen, Datenmodell, wichtige Kompromisse). Schreibe noch keine ADRs.
4. Präsentiere den Bestand dem Benutzer und bestätige jeden. Gib für jeden Kandidaten die abgeleitete Entscheidung und die Alternativen an, die sie scheinbar ausgeschlossen hat, und bitte den Benutzer, sie zu bestätigen, zu korrigieren oder zu verwerfen – hinterfrage die tragenden gründlich (grill-me, falls installiert). Der Benutzer besitzt die Entscheidung; der Agent bringt nur an die Oberfläche, was der Code impliziert.
5. Zeichne nur die bestätigten Entscheidungen als ADRs auf. Dies sind Ursprungsaufzeichnungen – sie ersetzen nichts. Erfasse die gewählte Option und die abgelehnten Alternativen, die der Benutzer bestätigt hat. Ein Kandidat, den der Benutzer verwirft, oder einer, dessen Begründung niemand kennt, wird nicht zu einem ADR erfunden.
6. Initialisiere das Architekturdokument mit den Mermaid-Ansichten auf hoher Ebene, die das System bereits hat (rules/architecture-diagrams.md), und setze dann die Wartungsschleife unten fort.

Wartung von Living-Docs (jede Aufgabe)

1. Vor dem Codieren: Lies den ## Living Docs-Durchsetzungsmodus aus dem Projektleitfaden (wenn der Block fehlt, ist dies die erste Ausführung – stelle die Erstausführungsfrage und speichere die Antwort). Lies dann die relevante Verfassung, ADRs, BDRs und den Inhalt, der den aktuellen Arbeitsbereich betrifft. Prüfe das Glossar auf Begriffe, die du verwenden wirst.
2. Während der Änderung: Für jede Codeänderung (neue Datei, signifikantes Refactoring, Schemaänderung, neuer Datenfluss):
   • Bevor du die Änderung festschreibst, aktualisiere das/die relevanten Architekturdiagramme (z.B. ein neues Modul → Flussdiagramm, das den neuen Pfad zeigt), die entsprechende BDR (wenn das beobachtbare Verhalten/Schnittstelle betroffen ist) und/oder den PRD (wenn die Funktion betroffen ist).
   • Wenn die Änderung aus einer Entscheidung resultiert, die nicht durch eine vorhandene ADR abgedeckt ist, zeichne die Entscheidung als ADR auf (siehe Vorlage).
3. Nach dem Codieren: Führe das Skript zur Driftprüfung aus (siehe scripts/lint-docs.sh), falls vorhanden. Stelle sicher, dass alle neuen Dateien vom Index aus erreichbar sind (docs/index.md und verzeichnislokale index.md).

Übernahme in bereichsspezifische Agenten

Wenn ein Agent auf einen bestimmten Teil des Korpus beschränkt ist (z.B. Frontend-Agent liest nur docs/context/), tue dies:

1. Lege explizit fest, welche Dokumente er lesen darf, und welche er schreiben darf (normalerweise nur seine eigenen).
2. Stelle sicher, dass er den Kontextindex und das Glossar als geteilte, schreibgeschützte Heimat für domänenspezifisches Vokabular verwendet.
3. Verwende die Leseliste (siehe rules/semantic-index.md) als Einstiegspfad.
4. Jeder Agent, der eine ADR, BDR oder einen PRD schreibt, muss dies in den entsprechenden Verzeichnissen tun, wobei die Benennungskonvention der fortlaufenden Nummern eingehalten werden muss.

---

Dateiaufbau

Nachfolgend ist der empfohlene Aufbau für ein Projekt, das Living-Docs verwendet. Die tatsächliche Struktur kann je nach Projektanforderungen variieren.

.
├── CLAUDE.md                  # Projektleitfaden (oder README.md / AGENTS.md)
├── docs/
│   ├── index.md               # Bundle-Stamm (okf_version: "0.1", semantischer Einstiegspunkt)
│   ├── adr/
│   │   ├── 0001-slug.md       # Eine ADR-Aufzeichnung
│   │   └── index.md
│   ├── bdr/
│   │   ├── 0001-slug.md       # Eine BDR-Aufzeichnung
│   │   └── index.md
│   ├── issues/
│   │   ├── 0001-slug.md       # Ein Issue (Tickets) – Spiegel des Trackers
│   │   └── index.md
│   ├── prd/
│   │   ├── 0001-slug.md       # Ein PRD
│   │   └── index.md
│   ├── research/
│   │   ├── 0001-slug.md       # Eine Recherchenotiz
│   │   └── index.md
│   ├── context/
│   │   ├── index.md           # Kontextindex (Semantische Gruppierung)
│   │   ├── glossary.md        # Glossar (Begriffe und Akronyme)
│   │   └── … (bis zu 10 Gruppendateien)
│   ├── architecture/
│   │   ├── index.md           # Architekturindex mit eingebettetem Mermaid-Diagramm
│   │   └── … (Diagramme aufteilen, wenn die Datei wächst)
│   └── rules/                 # Regeln (von diesem Skill verwaltet, nicht vom Projekt bearbeitet)
│       ├── adr-conventions.md
│       ├── bdr-conventions.md
│       ├── prd-conventions.md
│       ├── constitution-conventions.md
│       ├── architecture-diagrams.md
│       ├── glossary-conventions.md
│       ├── semantic-index.md
│       ├── maintenance-invariant.md
│       ├── doc-language.md
│       ├── citation-conventions.md
│       ├── issue-workflow.md
│       └── (…)                   # Jede Regel entspricht einem Dokumenttyp
├── templates/
│   ├── adr.md
│   ├── bdr.md
│   ├── prd.md
│   ├── constitution.md
│   ├── issue.md
│   ├── glossary.md
│   ├── architecture-index.md
│   ├── context-index.md
│   └── claude-hard-rules.md
└── scripts/
    └── lint-docs.sh            # Faktenvertragsprüfung (optional)

Hinweis: Das docs/rules/-Verzeichnis wird von diesem Skill verwaltet – gib dich niemals als der Benutzer aus, um diese Dateien zu bearbeiten, es sei denn, du wurdest angewiesen, dies zu tun. Der Projektleitfaden (oder das Äquivalent des Agenten) kann diese Regeln über die ## Living Docs-Richtlinie referenzieren.

---

Durchsetzungsmodi

Erstausführungsfrage

Wenn dieses Skill zum ersten Mal in einem Projekt ausgeführt wird, muss vor jeder anderen Aktion die folgende Frage gestellt werden:

"Living Docs kann die fünf No-Drift-Invarianten entweder mit Durchsetzung (Aufgaben werden abgelehnt, die dagegen verstoßen) oder ohne Durchsetzung (Empfehlungen) anwenden. Möchtest du die strikte Durchsetzung (strict) oder die weiche Durchsetzung (soft)?"

• strict – Aufgaben, die strukturelle Änderungen ohne Dokumentation vornehmen, werden mit einem Verweis auf die Invariante abgelehnt, die verletzt wurde. Wird verwendet, wenn das Projekt ein Governance-Niveau durchsetzen möchte.
• soft – Der Agent erinnert an die Invarianten, schreitet aber nicht ein. Wird für die schrittweise Einführung oder in Projekten verwendet, in denen Dokumentation nicht erzwungen werden kann.

Die Antwort wird als der ## Living Docs-Block im Projektleitfaden gespeichert. Wenn der Benutzer keine Präferenz hat, standardmäßig strict.

Regelinteraktion

• Überschreiben – Diese Durchsetzungsmodi überschreiben keine anderen Hard-Rules im Projektleitfaden. Sie fügen eine zusätzliche Governance-Ebene hinzu.
• Bereich – Sie gelten nur für dokumentationsbezogene Aufgaben und strukturelle Änderungen, nicht für Routinecodeänderungen.
• Ausnahmen – Der Benutzer kann jederzeit eine Ausnahme anfordern, indem er sie explizit angibt: "Ausnahme von Invariante 5 für diese Änderung – wir werden später dokumentieren." Protokolliere die Ausnahme im Issue/PR-Beschreibung.

---

Integration mit anderen Fertigkeiten

Dieses Skill arbeitet mit den folgenden Fertigkeiten zusammen:

• okf-knowledge-format – Erforderlich für die Formatkonformität. Stellt die OKF-Spezifikation und Validierung bereit.
• research-artifacts – Verantwortlich für Recherchenotizen. Paart sich mit deep-research.
• deep-research – Für gründliche Recherche-Workflows.
• grill-me – Optional, um Entscheidungen während der Brownfield-Übernahme zu hinterfragen.

Aufgabenspezifische Ladehinweise:

Aufgabe	Ladehinweise
ADR schreiben	lade rules/adr-conventions.md + templates/adr.md
PRD schreiben	lade rules/prd-conventions.md + templates/prd.md
BDR schreiben	lade rules/bdr-conventions.md + templates/bdr.md
Issue erstellen	lade rules/issue-workflow.md + templates/issue.md
Architekturdiagramm	lade rules/architecture-diagrams.md + templates/architecture-index.md
Verfassung ändern	lade rules/constitution-conventions.md + templates/constitution.md
Glossareintrag	lade rules/glossary-conventions.md + templates/glossary.md
Kontext indexieren	lade rules/semantic-index.md + templates/context-index.md
Wartungsregel anwenden	lade rules/maintenance-invariant.md
OKF-Format prüfen	lade okf-knowledge-format
Sprache festlegen	lade rules/doc-language.md
Recherche aufzeichnen	lade research-artifacts + erwäge deep-research

---

Lizenz

Dieses Skill ist unter der MIT-Lizenz lizenziert. Siehe LICENSE für Details.

---

Fazit

Living Docs bietet eine robuste, geschlossene Governance für die Dokumentation, die sich natürlich in den Entwicklungsablauf einfügt. Indem sie die fünf Invarianten durchsetzt und OKF-konforme Formate verwendet, stellt sie sicher, dass die Dokumentation eine lebendige, genaue und nützliche Ressource bleibt. Dieses Skill ist dazu gedacht, mit bestehenden Agenten-Workflows verwendet zu werden – es ersetzt nichts, es verbessert die Qualität und Wartbarkeit der Dokumentation.