# Jede Unklarheit in deiner Spezifikation ist ein Token, den dein Agent verbrennt.

Canonical: https://specscore.md/de/

SpecScore ist ein offenes, lintbares Dateiformat für Spezifikationen, geschrieben in Markdown und YAML (YAML Ain't Markup Language) – wie JSON (JavaScript Object Notation) für Daten – mit einer Befehlszeilenschnittstelle (CLI), die deine Agenten aufrufen, um sie abzufragen und zu bearbeiten, wie `jq` für JSON.

Zuletzt aktualisiert: 30. Oktober 2026

Erst eine Rückfrage mitten im Build. Dann ein Fix nach dem Release. Dann der Kontext, den du immer wieder neu erklären musst.

 Open-Source auf GitHub KI-Skills für deinen Agenten CLI installieren

## Ein Format für die Spezifikationen, die du bereits schreibst.

**SpecScore ist ein Markdown + YAML-Format** für Features, Anforderungen und Akzeptanzkriterien. Es definiert eine Struktur, die dein Team und deine KI-Agenten gleichermaßen verstehen – und es sind einfach Dateien in deinem Repository.

Ein SpecScore-Projekt besteht aus drei Arten von Artefakten entlang eines Lebenszyklus: Eine **Idea** erfasst eine grobe Richtung; eine **Feature**-Spezifikation friert das vereinbarte Verhalten ein; ein **Plan**zerlegt das Feature in geordnete Aufgaben, von denen jede die Akzeptanzkriterien nennt, die sie erfüllt.

**Warum es für deinen Agenten wichtig ist.** Weil die Struktur maschinenlesbar ist, können KI-Agenten die Spezifikation über die CLI abfragen, anstatt jede Datei einzulesen. Frage *„Woran sollte ich als Nächstes arbeiten?“*und die CLI liefert offene Features und ungeklärte Fragen. Die gleiche Form, die dein Team prüft; deutlich weniger Kontext, den der Agent laden muss.

 Feature → Requirements → Acceptance Criteria → Scenarios. idea → feature → plan BEISPIEL ideas/apply-discount.md

```
# Idea: Discount codes at checkout **Status:** Approved **Date:** 2026-05-19 **Owner:** cart-team **Promotes To:** features/apply-discount ## Problem Statement How might we let returning customers redeem a single promo code at checkout without breaking the existing cart math or the site-wide promotion engine? ## Recommended Direction A registered user can apply **one** valid code per cart. Codes are time-bounded and replaceable. Stacking with site-wide promotions follows a deterministic tiebreak rule (higher discount wins; site-wide wins on tie).
```

 BEISPIEL features/checkout/apply-discount.md

```
--- status: approved owners: [cart-team] --- # Feature: Apply Discount A registered user can apply one valid discount code to their cart at checkout. ## Requirements ### R1 — Single-code limit - **AC-1** The cart accepts at most one discount code at a time. - **AC-2** Applying a second code replaces the first, with a visible confirmation. - **AC-3** Removing the code restores the original cart total. ### R2 — Code validity - **AC-1** A code is valid only if `valid_from` ≤ now ≤ `valid_until` . - **AC-2** Invalid codes show a specific error message. ### R3 — Discount application - **AC-1** Percentage discounts apply to subtotal, not shipping. - **AC-2** Discount totals round down to the nearest cent. - **AC-3** Stacking with site-wide promotions follows the higher-of rule. ## Scenario: Apply a valid percent-off code **GIVEN** a cart with subtotal $50.00 and shipping $10.00 **WHEN** the user applies code `SAVE20` (20% off) **THEN** the cart shows subtotal $40.00, shipping $10.00, total $50.00
```

 BEISPIEL plans/apply-discount/README.md

```
# Plan: Apply Discount **Status:** approved **Features:** - [apply-discount](../../features/apply-discount.md) **Author:** cart-team **Effort:** M **Impact:** high ## Context The apply-discount Feature is Approved. This plan breaks it into ordered tasks; each task cites the acceptance criteria it satisfies. ## Tasks ### T1 — Accept a `code` field on the cart Cites: R1.AC-1, R1.AC-2, R1.AC-3 ### T2 — Validate code time-window Cites: R2.AC-1, R2.AC-2 ### T3 — Apply percentage to subtotal, round down Cites: R3.AC-1, R3.AC-2 ### T4 — Higher-of tiebreak vs site-wide promo Cites: R3.AC-3 ### T5 — Confirmation toast on apply / replace Cites: R1.AC-2
```

## Spezifikationen sind hierarchisch. Dein Spezifikationsbaum auch.

Eine flache Liste mit fünfzig Features verkommt zur Müllhalde. SpecScore hält den Baum navigierbar: Eltern definieren den Umfang, Kinder die Details, und die Verzeichnisstruktur spiegelt die Produktarchitektur wider, über die dein Team ohnehin nachdenkt.

**Offene Fragen steigen nach oben.** Unbeantwortete Fragen auf jeder Tiefe erscheinen im Index jedes übergeordneten Elements. Du siehst direkt an der Spitze des Baums, was ein Release blockiert, ohne graben zu müssen.

Die meisten Spezifikationswerkzeuge gehen davon aus, dass eine flache Liste ausreicht. Und das tut sie auch – bis sie es nicht mehr tut. SpecScore ist für den Moment gebaut, in dem die Frage „Wo gehört dieses Feature hin?“ entscheidend wird.

[Live in specscore-cli ansehen →](https://specscore.studio/app/github.com/specscore/specscore-cli/spec/features/cli?op=explore)

 AUS specscore-cli/spec/features/cli/

```
spec/features/cli/ ├── agent/ │ └── setup/ ├── feature/ │ ├── change-status/ │ ├── deps/ │ ├── info/ │ ├── list/ │ ├── new/ │ ├── refs/ │ └── tree/ ├── idea/ │ ├── change-status/ │ ├── new/ │ └── relocate/ ├── spec/ │ └── lint/ │ ├── issue-rules/ ← Sub-Sub-Feature │ └── plan-rules/ ├── task/ │ ├── info/ │ ├── list/ │ └── new/ └── … 10 weitere Features der obersten Ebene
```

## Was ohne sie schiefgeht.

- ### 🌀 Spezifikationen driften ab. Die Spezifikation im Dokument, der Thread in Slack und der Code im PR weichen wochenlang stillschweigend voneinander ab. Niemand weiß, welche Version des Gesprächs kanonisch ist. Die Lösung Eine einzige kanonische Spezifikation im Repository, versioniert zusammen mit dem Code. `specscore lint` läuft in der CI bei jedem Push; die Git-Historie ist der Prüfpfad. Spezifikation, Thread und PR können nicht unbemerkt voneinander abweichen – sie teilen sich dieselbe geprüfte Datei.
- ### 🌫️ AC bleiben vage. *„Fehler elegant behandeln“* sollte eigentlich heißen:*„Toast anzeigen und zurückrollen.“* Oder war es*„loggen und wiederholen“?* Der Agent muss raten. Die Lösung Der Linter fängt mehrdeutige Kriterien ab, bevor auch nur eine Zeile Code geschrieben wird. Das Verb fällt durch das Linting, weil ihm ein konkretes Objekt oder eine Bedingung fehlt. Die Warnung zu beheben zwingt dich aufzuschreiben, was *„behandeln“*tatsächlich bedeutet.
- ### 🤖 Agenten liefern das Falsche. Menschen interpolieren, fragen nach, klären auf. KI-Agenten nicht – sie implementieren das Muster, das in ihren Trainingsdaten am häufigsten vorkam. Der Code besteht das Review, weil er **irgendetwas** Sinnvolles tut. Nur eben nicht das, was du meintest. Die Lösung Strukturierte Eingabe. KI-Agenten parsen REQ-IDs, AC-IDs und `GIVEN / WHEN / THEN`-Szenarien deterministisch – es gibt nichts zu interpolieren. Jeder Plan muss die AC-IDs nennen, die jede Aufgabe erfüllt, sodass das Gebaute immer gegen das Spezifizierte überprüfbar bleibt.
- ### 🔁 Du zahlst doppelt für eine vage Spezifikation. Der Agent baut etwas anhand eines mehrdeutigen Briefings, du bemerkst den Fehler und promptest ihn erneut – auf vier verschiedene Arten. Jedes halbfertige Feature und jeder Neuversuch kostet Tokens. Je vager die Spezifikation, desto mehr Runden vergehen bis zum Ziel. Die Lösung Linte die Spezifikation, bevor der Agent startet.`specscore lint` weist vage Verben und fehlende Akzeptanzkriterien von vornherein ab, sodass der Agent ein konkretes Briefing einmal umsetzt, anstatt über mehrere Schleifen hinweg zu raten. Der günstigste Agenten-Durchlauf ist der, den du nicht wiederholen musst.
- ### 💸 Agenten zahlen dafür, deine Spezifikationen neu zu lesen. Ein KI-Agent, der beantworten soll: *„Was hängt von diesem Feature ab?“*, liest das gesamte README des Features. Dann jeden übergeordneten Index. Dann geschwisterliche Features zur Sicherheit. Jede Abfrage ist ein neuer Parsing-Vorgang. Tokens verpuffen; die Latenz steigt; und die Rechnung steigt mit. Die Lösung Strukturierte Abfragen statt Datei-Lesen.`specscore feature tree` liefert die Hierarchie als YAML; `feature deps` durchläuft die transitive Abhängigkeitskette; `feature info` liefert Status, Owner und offene Fragen – jeweils in einem einzigen Aufruf. Der Agent navigiert den Graphen, nicht die Prosa.
- ### 🔗 Code vergisst seine Spezifikation. Sechs Monate später debuggst du eine Funktion und niemand erinnert sich mehr, welches Feature sie implementiert. Die Verknüpfung zwischen Code und Spezifikation lebte in jemandes Kopf – und diese Person ist längst weg. Der PR, der sie einführte, liegt tief im Archiv. Die Lösung Quellcode-Annotationen. Kommentare wie`// specscore: features/checkout/apply-discount/R1.AC-2`machen die Verknüpfung maschinenlesbar und überstehen jedes Refactoring. `specscore code deps` beantwortet*„Welche Spezifikation implementiert diese Datei?“* in einem einzigen Aufruf; der Linter markiert Referenzen auf gelöschte Spezifikationen.
- ### 🏷️ Statusänderungen laufen auseinander. Du änderst ein Feature in seinem README von *Draft*auf *Approved*, aber der übergeordnete features-index führt es weiterhin als Draft. Drei Wochen später liest ein Agent den Index und glaubt, es sei noch im Review. Der Status lebt an zwei Stellen – und sie widersprechen sich. Die Lösung `specscore feature change-status` schreibt das Status-Feld des Features um und synchronisiert die Zeile im features-index in einem atomaren Schritt neu – schlägt der Lint fehl, wird die Änderung rückgängig gemacht. Der Status existiert an einem einzigen kanonischen Ort; der Index ist eine daraus generierte Ansicht.
- ### 📋 Spezifikationen vergessen, was sie nicht wissen. Eine Spezifikation liest sich, als sei alles geklärt – bis dir einfällt, dass die Frage *„Und was ist mit Zeitzonen?“*vor zwei Monaten in einem Slack-Thread unterging und nie im Dokument landete. Jetzt bist du mitten in der Implementierung und niemand kennt die Antwort. Die Lösung Jedes SpecScore-Feature hat einen Pflichtabschnitt**Outstanding Questions**. Der Linter lehnt Features ab, die ihn auslassen – leer ist in Ordnung (`"None at this time."`), aber fehlend nicht. Ungelöste Fragen stehen sichtbar im Dokument, sind per CLI abfragbar und können nicht vergessen werden.

## Der einfachste Einstieg: SpecStudio Skills für KI-Agenten.

[SpecStudio Skills](https://github.com/specscore/specstudio-skills)ist ein Claude Code Plugin, das den SpecScore-Lebenszyklus in vier Slash-Befehle verwandelt. Einmal installieren, danach der Reihe nach ausführen – von der rohen Idee bis zum ausführbaren Plan.

```
$ /plugin marketplace add specscore/ai-marketplace $ /plugin install specstudio@specscore
```

 Claude Code Autovervollständigung

```
> /specstudio: /specstudio:ideate Eine rohe Idee in eine SpecScore Idea verfeinern /specstudio:specify Eine freigegebene Idea in eine Feature-Spezifikation umwandeln /specstudio:plan Ein Feature in einen Aufgabenplan zerlegen /specstudio:implement Die nächste Aufgabe des Plans ausführen
```

 /ideate → /specify → /plan → /implement Claude Code /ideate

```
> /ideate Lass uns überlegen, wie der Warenkorb für den Checkout aussehen sollte.
```

 Claude Code /specify

```
> /specify Lass uns spec/ideas/checkout-basket.md spezifizieren
```

 Claude Code /plan

```
> /plan spec/features/checkout/basket/README.md planen
```

 Claude Code /implement

```
> /implement spec/plans/checkout-basket/README.md umsetzen
```

Kostenlos für jede Nutzung, auch kommerziell. Der Quellcode des Plugins liegt auf[specscore/specstudio-skills](https://github.com/specscore/specstudio-skills) – unter MIT-Lizenz.

## Prüfe deine Spezifikation in zwei Durchgängen.

Ein schneller, deterministischer Linter gefolgt von einem tieferen KI-Review – ausgeführt auf der Spezifikation, die du gerade gesehen hast. Zwei Durchgänge, zwei Arten von Gewissheit.

### Linter ausführen.

 deterministic

```
$ specscore spec lint features/apply-discount/README.md:0 [error] oq-section: Open Questions section not found features/apply-discount/README.md:0 [error] index-entries: Child directory not listed in index: refunds features/apply-discount/refunds:0 [error] readme-exists: README.md not found 3 violations found (3 errors) # exit code 1
```

Das gleiche Ergebnis bei jedem Lauf. Kostenlos, blitzschnell, läuft bei jedem Commit.

### Mit KI prüfen und bewerten.

 non-deterministic

```
> /score apply-discount.md Grade: B — ready with edits AC-2 vague trigger — name the actor and event AC-3 no error path for an expired code prose reads clean; criteria need tightening
```

Liest nach Sinn und Logik, genau wie ein menschlicher Reviewer.

## Das ist, was es nicht erkennt.

Ein Linter, der behauptet, alles zu finden, lügt. SpecScore ist ein mehrschichtiges System – ein deterministischer Linter, ein KI-Reviewer und dein eigenes Urteilsvermögen – und jede Schicht hat klare Grenzen. Wir haben sie alle aufgeschrieben: was der Linter erkennt, was die KI erkennt und was weiterhin in deiner Verantwortung liegt, weil kein Werkzeug das bisher leisten kann.

[Was der Linter nicht erkennt →](/de/validators/#limits)

## Was drin steckt.

### Das Format

Markdown + YAML. Funktioniert in jedem Editor, der Text öffnet. Keine neuen Tools erforderlich, um mit dem Schreiben zu beginnen.

### Der Linter

Go-CLI. Validiert Struktur, Referenzen und Integrität. Beendet sich mit Exit-Code ungleich null bei Fehlern – funktioniert in deinem Terminal und in deiner CI.

## Bring deine eigenen Werkzeuge mit.

SpecScore besteht nur aus Dateien in deinem Repository. Kein SaaS-Abo, kein Pflicht-Orchestrator. Nutze es mit Linear, Jira, GitHub Projects, reinem Markdown in einem Ordner oder ganz ohne Projektmanagement-Tool. Dem Format und dem Linter ist es egal, wo deine Tickets liegen.

## Wie sich SpecScore vergleicht.

Spezifikationsgetriebene Entwicklung ist ein belebtes Feld. Hier steht SpecScore im Vergleich zu den Alternativen – ganz ehrlich.

 Plain Markdown Der Standard. SpecScore ist das, wozu sich dein Markdown entwickelt. OpenSpec Ein guter Einstieg. SpecScore liefert die Leitplanken. Spec Kit Spec Kit ist der Workflow. SpecScore ist das Artefakt. Datarim Datarim führt die Pipeline aus. SpecScore ist das, was danach bleibt. CodeSpeak CodeSpeak setzt auf einen Compiler. SpecScore setzt auf ein Format. Kiro Kiro entwirft die Spezifikation in der IDE. SpecScore ist das Format, das CI linten kann. Tessl Tessl argumentiert für die Spezifikation als Quelle. SpecScore lintet die Spezifikation neben dem Code. BMAD Method BMAD führt die agile Schleife. SpecScore ist das Artefakt, das ein Pull Request prüfen kann. Task Master AI Task Master zerlegt ein PRD in Aufgaben. SpecScore ist die Spezifikation, die diese Aufgaben zitieren können.

[Vollständigen Vergleich ansehen →](/de/vs/)

## Lieber die CLI?

Keine KI-Agenten im Einsatz, oder du brauchst Spezifikationsprüfung in deiner CI-Pipeline? Dafür gibt es eine CLI. Installiert in 60 Sekunden – kein Account, keine Telemetrie, funktioniert in jedem Markdown-Spezifikationsordner.

 Linux / macOS Windows

```
$ curl -fsSL https://specscore.md/install/get-cli | sh
```

```
> irm https://specscore.md/install/get-cli.ps1 | iex
```

Prüfe die Beispielspezifikation, die mit der Binärdatei ausgeliefert wird:

```
$ specscore lint examples/checkout/apply-discount.md
```

Sieh dir die Ausgabe an:

```
examples/checkout/apply-discount.md ✓ R1 has acceptance criteria ✓ R2 has acceptance criteria ✗ R3 no acceptance criteria ✗ link "Related Feature: discount-tiers" not found ✗ section "Open Questions" missing 3 problems exit 1
```

Lies die [vollständige Dokumentation](/docs/) · [Auf GitHub beitragen](https://github.com/specscore/specscore)

## Auf SpecScore aufgebaut.

- ### DataTug Datenbankschemata erkunden, Abfragen erstellen und ausführen sowie Ergebnisse verstehen mit DataTug. SpecScore steuert die Anforderungen und Akzeptanzkriterien. [datatug.app →](https://datatug.app)[Die Tools dahinter →](https://datatug.app/en/under-the-hood/tools-we-built/)
- ### MeaningGraph Offene Registry für Datenmodelle und semantische Definitionen – in eigenen Git-Repositories gepflegt und mit Modellen und Code verknüpft. [meaninggraph.io →](https://meaninggraph.io/)[Registry durchsuchen →](https://meaninggraph.io/registry/)
- ### Codegrapher Code-Graph-Engine für schnelle Code-Exploration und bidirektionale Verknüpfung zwischen Spezifikation und Code. [codegrapher.dev →](https://codegrapher.dev/)
- ### DALgo Go-Datenzugriffsschicht, spezifiziert mit SpecScore. [dal-go.github.io →](https://dal-go.github.io/)
- ### inGitDB Git-gestützte versionierte Datenbank, spezifiziert mit SpecScore. [ingitdb.com →](https://ingitdb.com/)
- ### Rehearse Akzeptanz-Nachweisschicht – führt die Akzeptanzkriterien einer Spezifikation tatsächlich aus, mit wiederverwendbaren Prüfungen und ohne Glue-Code. [rehearse.ink →](https://rehearse.ink)
- ### SpecScore Studio Web-Oberfläche zum Anzeigen und Bearbeiten von SpecScore-Spezifikationen. [specscore.studio →](https://specscore.studio)

## Hast du Fragen?

Hier sind die Fragen, die immer wieder gestellt werden. Jede führt zur vollständigen Antwort auf der [FAQ-Seite](/de/faq/).

 Wie unterscheidet sich SpecScore von spec-kit?

spec-kit ist eine Methodik; SpecScore ist ein Speicherformat für die Spezifikationen, die du schreibst, plus eine CLI. Sie ergänzen sich – eine spec-kit-Erweiterung, die SpecScore schreibt, ist in Arbeit.

 Vollständige Antwort → Wie unterscheiden sich die SpecStudio Skills von Superpowers und agent-skills?

Ähnlich im Ansatz – alle drei führen KI-Agenten durch ideate → specify → plan → implement. SpecStudio Skills schreibt Artefakte im SpecScore-Format und nutzt die CLI `specscore` für Abfragen und Statusänderungen; die anderen lesen und schreiben Dateien direkt. Wähle SpecStudio, wenn der Token-Verbrauch zählt.

 Vollständige Antwort → Warum eine CLI – reicht es nicht, Skills zu installieren?

Skills können nicht verlässlich referenzielle Integrität garantieren, gefilterte Abfragen zurückgeben, ohne jede Datei zu lesen, oder das richtige Statusfeld im richtigen Moment ändern. Die CLI erledigt jedes dieser Dinge in einem einzigen Aufruf. Skills lesen jede Datei ein, um dasselbe zu tun.

 Vollständige Antwort → Warum „SpecScore“ – was wird bewertet?

Zwei Lesarten, beide beabsichtigt. Partitur – eine strukturierte Gesamtkomposition aus Anforderungen. Und eine buchstäbliche Qualitätsbewertung – der Linter der CLI liefert die deterministische Prüfung, und der Skill`/score` vergibt eine KI-bewertete Note von A bis F für den Reifegrad des Artefakts.

 Vollständige Antwort → Wo sind die Zahlen zur Token-Ersparnis?

Ein gemessener Direktvergleich ist vor dem Veröffentlichungsbeitrag in Arbeit. Strukturell gesehen: Die CLI liefert eine kurze, strukturierte Liste; ein Agent ohne CLI liest stattdessen N Dokumente in seinen Kontext.

 Vollständige Antwort → Unter welcher Lizenz steht SpecScore?

Spezifikation und Dokumentation im öffentlichen Repository [specscore/specscore](https://github.com/specscore/specscore) stehen unter [CC BY 4.0](https://github.com/specscore/specscore/blob/main/LICENSE). Die Referenz-Befehlszeilenschnittstelle (CLI) in [specscore/specscore-cli](https://github.com/specscore/specscore-cli) steht unter [Apache-2.0](https://github.com/specscore/specscore-cli/blob/main/LICENSE).

 Vollständige Antwort → Braucht SpecScore ein bestimmtes KI-Werkzeug?

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.

 Vollständige Antwort → Was ist spezifikationsgetriebene Entwicklung (SDD)?

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.

 Vollständige Antwort →

## Definiere Erfolg. Schaffe dann Platz dafür.

SpecScore legt fest, wann dein Projekt fertig ist. Ein Wochenziel hilft dir, den nächsten Schritt zu wählen. Verbinde beides mit einer kurzen Prüfung der Ergebnisse.

 Das nächste fertige Ergebnis wählen → CommittedMe kennenlernen (auf Englisch) →