wmartinez79/spec-council

spec-council Skill

Sie führen den /spec-council-Skill aus. Führen Sie alle Phasen der Reihe nach durch. Überspringen Sie keine Phasen.

Harte Regeln

• Ändern Sie niemals Quellcode
• Schreiben Sie niemals selbst direkt in .specify/ – das ist die eigene Infrastruktur von GitHub Spec Kit (templates/, scripts/, memory/, feature.json, integration.json). Wenn Spec Kits eigene Skills installiert sind (siehe Phase 0), delegieren Sie an diese und lassen Sie sie den Zustand verwalten; Sie greifen niemals direkt darauf zu.
• Das einzige Verzeichnis, in das Sie selbst schreiben, ist das Feature-Verzeichnis dieses Durchlaufs (<FEATURE_DIR>, aufgelöst in Phase 0/1) – konkret in das Unterverzeichnis council/ immer, und in spec.md/plan.md/tasks.md nur, wenn Spec Kits eigene Skills nicht installiert sind und Sie die Fallback-Vorlagen verwenden.
• Zeigen Sie dem Benutzer die spec.md, bevor Sie zum Plan übergehen, es sei denn, das Flag --auto wurde übergeben.
• Gremiumsagenten laufen sequenziell – niemals parallel.
• Wenn ein Gremiumsagent BLOCK ausgibt, stoppen Sie und machen Sie die Ergebnisse sichtbar, bevor Sie fortfahren.
• Ein behobener BLOCKER muss durch einen erneuten Durchlauf desselben Agenten neu verifiziert werden, bevor Sie fortfahren – vertrauen Sie nicht einfach Ihrer eigenen Änderungsbehauptung. Geben Sie dem Agenten seinen eigenen vorherigen Bericht plus die geänderten Artefakte und lassen Sie ihn die Behebung explizit anhand der Quelle bestätigen, nicht nur den neuen Text lesen.
• Ein behobener CONCERN erfordert keinen vollständigen Agentenneudurchlauf, aber lassen Sie niemals seinen Ursprungsbericht stillschweigend behaupten, das Problem sei noch offen – fügen Sie eine einzeilige Ergänzung an diesen Bericht an, die festhält, was sich geändert hat und dass es nicht unabhängig neu verifiziert wurde. Ein nicht ergänzter Bericht ist ein veralteter Datensatz, dem der nächste Agent (oder ein Mensch) sonst ungeprüft vertrauen würde.

---

Phase 0 – Bootstrap

1. Bestimmen Sie das Projektwurzelverzeichnis (das Verzeichnis, das CLAUDE.md/AGENTS.md enthält, oder das aktuelle Arbeitsverzeichnis).

2. Erkennen Sie, ob GitHub Spec Kit in diesem Projekt installiert ist:

   test -d .specify && echo "SPECKIT_PRESENT" || echo "NO_SPECKIT"
   

   Verwenden Sie nicht which specify – das prüft nur, ob die CLI-Binärdatei zufällig global auf diesem Rechner installiert ist, was nichts darüber aussagt, ob dieses Projekt Spec Kit verwendet.

3. Erkennen Sie, ob Spec Kits eigene agentenbasierte Workflow-Skills installiert sind (unabhängig davon, welcher Agent Sie sind – prüfen Sie beide bekannten Wurzeln, jede zählt):

   test -f .claude/skills/speckit-specify/SKILL.md -o -f .cursor/skills/speckit-specify/SKILL.md && echo "HAS_SPECKIT_SKILLS" || echo "NO_SPECKIT_SKILLS"
   

   Speichern Sie als HAS_SPECKIT_SKILLS (wahr/falsch). Dies sind echte, umfassende Skills (Git-Branch-Hooks, [NEEDS CLARIFICATION]-Handhabung, Qualitätscheck-Validierung) – wenn vorhanden, delegieren die Phasen 1–3 unten vollständig an diese, anstatt etwas davon neu zu implementieren.

4. Holen Sie die Feature-Beschreibung ein:

   • Wenn der Skill mit Argumenten aufgerufen wurde (z.B. /spec-council add password reset), verwenden Sie diese als Beschreibung.
   • Wenn keine Argumente, fragen Sie den Benutzer (über ein strukturiertes Auswahltool wie Claude Codes AskUserQuestion, falls vorhanden, sonst einfacher Chat-Text): „Welches Feature oder welche Änderung soll ich spezifizieren? Beschreiben Sie es in 1–3 Sätzen.“

