Fragen, die Reviewer wirklich gestellt haben.

spec-kit ist eine Methodik – ein Prozess zum Schreiben von Spezifikationen.SpecScore ist ein Speicherformat für die Spezifikationen, die du schreibst, plus eine CLI zum Abfragen und Bearbeiten. Die beiden ergänzen sich: spec-kit kann SpecScore-Dateien erzeugen, und eine spec-kit-Erweiterung, die im SpecScore-Format schreibt, ist bereits in Arbeit.

Wähle spec-kit, wenn du einen Prozess brauchst. Wähle SpecScore, wenn du Spezifikationen brauchst, die KI-Agenten linten, abfragen und ändern können, ohne jede Datei im Repository zu lesen. Nutze beide, wenn du beides möchtest.

Im Ansatz ähnlich. Alle drei sind Skill-Bibliotheken, die KI-Agenten durch ideate → specify → plan → implement führen. Der Unterschied ist technischer, nicht philosophischer Natur.

SpecStudio Skills schreibt seine Artefakte im SpecScore-Format (eine definierte Struktur aus Markdown + YAML) und steuert die CLI specscore für Abfragen, Linting und Statusänderungen an. Superpowers und agent-skills lesen und schreiben Dateien weitgehend direkt aus der Prosa des Skills heraus.

Wähle SpecStudio Skills, wenn der Token-Verbrauch zählt – die CLI liefert eine strukturierte Antwort auf „alle offenen Features mit ungeklärten Fragen“ in einem einzigen Aufruf, während ein dateibasierter Skill dafür N Dokumente einlesen muss.

Skills können Dateien lesen und schreiben. Sie können jedoch nicht zuverlässig:

• referenzielle Integrität im gesamten Spezifikationsbaum garantieren (dass Links auflösen, IDs eindeutig sind, Indizes synchron gehalten werden);
• eine gefilterte Liste „offener Features mit unbeantworteten Fragen“ zurückgeben, ohne jede Datei zu lesen;
• das richtige Statusfeld zum richtigen Zeitpunkt in jedem Artefakt mutieren.

Die CLI bietet Agenten einen sauberen Aufruf pro Aufgabe – genauso wie jq einen sauberen Aufruf für JSON-Abfragen bietet. Skills allein verbrauchen mehr Tokens, weichen häufiger ab und vergessen oft, den Index zu aktualisieren.

„Score“ lässt sich auf zwei Arten verstehen, und beide sind beabsichtigt.

Partitur. Eine strukturierte Partitur aus Anforderungen – genau wie eine Musikpartitur Stimmen, Parts und Takte strukturiert. Öffne einen SpecScore-Baum und du solltest ihn wie ein Dirigent lesen können: Hierarchie, Teile, Referenzen – alles auf einen Blick sichtbar.

Eine buchstäbliche Qualitätsbewertung. Der Linter der CLI ist die deterministische Prüfung (hält die Struktur der Spezifikation stand?). Der Skill /scoreist die KI-Beurteilung – eine Reifegradnote von A bis F pro Artefakt, mit Achsen-Feedback für den Autor. Der Namensteil „Score“ wird so zu einem konkreten Feature, das das Tool liefert, nicht nur zu einem Wunschgedanken.

Ein gemessener Direktvergleich ist in Arbeit und wird vor dem Veröffentlichungsbeitrag publiziert – dieselbe Aufgabe („Woran sollte ich als Nächstes arbeiten?“), zweimal ausgeführt: einmal mit einem Agenten ohne CLI, der Dokumente liest, und einmal mit demselben Agenten, der die SpecScore-CLI aufruft. Gemessen werden Token-Anzahl und Antwortzeit für beide Fälle.

Bis diese Zahlen vorliegen, gilt das strukturelle Argument: Ein Agent, der die CLI nach offenen Features und ungeklärten Fragen fragt, erhält eine kompakte, strukturierte Antwort. Derselbe Agent ohne CLI liest N Dokumente – oft Dutzende. Die CLI-Oberfläche ist genau dafür gebaut, dieses Ausufern an Lesevorgängen zu vermeiden.

Spezifikation und Dokumentation im öffentlichen Repository specscore/specscore stehen unter CC BY 4.0. Die Referenz-Befehlszeilenschnittstelle (CLI) in specscore/specscore-cli steht unter Apache-2.0.

Nein. Spezifikationen sind Textdateien im Repository. Die CLI ist ein lokales Programm. Die AI Skills auf dieser Website kapseln diese CLI für Agenten, die Skills ausführen können. Das Format verlangt keinen einzelnen Anbieter.

Spezifikationsgetriebene Entwicklung (SDD) heißt: zuerst eine testbare Spezifikation schreiben — Anforderungen und Akzeptanzkriterien — und das Ergebnis danach dagegen prüfen. SpecScore ist ein Dateiformat für diese Spezifikationen.