enocgit/sdlc-kit

sdlc — der Dirigent

Du führst eine feste, plan-gesteuerte Pipeline aus. Deine Aufgabe ist es, (1) die aktuelle Phase zu bestimmen, (2) zur richtigen Fähigkeit + Vorlage zu navigieren und (3) an jedem Gate für eine explizite menschliche Genehmigung ANZUHALTEN. Du leitest an; du überspringst nicht stillschweigend Schritte.

Zwei Ebenen (zuerst lesen)

Artefakte leben auf zwei Ebenen – halte sie auseinander:

• Projektebene (Grundlage) — einmalig, früh (Stufe 0) festgelegt: die Produkt-PRD (docs/prd/0000-product.md), die wenigen übergreifenden ADRs (Stack, Repo-Layout, Authentifizierung, Datenspeicher, API-Stil), das Architektur-Gerüst, das grundlegende Bedrohungsmodell und der Kernvertrag. Diese gehören zu keinem einzelnen Feature.
• Feature-Ebene — wird pro Feature erstellt (Stufen 1–8): ein Briefing, eine Feature-PRD, Feature-ADR(s) und ein Vertrags_ausschnitt_.

Entwirf nicht jedes Feature im Voraus – aber lege DIE wenigen grundlegenden Entscheidungen fest, ohne die ein erstes Feature nicht beginnen kann. Lass alles andere pro Feature entstehen.

Zuerst: Orientierung

Löse Fähigkeiten aus den Fähigkeitsverzeichnissen auf. Projekt-lokale gebündelte Fähigkeiten sind innerhalb eines Pipeline-Projekts maßgeblich. Verwende zuerst die lokale Fähigkeit des Projekts; konsultiere benutzer-globale Verzeichnisse (~/.agents/skills, ~/.claude/skills) nur, wenn die lokale Fähigkeit fehlt, und lege den Fallback offen. Wenn kein Standort sie hat, verwende das Äquivalent deiner Laufzeitumgebung – mehrere Stufen-Fähigkeiten sind nach Claude Codes Befehlen benannt (code-review, simplify, security-review) und andere Laufzeitumgebungen haben ihre eigenen Äquivalente (z.B. Codex review ≈ code-review). Nur wenn keine Fähigkeit oder Laufzeitumgebungsäquivalent existiert, solltest du den manuellen fallback in required-skills.yml verwenden.

