SpecScore vs Plain Markdown
Die meisten Teams haben bereits „Spezifikationen“ — als Ad-hoc-Markdown in einem Docs-Ordner, Notion-Seiten oder Jira-Tickets. Es ist kostenlos, bereits vorhanden und funktioniert. SpecScore ist das selbe Markdown, plus die Struktur, die ein KI-Agent linten, abfragen und bis zum Code zurückverfolgen kann.
Was sie gemeinsam haben.
Was der Standard gut macht.
Plain Markdown, Notion und Jira sind der tatsächliche Standard. Sie haben sich diesen Platz verdient.
Null Lernkurve
Kein Schema, keine Pflichtfelder, kein CLI im Arbeitsablauf. Datei öffnen, losschreiben. Für eine schnelle Notiz oder ein winziges Projekt ist das genau richtig — Struktur, die man nicht braucht, ist nur Reibung.
Bereits installiert
Ihr Team nutzt bereits Notion, Confluence oder einen docs/-Ordner. Nichts einzuführen, nichts zu migrieren. Die Option mit dem geringsten Widerstand ist die, die Sie bereits nutzen.
Universell portabel
Plain Markdown lässt sich überall öffnen und überlebt jedes Tool. SpecScore baut auf genau dieser Eigenschaft auf — deshalb ist SpecScore ebenfalls Markdown und keine Datenbank.
Feature-Vergleich.
Der Unterschied liegt nicht in der Datei — sondern darin, was ein Agent damit tun kann.
| Fähigkeit | Plain Markdown / Notion | SpecScore |
|---|---|---|
| Format | Freies Markdown / Docs | Markdown + YAML-Frontmatter (strukturiert) |
| Wo Anforderungen leben | Jira, Notion, Slack, im Kopf von jemandem | Im Repository, direkt neben dem Code |
| „Ist diese Spezifikation vollständig?“ | Ein Mensch liest sie und entscheidet | specscore lint — automatisch |
| Erkennung von Mehrdeutigkeiten | Keine — vage Verben passieren unbemerkt | Vage Verben, fehlende ACs, hängende Referenzen werden markiert |
| Anforderungs- / AC-IDs | Keine | Maschinenadressierbare IDs (REQ: slug) |
| Lebenszyklus-Status | Implizit, falls überhaupt erfasst | Durchgesetzt — Draft → Approved → Implementing → Stable |
| Code-zu-Spezifikation-Rückverfolgbarkeit | Keine | specscore:-Annotationen + Verifies:-Trailer |
| Agenten-Navigation | Jede Datei durchlesen, um etwas zu finden | Spezifikationsgraph abfragen über das CLI |
| CI-Qualitäts-Gate | Keines | specscore lint beendet sich mit Non-Zero-Code, wie ein Linter |
| Lernkurve | Keine | Ein Format zu lernen (inkrementell) |
| Kosten / Lizenz | Kostenlos | Kostenlos, Open Source |
Wo SpecScore weiter geht.
Mehrdeutigkeit wird erkannt, nicht interpretiert
Bei frei formulierten Spezifikationen beginnt jede Agenten-Interaktion mit Interpretation — „Login sollte funktionieren“ ist ein Münzwurf zwischen korrekt und plausibel-aber-falsch. Das lint von SpecScore markiert vage Verben und fehlende Akzeptanzkriterien, bevor ein Agent darauf aufbaut.
$ specscore lint auth/login.md ✗ R1 "should work" — nicht messbar ✗ R1 no acceptance criteria
Fehlinterpretationen summieren sich nicht mehr auf
Ein Agent missversteht eine Anforderung, ein zweiter baut darauf auf, ein dritter hängt von beiden ab — und Sie bemerken es erst drei Agenten später. Strukturierte Akzeptanzkriterien geben jedem Agenten dieselben Pass/Fail-Bedingungen, sodass die Interpretation zwischen ihnen nicht driftet.
Code lässt sich zurück zur Spezifikation verfolgen
Einfache Docs haben keine Verbindung zum Code, der sie implementiert. SpecScore ergänzt Quellcode-Annotationen specscore: und Commit-Trailer Verifies: — specscore code refs beantwortet deterministisch: „Welcher Code implementiert diese Anforderung?“
Eine Spezifikation statt vierzig Tickets
Ein neues Teammitglied (oder ein frischer Agent) liest eine Feature-Spezifikation mit vollem Kontext, statt die Intention mühsam aus vierzig Jira-Tickets und einem Slack-Thread zu rekonstruieren.
Agenten fragen ab, statt alles neu zu lesen
In einem Docs-Ordner bedeutet „Was ist in Arbeit?“, Dateien durchzusehen. In SpecScore heißt es specscore feature list — der Spezifikationsgraph antwortet über das CLI, sodass Agenten keinen Kontext mit dem wiederholten Einlesen des Repositories verschwenden.
Qualität wird in CI durchgesetzt
Frei formulierte Spezifikationen haben kein Gate — eine halb geschriebene Datei wird genauso leicht gemergt wie eine vollständige. specscore lint beendet sich bei Problemen mit einem Exit-Code ungleich null, genau wie ESLint oder go vet Ihren Code schützen.
Wann Sie welches Werkzeug nutzen sollten.
Plain Markdown reicht aus, wenn…
- Es sich um eine einmalige Notiz, einen Spike oder ein Projekt handelt, das zu klein für zusätzliche Struktur ist.
- Kein KI-Agent auf Basis des Dokuments baut — ein Mensch liest es und versteht es direkt.
- Sie eine grobe Idee festhalten, keine Anforderung, die jemand implementieren wird.
Greifen Sie zu SpecScore, wenn…
- Ein KI-Agent auf Basis der Spezifikation baut — Mehrdeutigkeit wird zu fehlerhaftem Code.
- Mehrere Agenten oder Personen von denselben Anforderungen abhängen.
- Sie wissen müssen, welcher Code welche Anforderung implementiert.
- „Ist diese Spezifikation fertig?“ von einem Tool beantwortet werden sollte, nicht in einem Meeting.
- Das Projekt groß genug ist, dass wiederholtes Lesen aller Dokumente nicht mehr skaliert.
Lassen Sie vorhandene Spezifikationen wachsen.
Sie müssen weder Ihr Backlog umstellen noch Ihre Tools austauschen. Wählen Sie Ihr nächstes Feature, schreiben Sie dafür eine SpecScore-Spezifikation und führen Sie specscore lint aus — prüfen Sie, ob es Dinge findet, die Ihr Ticket übersehen hat. Ergänzen Sie specscore:-Annotationen bei der Implementierung. Erweitern Sie es erst auf den nächsten Sprint, wenn es geholfen hat.
Plain Markdown ist die Auffahrt. SpecScore ist das, wozu es sich weiterentwickelt.
Weitere Vergleiche.
Dasselbe Format, neben anderen Werkzeugen der spezifikationsgetriebenen Entwicklung:
Alle zusammen, auf einer Seite: beste Werkzeuge für spezifikationsgetriebene Entwicklung 2026.
Rückmeldung
Dieser Vergleich beruht auf öffentlich zugänglicher Dokumentation und öffentlichem Quellcode. Etwas falsch oder veraltet? öffnen Sie ein Korrektur-Issue. Sollen wir SpecScore mit einem anderen Werkzeug vergleichen? fordern Sie einen an.