Nutze die an GitHub Spec Kit angelehnte Projektvorlage Governed Spec in Manager: Schreib einmal eine Verfassung und führe dann jedes Feature durch Spezifikation, Klarstellung, Planung, Aufgaben, Analyse und Umsetzung.
Regeln zu Tests, Architektur und Konventionen stehen in einer kurzen Verfassung, der Constitution. Jede Spezifikation, jeder Plan und jede Aufgabe wird daran gemessen.
Die Spezifikation hält priorisierte User Stories, Anforderungen und Erfolgskriterien fest. Technologieentscheidungen warten auf den Plan.
Clarify räumt Unklarheiten vor der Planung aus; Analyze gleicht Spezifikation, Plan und Aufgaben ab, bevor Code entsteht.
Bei Spec Kit ist die Spezifikation die Quelle des Codes: erst was und warum, dann wie. Die CLI specify (specify init) richtet ein Repository ein, und /speckit.constitution schreibt die Prinzipien nach .specify/memory/constitution.md.
Pro Feature schreiben /speckit.specify, /speckit.plan und /speckit.tasks spec.md, plan.md und tasks.md unter specs/, /speckit.implement baut es, und /speckit.converge hängt an, was noch fehlt. Optionale Gates: /speckit.clarify vor der Planung und /speckit.analyze, eine Prüfung, die nichts ändert und bei der Konflikte mit der Verfassung kritisch sind.
Angelehnt an GitHub Spec Kit, MIT © GitHub, Inc. (github.com/github/spec-kit). Nicht mit GitHub verbunden oder von GitHub empfohlen.
Wo jeder Befehl und jedes Artefakt von Spec Kit in deinem Projekt liegt.
| Spec Kit | In Manager |
|---|---|
| constitution.md | Der Skill constitution, dazu deine Prinzipien auf einer Wiki-Seite oder in der Projektbeschreibung. |
| Feature-Ordner (specs/001-name/) | Eine Aufgabe vom Typ Feature; der gespeicherte Filter „Features“ listet alle. |
| spec.md, plan.md | Die Beschreibung des Features oder verknüpfte Wiki-Seiten. |
| [NEEDS CLARIFICATION] | Das Label Needs-Clarify am Feature, solange Fragen offen sind. |
| tasks.md, Markierung [P] | Aufgaben vom Typ Task mit dem Feld User Story; parallele bekommen das Label [P]. |
| Analyze-Bericht | Ein Kommentar am Feature; Verstöße bekommen das Label Constitution-Violation. |
| /speckit.*-Befehle | Ein Skill pro Befehl, gespiegelt in den Status des Features. |
Verbinde deinen Agenten über MCP und lass ihn ein Projekt aus der Vorlage Governed Spec anlegen.
Sag deinem AgentenManager: Leg ein Projekt aus der Vorlage Governed Spec an und frag mich, was wir bauen.
Leg deine unverhandelbaren Prinzipien fest: Tests, Architektur, Konventionen, Ansprüche an Performance und UX. Halte sie kurz: Eine Regel, die du nicht durchsetzt, gehört nicht hinein.
Sag deinem AgentenManager: Führ den Skill constitution aus, frag mich nach unseren Prinzipien und schreib sie auf eine Wiki-Seite.
Der Skill specify schreibt priorisierte User Stories, Anforderungen und Erfolgskriterien. Der Skill clarify fragt nach Lücken, das Feature trägt so lange Needs-Clarify.
Sag deinem AgentenManager: Führ den Skill specify für mein nächstes Feature aus und klär danach die offenen Fragen mit mir.
Der Skill plan entscheidet das Wie und prüft es gegen die Verfassung. Der Skill tasks legt geordnete Aufgaben pro User Story an.
Sag deinem AgentenManager: Führ für dieses Feature den Skill plan und danach den Skill tasks aus.
Eine Prüfung, die nichts ändert, sucht Anforderungen ohne Aufgabe, Aufgaben ohne Anforderung und Widersprüche und schreibt die Befunde als Kommentar ans Feature.
Sag deinem AgentenManager: Führ den Skill analyze für dieses Feature aus und zeig mir die Befunde.
Nach einer sauberen Analyse arbeitet der Skill implement die Aufgaben Story für Story ab und setzt das Feature auf „Erledigt“, sobald es seine Spezifikation erfüllt.
Sag deinem AgentenManager: Führ den Skill implement für dieses Feature aus.
Ein Projekt aus der Vorlage Governed Spec startet mit diesen Aufgabentypen und Status. Anpassen kannst du alles später an dein Team.
Ein Feature von der Spezifikation bis zur Umsetzung, gebunden an die Verfassung.
Eine Arbeitseinheit, gruppiert nach User Story.
Diese Skills bringt die Vorlage in Manager mit:
constitutionLegt die unverhandelbaren Prinzipien fest, im Wiki oder in der Projektbeschreibung.
specifyLegt ein Feature mit priorisierten User Stories und Anforderungen an.
clarifyKlärt Unklarheiten vor der Planung mit dir, markiert mit Needs-Clarify.
planSchreibt den technischen Plan, samt Abgleich mit der Verfassung.
tasksLegt geordnete Aufgaben pro User Story an, parallele mit [P].
analyzePrüft Spezifikation, Plan, Aufgaben und Verfassung rein lesend vor der Umsetzung.
implementArbeitet die Aufgaben nach sauberer Analyse Story für Story ab.
Die Reihenfolge sichern die Skills; ein Feature lässt sich trotzdem von Hand verschieben. Ein Feature mit Needs-Clarify oder Constitution-Violation ist nicht bereit für die Umsetzung.
Artefakte liegen an Aufgaben und auf Wiki-Seiten statt in Dateien im Repository. „Klarstellung“ und „Analyse“ sind feste Schritte.
Nimm die Vorlage, wenn viele Menschen oder Agenten dieselben Standards einhalten müssen. Für bestehenden Code ist Change-Driven leichter; Spec-Driven passt zu Releases, Test-Driven zu testgetriebener Arbeit.
Die Verfassung, jede Spezifikation und jeder Befund liegen dort, wo dein Team sie prüfen kann.
Vorabzugang anfragen