Spezifikationsgetriebene Entwicklung (SDD) – geführter Modus

Der Benutzer muss den SDD-Ablauf nie kennen. Du steuerst ihn: Bei jeder Interaktion ermittelst du, wo das Projekt steht, erledigst alles, was du selbst tun kannst, fragst nur das, was du nicht ableiten kannst, und beendest die Antwort, indem du dem Benutzer genau mitteilst, was als Nächstes passiert.

Jedes Feature durchläuft spec.md → design.md → tasks.md → Implementierung → review.md. Vorlagen liegen in ${CLAUDE_PLUGIN_ROOT}/skills/slate-sdd/templates/. Beginne jeden Shell-Befehl, der Vorlagen kopiert, mit T="${CLAUDE_PLUGIN_ROOT}/skills/slate-sdd/templates"; (die Code-Ausschnitte unten verwenden $T).

Der Ablauf (führe dies jedes Mal aus, wenn die Skill verwendet wird)

Erkenne den Zustand (siehe Zustandserkennung). Tue dies still – lies Dateien, frage den Benutzer nicht, wo er ist.
Nimm die Eingabe auf. Was auch immer der Benutzer gesendet hat – einen task.md-Pfad, ein eingefügtes Dokument, einen Satz, „continue“, „ok“ – ordne es dem aktuellen Schritt zu (siehe Eingabe verarbeiten).
Erledige die Arbeit des Schrittes selbst. Entwerfe das Dokument aus dem, was du weißt: der Eingabe, docs/PRODUCT.md, docs/PRINCIPLES.md, docs/ARCHITECTURE.md, docs/GLOSSARY.md und dem Code selbst. Untersuche die Codebasis, anstatt Dinge zu fragen, die der Code beantwortet (Stack, Befehle, Dateipfade, bestehende Muster). Schreibe jedes Dokument gemäß Schreibstil und führe vor dem Anzeigen dessen Selbstprüfung durch.
Frage nur die Lücken (siehe Fragen stellen). Frage nie nach etwas, das du bereits mit angemessener Sicherheit entworfen hast – zeige es und lass es der Benutzer korrigieren.
Schließe mit dem Guide-Block (siehe Guide-Block). Jede Antwort endet damit, ausnahmslos.

Sprich mit dem Benutzer in der Sprache, in der er schreibt. Schreibe die Dokumente in der Sprache, die die vorhandenen Projektdokumente verwenden (Englisch, falls es noch keine gibt, es sei denn, der Benutzer wünscht etwas anderes).

Zustandserkennung

Prüfe in dieser Reihenfolge und stoppe beim ersten Treffer:

#	Bedingung	Aktueller Schritt
1	Kein `docs/PRODUCT.md` oder `docs/PRINCIPLES.md`	Setup – Projektdokumente
2	`PRODUCT.md`/`PRINCIPLES.md` enthalten noch `[placeholder]`-Text	Setup – fülle sie fertig aus
3	Benutzer hat neue Arbeit (Datei, Text, Idee) gesendet, die nicht das aktive Feature ist	Triage der neuen Arbeit
4	Aktives Feature hat `spec.md` mit `status: draft`	Spezifikation
5	`spec.md` genehmigt, `design.md` fehlt oder `status: draft`	Design
6	`design.md` genehmigt, `tasks.md` enthält noch Vorlagen-Platzhalter	Aufgaben (Planung)
7	`tasks.md` hat eine `T`, die nicht `done` ist	Implementieren – nächste `T`
8	Alle `T` erledigt, `review.md` `status: pending`	Review
9	`review.md` genehmigt / genehmigt-mit-Anmerkungen	Abschluss – Gedächtnis + Zustand, dann nächstes Feature anbieten

Aktives Feature = dasjenige, das in docs/MEMORY.md → Aktueller Zustand → In Bearbeitung genannt ist; falls das leer ist, das docs/specs/NNN-*/ mit der höchsten Nummer, dessen review.md nicht genehmigt ist. Wenn mehrere offen sind und der Benutzer keins genannt hat, frage welches (eine Frage, liste sie auf).

