Beste Werkzeuge für spezifikationsgetriebene Entwicklung 2026
SpecScore ist ein offenes, lintbares Dateiformat für Spezifikationen, geschrieben in Markdown und YAML (YAML Ain't Markup Language). Spezifikationsgetriebene Entwicklung (SDD) ist eine Praxis, bei der eine schriftliche Spezifikation die Quelle der Wahrheit ist, gegen die Code gebaut und geprüft wird. Werkzeuge für spezifikationsgetriebene Entwicklung sind die Formate, Workflows und Produkte, mit denen diese Spezifikationen geschrieben, gespeichert und manchmal geprüft werden. Ein Produktanforderungsdokument (PRD) ist Fließtext, der das Problem und den Umfang nennt, bevor jemand ihn in Aufgaben aufteilt. Einfacher Ansatz zur Syntax von Anforderungen (EARS) ist ein Anforderungssatz in der Form „WHEN etwas geschieht, THE SYSTEM SHALL etwas tun“. Eine Befehlszeilenschnittstelle (CLI) ist ein Programm, das Sie in einem Terminal ausführen. Kontinuierliche Integration (CI) ist eine automatische Prüfung bei jeder vorgeschlagenen Änderung.
Dieser Vergleich von Werkzeugen für spezifikationsgetriebene Entwicklung umfasst GitHub Spec Kit, OpenSpec, Kiro, Tessl, die BMAD Method, Task Master AI, CodeSpeak, Datarim, reines Markdown und SpecScore. Öffentliche Seiten und Repositories wurden am 30. Oktober 2026 gelesen. Befehle, Dateianordnungen und was ein Produkt prüft, können sich ändern; die Quellen unten nennen die Seite, aus der jede Aussage stammt.
Die Trennung, auf die es bei einem Repository ankommt, ist, ob die Spezifikation die CI aus eigener Kraft fehlschlagen lassen kann. Im Repository der SpecScore-Website installiert dogfood.yml das SpecScore-CLI und führt specscore spec lint bei Pull Requests und bei Pushes auf main aus. Der /score-Skill in specstudio-skills ist eine manuelle KI-Bewertung eines Artefakts. Sie rufen ihn auf. Dieser Workflow nicht.
Werkzeuge für spezifikationsgetriebene Entwicklung, nebeneinander.
Jede Zeile ist eine Rolle, keine Punktzahl. Folgen Sie dem Namen zum SpecScore-Vergleich oder der Überschrift darunter zur Quelle hinter der Zelle.
| Werkzeug | Was es ist | Wie Spezifikationen geschrieben und gespeichert werden | Automatische Prüfung der Spezifikation | Lizenz | Für wen es passt |
|---|---|---|---|---|---|
| GitHub Spec Kit | Agenten-Workflow, der Markdown-Artefakte erzeugt | Feature-Verzeichnis unter specs/: spec.md, plan.md, tasks.md | /speckit.analyze meldet Lücken zwischen den Artefakten in der Agentensitzung. Community-Erweiterungen können Gates hinzufügen. | MIT in github/spec-kit | Ein Team, das einen gemeinsamen Prozess für den Agenten will |
| OpenSpec | Änderungsordner und Agentenbefehle, um sich vor dem Code zu einigen | Reines Markdown unter openspec/changes/: Vorschlag, Spezifikationen, Entwurf, Aufgaben | openspec validate prüft die Struktur von Änderung und Spezifikation und kann mit einem Exit-Code ungleich null enden, auch aus einem CI-Skript. | MIT in Fission-AI/OpenSpec | Ein Team, das einen leichten Änderungsordner plus eine Strukturprüfung will |
| Kiro | Agentische IDE, CLI und Web-App von AWS, die Spezifikationen entwirft | requirements.md in EARS, plus design.md und tasks.md | Analyze Requirements innerhalb von Kiro, vor dem Entwurf. Die Feature-Spec-Seite beschreibt diese Prüfung im Produkt. | IDE und CLI sind AWS Content unter der Kiro-Lizenz (AWS Customer Agreement). | Jemand, der will, dass Kiro die Anforderungen, den Entwurf und die Aufgaben entwirft |
| Tessl | Plattform für Agent-Skills, plus ein Tile für spezifikationsgetriebene Entwicklung | Skills als Dateien im Repository. Das Tile schreibt .spec.md unter specs/. | Das Tile liefert scripts/validate-specs.sh und scripts/check-spec-links.sh. Seine GitHub Actions linten das Tile. | Das Tile ist MIT in tesslio/spec-driven-development-tile. Die Plattform ist das Produkt von Tessl. | Ein Team, das Agent-Skills vereinheitlicht oder die Regeln Spezifikation-vor-Code des Tiles nutzt |
| BMAD Method | Agile Methode für KI-getriebene Entwicklung | Briefs, Spezifikationen und Architektur, die Sie in einen anderen Workflow mitnehmen können | Die README beschreibt die Artefakte der Methode und die Agenten-Workflows. Die README dokumentiert keinen Format-Linter für die CI. | MIT in bmad-code-org/BMAD-METHOD, mit einem Markenhinweis in dieser Datei. | Ein Team, das eine agile Agentenmethode will, zugeschnitten auf die Änderung |
| Task Master AI | Aufgabenliste für Coding-Agenten, aus einem PRD geparst | PRD-Fließtext, oft .taskmaster/docs/prd.txt, danach erzeugte Aufgaben | Die README beschreibt das Parsen eines PRD in Aufgaben. Die README beschreibt keinen Linter für das PRD. | MIT mit einer Commons Clause in eyaltoledano/claude-task-master | Ein Team, das schon ein PRD hat und es in Aufgaben aufgeteilt haben will |
| CodeSpeak | Agentisches Toolkit, das Chat-Absicht in Anforderungen verwandelt, die dem Code zugeordnet sind | Strukturierte Anforderungen im Produkt, dem Code zugeordnet | Die Website sagt, dass Anforderungen bei jeder Änderung durchgesetzt werden, innerhalb des Produkts. | Nutzungsbedingungen (wirksam ab dem 3. März 2026): CodeSpeak Ltd behält den Service, einschließlich seines Quellcodes. Die Produktwebsite veröffentlicht kein Quell-Repository für das Toolkit. | Ein Team, das Absicht aus Chats erfasst und dem Code zugeordnet halten will |
| Datarim | Iterativer Workflow für Claude Code, Codex CLI, Cursor und Antigravity | /dr-prd schreibt ein PRD. Aktive Aufgaben stehen in backlog.md. | /dr-compliance und /dr-dream lint laufen, wenn Sie diese Befehle aufrufen. | MIT in Arcanada-one/datarim | Ein Team, das gestufte Befehle und ein Backlog im Repository will |
| Reines Markdown | Eine gewöhnliche Markdown-Datei, die Sie schreiben und committen | Jede .md-Datei, in welchem Verzeichnis auch immer Sie sie ablegen | Welche Durchsicht Sie auch durch Lesen vornehmen, bis Sie ein Prüfwerkzeug hinzufügen | Kein Produkt und keine Lizenzdatei. Die Bedingungen der Datei sind die des Repositorys. | Eine kurze Notiz, ein Spike oder eine Prüfung, die Sie durch Lesen erledigen |
| SpecScore | Offenes Spezifikationsformat plus ein CLI, das die Dateien lintet | Markdown + YAML in einem spec/-Baum | dogfood.yml führt specscore spec lint bei Pull Requests und Pushes auf main aus. /score ist eine manuelle KI-Bewertung, und dieser Workflow führt sie nicht aus. | CC BY 4.0, Format in specscore/specscore. Apache-2.0, CLI in specscore/specscore-cli. | Ein Team, das braucht, dass die Spezifikationsdatei die CI fehlschlagen lässt, wenn das Format bricht |
GitHub Spec Kit
GitHub Spec Kit ist ein offenes Toolkit, das einem Coding-Agenten einen Prozess vorgibt: Specify, Plan, Tasks, Implement und Converge. Die Startseite der Spec-Kit-Dokumentation, datiert 28. September 2026, sagt, dass jede Phase ein Markdown-Artefakt erzeugt, das die nächste Phase liest.
Diese Dateien liegen in einem Feature-Verzeichnis unter specs/. Der Upgrade-Leitfaden, gelesen am 30. Oktober 2026, nennt Pfade wie specs/001-my-feature/spec.md, mit plan.md und tasks.md daneben. Die Referenz für agentisches SDD beschreibt /speckit.analyze als einen Bericht über Widersprüche zwischen der Spezifikation, dem Plan und den Aufgaben, ohne die Dateien zu bearbeiten. /speckit.clarify und /speckit.checklist sind weitere Befehle, die Sie im Agenten ausführen. Die Dokumentationsstartseite nennt außerdem Community-Erweiterungen, darunter eine namens CI Guard, die Compliance-Gates hinzufügen.
Die Lizenz ist MIT, im öffentlichen Repository github/spec-kit. Spec Kit passt zu einem Team, das diesen Prozess will und die Spezifikation als das Markdown belässt, das der Agent geschrieben hat. Ein Vergleich mit SpecScore steht auf SpecScore vs Spec Kit.
OpenSpec
OpenSpec, von Fission-AI, hält jede Änderung in einem eigenen Ordner, damit eine Person und ein Agent sich einigen können, bevor Code geschrieben wird. Die README, gelesen am 30. Oktober 2026, zeigt openspec/changes/add-dark-mode/ mit proposal.md, einem Verzeichnis specs/, design.md und tasks.md. Anforderungen sind reines Markdown: eine SHALL-Aussage und ein WHEN / THEN-Szenario. Dieselbe README sagt, dass sie 30+ KI-Assistenten unterstützt.
openspec validate prüft Änderungen und Spezifikationen auf strukturelle Probleme. Die CLI-Referenz, gelesen am 30. Oktober 2026, dokumentiert einen Exit-Code ungleich null, wenn die Validierung fehlschlägt, und einen Shell-Schnipsel, den ein CI-Job ausführen kann. Diese Prüfung ist die Änderungs- und Spezifikationsstruktur von OpenSpec.
Die Lizenz ist MIT, in Fission-AI/OpenSpec. OpenSpec passt zu einem Team, das den Änderungsordner und diese Strukturprüfung will. Siehe SpecScore vs OpenSpec.
Kiro
Kiro, von Amazon Web Services (AWS), ist eine agentische Entwicklungsumgebung: ein Editor, ein CLI und eine Web-App. Die Seite der Feature-Specs, aktualisiert am 4. August 2026, führt ein Feature durch Anforderungen, Entwurf und Aufgaben. requirements.md verwendet EARS. design.md und tasks.md liegen daneben. Quick Spec kann alle drei ohne einen Freigabestopp dazwischen ausführen.
Analyze Requirements sucht vor dem Entwurf nach Widersprüchen, Mehrdeutigkeit, kollidierenden Einschränkungen und Lücken. Diese Analyse läuft innerhalb von Kiro. Die Feature-Spec-Seite beschreibt die Prüfung im Produkt.
Die Kiro-Lizenz, gelesen am 30. Oktober 2026, sagt, dass die IDE und das CLI als AWS Content unter dem AWS Customer Agreement oder einer anderen schriftlichen Vereinbarung und der AWS Intellectual Property License lizenziert sind. Kiro passt zu jemandem, der will, dass dieses Produkt die drei Dateien entwirft. Siehe SpecScore vs Kiro. Die Satzmuster stehen in der EARS-Anforderungssyntax.
Tessl
Die Dokumentation von Tessl, gelesen am 30. Oktober 2026, beschreibt eine offene Plattform zum Verwalten von Agent-Skills: eine Registry, Governance, Evals und zugehörige Kontrollen. Skills, Regeln und Dokumente sind Dateien im Repository.
Ein separates Artefakt, das Tile für spezifikationsgetriebene Entwicklung, wird aus tesslio/spec-driven-development-tile veröffentlicht und in der Tessl-Registry geführt. Die Tile-README sagt, dass der Agent .spec.md-Dateien in einem Verzeichnis specs/ schreibt, mit YAML-Frontmatter, targets und [@test]-Links. Die README dokumentiert scripts/validate-specs.sh und scripts/check-spec-links.sh sowie GitHub Actions, die das Tile selbst linten.
Die Lizenz des Tiles ist MIT, in diesem Repository. Die Dokumentation beschreibt die Registry-Plattform als das Produkt von Tessl und verweist nicht auf ein öffentliches Repository für die gesamte Plattform. Tessl passt zu einem Team, das Skills vereinheitlicht, oder zu einem Team, das die Steuerung Spezifikation-vor-Code des Tiles will. Siehe SpecScore vs Tessl.
BMAD Method
Die README des BMAD Method-Repository, gelesen am 30. Oktober 2026, beschreibt eine agile Methode für KI-getriebene Entwicklung. Die README sagt, dass Sie die Methode von Anfang bis Ende nutzen oder ihre Briefs, Spezifikationen und Architektur in einen Workflow mitnehmen können, den Sie schon haben. Die dort genannte stabile Linie ist v6.12. v7 wird als Vorschau auf dem Branch main beschrieben. Das Projekt schreibt den Namen BMad; das Repository ist BMAD-METHOD.
Die README stellt diese Planungsartefakte und die Agent-Skills, die sie erzeugen, in den Mittelpunkt. Die README dokumentiert keinen Befehl, der ein festes Spezifikationsschema in der CI lintet.
Die Lizenz ist MIT, in bmad-code-org/BMAD-METHOD. Diese Lizenzdatei trägt außerdem einen Markenhinweis für BMad. Die Methode passt zu einem Team, das die agile Schleife will und die Spezifikation in diesen Briefs und Spezifikationen behält. Siehe SpecScore vs die BMAD Method.
Task Master AI
Task Master AI ist eine Aufgabenliste für KI-Coding-Agenten. Die README, gelesen am 30. Oktober 2026, empfiehlt ein PRD, oft unter .taskmaster/docs/prd.txt, und task-master parse-prd, um diesen Fließtext in Aufgaben zu verwandeln. Die Dokumentation behandelt Aufgabenstruktur, Abhängigkeiten und Tags.
Die README behandelt das PRD als Eingabe und die Aufgabenliste als das, wovon der Agent arbeitet. Die README beschreibt keinen Linter für Wortlaut oder Struktur des PRD.
Die Lizenz ist MIT mit einer Commons Clause, in eyaltoledano/claude-task-master. Die README sagt, dass Sie Produkte mit Task Master bauen dürfen, und dass der Verkauf von Task Master selbst oder das Anbieten als gehosteter Dienst außerhalb dieser Einräumung liegt. Es passt zu einem Team, das das PRD in Aufgaben aufgeteilt haben will. Siehe SpecScore vs Task Master AI.
CodeSpeak
Die Website von CodeSpeak, gelesen am 30. Oktober 2026, beschreibt ein agentisches Engineering-Toolkit. Es erfasst Absicht aus Agenten-Chats, verwandelt diese Absicht in strukturierte Anforderungen, die dem Code zugeordnet sind, und sagt, dass es diese Anforderungen bei jeder Änderung durchsetzt. Die Website sagt außerdem, dass ein Web-Werkzeug Absicht aus Chats wiederherstellt, bis das volle Produkt erscheint.
Die Nutzungsbedingungen, wirksam ab dem 3. März 2026, stellen fest, dass CodeSpeak Ltd den Service behält, einschließlich seiner Software und seines Quellcodes. Die Produktwebsite veröffentlicht kein Quell-Repository für dieses Toolkit, daher nennt diese Seite keine Softwarelizenz dafür.
CodeSpeak passt zu einem Team, das Anforderungen aus dem Gespräch erfasst und innerhalb dieses Produkts dem Code zugeordnet halten will. Siehe SpecScore vs CodeSpeak.
Datarim
Die README von Datarim, mit einem Versionsabzeichen 4.9.0 und gelesen am 30. Oktober 2026, beschreibt einen iterativen Workflow für Claude Code, Codex CLI, Cursor und Google Antigravity. /dr-prd erzeugt ein PRD. Aktive Aufgaben stehen in backlog.md, mit erledigter Historie in backlog-archive.md.
/dr-compliance prüft eine Implementierung gegen das PRD, wenn Sie diesen Befehl ausführen. /dr-dream lint prüft eine Wissensbasis auf Widersprüche, verwaiste Einträge, defekte Links, veralteten Inhalt und Duplikate. Das sind Befehle im Workflow.
Die Lizenz ist MIT, in Arcanada-one/datarim. Datarim passt zu einem Team, das diese gestuften Befehle über die Agenten hinweg will, die die README nennt. Siehe SpecScore vs Datarim.
Reines Markdown
Reines Markdown ist die Spezifikation als gewöhnliche .md-Datei: eine Überschrift, einige Aufzählungspunkte, wo auch immer Sie sie committen. Es gibt kein Schema. Die Durchsicht ist jemand, der die Datei liest, bis Sie ein eigenes Prüfwerkzeug hinzufügen.
Es gibt kein Produkt und keine Lizenzdatei zum Verlinken. Die Bedingungen der Datei sind die Lizenz, die Sie auf das Repository anwenden. Reines Markdown passt zu einer kurzen Notiz, einem Spike oder einem Team, das die Prosa durch Lesen prüfen wird. Siehe SpecScore vs reines Markdown.
SpecScore
SpecScore ist ein Format für die Spezifikation — Features, Anforderungen und Akzeptanzkriterien als Markdown mit YAML — und ein CLI, das die Dateien prüft. Das Format liegt in specscore/specscore. Das CLI liegt in specscore/specscore-cli.
Wie man die Kriterien so schreibt, dass ein Agent sie prüfen kann, steht in Akzeptanzkriterien schreiben.
Eine Markdown-Vorlage für eine Feature-Spezifikation — Anforderungen, Akzeptanzkriterien, ein Plan und Aufgaben — steht in PRD-Vorlage in Markdown.
Spec-driven Development mit Claude Code und Cursor — die Feature-Datei, die Anweisungsdatei des Agenten und specscore spec lint in der Schleife stehen in Spec-driven Development mit Claude Code und Cursor.
Wie man diesen Linter in der kontinuierlichen Integration ausführt, steht in Spezifikationen in CI linten.
Im Repository dieser Website installiert dogfood.yml dieses CLI und führt specscore spec lint bei Pull Requests und bei Pushes auf main aus. Eine Spezifikation, die das Format bricht, lässt diesen Job fehlschlagen. Der /score-Skill ist eine manuelle KI-Bewertung: Er führt die konfigurierten Reviewer erneut aus, wenn Sie danach fragen, und der Dogfood-Workflow ruft ihn nicht auf.
Die Lizenz des Formats ist CC BY 4.0, in specscore/specscore. Die Lizenz des CLI ist Apache-2.0, in specscore/specscore-cli. SpecScore passt zu einem Team, das braucht, dass die Spezifikation die CI fehlschlagen lässt, wenn eine Überschrift, ein Link oder ein Status falsch ist, gleich welcher Agent die Datei geschrieben hat. openspec validate ist die am nächsten liegende strukturelle Prüfung unter den anderen Werkzeugen hier; sie prüft die eigene Änderungsform von OpenSpec. Die einzelnen Vergleiche beginnen unter /vs/.
Wie Sie wählen.
Wählen Sie GitHub Spec Kit, OpenSpec, die BMAD Method oder Datarim, wenn Sie einen geführten Prozess wollen und Markdown, das Sie in einem Pull Request prüfen können. Wählen Sie Kiro, wenn dieses Produkt EARS-Anforderungen entwerfen soll. Wählen Sie Task Master AI, wenn das PRD zu einer Aufgabenliste werden soll. Wählen Sie CodeSpeak, wenn die Absicht aus Chats innerhalb dieses Produkts erfasst werden soll. Wählen Sie Tessl, wenn das Problem Agent-Skills sind, mit dem Spec-Tile als optionaler Steuerung.
Wählen Sie SpecScore, wenn die Spezifikationsdatei selbst die CI fehlschlagen lassen muss. Die Prüfung in diesem Repository ist specscore spec lint in dogfood.yml. Ein Workflow aus der Liste oben kann weiterhin die Art sein, wie die Spezifikation geschrieben wird.
Quellen.
Gelesen am 30. Oktober 2026, außer wo eine Seite ihr eigenes Aktualisierungsdatum nennt. Preise und Plannamen sind ausgelassen, weil sie sich ändern.