Vergleich
Deep Work Plan und die Alternativen
Wählen Sie die richtige Ebene für Ihre Situation. Jede Alternative wird in ihren eigenen Begriffen beschrieben, jede Angabe lässt sich zur offiziellen Dokumentation zurückverfolgen, und die Seite nennt das Datum der letzten Prüfung. Dies ist eine Karte, keine Rangliste.
Wie Sie diese Seite lesen
Drei Werte beschreiben jede Fähigkeit. Sie sagen, wo eine Fähigkeit in einem Werkzeug liegt — nicht, wie gut das Werkzeug ist.
- Integriert
- Optional oder über Erweiterung
- Nicht im Umfang
Zuletzt geprüft:
Die Alternativen, in ihren eigenen Begriffen
Werkzeuge für spec-driven Entwicklung
-
Werkzeuge für spec-driven Entwicklung
GitHub Spec Kit
Überführt ein Feature über eine Konstitution, eine Spezifikation, einen Plan und eine Aufgabenliste in eine ausführbare Spezifikation, angetrieben von Slash-Befehlen, die mehr als fünfzig Coding-Agenten integrieren, und kann prüfen, ob die Artefakte vor Beginn der Umsetzung untereinander konsistent bleiben.
Teams, die einen wiederholbaren Workflow aus Specify, Plan, Tasks und Implement im bereits genutzten Agenten wollen.
-
Werkzeuge für spec-driven Entwicklung
OpenSpec
Erfasst jede Änderung als Proposal mit Delta-Specs (hinzugefügt, geändert, entfernt) und RFC-2119-Anforderungen mit Szenarien und archiviert sie anschließend in lebenden Spezifikationen, mit einem Validator, der Vollständigkeit des Proposals und Szenario-Abdeckung prüft, bevor eine Änderung akzeptiert wird.
Teams an bestehenden Systemen, deren Spezifikationen Änderung für Änderung wachsen sollen.
-
Werkzeuge für spec-driven Entwicklung
Amazon Kiro
Eine agentische IDE und CLI, deren Spezifikationen von EARS-artigen Anforderungen über das Design zu Aufgaben führen, mit Steering-Dateien und Hooks, die auf Editor-Ereignissen laufen, und die Spezifikationen für eine bestehende Codebasis erzeugen kann, um Lücken in den Anforderungen schon vor dem Design zu erkennen.
Entwickler, die spec-driven Development fest im Editor integriert haben möchten, gestützt auf AWS-Werkzeuge.
Agenten-Workflow-Frameworks
-
Agenten-Workflow-Frameworks
BMAD Method
Ein agiles Framework spezialisierter Agentenrollen (Analyse, Produkt, Architektur, Entwicklung, Qualität), das Briefings, Anforderungen, Architekturdokumente und Story-Dateien erzeugt, mit einer Definition of Done, die verlangt, dass jede Story von einem Teammitglied oder einem KI-Peer-Reviewer geprüft wird, bevor sie als abgeschlossen gilt.
Teams, die rollenbasierte Zeremonien schätzen und für Agentenarbeit einen vollständigen agilen Lebenszyklus wollen.
-
Agenten-Workflow-Frameworks
Superpowers
Eine Skills-Bibliothek und ein Workflow für Brainstorming, Planung in kleinen Test-first-Schritten, Ausführung mit Subagenten und Review vor dem Abschluss, mit mehr unterstützten Coding-Agenten-Hosts als jede andere Alternative auf dieser Seite, plus einem zweistufigen Subagenten-Review (Spezifikationstreue, dann Codequalität) bei jeder Aufgabe.
Entwickler, die disziplinierte testgetriebene Ausführung innerhalb ihres Coding-Agenten wollen.
-
Agenten-Workflow-Frameworks
GSD Core
Ein Planungssystem mit einem .planning-Verzeichnis, Anforderungs-IDs, Phasenplänen, Ausführung mit frischem Kontext und einem Verifizierungsdurchlauf gegen die aus der Zusammenfassung jedes Plans abgeleiteten, für Nutzer beobachtbaren Ergebnisse — gezielt gegen Context Rot ausgelegt, indem Recherche, Planung und Ausführung in wegwerfbaren Subagenten laufen und veraltete Verifizierungen per Content-Fingerprint erkannt werden.
Einzelentwickler und kleine Teams, die Context Engineering und Verifizierung mit wenig Zeremoniell wollen.
-
Agenten-Workflow-Frameworks
Gentle-AI
Konfiguriert die Coding-Agenten, die Sie bereits nutzen, mit persistentem Gedächtnis, das zusätzlich über Sitzungen und Modelle hinweg routet, kuratierten Skills, MCP-Servern, Personas und optionalem Spec-Driven Development oder Receipt-Driven Development. Die Konfiguration wird standardmäßig in die globalen Agenten-Einstellungen geschrieben; eine auf das Workspace beschränkte Installation ist optional.
Entwickler, die ein konfiguriertes Agenten-Ökosystem wollen, das sich sitzungsübergreifend erinnert und bei Bedarf Nachweise liefert.
AI-native SDLC
-
AI-native SDLC
Claudes AI-native SDLC
Ein sechsstufiger Kreislauf von Plan und Design über Build, Test, Deploy bis Maintain, mit verpflichtender menschlicher Freigabe in jeder Stufe, dauerhaften Artefakten, die zwischen den Stufen ins Repository committet werden, einem eigenen, als Sicherheit gekennzeichneten Review-Durchlauf vor dem Deploy und kontinuierlichen Evals, die vorlaufende und nachlaufende Liefer-Indikatoren veröffentlichen.
Teams, die Claude Codes durchgängigen Software-Delivery-Playbook und seinen Produktions-Feedback-Loop evaluieren.
Hersteller-native Plan-Modi
-
Hersteller-native Plan-Modi
Hersteller-native Plan-Modi
Claude Code, Codex, Cursor und Gemini CLI liefern Plan-Modi, Anweisungsdateien und Skills, die auf den offenen, herstellerübergreifenden Standards AGENTS.md und Agent Skills aufbauen, auch wenn das genaue Verhalten des Plan-Modus weiterhin von Hersteller, Client und Version abhängt. Agent Skills insbesondere lädt beim Start nur eine kurze Zusammenfassung und die vollständigen Anweisungen erst bei Aktivierung, sodass ungenutzte Fähigkeiten den Kontext nicht belasten.
Alle, die Planung innerhalb eines einzelnen Agenten wollen, ohne eine Methodik zu übernehmen.
Was Deep Work Plan mitbringt
-
Werkzeug-agnostisch und repository-nativ
Das Harness und der Plan sind Dateien in Ihrem Repository, lesbar für jeden Agenten, der den AGENTS.md- und Agent-Skills-Standards folgt. Ein Agentenwechsel verliert den Plan nicht.
-
Validierung, ausgewählt aus dem, was jede Aufgabe berührt hat
Jede Aufgabe deklariert ihre berührte Oberfläche und führt die Tests des geänderten Verhaltens und seiner Konsumenten aus, ausgeweitet auf die gesamte Suite, wenn die Wirkung sich nicht abgrenzen lässt. Null ausgewählte Tests sind niemals ein Bestehen.
-
Ein Final Review mit Sicherheitstest
Ein Plan schließt mit einer Sicherheitsprüfung der kumulierten Änderungsmenge — einschließlich eines erforderlichen lokalen Reviews des Diffs — und einer Validierung des Endzustands. Kritische Befunde blockieren den Abschluss.
-
Zustand, der Sitzungen und Agenten übersteht
README-Checkboxen, Aufgabenprotokolle, ein begrenzter Arbeitsindex und eine maschinenlesbare Zustandsdatei werden an jeder Grenze geschrieben, sodass eine andere Sitzung oder ein anderer Agent von der Festplatte aus weitermacht. Selbst eine unterbrochene Planerstellung ist wiederherstellbar.
-
Ein Konformitätsprüfer für das Repository selbst
Ein nur lesendes Skript verifiziert das Harness und jeden Plan gegen die Spezifikation, versteht beide Plan-Lebenszyklen und beendet sich mit einem CI-freundlichen Code.
-
Instruktionslast gemessen und veröffentlicht
Ein committetes Skript veröffentlicht zwei Messwerte pro Flow — das Einstiegs-Bundle, das er zu Beginn einer Sitzung lädt, und den End-to-End-Pfad, sobald seine eigentlichen Trigger auslösen — dazu, was jeder Wert ausschließt, sodass die Einstiegszahl allein nie als Gesamtkosten eines Laufs gelesen wird. Die Ergebnisse, Zunahmen eingeschlossen, werden als Bytes veröffentlicht, niemals als Token- oder Kostenprozente.
Ehrliche Grenzen
Deep Work Plan hat keinen Mechanismus für lebende oder Delta-Spezifikationen; OpenSpec und ähnliche Werkzeuge sind dort stärker. Ein unabhängiger Benchmark der Methodik existiert noch nicht; eine eigene Evaluation mit frischen Agenten ist unter einem eingefrorenen Protokoll gelaufen — im kleinen Maßstab: eine Workload, zwei Features pro Konfiguration, eine Maschine — und ihre Ergebnisse werden in beide Richtungen veröffentlicht: Agenten auf Harness-tragenden Bäumen lasen in beiden Aufgaben weniger Bytes, und die Sitzungen der aktuellen Version verbrauchten weniger vom Harness berichtete Modell-Ein- und -Ausgabe als die der vorherigen Major-Version, während die Netto-Token-Richtung je Workload gemischt war und kein Wanduhr-Vorteil beansprucht wird. Das Instruktionslast-Ledger misst geladene Bytes, nicht Token, Kosten oder Ergebnisse, und sein Einstiegs-Bundle-Wert ist keine Obergrenze dessen, was ein Lauf liest. DWP ist bewusst auf das Repository begrenzt: Es ist kein projektübergreifendes Gedächtnissystem, kein rollenbasiertes Agenten-Framework und keine IDE, und tritt auf diesen Achsen daher auch nicht an – kombinieren Sie es bei Bedarf mit einem Werkzeug, das genau das abdeckt.
Helfen Sie uns, diese Seite korrekt zu halten
Helfen Sie uns, diese Seite korrekt zu halten
Diese Seite wird am angezeigten Datum geprüft und auf Anfrage korrigiert. Ist eine Beschreibung Ihres Werkzeugs veraltet oder unvollständig, eröffnen Sie ein Issue, und wir korrigieren es.