Eine schnelle Möglichkeit, den Zustand zu lesen:

ls docs/ docs/specs/ 2>/dev/null
grep -H '^status:' docs/specs/*/*.md 2>/dev/null
grep -H -- '- \*\*Status:\*\*' docs/specs/*/tasks.md 2>/dev/null

Eingabe verarbeiten

Ein Pfad zu einer task.md (oder einer .md/.txt) – lies sie vollständig. Behandle sie als rohe Anforderungen, nicht als fertige tasks.md: extrahiere Problem, Verhalten, Beispiele, Grenzfälle, Einschränkungen, Dateihinweise. Führe dann die Triage durch.
Eingefügter Text oder eine einzeilige Idee – wie oben.
"continue" / "próximo" / "ok" / "aprovado" / "pode seguir" – wenn das aktuelle Dokument auf Genehmigung wartet, ist dies die Genehmigung: setze seinen status und wechsle in derselben Antwort zum nächsten Schritt. Ansonsten führe einfach den aktuellen Schritt aus.
Eine Korrektur oder Antwort – wende sie auf das aktuelle Dokument an, aktualisiere alle dadurch aufgelösten Q, prüfe erneut auf Lücken, fahre fort.
Eine Frage zum Ablauf – beantworte kurz, fahre dann mit dem Guide-Block fort.

Triage (neue Arbeit)

Entscheide die Größe und sag in einer Zeile, was du entschieden hast:

Klein – offensichtlich, umkehrbar, ~1–3 Dateien, keine Designentscheidung (Tippfehler, kleiner Bug, Konfigurationsänderung). Erstelle nur tasks.md (in docs/specs/NNN-name/), fülle es aus und gehe direkt zu Implementieren. Überspringe Spezifikation/Design/Review, es sei denn, der Benutzer wünscht sie.
Feature – alles mit zu definierendem Verhalten oder einer Designentscheidung. Führe den vollständigen Ablauf aus.
Forschungsbedürftig – eine Schlüsselentscheidung ist wirklich unbekannt (Bibliothek, Ansatz, Anbieter). Vollständiger Ablauf plus research.md vor dem Design.

Wenn du zwischen klein und Feature unsicher bist, wähle Feature und sag, dass der Benutzer um eine Abkürzung bitten kann.

Erstelle dann den Ordner:

Nächste Nummer = höchste NNN- in docs/specs/ + 1 (beginne bei 001). Name = kurzer Kebab-Case aus der Eingabe; frage nicht danach.
Kopiere Vorlagen:

D=docs/specs/NNN-feature-name; mkdir -p "$D"
cp $T/specs/spec.md $T/specs/design.md $T/specs/tasks.md $T/specs/review.md "$D"/
# nur wenn Forschung nötig ist:
cp $T/specs/research.md "$D"/

Setze alle aus der Eingabe gewonnenen Informationen sofort in die richtigen Dokumente ein: Problem/Abnahmekriterien/Einschränkungen/Ausgeschlossen → spec.md; Implementierungshinweise und Dateipfade → als Notizen für design.md/tasks.md behalten (nicht verlieren; unter dem entsprechenden Abschnitt hinzufügen, sobald du ihn erreichst).
Aktualisiere docs/MEMORY.md → Aktueller Zustand → In Bearbeitung mit der Feature-ID und dem Schritt.
Fahre in derselben Antwort direkt mit dem Spezifikations-Schritt fort.

Schritte

Setup

mkdir -p docs/decisions docs/specs
for f in PRODUCT PRINCIPLES ARCHITECTURE GLOSSARY MEMORY; do [ -f docs/$f.md ] || cp $T/$f.md docs/$f.md; done
[ -f docs/decisions/0000-template.md ] || cp $T/decisions/0000-template.md docs/decisions/
[ -f CLAUDE.md ] || cp $T/CLAUDE.md CLAUDE.md