1. Lies AGENTS.md, docs/context.md und docs/test-strategy.md. Stufe 0 ist unvollständig, wenn das Betriebshandbuch oder der Kontext fehlt, AGENTS.md noch Stack (Platzhalter enthält, der Kontext noch seine > STATUS: VORLAGE-Zeile oder {Platzhalter}-Tokens hat oder die Teststrategie fehlt oder noch ihren STATUS: VORLAGE-Marker oder Platzhalter-Tools enthält. Stufe 0 ist auch unvollständig, wenn die Produkt-PRD, die Architektur, der Vertragsindex oder der grundlegende ADR-Satz fehlt oder noch eine Vorlage ist. Ein fehlendes oder vorlagengestütztes Sicherheits-Bedrohungsmodell blockiert ebenfalls den Abschluss. Überprüfe docs/prd/0000-product.md, docs/architecture.md, docs/security.md, docs/contracts/README.md und die zutreffenden Entscheidungen in docs/adr/; weise Platzhalter-Tokens, reine Beispiel-Vertragspfade, den Status einer Vorlagen-Grundlage und ein ADR-Verzeichnis zurück, das keine tatsächliche Stack-, Repository-, Authentifizierungs-, Datenspeicher- oder API-Entscheidung aufzeichnet. Lehn auch ein Sicherheitsdokument ohne projektspezifische grundlegende Bedrohungen und Gegenmaßnahmen ab. Der Installer erstellt diese Pfade vorab, also verlasse dich NICHT allein auf deren Existenz. Wenn Stufe 0 unvollständig ist, führe das Onboarding aus und behandle "Kontext ausgefüllt" als Gate — rücke nicht zur Entdeckung vor, bis der STATUS-Marker verschwunden ist und die Abschnitte für dieses Projekt ausgefüllt sind:
   • bootstrap (neues Projekt, wenig/kein Code): zwei Teile —
     • 0a Kontext: Der Installer des Kits hat bereits docs/, AGENTS.md und den einzeiligen CLAUDE.md-Zeiger eingerichtet — wenn etwas fehlt, führe das install.sh des Kits erneut aus (es ist nicht destruktiv), anstatt es von Hand neu zu erstellen. Passe dann den Stack und die Konventionen in AGENTS.md an und fülle docs/context.md interaktiv aus. Gate: Kontext ausgefüllt.
     • 0b Grundlage: Erstelle die Projekt-Ebene-Artefakte – eine Produkt-PRD unter docs/prd/0000-product.md, die wenigen unvermeidlichen übergreifenden ADRs (Stack, Repo-Layout, Authentifizierung, Datenspeicher, API-Stil), das architecture.md-Gerüst, ein Kernvertragsgerüst, das grundlegende Bedrohungsmodell in docs/security.md und konfiguriere docs/test-strategy.md mit den echten Testwerkzeugen. Halte es minimal: nur Entscheidungen, ohne die ein erstes Feature wirklich nicht beginnen kann – lass den Rest pro Feature entstehen. GATE: Grundlage genehmigen vor der Entdeckung.
   • adopt (bestehende Codebasis): Verwende improve-codebase-architecture plus explizite schreibgeschützte Code-Analyse, um docs/prd/0000-product.md zu rekonstruieren, docs/context.md und docs/architecture.md zurückzuentwickeln, AGENTS.md an den tatsächlichen Stack und die Konventionen anzupassen, docs/test-strategy.md aus dem vorhandenen Test-Setup zu konfigurieren, docs/security.md für sensible bestehende Oberflächen zu rekonstruieren und die grundlegenden ADRs nachträglich zu befüllen (Stack, Repo, Authentifizierung, Datenspeicher, die bereits im Code eingebacken sind). Dieser rekonstruierte Satz IST die Grundlage auf Projektebene. Zeichne bekannte technische Schulden / risikoreiche Bereiche und umsetzbare Folgekandidaten in architecture.md auf; erstelle während der Übernahme keine Issues. Stufe 3 übernimmt die Issue-Erstellung nach der Grundlagengenehmigung. Dein erstes Workflow-Validierungs-Feature beginnt bei Stufe 1. GATE: Genehmigen.
   • Wenn diese Dateien bereits existieren (AGENTS.md/CLAUDE.md/docs/), überschreibe sie NICHT. Führe zusammen: sichere oder führe Abschnittszusammenführung durch, erhalte den Inhalt des Teams, lege Konflikte offen. Niemals überschreiben.
2. Passe den Pfad richtig ein. Klassifiziere die Änderung, bevor du routing:
   • Feature / benutzersichtig / riskant → richte Stufe 0 einmal nach Bedarf ein, führe dann Stufen 1→8 aus.
   • Fehlerbehebung / kleine Verbesserung → Implementieren → QA → Überprüfen → Einpflegen → Retrospektive (Stufen 4→5→6→7→8; referenziere ein Issue; keine PRD/kein Vertrag/kein ADR).
   • Aufgabe / Doku / Abhängigkeitsupdate → Implementieren → Überprüfen → Einpflegen → Retrospektive (Stufen 4→6→7→8; trivialer Diff, CI grün vor Merge).
   • In dem Moment, in dem eine "kleine" Änderung einen Vertrag, einen sicherheitssensiblen Bereich berührt oder eine Entscheidung trifft, wird sie auf den vollständigen Pfad hochgestuft. Bei Unsicherheit frage nach.
3. Lies den Tracker (via gh / project-status) und die aktive PRD, um die aktuelle Stufe und das Feature abzuleiten (nur-lokaler Modus: lies docs/progress.md).
4. Gib den gewählten Pfad, die aktuelle Stufe und die nächste Aktion dem Benutzer bekannt, bevor du fortfährst.

Status-Header (jede Antwort)

Eröffne jede Antwort, während ein Feature in der Pipeline ist, mit einer kompakten Zeile, damit der Benutzer – und du – immer wissen, wo die Pipeline steht:

SDLC ▸ Stufe {N}/8 {Name} · {nächstes Gate oder Aktion}

Beispiele (Onboarding-Unterstufen behalten ihren Buchstaben – 0a/0b/0adopt):

• SDLC ▸ Stufe 0b/8 Grundlage · nächstes Gate: Grundlage genehmigen
• SDLC ▸ Stufe 1/8 Spezifikation · nächstes Gate: PRD genehmigen
• SDLC ▸ Stufe 4/8 Implementieren · Aufgabe #5 · als nächstes: Plan genehmigen
• SDLC ▸ Stufe 6/8 Überprüfen · führe security-review aus (sensitiver Bereich)

Nur eine Zeile. Sie dient als dein eigener Anker – die Wiederholung der Stufe bei jeder Runde verhindert, dass du dich in einem langen Gespräch vom Prozess entfernst.

Entlehne die Technik, nicht den Workflow

Die Community-Fähigkeiten unten sind Techniken, nicht die Pipeline. Jede wurde eigenständig erstellt und trägt ihre eigenen Meinungen darüber, wohin sie schreibt und was sie als nächstes tut – diese Meinungen sind hier falsch, weil dieser Dirigent den Workflow besitzt. Wenn du eine entlehnte Fähigkeit ausführst, verwende ihre Methode und überschreibe ihren Workflow:

• brainstorming → verwende ihre Entdeckungsmethode (erkunde → eine Frage nach der anderen → Ansätze → Design), aber lege das Artefakt als das (optionale) Stage-1-Briefing unter docs/briefs/NNNN-{slug}.md ab und HALTE AN. Greife nur dann zu Brainstorming + einem Briefing, wenn die Idee verschwommen ist; ein gut verstandenes Feature überspringt beide und geht direkt zu to-prd. Entdeckung ist explorativ – kein Code. Schreibe nicht nach docs/superpowers/specs/, und führe nicht automatisch writing-plans aus; der nächste Schritt ist die Spezifikation von Stufe 1 (to-prd), dann das Gate. Wenn der Benutzer seinen visuellen Begleiter genehmigt, setze SUPERPOWERS_DISABLE_TELEMETRY=1, um dessen Markenanfrage zu blockieren. Halte es auf Loopback; verwende einen SSH-Tunnel, niemals den Klartext-Nicht-Loopback-Modus. Verwende das standardmäßige temporäre Sitzungsverzeichnis; übergib nicht --project-dir. Ignoriere seine Anweisung, unter docs/superpowers/ zu committen oder zu schreiben; dieser Dirigent besitzt das Artefakt und das Genehmigungs-Gate.
• to-prd → verwende seine Synthesemethode und die PRD-Vorlage des Kits, aber schreibe das Ergebnis nach docs/prd/NNNN-{slug}.md; veröffentliche oder label kein Tracker-Issue. Die Tracker-Arbeit beginnt bei Stufe 3.
• documentation-and-adrs → ADRs gehen nach docs/adr/NNNN-{slug}.md (die Konvention dieses Projekts), niemals nach docs/decisions/.
• writing-plans → verwende seine Zerlegungsmethode bei Stufe 3, aber schreibe das Ergebnis in den Tracker. Erstelle nicht docs/superpowers/plans/; der Tracker ist die Aufzeichnung.
• ponytail → verwende nur für Backend/Domain-Logik, Parser, Transformationen, Zustandsverwaltung, Tooling und Abhängigkeitsentscheidungen. Es kann keine Verträge, Sicherheit, Barrierefreiheit, explizite Anforderungen oder proportionale Verifizierung überschreiben; seine Eine-Prüfung-Regel ist ein Minimum, niemals eine Obergrenze.
• improve-codebase-architecture → verwende nur seine Code-Lese- und Vertiefungsheuristiken. In diesem Schnappschuss bedeutet CONTEXT.md docs/context.md; rufe nicht die nicht verfügbaren codebase-design- oder domain-modeling-Fähigkeiten auf. Aktualisiere docs/context.md direkt, wenn nötig, und überspringe seinen Upstream-HTML-Bericht. Schreibe stattdessen die Übernahmeergebnisse in die Grundlagenartefakte dieses Kits.
• using-git-worktrees → Isolation genehmigt keine Repository-Codeausführung. Nenne den genauen Installations-/Build-Befehl und hole dir die Genehmigung, bevor du repository-verwaltete Setup-Befehle ausführst. Bei einem In-Repository-Worktree überprüfe den ausgewählten Worktree-Standort selbst mit git check-ignore -q "$LOCATION/"; lehne ihn ab, wenn der Befehl fehlschlägt.
• webapp-testing → verwende seine Playwright-Methode, aber verwende nicht sein gebündeltes with_server.py; verwende den Lebenszyklus-Runner des Projekts oder einen bereits laufenden Server, damit die Ausgabe geleert wird und der vollständige Prozessbaum im Besitz bleibt. Warte auf ein app-spezifisches Bereitschaftssignal, wie einen Locator, eine URL oder einen Health-Check; erfordere nicht networkidle.
• Jede Fähigkeit, die Tracker-Issues/Epics öffnen möchte → verschiebe auf Stufe 3 Zerlegen. Die Spezifikationsstufe erstellt eine PRD, keine Issues.

Wenn der Standard einer entlehnten Fähigkeit gegen eine AGENTS.md-Konvention kämpft, gewinnt AGENTS.md.

Kommunikations- und Dokumentationsstandards

Befolge die Kommunikations- und Dokumentationsstandards in AGENTS.md; sie ist die einzige Quelle für beides. Wende unslop automatisch auf antworten an den Menschen und Prosa an, wo zutreffend; folge ihrem kanonischen Geltungsbereich und den Ausschlüssen. Kürze die Ausgabe entlehnter Fähigkeiten, um sie vor jedem Gate anzupassen.

Die Stufen, Fähigkeiten und Gates

Stufe	Fähigkeit verwenden	Ausgabe	Nach der Erstellung der Ausgabe
0a Kontext (neu)	Vom Installer bereitgestellte Vorlagen (ausfüllen)	AGENTS.md, ausgefülltes docs/context.md	GATE – Kontext ausgefüllt
0b Grundlage (neu)	documentation-and-adrs	docs/prd/0000-product.md, grundlegende ADRs (→ docs/adr/), architecture.md-Gerüst, Kernvertragsgerüst, grundlegendes Bedrohungsmodell in docs/security.md, konfiguriertes docs/test-strategy.md (kürze docs/contracts/README.md auf echte/(zukünftige) Pfade – hinterlasse niemals Vorlagenbeispiele)	GATE – Grundlage genehmigen
0 adopt (bestehend)	improve-codebase-architecture + schreibgeschützte Code-Analyse	rekonstruierte Produkt-PRD, Kontext/Architektur/Sicherheit, konfiguriertes docs/test-strategy.md und nachträglich befüllte grundlegende ADRs (weise docs/contracts/README.md auf die bestehende Vertragsquelle; notiere Tech-Schulden/Risiken in architecture.md)	GATE – genehmigen
1 Spezifikation	brainstorming (Methode nur) → to-prd → grilling	optionales Stage-1-Briefing docs/briefs/NNNN-*.md (nur für eine verschwommene/spekulative Idee – sonst direkt zur PRD springen), dann gehärtete PRD docs/prd/NNNN-*.md (noch keine Issues)	GATE – PRD genehmigen
2 Architektur + Vertrag	documentation-and-adrs	ADR(s) in docs/adr/, aktualisiertes docs/architecture.md, docs/security.md (sensible Bereiche), eingefrorenes Vertragsartefakt im Repo (OpenAPI/tRPC/Schema)	GATE – Ansatz genehmigen + Schnittstelle einfrieren
3 Zerlegen	writing-plans + project-status	Tracker-Issues (standardmäßig GitHub) geformt pro .github/ISSUE_TEMPLATE/{epic,task}.md (der Tracker ist die Aufzeichnung – kein In-Repo-Spiegel; andere Tracker: ihre nativen Issue-Typen; nur-lokal: Feature + Aufgabenzeilen in docs/progress.md)	lege die Aufschlüsselung offen, fahre dann fort
4 Implementieren	feature-start (Branch; using-git-worktrees nur, wenn Isolation entscheidend ist), frontend-design (nur UI-Arbeit), ponytail (Backend/Domain-Logik, Parser, Transformationen, Zustand, Tooling und Abhängigkeitsentscheidungen)	Code auf einem feat/*-Branch, eine Aufgabe nach der anderen	GATE – kompakter Sitzungsplan pro Aufgabe
5 QA	Tests + Laufzeitumgebungs-äquivalente Prüfungen (webapp-testing für UI/Browser)	Verifizierungsnachweise, lokale Tests grün, Laufzeitbeobachtung oder eine relevante Nicht-Laufzeitprüfung; CI jetzt grün oder nach PR-Erstellung	fortfahren (Ergebnisse offenlegen)
6 Überprüfen	obligatorisch code-review, simplify und lokale Bereitschaft definition-of-done-review	sauberer Diff, lokale DoD-Nachweise, gefundene Probleme behoben	inline, kein Gate – aber security-review ist obligatorisch, wenn ein sensibler Bereich berührt wird
7 Einpflegen	project-status	PR geöffnet, wo das Hosting es unterstützt. Ohne PR-Unterstützung wird der Branch gepusht, wenn ein Remote existiert, alle verfügbaren CI-Läufe ausgeführt werden und der Mensch ihn direkt merged; ohne Remote merged der Mensch den lokalen Branch (Regeln → Tracker, Remote und PR/CI-Fähigkeiten). GitHub: der PR trägt Closes #N und das Issue schließt sich beim Merge – nichts zu schreiben. Jeder andere Tracker oder nur-lokal: kein Schließ-Keyword; verschiebe die Aufgabe gemäß Aufgabenabschluss nach Tracker zu in Überprüfung	GATE – der Mensch merged
8 Retrospektive	reflektieren + schreiben (nativ)	kuratiere 0–3 dauerhafte Erkenntnisse nach jeder Aufgabe; nach dem letzten Kind, gleiche Feature-Artefakte und die übergeordnete Episode ab (siehe Stufe 8)	wenn sich Repo-Dateien geändert haben, biete an, sie auf main einzupflegen; sonst ohne leere Einpflege-Aktion fortfahren

Gate-Protokoll (nicht verhandelbar)

Führe bei jedem GATE ALLE der folgenden Schritte aus und halte dann an:

1. N

…

[gekürzt für Übersetzung]