5. Lesen Sie CLAUDE.md und/oder AGENTS.md (Projektwurzel und verschachtelte wie api/CLAUDE.md, falls vorhanden), um den Projektarchitekturkontext zu laden. Fügen Sie diesen in jeden Generierungs-Prompt ein und übergeben Sie ihn an jeden Gremiumsagenten unten.

<FEATURE_DIR> ist zu diesem Zeitpunkt noch nicht bekannt – es wird während Phase 1 aufgelöst, entweder durch Spec Kits eigenen speckit-specify-Skill oder durch die unten stehende Fallback-Logik.

---

Phase 1 – Spezifikation (spec.md)

Ziel: Erstellen Sie eine Feature-Spezifikation und ermitteln Sie <FEATURE_DIR> für alle Phasen danach.

Wenn HAS_SPECKIT_SKILLS = wahr:

Lesen Sie den vollständigen Inhalt von demjenigen, das existiert – .claude/skills/speckit-specify/SKILL.md oder .cursor/skills/speckit-specify/SKILL.md – und befolgen Sie es wörtlich als Ihre Anweisungen, wobei Sie die Feature-Beschreibung als dessen Eingabe übergeben. Lassen Sie es die Nummerierung, Git-Branch-Hooks, [NEEDS CLARIFICATION]-Aufforderungen und die Qualitätscheck-Validierung vollständig eigenständig handhaben; hinterfragen Sie nichts davon und implementieren Sie nichts davon neu.

Nach Abschluss lesen Sie .specify/feature.json und übernehmen Sie dessen Feld feature_directory als <FEATURE_DIR> (z.B. specs/012-quote-export-print). Dies ist Spec Kits eigener autoritativer Datensatz des aktuellen Features – verwenden Sie ihn, leiten Sie den Pfad nicht selbst neu ab.

Wenn HAS_SPECKIT_SKILLS = falsch:

Lösen Sie <FEATURE_DIR> selbst auf:

1. Wenn specs/ nicht existiert, wird es unten erstellt.
2. Durchsuchen Sie specs/ nach vorhandenen NNN-*-Verzeichnissen, finden Sie die höchste NNN, addieren Sie 1 (nullaufgefüllt auf 3 Stellen). Wenn keines existiert, beginnen Sie bei 001.
3. Machen Sie einen Slug aus der Feature-Beschreibung zu einem kurzen Kebab-Case-Namen (2–4 Wörter, z.B. „PDF/print-friendly rendering of a quote“ → quote-export-print).
4. <FEATURE_DIR> = specs/<NNN>-<slug>
5. mkdir -p <FEATURE_DIR>

Schreiben Sie direkt <FEATURE_DIR>/spec.md. Verwenden Sie die folgende Struktur:

# Spezifikation: <Feature-Name>

## Übersicht
<Was dieses Feature tut und warum es benötigt wird. 2–4 Sätze.>

## Anforderungen
1. <Funktionale Anforderung>
2. ...

## Abnahmekriterien
1. <Überprüfbares Kriterium – „gegeben X, wenn Y, dann Z“-Format bevorzugt>
2. ...

## Technische Einschränkungen
- <Vorhandene Muster, Bibliotheken oder Regeln, die respektiert werden müssen>
- <Architekturgrenzen, die dieses Projekt erzwingt (Isolationsmodell, nur Soft-Delete, etc.), falls vorhanden>

## Nicht im Umfang
- <Explizite Ausschlüsse, um Scope Creep zu verhindern>

Verwenden Sie den Kontext von CLAUDE.md/AGENTS.md des Projekts, um die technischen Einschränkungen genau auszufüllen.

Nachdem die Spezifikation geschrieben wurde (beide Pfade):

Zeigen Sie dem Benutzer <FEATURE_DIR>/spec.md. Fragen Sie (über ein strukturiertes Auswahltool, falls vorhanden, sonst einfacher Chat-Text):

„Spezifikation ist bereit. Zum Plan fortfahren, oder soll ich zuerst Anforderungen klären?“

