Spezifikationsgesteuerte Feature-Entwicklung
Überblick
Diese Fertigkeit erzwingt ein Plan-vor-Code-Gating-Protokoll. Autonome Codierungsagenten scheitern oft daran, direkt in Dateiänderungen zu springen, was zu Kontextverlust, halluzinierten APIs und verschwendeten Tokens bei Trial-and-Error-Debugging führt.
Wenn diese Fertigkeit aktiviert ist, darf kein Anwendungscode geändert werden, bis eine formale Spezifikation (SPEC.md oder .specs/<feature-slug>.md) erstellt, gegen Repository-Restriktionen verifiziert und genehmigt wurde.
1. Phase 1: Kontext- & Einschränkungserkundung
Vor dem Erstellen der Spezifikation:
- Identifiziere bestehende Konventionen, Datenmodelle und API-Dienstprogramme im Projekt.
- Finde Typdefinitionen oder Schemadateien (z.B.
schema.prisma,drizzle/schema.ts, Zod-Schemas, OpenAPI-Spezifikationen). - Lies nicht ganze Dateien, sofern nicht nötig; inspiziere Exporte, Schnittstellenheader und Typen.
2. Phase 2: Entwurf von SPEC.md
Lies ./references/spec_template.md und erstelle .specs/<feature-slug>.md (oder SPEC.md im Repository-Stammverzeichnis, falls gewünscht) nach dieser exakten Struktur:
- Ziel, Erfolgskriterien & explizite Nicht-Ziele: Klare 2-Satz-Problemerklärung, deterministische Bestehenskriterien und explizite Grenzen des Umfangs.
- Datenverträge & Signaturen: Exakte TypeScript-Schnittstellen, Datenbankspalten-Typen oder API-Schemas.
- Dateiänderungs-Matrix: Explizite
Create-,Modify- (mit Zielfunktionen/-zeilen) undForbidden-Pfade. - Implementierungs-Checkliste & Verifikationsprotokoll: Exakte Testbefehle, Linter-Prüfungen und Randfälle.
3. Phase 3: Der Gating-Checkpoint (VERPFLICHTEND)
Sobald die Spezifikation erstellt wurde:
- Interaktiver Modus (Benutzersitzung): Präsentiere eine kurze Zusammenfassung mit Link zur Spezifikationsdatei, zeige etwaige architektonische Kompromisse auf (verwende
ask_question, falls mehrere gültige Ansätze existieren) und bitte vor dem Schreiben von Code um Bestätigung:"Ich habe die Spezifikation in
SPEC.mdentworfen. Bitte überprüfe die vorgeschlagenen Datenverträge und die Dateiänderungs-Matrix. Soll ich mit der Implementierung fortfahren?" - Autonomer Subagenten-Modus: Wenn von einem übergeordneten Lead-Orchestrator (z.B. von
code-audit-orchestrator) aufgerufen, der bereits einen genehmigten Sanierungsplan bereitgestellt hat, überprüfe, ob die Dateiänderungsmatrix keine Konflikte mitForbidden-Pfaden aufweist, und fahre mit Phase 4 fort. - HARD STOP: Warte in interaktiven Sitzungen auf Genehmigung oder Feedback. Berühre keine Quelldateien, bis grünes Licht gegeben wird.
4. Phase 4: Phasenweise Ausführung & Änderungsprotokoll während des Flugs
Nach Genehmigung:
- Optionale Sandbox-Isolation: Stelle bei dateiübergreifenden Änderungen oder wenn der primäre Arbeitsbaum unzusammenhängende Änderungen enthält, einen isolierten Arbeitsbaum über
git-worktree-isolatorbereit, bevor Dateien geändert werden. - Implementiere das Feature in diskreten, atomaren Meilensteinen (z.B. Schema $\to$ Kernlogik $\to$ API-Handler $\to$ UI/Integration).
- Markiere Fortschrittskontrollkästchen in der Spezifikationsdatei, während Meilensteine abgeschlossen werden.
- Halte Git-Commits auf einzelne Meilensteine beschränkt.
Notausstieg: Spezifikationsänderung während des Flugs
Falls die Implementierung eine unvorhergesehene Einschränkung aufdeckt (z.B. eine Forbidden-Datei muss geändert werden, ein upstream SDK-Typ passt nicht zum entworfenen Vertrag, oder der Benutzer ändert Anforderungen während des Flugs):
- Stoppe Änderungen sofort am betroffenen Meilenstein.
- Füge einen Eintrag in
## 6. Spezifikationsänderungen (Delta-Protokoll)in der Spezifikationsdatei hinzu, der Folgendes dokumentiert:- Auslöser / Blocker: Warum der ursprüngliche Vertrag nicht halten kann.
- Geänderter Abschnitt & Delta: Exakte Änderungen an Datenverträgen oder der Dateiänderungs-Matrix.
- Wenn das Delta eine zuvor
Forbidden-Datei betrifft oder einen öffentlichen API-/Schema-Vertrag ändert, pausiere und bitte um schnelle Benutzerbestätigung, bevor du fortfährst. Wenn das Delta rein intern ist (z.B. Extrahieren einer internen Hilfsdatei), protokolliere das Delta in der Spezifikation und fahre fort.
5. Phase 5: Verifikation & Archivierung
- Führe die in Phase 2 festgelegte deterministische Testsuite aus.
- Stelle sicher, dass alle Typprüfungen und Linter sauber durchlaufen.
- Aktualisiere den Spezifikationsstatus auf
Completedund archiviere sie unter.specs/completed/YYYY-MM-DD-<feature-name>.md(oder entferne temporäre Spezifikationsdateien, wenn das Repository.specs/nicht verfolgt).