PRD-Vorlage in Markdown für KI-Coding

Ein Produktanforderungsdokument (PRD, product requirements document) ist die Prosa, die das Problem und den Umfang nennt, bevor die Arbeit in Aufgaben zerlegt wird. Eine Feature-Spezifikation ist die Datei von SpecScore für eine Produktfähigkeit: was sie tut, warum es sie gibt und wie sie sich verhält. Markdown ist das Klartextformat dieser Datei. Spezifikationsgetriebene Entwicklung (SDD, spec-driven development) ist die Praxis, die Spezifikation vor dem Code zu schreiben und die Spezifikation als Quelle der Wahrheit zu behandeln. In SpecScore ist eine Anforderung (REQ) eine benannte Regel in einem Feature. Ein Akzeptanzkriterium (AC, acceptance criterion) ist eine optionale abstrakte Bedingung, die auf eine oder mehrere dieser Regeln zeigt. Ein Szenario ist ein konkretes Beispiel, geschrieben als Schritte Given, When und Then. Ein Plan ist das Dokument, das das Feature in Aufgaben zerlegt. Eine Aufgabe ist eine Arbeitseinheit, die eine Person oder ein Agent abschließen kann. Kontinuierliche Integration (CI, continuous integration) ist eine automatische Prüfung bei jeder vorgeschlagenen Änderung. Die Prüfung ist ein Befehl der Kommandozeile (CLI, command-line interface), specscore spec lint, aus der CLI in specscore/specscore-cli. Easy Approach to Requirements Syntax (EARS) ist ein Satzmuster, das eine Anforderung verwenden kann. Claude Code ist der KI-Coding-Agent, für den das Plugin CLI Skills auf dieser Website geschrieben ist. Diese Feature-Spec-Vorlage ist diese Feature-Datei, plus der Plan und die Aufgabe, die darauf zurückzeigen.

Zuletzt aktualisiert: 5. November 2026

Was diese Feature-Spec-Vorlage ist

Ein PRD ist oft eine Prosadatei, die eine Person liest. SpecScore hält denselben Auftrag in Dateien, die ein Linter prüfen kann. Die Feature-Spezifikation nennt ein Feature die atomare Einheit der Produktspezifikation: ein Verzeichnis unter spec/features/, dessen README.md die einzige Quelle der Wahrheit dafür ist, was das Feature tut. Die Planspezifikation nennt einen Plan das Dokument, das dieses Feature in Aufgaben zerlegt. Ein Szenario ist in der Szenariospezifikation eine konkrete Given/When/Then-Datei im Verzeichnis _tests/ des Features. Die Spezifikation der Akzeptanzkriterien hält das Kriterium abstrakt: sie sagt, was wahr sein muss, und das Szenario sagt, wie man es beweist.

Die Checkout-Datei unten ist die ausgefüllte Vorlage. Zusammen mit dem Feature-Index, einem Spec-README und specscore.yaml hat specscore spec lint sie mit 0 Verstößen akzeptiert. Diese Prüfung lief am 2. November 2026 mit specscore 0.55.1 und mit 0.39.1, dem Tag, den dogfood.yml installiert. Die Zeile der Studio-Werkzeugleiste in der Feature-Datei ist die Zeile, die Feature-READMEs in specscore/specscore tragen. Die Tabelle der Pflichtabschnitte in der Feature-Spezifikation führt sie nicht auf.

Das Feature-README

Die Tabelle der Pflichtabschnitte in der Feature-Spezifikation sagt, dass jedes Feature-README einen Titel # Feature: {Title}, eine Zeile **Status:** unmittelbar nach dem Titel, ein Summary, ein Problem, einen Abschnitt Behavior, einen Abschnitt Acceptance Criteria, einen Abschnitt Open Questions und eine Adherence-Fußzeile hat. Der Statuswert ist einer von Draft, In Review, Approved, Implementing, Stable, Amending, Rejected oder Deprecated. Ein Abschnitt Contents ist nur Pflicht, wenn das Feature Unterverzeichnisse hat. **Source Ideas:** ist optional. Die geprüfte Datei setzt es auf —.

Open Questions wird nie weggelassen. Wenn es keine gibt, sagt der Abschnitt None at this time. Acceptance Criteria wird ebenfalls nie weggelassen. Wenn keine Kriterien definiert sind, sagt dieser Abschnitt Not defined yet. und Open Questions muss dann Acceptance criteria not yet defined for this feature. enthalten. Die Fußzeile ist die letzte Zeile, und ihre URL ist https://specscore.md/feature-specification.

