Spec Kit ohne schweres CLI: Spec-Driven Development im eigenen Projekt mit Cursor umsetzen

Der Artikel richtet sich an Entwickler, Analysten und technische Autoren, die spezifikationsgesteuerte KI-Entwicklung in Cursor nutzen möchten, ohne das vollständige Spec Kit von GitHub bereitzustellen. Statt der kompletten Pipeline (constitution, specify, plan, tasks, implement) schlagen sie ein Minimalpaket vor: eine Verfassung mit unveränderlichen Repository-Regeln, eine Aufgabenspezifikation, eine explizite menschliche Zustimmung (der Agent kann sich nicht selbst zustimmen), eine Implementierung auf Basis der vereinbarten Spezifikation und einen Verweis auf die aktive Arbeit. Sie argumentieren, dass zusätzliche Schritte wie Plan, Tasks und Massen-Neubauten oft überflüssig sind, Rauschen erzeugen und Überschreibungen riskieren. Der angepasste Ansatz besteht aus drei Teilen: Cursor-Regeln (immer im Kontext), Fähigkeiten (explizite Befehle wie /project-init, /project-specify, /project-implement) und Repository-Artefakte (Verfassung, Spezifikationen, Entwürfe, feature.json-Verweis). Der Arbeitsablauf ist: init, specify, menschliche Zustimmung, implement. Die Verfassung schreibt Projektziele, Pipelinestufen, was zu vermeiden ist (Plan/Tasks), Trennung von semantischer und Ergebnis-Ebene, Treue zu Quellen mit [NOT KNOWN]-Tags, reasoning_temperature niedrig für die Implementierung, Verbot von Geheimnissen und klare Verfahren zur Änderung der Verfassung vor. Die Implementierung ist nur zulässig, wenn die Spezifikation den Status "zugestimmt" hat und keine blockierenden unbekannten Punkte vorliegen. Sie skizzieren auch häufige Fehler und weisen darauf hin, dass der vereinfachte Zyklus für inkrementelle Aufgaben ausreicht, während das vollständige Spec Kit für diejenigen gedacht ist, die seine CLI oder die standardmäßige mehrstufige Pipeline benötigen. Beide Ansätze sind kompatibel; Artefakte können wiederverwendet werden. Der Artikel schließt mit der Betonung der Pipeline-Disziplin gegenüber der Verzeichnisstruktur.