Überschreibe niemals vorhandene Dateien. Dann befülle vorab aus dem Repository, bevor du etwas fragst: lies package.json / pyproject.toml / go.mod / Cargo.toml / Makefile / CI-Dateien / README, um Stack, Befehle, Verzeichniszuordnung und Komponenten auszufüllen. Frage den Benutzer nur nach dem, was der Code nicht sagen kann: was das Produkt ist und für wen, Ziele, Nicht-Ziele, Geschäftsregeln, Teamregeln. Wenn der Benutzer mit einem Feature kam, halte das Setup kurz (PRODUCT + PRINCIPLES Wesentliches) und fahre mit dem Feature fort; ARCHITECTURE und GLOSSARY können später schrittweise ausgefüllt werden.

Spezifikation

Fülle spec.md aus der Eingabe. Jedes Abnahmekriterium (AC) muss Gegeben/Wenn/Dann und eigenständig testbar sein – formuliere vage Anforderungen selbst in ACs um und zeige sie an. Jedes Unbekannte, das das Design blockiert, wird zu einem Q [blocking]; kleinere Unbekannte werden zu Q [non-blocking] mit deinem Lösungsvorschlag. Präsentiere eine kurze Zusammenfassung (Problem, ACs, Ausgeschlossen, offene Qs) und bitte um Genehmigung. Tor: Das Design beginnt erst, wenn keine blocking Q offen ist und der Benutzer genehmigt hat (oder gesagt hat, ohne zu fragen fortzufahren) → setze status: approved.

Design

Lies docs/PRINCIPLES.md und docs/ARCHITECTURE.md und untersuche die beteiligten Codepfade. Verfasse das vollständige design.md selbst; decke jedes AC ab (sage, welcher Teil welches abdeckt). Triff die lokalen Entscheidungen selbst als D-Einträge mit Begründung; bringe dem Benutzer nur Entscheidungen vor, die teuer rückgängig zu machen oder Geschmackssache sind, jede mit deiner Empfehlung. Eine Entscheidung, die das gesamte Projekt betrifft → schlage einen ADR in docs/decisions/ vor. Zeige eine kurze Zusammenfassung und bitte um Genehmigung. Tor: Wie Spezifikation.

Aufgaben

Fülle tasks.md aus Spezifikation + Design: kleine Ts in Abhängigkeitsreihenfolge, jede mit Covers, Files und einem echten Verify-Befehl aus PRINCIPLES.md → Commands. Jedes AC wird von mindestens einer T abgedeckt; jeder Grenzfall E hat einen Test. Kein Genehmigungstor, es sei denn, der Benutzer hat eines verlangt – zeige die Aufgabenliste und wechsle zu Implementieren.

Implementieren

Eine T nach der anderen: setze in-progress, implementiere, führe ihr Verify aus, setze done (oder blocked mit Grund). Nach jeder T berichte in 2–3 Zeilen und fahre mit der nächsten fort, es sei denn, etwas ist fehlgeschlagen, eine T widerspricht PRINCIPLES.md oder die Fertigstellung benötigt etwas aus Out of Scope – dann halte an und frage. Halte docs/MEMORY.md → In Bearbeitung auf die aktuelle T ausgerichtet.

Review

Fülle review.md: Implementierungsbericht, jedes AC mit Ergebnis und Nachweis, führe die vollständigen Test/Lint/Build-Befehle aus, wende die PRINCIPLES-Review-Checkliste an, liste Befunde auf. Prüfe die Feature-Dokumente gegen Schreibstil. Notiere jeden Verstoß als minor-Befund. Gib das Urteil ab. Behebe blocker/major-Befunde, wenn der Benutzer zustimmt, und wiederhole dann das Review.

Abschluss

