Was macht Plan-Doc-Do-Follow Skill?
Plan → Doc → Do → Follow
Intent matchen → erste Route gewinnt → routes/a-b.md lesen (Route a/b) → ihr folgen → Globale Invarianten + Statusmodell anwenden. Nur die benötigte Route, ihre Vorlagen und ihre Sub-Agenten laden – niemals alles
Routen
Planung
| Intent | Route | Parameter |
|---|---|---|
| Epics aus Produktvision extrahieren | plan/proj | |
| Epics mit Stakeholdern validieren | plan/proj-review | |
| Epic-PRD und Tracking erstellen | plan/epic | E{n} |
| Epic-Spezifikation oder -Architektur validieren | plan/epic-review | E{n} {prd |
| Epic-Architektur entwerfen | plan/epic-arch | E{n} |
| Feature-PRD erstellen | plan/feat | E{n} F{n} |
| Feature-Spezifikation oder -Architektur validieren | plan/feat-review | E{n} F{n} {prd |
| Feature-Architektur (nur Ausnahmen) | plan/feat-arch | E{n} F{n} |
| Feature in Aufgaben zerlegen | plan/tasks | E{n} F{n} |
| Scope-Change – Feature/Epic hinzufügen/aktualisieren, auch bereits umgesetzt | plan/change | Beschreibung |
| V2-Projektdokumente zu V3 migrieren (einmalig) | plan/migrate |
Ausführung
| Intent | Route | Parameter |
|---|---|---|
| Token-sparende Tooling einrichten (LSP, Filter, Economy, native Agenten) | do/init | |
| Eine Aufgabe ausführen | do/task | E{n} F{n} T{n} |
| Alle Feature-Aufgaben ausführen, inline verifizieren | do/all-tasks | E{n} F{n} |
| Abgeschlossene Arbeit verifizieren (Aufgabe-für-Aufgabe-Pfad) | do/verify | E{n} F{n} |
| Alle Stati neu berechnen und reparieren | do/sync-status | |
| Gute Praktiken merken | do/memorize |
Globale Invarianten (alle Routen)
- Spirit-Check: Ausrichtung mit
docs/product.md; Product Spirit (oben indocs/project-status.md) wörtlich in jeder Planungsroute + Reviewer-Briefing - Benutzerwille:
docs/decisions.mdbindend; Abweichung = Frage, nie stillschweigend anwenden - Business zuerst: Spezifikations-Review vor der nächsten Phase
- Architektur-Check: Ausrichtung mit
docs/global_architecture.md+docs/technical-stack.md - Ein Fakt, eine Datei: Status/Fakt hat eine eigene Datei (Statusmodell); andere verlinken, nie kopieren
- Zielgruppensprache: Mensch/Business = vollständige Sätze, keine unerklärten Abkürzungen; Agentengerichtet = Dokumentstil (caveman-knapp)
- Kein leeres Gerüst: Unbenutzte Vorlagenabschnitte löschen; niemals „N/V“ oder Platzhalter
- Kein Raten: Blockierende Unklarheit → zuerst fragen; als blockierend/wichtig/nebensächlich kennzeichnen
- Rückverfolgbarkeit: Jedes Dokument referenziert sein Elternelement; Geschichten ↔ Anforderungen ↔ Aufgaben ↔ Tests verknüpft
- Lebendige globale Docs:
docs/data-model.md,docs/ui-map.md,docs/decisions.mdin derselben Änderung aktualisieren, die sie betrifft – niemals „später“ - Modell-Einstufung:
plan/*+ Reviewer = starkes Modell; jedeplan/tasks-Aufgabe von schwächerem Modell ausführbar, ohne PRD zu öffnen - Status-Sync: Jede statusändernde Route endet mit Status-Sync-Prozedur
- Handoff-Format: Kurze Zusammenfassung · Aktueller Fortschritt · Exakter nächster Befehl · Offene Fragen
- Begrenzte Sub-Agenten: Nur die in ihrer Definitionsliste genannten Eingaben
- Denkweise pro Route: Die Denkweise der Route übernehmen
- Beratung bleibt intern: Kritiker-Austausch niemals in Docs/Handoffs – der Mensch sieht das Endergebnis + was zu validieren ist
- Wirtschaftlichkeit überall: Arbeitssparende Wirtschaftlichkeit auf jeder Route und jedem Sub-Agenten
Statusmodell
⚪ TODO · 🟡 SPEC spezifiziert · 🟣 PLAN Aufgaben generiert · 🔵 DEV in Bearbeitung · 🟢 DONE abgeschlossen und verifiziert
Eigentümerschaft – Single Source of Truth
| Fakt | Eigene Datei (einziger Ort, wo geschrieben) |
|---|---|
| Aufgabenstatus | feat-tasks.md – Aufgabentabelle |
| Feature-Status und -Fortschritt | epic-status.md – Feature-Tabelle |
| Epic-Status und -Fortschritt | docs/project-status.md – Epic-Roadmap-Tabelle |
| Projektfortschritt | docs/project-status.md – Fortschrittsabschnitt |
Kein feat-status.md. Pro-Aufgaben-Abschnitte: keine Statuszeile. Mermaid = dekorativ, aus Eigentümertabellen neu generiert, niemals Quelle der Wahrheit
Ableitungsregeln
- Feature: Kein
feat-prd.md→ ⚪ · PRD vorhanden → 🟡 ·feat-tasks.mdvorhanden, keine Aufgabe über TODO hinaus → 🟣 · irgendeine Aufgabe DEV/DONE → 🔵 · 🟢 nur über Verifikations-Gates (do/verifyoder letzte Phase vondo/all-tasks). Aufgaben zu 🟢 Feature hinzugefügt → zurück auf 🔵 - Epic: Kein
epic-prd.md→ ⚪ · PRD vorhanden → 🟡 · alle Features ≥ 🟣 → 🟣 · irgendein Feature 🔵/🟢 (nicht alle 🟢) → 🔵 · alle 🟢 → 🟢 - Projekt: gleiche Aggregation über Epics
- Fortschritt: erledigte Aufgaben / Gesamtaufgaben (0 wenn keine), summiert auf Epic- und Projektebene
Status-Sync-Prozedur
Am Ende jeder statusändernden Route (eigenständig: do/sync-status, alle Epics):
- Aufgabentabellen der betroffenen Features lesen
- Jeden Feature-Status + Fortschritt neu berechnen; Zeile in
epic-status.mdaktualisieren - Jedes betroffene Epic neu berechnen; dessen Zeile, Fortschrittsabschnitt, Kreisdiagramm in
docs/project-status.mdaktualisieren. Status-Sync schreibt niemals Changelog – nur Ereignisse, die durch die Changelog-Hartregel benannt sind (Dokumentstil), geschrieben von der Route, die den Meilenstein erzeugt hat - Abweichung (gespeichert ≠ abgeleitet) im Handoff melden
Deterministisch und idempotent
Sub-Agenten
Definitionen in subagents/ – eine Datei pro Agent (Format: subagents/README.md). Aufruf: Datei lesen → genau die aufgeführten Eingaben zusammenstellen (Reviewer erhalten immer Product Spirit) → mit Dateiinhalt als System-Prompt spawnen
Wirtschaftlichkeitsprofil
Subagent economy: aus dem Abschnitt Tooling der Repository-Anweisungsdatei lesen (do/init schreibt ihn). Fehlt → balanced
| Profil | Verhalten |
|---|---|
strict | Inline-first hart · Scout fast immer inline · Frage/Tool/Rückgabe-Limits durchgesetzt · Kritiker werden trotzdem gespawnt |
balanced | Inline-first wie unten beschrieben · Limits durchgesetzt · weiche Warnung bei >5 Scout-Fragen |
quality | Kostengrenze nur beratend · Limits gelten weiterhin für Scout-Tool-Nutzung und Rückgabegröße |
Vor jedem Spawn (inline-first)
In Reihenfolge ausführen – erster Treffer gewinnt → nicht spawnen:
- Fakten bereits im Hauptkontext → inline arbeiten
- Vom Haupt in ≤5 Grep/Glob/Read (oder LSP)-Aufrufen beantwortbar → inline (Scout-Lite-Checkliste in
subagents/repo-scout.mdverwenden) - Briefing würde die Größe der erwarteten Antwort erreichen → inline
- Ergebnisse wahrscheinlich kosmetisch/mechanische Checkliste auf kleiner Oberfläche → inline (wie heute Kostengrenze)
- Sonst spawnen
repo-scout extra (unter strict / balanced): nur spawnen, wenn ≥3 falsifizierbare Fragen und Suche über ≥2 Bereiche, die der Haupt nicht geöffnet hat, oder Hauptkontext bereits überladen und Isolation eindeutig günstiger. Sonst Scout-Lite inline
Beim Spawnen:
- Tooling-Injektion: Briefing enthält einzeiligen Tooling-Block aus der Repo-Anweisungsdatei (CLI-Filter-Präfix, LSP-Präferenz, Wirtschaftlichkeitsprofil) – Sub-Agent muss ihn befolgen
- Präzises Briefing: Exakte Fragen/Prüfungen · Standards, gegen die gearbeitet wird · Ausgeschlossenes · für Scout: Startpfade/Globs, wenn Bereich bekannt · ≤5 Fragen pro Scout-Welle (
balanced/strict; Rest aufteilen oder inline) - Die Latte vorne legen: Vor Entwurf die Review-Fragen des Kritikers lesen; Entwurf so gestalten, dass er beim ersten Mal besteht
- Rückgabegrenze: Scout ≤15 Zeilen · Kritiker ≤25 Zeilen · Haupt behält nur benötigte Fakten – niemals Scout-Dumps in Docs einfügen
Kritiker-Ergebnisse: anwenden, wenn sie Verhalten, Vertrag oder menschliche Entscheidung ändern; sinnlose/kosmetische Ergebnisse stillschweigend verwerfen. Abgelehnte Ermessensentscheidung → Entscheidungsfrage an den Menschen. Konvergenz: ein Lauf pro Dokument; höchstens ein Wiederholungslauf nach substanzieller Überarbeitung blockierender Ergebnisse, auf diese beschränkt – Wiederholungslauf akzeptiert nur blockierende; niemals dritter Lauf. Niemals Austausch berichten (Invariante 16)
| Sub-Agent | Art | Aufgerufen von | Wann |
|---|---|---|---|
repo-scout | Recherche | plan/epic-arch, plan/feat, plan/feat-arch, plan/change | Planung muss im bestehenden Code fundieren |
prd-critic | Reviewer | plan/epic, plan/feat | immer |
arch-critic | Reviewer | plan/epic-arch, plan/feat-arch | immer |
perf-critic-backend / -frontend | Reviewer | Architektur-Routen, Verifikations-Gates | nur wenn Auslösekriterien (oben in ihren Dateien) zutreffen |
task-checker | Reviewer | plan/tasks | nach Selbst-Review; maximal zwei Läufe |
feature-coder | Ausführer | do/all-tasks | einer pro parallelisierbarer Aufgabe pro Welle |
ui-consistency-reviewer | Reviewer | Verifikations-Gates | UI-Features, nicht-triviale Oberfläche |
doc-coherence-reviewer | Reviewer | Verifikations-Gates · plan/change · plan/migrate | Epic-Abschluss · nach Änderung · nach Migration |
Verifikations-Gates (+ ihre Sub-Agenten) laufen in do/verify oder inline als letzte Phase von do/all-tasks
Menschliches Review-UI
Schlussfolgerungen, nicht Prozess. Mechanische Prüfungen automatisch verifiziert → eine Zusammenfassungszeile. „Entscheidungen, die Ihre Validierung erfordern“: ≤10 klare Satzaussagen + offene Fragen, gekennzeichnet als blockierend/wichtig/nebensächlich. Validierte Entscheidungen → docs/decisions.md. Stakeholder-Antworten wörtlich – niemals paraphrasieren, niemals erneut fragen (bei Mehrdeutigkeit nur Klarstellung erfragen)
Arbeitssparende Wirtschaftlichkeit (Invariante 17)
Eingabe-Wirtschaftlichkeit
- LSP/semantische Navigation bevorzugt gegenüber Datei-Lesen; eingeschränkte Zeilenbereiche
- Grep/Glob/LSP gegenüber Shell für Codesuche bevorzugen – Shell nur wenn nötig
- Lange CLI-Ausgaben (Tests, Builds, Git, Paketmanager) durch reposweit deklarierten Filter (z. B.
rtk,snip) –do/initrichtet ein; wenn Shell ohne aktiven Hook verwendet, manuell vorschalten - Nie erneut lesen, was im Kontext ist; nie Dokument „zur Sicherheit“ laden
- Wirtschaftlichkeitsprofil + inline-first vor Spawnen einhalten (Sub-Agenten)
Ausgabestil (Haupt und Sub-Agenten)
- Caveman-knapp (gleiche Latte wie agentengerichtete Docs): keine Einleitung, kein Wiederholen der Anfrage, keine abschließende Zusammenfassung, kein Füllmaterial/Abwägen
- Code, Befehle, Pfade, Fehler: bytegenau – niemals paraphrasieren
- Code-Änderungen als Diffs oder gezielte Edits – niemals vollständige Dateilistings, außer auf Anfrage
- Recherche-Antworten ≤10 Zeilen, außer wenn Tiefe angefordert; Sub-Agenten-Rückgaben befolgen Rückgabegrenze
- Handoff (Invariante 13) = nur abschließender Block: ≤5 Zeilen
Minimale Implementierung (do-Routen und feature-coder)
Vollständig verstehen, bei erster haltender Stufe abbrechen:
- Muss nicht existieren → überspringen (YAGNI)
- Bereits in Codebasis → wiederverwenden
- Stdlib macht es → verwenden
- Native Plattformfunktion → verwenden
- Installierte Abhängigkeit → verwenden
- Eine Zeile reicht → eine Zeile
- Erst dann das Minimum schreiben, das funktioniert
Niemals kürzen: Vertrauensgrenzen-Validierung, Datenverlust-Handling, Sicherheit, Barrierefreiheit
Dokumentstil
Zwei Zielgruppen – nach Dateizweck auswählen, nicht nach Routing-Stimmung
Mensch / Business (vollständige Prosa) – PRDs (epic-prd.md, feat-prd.md), docs/product.md, Product Spirit, menschliche Review-Bodies (*-review.md-Entscheidungsabschnitte), benutzerzentrierte Docs (developer-setup, Onboarding, menschliche READMEs). Vollständige Sätze. Stakeholder-lesbar. Keine unerklärten Abkürzungen
Agentengerichtet (caveman-knapp) – Skill-Playbooks (SKILL.md, routes/, subagents/, Vorlagenkommentare), feat-tasks.md, epic-arch.md / feat-arch.md, Statustabellen/-notizen, lebendige technische Docs (data-model.md, ui-map.md, decisions.md), docs/patterns/*. Inspiriert von caveman vollständig:
- Nur Fakten und Anweisungen – Artikel/Füllmaterial/Abwägen weglassen, wenn Bedeutung klar; Fragmente OK
- Kurze Synonyme; Muster
[Sache] [Aktion] [Grund]·[nächster Schritt] - Keine erfundenen Abkürzungen (
cfg/impl/fn); bekannte technische Akronyme OK (DB/API/HTTP) - Pfade, Symbole, Code, Befehle, Fehlerstrings: exakt
- Niemals
nicht/nie/kein/nur/außerweglassen - Kein abschließender Punkt vor Zeilenumbruch (Zwischenpunkte in mehrsatzigen Zeilen bleiben)
- Nur Entscheidungen und Fakten – niemals Prozess („Reviewer schlug vor…“, „nach Diskussion…“)
- Nur begründen, wenn zukünftiger Agent das Warum benötigt (Trade-off, Scope-Kürzung): ≤2 kurze Zeilen
- Automatische Klarheit: ausführlichere Prosa für Sicherheitswarnungen, irreversible Schritte oder Fragmente, die Gefahr der Fehlinterpretation von Reihenfolge/Verneinung bergen – dann wieder knapp
Changelog-Hartregel: eine Zeile {Datum}: {Fakt}, ≤25 Wörter. Berechtigt nur – Projekt: Epic abgeschlossen, größere Scope-Änderung, Migration; Epic: Feature verifiziert 🟢, Scope-Änderung. Alles andere (Aufgaben generiert, PRD entworfen/genehmigt, Wellen, Syncs, Abweichungsreparaturen) = kein Eintrag. Niemals: Kritiker-Austausche (Invariante 16), Aufgabenlisten, Gate-Ergebnisse, Fortschrittszahlen, Next:-Befehle. Wortreiche vorhandene Einträge = Legacy, niemals Präzedenzfall – nur berechtigte Zeile schreiben oder nichts
Dateiorganisation
docs/
├── product.md (Eingabe: Produktvision)
├── global_architecture.md (Eingabe: Architekturübersicht)
├── technical-stack.md (Eingabe: Technologieentscheidungen)
├── project-status.md (Eigentümer: Product Spirit, Epic-Stati, Fortschritt)
├── project-review.md
├── decisions.md (lebendig: bindende Benutzerentscheidungen, eine Zeile pro)
├── data-model.md (lebendig: globales Datenschema, falls vorhanden)
├── ui-map.md (lebendig: globale Navigationskarte, falls UI)
├── design-guidelines.md (lebendig: UI-Stilkonventionen, falls UI)
├── patterns/{pattern-name}.md (von do/memorize)
└── epics/e{n}-{epic-name}/ (Slug z. B. e2-orm-discovery)
├── epic-brief.md (plan/proj)
├── epic-prd.md (plan/epic)
├── epic-status.md (Eigentümer: Feature-Stati)
├── epic-arch.md (plan/epic-arch)
├── epic-review.md (plan/epic-review)
└── f{n}-{feat-name}/ (direktes Kind – keine features/-Ebene)
├── feat-prd.md (plan/feat; hat Einstiegspunkte + Architektur-Delta)
├── feat-arch.md (plan/feat-arch – nur Ausnahmen)
├── feat-tasks.md (Eigentümer: Aufgaben-Stati)
└── feat-review.md (plan/feat-review)
Plattformintegration
Repo-Konventionen, Priorität: CLAUDE.md · AGENTS.md · .github/copilot-instructions.md · .cursor/rules/ · .github/instructions/. do/memorize schreibt in die/das tatsächlich vorhandene(n) Datei(en) zurück
Vorlagen
In templates/ – Namen spiegeln Ausgabedateien wider