Die Konvention für Artefakt-Frontmatter sagt, dass jedes Artefakt einen Schlüssel format: im YAML-Frontmatter trägt und dass ein Artefakt mit Status außerdem status: trägt, als Spiegel des Tokens **Status:** im Körper. Dasselbe Feature sagt, dass die erzwingenden Lint-Regeln hinter einer Schonfrist ausgeliefert werden. Die geprüfte Datei enthält beide Schlüssel. Diese Seite behauptet nicht, dass der Pin v0.39.1 eine Datei ablehnt, die sie weglässt.

Feature-README, das specscore spec lint akzeptiert hat (2. November 2026)

---
format: https://specscore.md/feature-specification
status: Draft
---

# Feature: Checkout validation

> [SpecScore.**Studio**](https://specscore.studio): | [Explore](https://specscore.studio/app/github.com/example/checkout/spec/features/checkout?op=explore) | [Edit](https://specscore.studio/app/github.com/example/checkout/spec/features/checkout?op=edit) | [Ask question](https://specscore.studio/app/github.com/example/checkout/spec/features/checkout?op=ask) | [Request change](https://specscore.studio/app/github.com/example/checkout/spec/features/checkout?op=request-change) |

**Status:** Draft
**Source Ideas:** —

## Summary

The checkout form shows a validation error next to a field when the shopper submits invalid data, and it rejects an email that is not a valid address.

## Problem

A vague sentence such as "the form should handle bad input" does not say which event causes which response. Checkout needs those obligations written so a reviewer and a linter can point at them.

## Behavior

### Field validation

The checkout system checks the form when the shopper submits it.

#### REQ: show-field-error

When a shopper submits the checkout form with invalid data, the checkout system MUST show a validation error next to the invalid field.

#### REQ: reject-invalid-email

If the submitted email is not a valid address, then the checkout system MUST reject the form.

## Acceptance Criteria

### AC: invalid-submission

**Requirements:** checkout#req:show-field-error, checkout#req:reject-invalid-email

Submitting the checkout form with invalid data shows a validation error next to the invalid field, and an email that is not a valid address is rejected.

## Open Questions

None at this time.

---
*This document follows the https://specscore.md/feature-specification*

Feature-Index aus demselben Lint-Lauf

---
format: https://specscore.md/features-index-specification
---

# Features

| Feature | Status | Description |
|---|---|---|
| [Checkout validation](checkout/README.md) | Draft | The checkout form shows a validation error next to a field when the shopper submits invalid data, and it rejects an email that is not a valid address. |

## Open Questions

None at this time.

---
*This document follows the https://specscore.md/features-index-specification*

Spec-README aus demselben Lint-Lauf

# Checkout specification

## Open Questions

None at this time.

specscore.yaml aus demselben Lint-Lauf

# SpecScore Repo Config Schema: https://specscore.md/repo-config

project:
  title: Checkout sample
  host: github.com
  org: example
  repo: checkout

Der Bezeichner des Features ist sein Verzeichnispfad relativ zu spec/features/. Der Index-Link checkout/README.md bedeutet, dass die Datei unter spec/features/checkout/README.md liegt, also ist die Feature-Id, die Anforderungen und Kriterien verwenden, checkout. Der Index listet jedes Feature der obersten Ebene. Ein Unterverzeichnis, das nicht aufgeführt ist, ist ein Verstoß gegen index-entries, den Spezifikationen in CI linten beschreibt. Das Spec-README in diesem Baum hat einen Abschnitt, Open Questions, und der sagt None at this time. Die Konfigurationsdatei ist das, wonach die CLI nach oben sucht. Ohne specscore.yaml endet der Befehl mit 3 und nennt specscore init.

REQ-Ids, Akzeptanzkriterien und Szenarien

Die Anforderungsspezifikation setzt jede Regel unter eine Themenüberschrift innerhalb von ## Behavior. Die Überschrift ist #### REQ: {slug}, mit einem Leerzeichen nach dem Doppelpunkt. Der Slug verwendet Kleinbuchstaben, Ziffern und Bindestriche. Die kanonische Id ist {feature-path}#req:{slug}. In der Checkout-Datei ist das checkout#req:show-field-error und checkout#req:reject-invalid-email. Eine Anforderung nennt eine Pflicht. Die Spezifikation sagt, Anforderungen SHOULD die Schlüsselwörter von RFC 2119 verwenden: MUST, MUST NOT, SHOULD, SHOULD NOT und MAY. Eine Überschrift REQ: ist außerhalb von ## Behavior nicht gültig. Ein EARS-Satz kann diese Prosa sein. Der Linter benotet das Englisch nicht. Die Muster stehen in der EARS-Anforderungssyntax.

Akzeptanzkriterium

Die Spezifikation der Akzeptanzkriterien sagt, dass jedes Kriterium eine Überschrift ### AC: {slug} innerhalb von ## Acceptance Criteria ist, dann eine Zeile **Requirements:**, die Werte {feature-id}#req:{slug} auflistet, und danach eine abstrakte Aussage dessen, was wahr sein muss. Kriterien sind optional. Die Spezifikation sagt, eines hinzuzufügen, wenn das Bündeln von zwei oder mehr verwandten Anforderungen Klarheit bringt. Die Checkout-Datei bündelt beide Regeln in checkout#ac:invalid-submission. Die Aussage enthält weder Given noch When noch Then. Akzeptanzkriterien schreiben ist der Schreibleitfaden. Die Regel ac-heading-format (ac_heading.go beim CLI-Tag v0.55.1) prüft, dass die Überschrift ### AC: <id> mit einer Id in kebab-case ist. Der Lint-Artikel hält fest, dass diese Regel die Zeile **Requirements:** nicht verlangt und Wörter nicht benotet. Die Spezifikation der Akzeptanzkriterien verlangt diese Zeile weiterhin.

Szenario

Die Szenariospezifikation legt ein Szenario in _tests/, das kein Unter-Feature ist und vom Feature-Index ausgeschlossen ist. Die Datei beginnt mit # Scenario: {Title}, einer Zeile **Validates:**, die auf eine Anforderung oder ein Kriterium zeigt, und einem Abschnitt ## Steps, dessen Schlüsselwörter in Großbuchstaben GIVEN, WHEN, THEN und AND sind. Jedes Verzeichnis _tests/ muss ein README mit einem Szenario-Index enthalten. Die Probe unten hat diese Dateiform. Sie war nicht Teil des Lint-Laufs vom 2. November. specscore spec lint prüft die Schlüsselwörter der Szenarioschritte nicht. specscore rehearse führt Szenariodateien aus. Rehearse ist dieser Ausführer. Der Dogfood-Workflow führt den Linter aus und ruft rehearse nicht auf.

Dateiform eines Szenarios aus der Szenariospezifikation

# Scenario: Reject an invalid email

**Validates:** [checkout#ac:invalid-email-rejected](../README.md#ac-invalid-email-rejected)

## Steps

GIVEN the shopper is on the checkout form
WHEN the shopper submits the email "not-an-email"
THEN the page shows "Enter a valid email address" beside the email field
AND the order is not placed

Lies die drei Schichten der Reihe nach. Die Anforderung sagt die Regel. Das Akzeptanzkriterium sagt, was für die Regeln wahr sein muss, die es nennt. Das Szenario gibt einen konkreten Ablauf. Ein Agent, der nur die PRD-Prosa sieht, muss diese Zerlegung erfinden. Die Vorlage hat sie bereits.

Pläne und Aufgaben

Ein Plan-README liegt unter spec/plans/{plan-slug}/README.md. Die Planspezifikation verlangt den Titel # Plan: {Title} und die Kopffelder Status, genau eine Herkunftszeile, Date, Owner und Supersedes. Ein Plan mit Herkunft in einem Feature verwendet **Source Feature:** plus den Feature-Slug, hier checkout. Die anderen zulässigen Herkunftszeilen sind **Source:** idea:{slug} und **Source:** none. Pflichtabschnitte sind Summary, Approach, Tasks und Open Questions. Im Plan ist jede Aufgabe eine Überschrift ### Task N: mit einer Zeile **Verifies:** der Form feature-slug#ac:ac-slug. Die Regel P-001 in plan_rules.go meldet eine Überschrift eines Akzeptanzkriteriums, die keine Aufgabe abdeckt und die nicht unter ## Deferred AC Coverage aufgeführt ist. Die Regel P-002 meldet einen Wert **Verifies:**, der sich nicht in eine dieser Überschriften auflöst. Pläne mit Herkunft in einer Idee und Pläne mit **Source:** none sind von P-001 ausgenommen.

Der Plan unten folgt dieser veröffentlichten Form für das Feature checkout, einschließlich des Frontmatters format: und status:. Er war nicht im Lint-Lauf vom 2. November. Ein Feature, das ein Plan berührt, muss eine Tabelle ## Plans mit den Spalten Plan, Status, Author und Approved enthalten. Die geprüfte Feature-Datei hat keinen Abschnitt Plans, weil dieser Baum keinen Plan hat.

Die Aufgabenspezifikation definiert eine Aufgabe außerdem als eigenes Verzeichnis und README.md unter dem Plan. Der Titel ist # Task: {Title}. Pflichtfelder sind **Status:**, **Depends on:** (das Literal none, wenn es keine Abhängigkeit gibt) und **Model:** (small, medium, large oder inherit). Ein Verzeichnis, das Unterverzeichnisse von Aufgaben enthält, ist ein Plan, keine Aufgabe. Die Aufgabendatei unten verwendet diese Felder für die erste Aufgabe von checkout. Sie war nicht im Lint-Lauf vom 2. November. Die URL der Fußzeile eines Aufgabendokuments ist https://specscore.md/task-specification.

Planform aus der Planspezifikation, ausgefüllt für checkout

---
format: https://specscore.md/plan-specification
status: Draft
---

# Plan: Show checkout validation errors

**Status:** Draft
**Source Feature:** checkout
**Date:** 2026-11-05
**Owner:** @example
**Supersedes:** —

## Summary

This plan decomposes the checkout feature into the work that shows a field error and rejects an email that is not a valid address.

## Approach

Both tasks verify the same acceptance criterion, which bundles the two requirements. Nothing is deferred, so this plan has no Deferred AC Coverage section.

## Tasks

### Task 1: Show a validation error beside the invalid field

**Verifies:** checkout#ac:invalid-submission

When the shopper submits the checkout form with invalid data, show a validation error next to the invalid field.

### Task 2: Reject an email that is not a valid address

**Verifies:** checkout#ac:invalid-submission

If the submitted email is not a valid address, reject the form.

## Open Questions

None at this time.

---
*This document follows the https://specscore.md/plan-specification*

Form eines Aufgabendokuments aus der Aufgabenspezifikation

---
format: https://specscore.md/task-specification
status: queued
---

# Task: Show a validation error beside the invalid field

**Status:** queued
**Depends on:** none
**Model:** medium

## Acceptance Criteria

- Submitting the checkout form with invalid data shows a validation error next to the invalid field.

## Open Questions

None at this time.

---
*This document follows the https://specscore.md/task-specification*

Die Feature-Datei beantwortet, was das Checkout-Formular tun muss. Der Plan beantwortet, wie diese Arbeit zerlegt wird, und jede eingebettete Aufgabe nennt das Kriterium, das sie verifiziert. Das Aufgabendokument ist das Blatt, das eine Person oder ein Agent aufnimmt. Halte die Id des Kriteriums stabil. checkout#ac:invalid-submission ist die Zeichenkette, die das Feature und der Plan verwenden.

Die Vorlage in CI linten

specscore spec lint prüft den Spec-Baum auf Verstöße gegen strukturelle Konventionen. Ein sauberer Lauf gibt 0 violations found aus und endet mit 0. Ein Lauf, der Verstöße findet, gibt eine Zeile je Befund aus und endet mit 1. Dieser Exitcode lässt einen CI-Job fehlschlagen. Ungültige Argumente enden mit 2. Ein fehlendes specscore.yaml endet mit 3. dogfood.yml installiert die CLI mit SPECSCORE_VERSION auf v0.39.1 und führt dann specscore spec lint bei Pull Requests und bei Pushes auf main aus. Der Workflow-Auszug, der Fehlerbericht und der Regelkatalog stehen in Spezifikationen in CI linten.

Die Lizenz des Formats ist CC BY 4.0 in specscore/specscore. Die Lizenz der CLI ist Apache-2.0 in specscore/specscore-cli.

Andere spezifikationsgetriebene Werkzeuge veröffentlichen andere Prüfungen. Die Sätze unten verwenden nur das, was die eigenen Seiten dieser Projekte sagen. Die Werkzeugrunde verzeichnet dieselben Seiten als gelesen am 30. Oktober 2026, außer der Dokumentationsstartseite von Spec Kit, die den 28. September 2026 druckt.

OpenSpec dokumentiert openspec validate in seiner CLI-Referenz. Dieser Befehl prüft die Struktur der Änderungen und Spezifikationen von OpenSpec und endet ungleich null, wenn die Validierung fehlschlägt. Er prüft keine Überschrift ### AC: von SpecScore und keinen Index von SpecScore.

Das README von Task Master beschreibt, ein PRD mit task-master parse-prd in Aufgaben zu zerlegen. Es beschreibt keinen Linter für dieses PRD. Ein PRD kann trotzdem die Eingabe sein, die du in die Feature-Datei auf dieser Seite umschreibst. specscore spec lint ist das, was die Feature-Datei dann prüft.

GitHub Spec Kit beschreibt einen Agenten-Workflow, dessen Phasen Markdown-Artefakte schreiben. Diese Dokumentationsstartseite beschreibt keinen Befehl, der ein SpecScore-Feature-README in CI lintet. Der Vergleich dieser Werkzeuge ist die Werkzeugrunde.

Eine Spec-Vorlage, die Claude Code lesen kann

Die Dateien sind Markdown, also kann ein Agent, der ein Repository lesen kann, die Vorlage lesen. Claude Code ist der Agent, auf den die Seite CLI Skills zielt. Diese Seite dokumentiert ai-plugin-specscore, ein schlankes Claude-Code-Plugin, das die CLI umhüllt. Das Repository des Plugins ist specscore/ai-plugin-specscore. Die Seite sagt, das Plugin stellt specscore spec lint, specscore feature, specscore task und specscore feature change-status als Plugin-Befehle bereit. Die Installationszeilen auf dieser Seite sind /plugin marketplace add specscore/ai-marketplace und /plugin install cli-skills@specscore.

Dieselbe Seite dokumentiert specscore agent setup <agent-name> für claude, copilot, cursor, codex, antigravity.google, pi.dev oder opencode, ausgeführt in einem von SpecScore verwalteten Projekt. SpecStudio Skills ist der geführte Ablauf (/ideate, /specify, /plan, /implement) und ebenfalls ein Claude-Code-Plugin. Die Vorlage auf dieser Seite ist die Datei, die diese Befehle linten. Das Plugin ersetzt das Feature-README nicht.

FAQ

Was ist eine PRD-Vorlage in Markdown?

Sie ist ein Produktanforderungsdokument, geschrieben als Markdown-Dateien mit fester Form. In SpecScore ist diese Form ein Feature-README: Titel, Status, Zusammenfassung, Problem, Verhalten mit Regeln #### REQ:, Akzeptanzkriterien und offene Fragen. Die Checkout-Datei auf dieser Seite ist eine, die specscore spec lint akzeptiert hat.

Wohin gehören REQ-Ids in einer Feature-Spec-Vorlage?

Unter eine Themenüberschrift innerhalb von ## Behavior, als #### REQ: {slug}. Die Id ist {feature-path}#req:{slug}. Akzeptanzkriterien listen diese Ids auf **Requirements:**. Eine Aufgabe im Plan listet die Id des Kriteriums auf **Verifies:**.

Was ist der Unterschied zwischen einem Akzeptanzkriterium und einem Szenario?

Ein Akzeptanzkriterium ist eine abstrakte Bedingung. Ein Szenario ist ein konkreter Ablauf Given/When/Then in _tests/. Die Spezifikation der Akzeptanzkriterien sagt, das Kriterium darf die Schritte nicht vorschreiben. Die Szenariodatei schreibt sie vor.

Benotet der Linter die PRD-Prosa?

Nein. specscore spec lint prüft die Struktur: Überschriften, Pflichtabschnitte, Indexzeilen und Verweise wie P-001 und P-002. Er entscheidet nicht, ob das Produkt eine gute Idee ist. Spezifikationen in CI linten ist die längere Darstellung dieses Befehls.

Kann Claude Code diese Spec-Vorlage verwenden?

Ja. Die Vorlage ist Markdown im Repository. Das Plugin CLI Skills stellt specscore spec lint und die Befehle für Feature und Aufgabe in Claude Code bereit. specscore agent setup claude schreibt eine Anweisungsdatei für diesen Agenten. Das Plugin erfindet keine andere Vorlage.

Ersetzt ein Plan die Feature-Spezifikation?

Nein. Das Feature-README ist die Quelle der Anforderungen und der Akzeptanzkriterien. Der Plan zerlegt dieses Feature in Aufgaben, und jede Aufgabe verweist mit **Verifies:** zurück. Die Planspezifikation und die Aufgabenspezifikation sind die beiden Dokumente dieser Zerlegung.

Quellen

Das Feature checkout, der Feature-Index, das Spec-README und specscore.yaml wurden am 2. November 2026 von specscore spec lint mit specscore 0.55.1 und mit 0.39.1 akzeptiert. Die Proben für Plan und Aufgabe folgen den veröffentlichten Spezifikationen und waren nicht Teil dieses Laufs. Die Seiten der Wettbewerber sind die unten verlinkten; die Werkzeugrunde verzeichnet sie als gelesen am 30. Oktober 2026, außer der Dokumentationsstartseite von Spec Kit, die den 28. September 2026 druckt.