Verschiebe dauerhafte Lektionen in docs/MEMORY.md, aktualisiere Aktueller Zustand (Erledigt += dieses Feature, In Bearbeitung gelöscht), füge die Fähigkeit zu PRODUCT.md → Capabilities hinzu, erstelle alle ADRs aus Nachverfolgungen. Biete dann das nächste Element an (aus Next, aus Review-Nachverfolgungen oder „sende mir die nächste Aufgabe").

Fragen stellen

Stelle maximal 3–5 Fragen pro Durchgang, die wichtigsten zuerst. Nummeriert, kurz.
Jede Frage enthält deinen Lösungsvorschlag, sodass der Benutzer mit „ok" / „1 ok, 2 nein" antworten kann, anstatt zu schreiben: 1. Sollen abgelaufene Links eine Fehlerseite anzeigen? → Vorschlag: ja, mit einem „erneut senden"-Button.
Wenn das AskUserQuestion-Werkzeug verfügbar ist und die Antwort eine Auswahl aus wenigen Optionen ist, verwende es, mit der empfohlenen Option zuerst.
Frage niemals, was der Code, die Dokumente oder die Eingabe bereits beantworten. Frage niemals den Benutzer, welchen SDD-Schritt er als Nächstes machen soll – das ist deine Aufgabe.
Wenn der Benutzer „entscheide du" / „tanto faz" / „pode seguir" sagt, übernimm deine Vorschläge, dokumentiere sie (als Q → Antwort oder D) und fahre fort.

Guide-Block

Beende jede Antwort mit diesem Block (in der Sprache des Benutzers), damit der Benutzer nie darüber nachdenken muss, was zu tun ist:

---
📍 Feature: NNN-feature-name · Schritt: Spezifikation (2/6)   [Setup · Spezifikation · Design · Aufgaben · Implementieren · Review]
✅ Erledigt jetzt: <eine Zeile>
❓ Benötigt von dir: <nummerierte Fragen oder „nichts">
➡️ Nächstes: <genau das, was nach der Antwort des Benutzers passiert – z.B. „Antworte ‚ok' um die Spezifikation zu genehmigen, und ich schreibe das Design">

Wenn nichts vom Benutzer benötigt wird, sag das und sag, was du als Nächstes bei „continue" tun wirst.

Der Guide-Block und Chat-Nachrichten müssen nicht die vollständige Schreibstil-Selbstprüfung durchlaufen. Halte sie kurz und direkt.

Dokumentenregeln

Ersetze jeden [placeholder], NNN und YYYY-MM-DD. Ein leerer Abschnitt wird zu None. – lösche niemals die Überschrift.
Verwende IDs (AC, Q, D, T, E, F), um zwischen Dokumenten zu verweisen, anstatt Text zu kopieren.
Lese docs/PRINCIPLES.md vor design.md und vor der Implementierung einer Aufgabe.
Wenn eine Anforderung unklar ist, füge ein Q hinzu und frage, anstatt zu raten. Wenn eine Aufgabe mit PRINCIPLES.md kollidiert, halte an und frage.
Jede Tatsache lebt in einem Dokument; andere verweisen darauf.

Schreibstil (jedes Dokument)

Das nächste Modell liest diese Dokumente und handelt danach. Schreibe so, dass jeder Satz nur eine Bedeutung hat. Diese Regeln gelten in jeder Sprache. Portugiesische Äquivalente sind in Klammern angegeben.

Klarheit & Präzision (inspiriert von ASD-STE100)

Eine Idee pro Satz. Verwende maximal 20 Wörter in einer Anweisung. Verwende maximal 25 Wörter in einer Beschreibung.
Eine Anweisung pro Satz. Verwende den Imperativ für Aktionen. Schreibe „Gib 404 zurück." Schreibe nicht „Das System sollte wahrscheinlich 404 zurückgeben."
Aktiv, Präsens. Nenne den Akteur: den Benutzer, das System oder eine Komponente mit ihrem Namen.
Ein Begriff = eine Bedeutung. Verwende den genauen Begriff aus docs/GLOSSARY.md. Verwende keine Synonyme für dasselbe Konzept. Wenn du einen neuen Fachbegriff verwendest, füge ihn in GLOSSARY.md hinzu.
Anforderungsschlüsselwörter: verwende nur muss / darf nicht / kann (deve / não deve / pode). Verwende nicht „sollte", „idealerweise", „versuche", „wenn möglich" („deveria", „idealmente", „tentar", „se possível").
Quantifiziere. Ersetze jedes vage Wort durch eine Zahl, eine Einheit oder ein beobachtbares Ergebnis. Verwende diese Wörter nicht ohne Zahl: schnell, langsam, viele, wenige, groß, klein, robust, einfach, benutzerfreundlich, einige, „usw.", „und so weiter" (rápido, lento, muitos, poucos, grande, robusto, fácil, adequado, alguns, „etc.").
- Falsch: „Die Seite lädt schnell." Richtig: „Die Seite lädt in weniger als 2 s (p95)."
Keine Redewendungen, Metaphern, Witze, Füllwörter oder Marketing-Ton.
Keine unklaren Pronomen. Wenn „es", „dies" oder „das" („ele", „isso", „este") sich auf zwei Substantive beziehen kann, wiederhole das Substantiv.
Struktur statt Prosa. Bevorzuge Listen und Tabellen. Ein Absatz hat maximal 3 Sätze.
Exakte Namen in code. Schreibe Bezeichner, Pfade, Befehle, Felder und Werte in Backticks. Paraphrasiere sie nicht.

Grundprinzipien

Beginne mit Tatsachen. Gewohnheit und Analogie sind keine Gründe. „Andere Projekte machen X" ist kein Grund.
Kennzeichne jede relevante Behauptung:
- Tatsache – verifiziert. Gib die Quelle an: Dateipfad, Befehlsausgabe, Daten oder Dokument.
- Annahme – nicht verifiziert. Schreibe, wie sie zu verifizieren ist.
- Entscheidung – eine Wahl. Gib den Grund an, abgeleitet aus Tatsachen oder Einschränkungen.
Führe jede Entscheidung auf ein Problem, ein AC oder eine Einschränkung zurück. Wenn eine Entscheidung keine Rückverfolgung hat, entferne sie.
Bedarf vor Lösung. Schreibe in dieser Reihenfolge: Problem → Einschränkungen → die einfachste Lösung, die diese erfüllt.
Einfachste Option zuerst. Wähle die einfachste Option, die alle ACs erfüllt. Jede hinzugefügte Komponente, Abhängigkeit oder Schritt benötigt einen genannten Grund.

Selbstprüfung (vor dem Anzeigen eines Dokuments ausführen)

Kein [placeholder], NNN oder YYYY-MM-DD ist mehr vorhanden.
Kein verbotenes Wort aus Regel 5 und 6 ist mehr vorhanden.
Jeder Satz liegt innerhalb der Wortgrenze von Regel 1.
Jeder Fachbegriff ist in docs/GLOSSARY.md.
Jedes D und jede Entscheidung hat einen Grund.
Jede nicht verifizierte Behauptung ist als Annahme gekennzeichnet und hat eine Verifikationsmethode.

Referenz

Vorlagen in $T = ${CLAUDE_PLUGIN_ROOT}/skills/slate-sdd/templates/:

PRODUCT.md, PRINCIPLES.md, ARCHITECTURE.md, GLOSSARY.md, MEMORY.md, CLAUDE.md – auf Projektebene, einmal erstellt.
decisions/0000-template.md – ein ADR pro projektweiter Entscheidung.
specs/spec.md, design.md, tasks.md, review.md, research.md – ein Satz pro Feature.

wolneydev/slate-sdd

Was ist slate-sdd?

In Ihrer bevorzugten KI fragen

Dokumentation