Communitygithub.com

jeffreyehogg/agent-skills

Durchsetzt einen spezifikationsgesteuerten Entwicklungsablauf (SPEC.md-Gating-Protokoll). Aktiviert beim Entwurf oder der Implementierung komplexer dateiübergreifender Funktionen (3+ Dateien), neuer API-Endpunkte, Datenbankschema-Migrationen oder architektonischer Änderungen. Nicht auslösen bei einzelnen Dateiänderungen, isolierten Fehlerbehebungen, test-only Ergänzungen oder wenn bereits eine genehmigte Spezifikation existiert.

Was ist agent-skills?

Diese Fertigkeit (Skill) implementiert ein **Plan-vor-Code-Gating-Protokoll**, das KI-Agenten (wie Claude Code, Cursor, Codex) dazu zwingt, vor der Implementierung komplexer, dateiübergreifender Änderungen eine formale Spezifikation zu erstellen. Es verhindert typische Fehler wie Kontextverlust, erfundene APIs und ineffiziente Trial-and-Error-Schleifen, indem es Code-Änderungen blockiert, bis ein SPEC.md-Dokument erstellt, gegen Repository-Restriktionen verifiziert und genehmigt wurde. Der Skill ist ideal für Agenten und Entwickler, die strukturiert und nachvollziehbar neue Features, API-Endpunkte oder Schema-Migrationen umsetzen möchten. Er ist plattformunabhängig in jedem KI-gesteuerten Entwicklungstool einsetzbar. Der Workflow umfasst fünf Phasen: Kontextanalyse, Erstellung der Spezifikation mit festgelegten Datenverträgen und Änderungsmatrix, einen obligatorischen Genehmigungsstopp (in interaktiven Sitzungen), die phasenweise Ausführung mit optionaler Sandbox-Isolation und einem Notfallprotokoll für Änderungen während des Flugs sowie abschließende Verifikation und Archivierung. Unterstützt werden sowohl interaktive Benutzersitzungen mit Genehmigungsschleife als auch autonome Subagenten, die von einem übergeordneten Orchestrator gesteuert werden. Artefakte wie eine Vorlage (`spec_template.md`) und das `git-worktree-isolator`-Skill ergänzen die Infrastruktur.

Funktioniert mit✓Claude Code~Codex CLI~Cursor
npx skills add https://github.com/jeffreyehogg/agent-skills/tree/HEAD/spec-driven-feature

In Ihrer bevorzugten KI fragen

Öffnet einen neuen Chat, in dem dieser Agent-Skill bereits geladen ist.

Dokumentation

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:

  1. Identifiziere bestehende Konventionen, Datenmodelle und API-Dienstprogramme im Projekt.
  2. Finde Typdefinitionen oder Schemadateien (z.B. schema.prisma, drizzle/schema.ts, Zod-Schemas, OpenAPI-Spezifikationen).
  3. 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:

  1. Ziel, Erfolgskriterien & explizite Nicht-Ziele: Klare 2-Satz-Problemerklärung, deterministische Bestehenskriterien und explizite Grenzen des Umfangs.
  2. Datenverträge & Signaturen: Exakte TypeScript-Schnittstellen, Datenbankspalten-Typen oder API-Schemas.
  3. Dateiänderungs-Matrix: Explizite Create-, Modify- (mit Zielfunktionen/-zeilen) und Forbidden-Pfade.
  4. Implementierungs-Checkliste & Verifikationsprotokoll: Exakte Testbefehle, Linter-Prüfungen und Randfälle.

3. Phase 3: Der Gating-Checkpoint (VERPFLICHTEND)

Sobald die Spezifikation erstellt wurde:

  1. 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.md entworfen. Bitte überprüfe die vorgeschlagenen Datenverträge und die Dateiänderungs-Matrix. Soll ich mit der Implementierung fortfahren?"

  2. 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 mit Forbidden-Pfaden aufweist, und fahre mit Phase 4 fort.
  3. 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:

  1. 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-isolator bereit, bevor Dateien geändert werden.
  2. Implementiere das Feature in diskreten, atomaren Meilensteinen (z.B. Schema $\to$ Kernlogik $\to$ API-Handler $\to$ UI/Integration).
  3. Markiere Fortschrittskontrollkästchen in der Spezifikationsdatei, während Meilensteine abgeschlossen werden.
  4. 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):

  1. Stoppe Änderungen sofort am betroffenen Meilenstein.
  2. 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.
  3. 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

  1. Führe die in Phase 2 festgelegte deterministische Testsuite aus.
  2. Stelle sicher, dass alle Typprüfungen und Linter sauber durchlaufen.
  3. Aktualisiere den Spezifikationsstatus auf Completed und archiviere sie unter .specs/completed/YYYY-MM-DD-<feature-name>.md (oder entferne temporäre Spezifikationsdateien, wenn das Repository .specs/ nicht verfolgt).

Individual skills in this repo

This repo contains 1 individual skill — each has its own dedicated page.

Verwandte Skills