Fans von Spec Driven Development werden sdd-flow lieben

Letzte Woche habe ich Redakt veröffentlicht, ein Open-Source-Tool für GDPR-Compliance. Sechs Features für eine Web-UI und REST API, die uns besser im Umgang mit PII (Personally Identifiable Information) unterstützen.

Ich hatte den spec-getriebenen Entwicklungsprozess (SDD) seit Monaten über ein Plugin verwendet, das ich selbst gebaut hatte. Als ich sah, dass Claude das Kontextfenster auf eine Million Tokens erweitert hatte, dachte ich mir: "Warum nicht versuchen, die Grenzen meiner Softwareentwicklung auszureizen?" Was ich damit meine: Der SDD-Prozess wurde ursprünglich entwickelt, um das Kontextmanagement zu verbessern. Er folgt einem traditionellen und rigorosen Softwareentwicklungszyklus, war aber im Vergleich dazu, wie schnell sich die AI-Landschaft bewegt, recht langsam. Ich entschied mich, ein Feature mit einem Skill in einem einzigen Durchgang zu entwickeln, der die Phasen eines Entwicklungszyklus orchestriert — und es hat überraschend gut funktioniert.

Der Skill war nicht das Einzige, was den Prozess optimiert hat. Anthropics Veröffentlichung von --permission-mode auto letzte Woche war der Anstoß, den ich brauchte, um endlich die Stützräder abzunehmen. Ich war gespannt, es auszuprobieren. Dieser Modus ist vorerst auf Teams-Konten beschränkt. Anfangs war er instabil, aber er gab mir einen Vorgeschmack auf die verbotene Frucht. Ich wollte nicht mehr zurück zum Bestätigen jeder einzelnen Anfrage. Zu Hause wusste ich allerdings, dass es noch eine andere Option gab, eine gefährliche, die ich bis dahin vermieden hatte: --dangerously-skip-permissions. Nach fast einem Jahr Claude-Nutzung, ohne jemals einen "Oh Scheiße"-Moment gehabt zu haben, entschied ich mich, alle Leitplanken zu entfernen und Berechtigungen zu umgehen. Es fühlte sich an, als würde mein Gesicht von der Schwerkraft nach hinten gedrückt, wie man es in Kampfpiloten-Videos sieht, wenn sie mit mehreren Machs fliegen... und das Gefühl macht süchtig.

SDD, Nicht STD

Nicht STD, wie mein Spracherkennungsmodell es gerne ausspuckt. Specification-driven Development leitet die AI dazu an, die Codebasis und die Anforderungen zu recherchieren, die Spezifikation zu schreiben und dann gegen diese Spezifikation zu implementieren. Die Spec wird das, was du versionierst und reviewst, während der Code das Ergebnis ist.

Das Konzept hat mir gefallen und die Ergebnisse haben mich begeistert.

Was /sdd-flow Macht

/sdd-flow ist ein Claude Code Skill, ein benutzerdefinierter Slash-Befehl, den du mit einer Aufgabe aufrufst:

/sdd-flow Add GDPR-compliant audit logging for all anonymization requests

Dann übernimmt eine Pipeline von Subagenten. Separate Claude-Konversationen, jede mit einem frischen Kontextfenster, jede für eine Phase zuständig.

Research. Der erste Subagent untersucht die Codebasis. Für Redakts Audit-Logging-Feature hat er die bestehende Logging-Infrastruktur kartiert, einen doppelten Handler-Bug gefunden, von dem ich nichts wusste, und festgestellt, dass das Schema im Code von der ursprünglichen Spec abgewichen war. Er lieferte ein Research-Dokument mit Dateipfaden, konkreten Zeilennummern und Integrationspunkten.

Adversariales Review des Research. Ein zweiter Subagent zerlegt den Research. Beim Audit Logging fand er echte Probleme: sechs kritische Lücken, vier fragwürdige Annahmen, vier fehlende Perspektiven.

Spezifikation. Ein Planungs-Subagent liest den reviewten Research und schreibt eine vollständige Spec: funktionale Anforderungen, Edge Cases, Fehlerszenarien, Sicherheitsrestriktionen.

Adversariales Review der Spec. Beim Audit Logging wurde dabei ein Problem entdeckt: Wenn es auf der Audit-Ebene behoben worden wäre, hätte es invasive Änderungen an gemeinsam genutzten Upstream-Funktionen bedeutet.

Implementierung, Code Review, kritisches Review. Code und Tests werden gegen die Spec geschrieben. Ein Code-Review-Subagent prüft die Übereinstimmung, während ein kritischer Review-Subagent einen abschließenden adversarialen Durchgang macht. Jeder Befund, egal wie schwerwiegend, wird vor einem Commit aufgelöst.

Wie /sdd-flow Aussieht

Nach Abschluss von /sdd-flow bekommst du ein Verzeichnis wie dieses:

SDD/
├── research/
│   └── RESEARCH-006-audit-logging.md
├── requirements/
│   └── SPEC-006-audit-logging.md
├── prompts/
│   ├── PROMPT-006-audit-logging-2026-03-29.md
│   ├── implementation-complete/
│   │   └── IMPLEMENTATION-SUMMARY-006-...md
│   └── context-management/
│       └── progress.md
└── reviews/
    ├── CRITICAL-SPEC-audit-logging-20260329.md
    └── CRITICAL-IMPL-audit-logging-20260329.md

Ein Skill, Zwei Modi

Der überwachte Modus ist der Standard, weil er dich zwingt, kritische Entscheidungen zu treffen, die normalerweise nicht automatisiert werden sollten. Dazu gehört das Review des abgeschlossenen Research und das Review des Codes vor dem Commit.

Der autonome Modus existiert für Features, bei denen die Anforderungen klar sind und du dir sicher bist. Ich habe ihn für einige der späteren Redakt-Features verwendet, nachdem die ersten beiden den Prozess bewiesen hatten. Aber das Innehalten zum Review ist aus gutem Grund der Standard — denn Selbstsicherheit ist oft Selbstüberschätzung.

Probier Es Aus

Sowohl der Skill als auch das Plugin sind open source:

• Skill (Orchestrator): claude-skills
• Plugin (Phasenbefehle): claude-plugins
• Redakt (damit gebaut): redakt, schau dir das SDD/-Verzeichnis für den vollständigen Artefakt-Trail an

Die Artefakte in Redakts SDD/-Verzeichnis sind das beste Argument, das ich machen kann. Lies die Research-Dokumente, die Specs und vor allem die kritischen Reviews. Und dann lass einfach den SDD Flow laufen.