• Wenn „klären“: Erzeugen Sie einen fork-Agenten mit dem Prompt: „Lesen Sie <FEATURE_DIR>/spec.md. Stellen Sie dem Benutzer bis zu 5 gezielte Klärungsfragen zu Unklarheiten, schreiben Sie sie dann um, indem Sie die Antworten einarbeiten. Ändern Sie nicht die Struktur.“ (Wenn HAS_SPECKIT_SKILLS und ein speckit-clarify-Skill an derselben Wurzel wie speckit-specify existiert, bevorzugen Sie die Delegierung an diesen – er ist genau dafür gebaut.)
• Wenn „fortfahren“: Fahren Sie fort.

---

Phase 2 – Plan (plan.md)

Ziel: Erstellen Sie <FEATURE_DIR>/plan.md

Wenn HAS_SPECKIT_SKILLS = wahr:

Lesen und befolgen Sie .claude/skills/speckit-plan/SKILL.md oder .cursor/skills/speckit-plan/SKILL.md (je nachdem, was existiert) wörtlich. Es löst das aktuelle Feature selbst auf (über .specify/scripts/bash/setup-plan.sh oder Äquivalent) – Sie müssen ihm <FEATURE_DIR> nicht selbst übergeben.

Wenn HAS_SPECKIT_SKILLS = falsch:

Schreiben Sie <FEATURE_DIR>/plan.md unter Verwendung dieser Struktur, informiert durch <FEATURE_DIR>/spec.md und die CLAUDE.md/AGENTS.md des Projekts:

# Plan: <Feature-Name>

## Ansatz
<Architekturentscheidungen. Welche Muster/Ebenen werden verwendet. Warum.>

## Betroffene Dateien/Module
- `path/to/file.ts` – <was sich ändert>
- ...

## Implementierungsschritte
1. <Schritttitel> (Abh.: keine)
   <1–2-zeilige Beschreibung>
2. <Schritttitel> (Abh.: Schritt 1)
   ...

## Risiken
- <Risiko> – <Maßnahme>

---

Phase 3 – Aufgaben (tasks.md)

Ziel: Erstellen Sie <FEATURE_DIR>/tasks.md

Wenn HAS_SPECKIT_SKILLS = wahr:

Lesen und befolgen Sie .claude/skills/speckit-tasks/SKILL.md oder .cursor/skills/speckit-tasks/SKILL.md (je nachdem, was existiert) wörtlich. Gleiche Selbstauflösung wie Phase 2.

Wenn HAS_SPECKIT_SKILLS = falsch:

Schreiben Sie <FEATURE_DIR>/tasks.md. Jede Aufgabe muss atomar (1 PR oder weniger) und unabhängig testbar sein:

# Aufgaben: <Feature-Name>

## Checkliste
- [ ] T1: <Titel> – <1-zeilige Beschreibung> (Abh.: keine)
- [ ] T2: <Titel> – <1-zeilige Beschreibung> (Abh.: T1)
- [ ] T3: <Titel> – <1-zeilige Beschreibung> (Abh.: T1)
- [ ] T4: <Titel> – <1-zeilige Beschreibung> (Abh.: T2, T3)

## Notizen
<Alle Hinweise zur Reihenfolge oder Parallelität>

---

Phase 4 – Gremiumsprüfung

Zu diesem Zeitpunkt ist <FEATURE_DIR> bekannt (aus Phase 1, entweder über .specify/feature.json oder Ihre eigene Fallback-Auflösung). Erstellen Sie dessen council-Unterverzeichnis:

mkdir -p <FEATURE_DIR>/council

Führen Sie 4 Agenten sequenziell, einen isolierten Unteragenten pro Prüfer aus. Dies ist eine Designentscheidung, keine Tool-Einschränkung – jeder Prüfer baut explizit auf den Erkenntnissen der vorherigen auf, daher benötigen spätere Agenten, dass frühere Berichte bereits existieren. Führen Sie sie parallel aus und Sie verlieren das (jeder würde von null Erkenntnissen starten), selbst auf einer Laufzeitumgebung, die parallele Erzeugungen unterstützt.

Jeder Agent läuft als sein eigener isolierter Unteragent, nicht inline in diesem Thread:

• Claude Code: das Agent-Tool mit subagent_type: "fork".
• Cursor: das Task-Tool mit subagent_type: "generalPurpose" – bestätigt, dass ein wirklich isolierter Unteragent ohne Sichtbarkeit des übergeordneten Kontexts erzeugt wird, ohne dass zuerst eine .cursor/agents/*.md-Datei für diesen Typ existieren muss.

Verwenden Sie das, was Ihre Laufzeitumgebung bereitstellt. Beide bieten die gleiche Eigenschaft, von der diese Phase abhängt: ein Unteragent, der nur das sieht, was in seinem Prompt steht, nicht die Historie dieses Threads.

Persona-Dateien befinden sich im eigenen personas/-Verzeichnis dieses Skills, neben dieser Datei. Lösen Sie den Pfad relativ zu dieser SKILL.md auf – gehen Sie nicht von einem Pfad relativ zum Arbeitsverzeichnis aus.

Erzeugen Sie für jeden Agenten den isolierten Unteragenten mit der untenstehenden Prompt-Vorlage. In jeder Vorlage bedeutet <PERSONA>: Lesen Sie den vollständigen Inhalt der genannten Persona-Datei aus dem personas/-Verzeichnis dieses Skills und befolgen Sie ihn als Ihre Anweisungen für diese Phase, einschließlich seiner eigenen Abschnitte „bevor Sie beginnen“ und „Ausgabe“. Teilen Sie jedem Agenten explizit mit, was <FEATURE_DIR> für diesen Durchlauf aufgelöst wurde – die Personas erwarten, dies mitgeteilt zu bekommen, nicht zu erraten. Da der Unteragent keine Sichtbarkeit in diesen Thread hat, muss sein Prompt vollständig in sich geschlossen sein – verweisen Sie nicht auf etwas mit „wie oben besprochen“, sondern formulieren Sie es neu.

---

Agent 1 – Domänenprüfer

Prompt:

<PERSONA: personas/domain-reviewer.md>

Feature-Verzeichnis für diesen Durchlauf: <FEATURE_DIR>

Lesen Sie auch, falls vorhanden:
- <FEATURE_DIR>/spec.md
- <FEATURE_DIR>/plan.md
- <FEATURE_DIR>/tasks.md
- .specify/memory/constitution.md

Nach Abschluss des Agenten lesen Sie <FEATURE_DIR>/council/01-domain.md und prüfen auf BLOCK. Wenn BLOCK gefunden, stoppen Sie Phase 4, zeigen Sie die Ergebnisse dem Benutzer (über ein strukturiertes Auswahltool, falls vorhanden, sonst einfacher Chat-Text) und fragen Sie: „Domänenprüfer hat diese Spezifikation blockiert. Spezifikation/Plan/Aufgaben ändern und erneut ausführen oder überschreiben und fortfahren?“

---

Agent 2 – Architekturwächter

Prompt:

<PERSONA: personas/architecture-guardian.md>

Feature-Verzeichnis für diesen Durchlauf: <FEATURE_DIR>

Lesen Sie auch:
- <FEATURE_DIR>/spec.md
- <FEATURE_DIR>/plan.md
- <FEATURE_DIR>/tasks.md
- <FEATURE_DIR>/council/01-domain.md

Prüfen Sie vor dem Fortfahren auf BLOCK (gleiche Handhabung wie bei Agent 1).

---

Agent 3 – Sicherheitsprüfer

Prompt:

<PERSONA: personas/security-auditor.md>

Feature-Verzeichnis für diesen Durchlauf: <FEATURE_DIR>

Lesen Sie auch, falls vorhanden:
- <FEATURE_DIR>/spec.md
- <FEATURE_DIR>/plan.md
- <FEATURE_DIR>/tasks.md
- <FEATURE_DIR>/council/01-domain.md
- <FEATURE_DIR>/council/02-architecture.md
- .specify/memory/constitution.md

Prüfen Sie vor dem Fortfahren auf BLOCK.

---

Agent 4 – QA-Planer

Prompt:

<PERSONA: personas/qa-planner.md>

Feature-Verzeichnis für diesen Durchlauf: <FEATURE_DIR>

Lesen Sie auch:
- <FEATURE_DIR>/spec.md
- <FEATURE_DIR>/plan.md
- <FEATURE_DIR>/tasks.md
- <FEATURE_DIR>/council/01-domain.md
- <FEATURE_DIR>/council/02-architecture.md
- <FEATURE_DIR>/council/03-security.md

Prüfen Sie vor dem Fortfahren auf BLOCK.

---

Phase 5 – Synthese

1. Lesen Sie alle vier Gremiumsberichte aus <FEATURE_DIR>/council/:

   • 01-domain.md
   • 02-architecture.md
   • 03-security.md
   • 04-qa.md

   Prüfen Sie vor der Zusammenstellung jeden Bericht gegen den aktuellen Zustand von spec.md/plan.md/tasks.md: Wenn ein CONCERN nach der Erstellung dieses Berichts durch direkte Bearbeitung behoben wurde und der Bericht nie neu verifiziert wurde (siehe Harte Regeln), zählen Sie ihn in der untenstehenden Zusammenfassungstabelle nicht als offen – sagen Sie es aber explizit („funktional gelöst, Bericht nicht neu verifiziert – siehe Anmerkung“), anstatt es stillschweigend zu entfernen oder stillschweigend als noch offen darzustellen. Beides ist unehrlich; nur eine gekennzeichnete Abgleichung ist korrekt.

2. Sammeln Sie alle BLOCKER- und CONCERN-Einträge aus allen Berichten.

3. Für jeden BLOCKER, der eine neue Implementierungsaufgabe erfordert (nicht nur eine Spezifikationsbearbeitung), hängen Sie ihn an <FEATURE_DIR>/tasks.md an:

   - [ ] TC1: [Gremium] <Titel> – <was zu implementieren ist, um den Blocker zu beheben> (Abh.: <relevante Aufgabe>)
   

   Präfixieren Sie vom Gremium hinzugefügte Aufgaben mit [Gremium].

4. Schreiben Sie <FEATURE_DIR>/council/REPORT.md:

# Gremiumsbericht – Zusammenfassung

| Agent | Urteil | Blocker | Bedenken |
|-------|--------|---------|----------|
| Domänenprüfer | <Urteil> | <Anzahl> | <Anzahl> |
| Architekturwächter | <Urteil> | <Anzahl> | <Anzahl> |
| Sicherheitsprüfer | <Urteil> | <Anzahl> | <Anzahl> |
| QA-Planer | <Urteil> | <Anzahl> | <Anzahl> |

## Alle Blocker
<Liste aus allen Berichten>

## Alle Bedenken
<Liste aus allen Berichten>

## Vom Gremium hinzugefügte Aufgaben
<Liste der hinzugefügten TC*-Aufgaben oder „Keine“>

## Endstatus
APPROVED | APPROVED_WITH_CONCERNS | BLOCKED

5. Zeigen Sie dem Benutzer <FEATURE_DIR>/tasks.md (final) und <FEATURE_DIR>/council/REPORT.md.

6. Geben Sie aus:

„Gremium abgeschlossen. Artefakte in <FEATURE_DIR>. Übernehmen Sie die Aufgaben in Ihrem Aufgabenmanager oder Ihrem üblichen Implementierungsablauf.“

---

Phase 6 – Implementierungsverfolgung

Diese Phase läuft während und nach der Implementierung (nicht während des Gremiumslaufs selbst).

Regel: Jedes Mal, wenn eine Aufgabe aus <FEATURE_DIR>/tasks.md vollständig implementiert ist (Code geschrieben, Tests bestanden), aktualisieren Sie sie sofort:

Ändern Sie:

- [ ] T<n>: <Titel> ...

In:

- [x] T<n>: <Titel> ...

Tun Sie dies pro Aufgabe, sobald sie abgeschlossen ist – nicht in einem Batch am Ende. Dies hält tasks.md während der gesamten Implementierungssitzung als Live-Fortschrittsverfolgung.

Wenn mehrere Aufgaben in einem Schritt abgeschlossen werden, aktualisieren Sie alle, bevor Sie fortfahren.

---

Artefaktübersicht

specs/<NNN>-<feature-slug>/     ← <FEATURE_DIR>. Nummer/Slug gewählt von Spec Kits eigenem
                                   speckit-specify-Skill, wenn installiert, oder durch deine
                                   eigene Fallback-Auflösung in Phase 1.
├── spec.md                     Feature-Spezifikation
├── plan.md                     Implementierungsplan
├── tasks.md                    Aufgabenliste (lebender Fortschrittsverfolger)
└── council/
    ├── 01-domain.md            Bericht des Domänenprüfers
    ├── 02-architecture.md      Bericht des Architekturwächters
    ├── 03-security.md          Bericht des Sicherheitsprüfers
    ├── 04-qa.md                Bericht des QA-Planers
    └── REPORT.md               Synthetisierter Endbericht