spec-driven

Die Artefakte des Standard-Workflows: ihre Reihenfolge, ihre Formate und der Änderungsordner, den sie erzeugen.

spec-driven ist das in OpenSpec integrierte Standard-Schema. schema.yaml definiert die Felder, die es festlegt.

Artefakte

Der Workflow erstellt vier Artefakte:

Artefakt	Datei	Zweck
proposal	proposal.md	Warum die Änderung erforderlich ist
specs	specs/<capability-path>/spec.md, eines pro Funktion	Welches Verhalten sich ändert
design	design.md	Wie sie umgesetzt wird
tasks	tasks.md	Die Implementierungs-Checkliste

Erstellungsreihenfolge

             ┌─ specs ──┐
proposal ────┤          ├── tasks ── apply
             └─ design ─┘

Die Proposal kommt zuerst. Specs und Design folgen in beliebiger Reihenfolge, und Tasks benötigt beides. Die Implementierung (apply) beginnt, sobald tasks.md vorhanden ist.

Zwei Artefakte können übersprungen werden:

• design: Wenn keine der Bedingungen zutrifft, lässt der Agent es weg und erstellt trotzdem tasks.
• specs: Setzen Sie skip_specs: true in der .openspec.yaml des Changes.

Beispiel eines Change-Ordners

Ein Change namens add-user-auth, mit allen erstellten Artefakten:

openspec/changes/add-user-auth/
├── .openspec.yaml      Change-Metadaten, geschrieben bei der Erstellung des Changes
├── proposal.md
├── specs/
│   └── user-auth/
│       └── spec.md     ein Delta-Spec pro Fähigkeit
├── design.md
└── tasks.md

proposal.md

Legt fest, warum der Change benötigt wird.

Struktur

Die Vorlage, die der Agent als Ausgabeformat erhält (templates/proposal.md):

# Proposal

## Why

<!-- Erklären Sie die Motivation für diesen Change. Welches Problem löst er? Warum jetzt? -->

## What Changes

<!-- Beschreiben Sie, was sich ändern wird. Seien Sie spezifisch bezüglich neuer Fähigkeiten, Modifikationen oder Entfernungen. -->

## Capabilities

### New Capabilities
<!-- Einzuführende Fähigkeiten. Benennen Sie jede Fähigkeit nach einem zusammenhängenden Systemverhalten, das im Laufe der Systementwicklung verwandte Anforderungen besitzen kann. Benennen Sie keine Implementierungsaufgaben oder Proposal-Abschnitte. Vermeiden Sie breite Auffangnamen. Verwenden Sie kebab-case für Pfadsegmente, die Sie einführen (z.B. user-auth oder identity/user-auth), die der bestehenden Spec-Organisation des Projekts folgen. Jede erstellt specs/<capability-path>/spec.md. -->
- `<capability-path>`: <kurze Beschreibung, was diese Fähigkeit abdeckt>

### Modified Capabilities
<!-- Bestehende Fähigkeiten, deren ANFORDERUNGEN sich ändern (nicht nur die Implementierung). Listen Sie hier nur auf, wenn sich das Verhalten auf Spec-Ebene ändert. Jede benötigt eine Delta-Spec-Datei. Verwenden Sie den exakten bestehenden Pfad unter openspec/specs/. Lassen Sie dies leer, wenn keine Anforderungen sich ändern. Ein Change ohne Fähigkeiten (reines Refactoring, Tooling, Doku) muss `skip_specs: true` in seiner .openspec.yaml setzen - openspec validate lehnt einen Change mit null Delta ohne diesen Marker ab. Erfinden Sie keine Anforderung nur, um die Validierung zu erfüllen. -->
- `<existing-capability-path>`: <welche Anforderung sich ändert>

## Impact

<!-- Betroffener Code, APIs, Abhängigkeiten, Systeme -->

Anweisungen

Die Anweisung, die der Agent erhält, wenn er dieses Artefakt erstellt (aus schema.yaml):

Erstellen Sie das Proposal-Dokument, das festlegt, WARUM dieser Change benötigt wird.

Abschnitte:
- **Why**: 1-2 Sätze zum Problem oder zur Gelegenheit. Welches Problem löst dies? Warum jetzt?
- **What Changes**: Aufzählungsliste der Änderungen. Seien Sie spezifisch bezüglich neuer Fähigkeiten, Modifikationen oder Entfernungen. Kennzeichnen Sie Breaking Changes mit **BREAKING**.
- **Capabilities**: Identifizieren Sie, welche Specs erstellt oder geändert werden:
  - **New Capabilities**: Listen Sie einzuführende Fähigkeiten auf. Jede wird zu einem neuen `specs/<capability-path>/spec.md`. Benennen Sie jede Fähigkeit nach einem dauerhaften Systemverhalten (zum Beispiel `user-auth`), nicht nach der Arbeit in diesem Change (zum Beispiel `add-login-endpoint`). Wählen Sie eine zusammenhängende Grenze, die im Laufe der Systementwicklung verwandte Anforderungen besitzen kann; vermeiden Sie breite Auffang-Fähigkeiten. Verwenden Sie kebab-case für Pfadsegmente, die Sie einführen (z.B. `user-auth` oder `identity/user-auth`), und folgen Sie der bestehenden Spec-Organisation des Projekts.
  - **Modified Capabilities**: Listen Sie bestehende Fähigkeiten auf, deren ANFORDERUNGEN sich ändern. Nur aufnehmen, wenn sich das Verhalten auf Spec-Ebene ändert (nicht nur Implementierungsdetails). Jede benötigt eine Delta-Spec-Datei. Verwenden Sie den exakten bestehenden Pfad unter `openspec/specs/`. Lassen Sie dies leer, wenn keine Anforderungen sich ändern.
- **Impact**: Betroffener Code, APIs, Abhängigkeiten oder Systeme.

WICHTIG: Der Abschnitt Capabilities ist entscheidend. Er erstellt den Vertrag zwischen Proposal- und Specs-Phase. Recherchieren Sie bestehende Specs, bevor Sie dies ausfüllen:
führen Sie `openspec list --specs` für das Fähigkeiten-Inventar des Projekts aus, dann `openspec show "<spec-id>" --type spec --json --no-scenarios` für alle, die ähnlich aussehen - dies gibt den Zweck und die Anforderungstexte einer Fähigkeit zurück, ohne ganze Spec-Dateien in den Kontext zu ziehen. Fügen Sie `--store "<id>"` nur für einen registrierten eigenständigen Store an beide Befehle an, und behalten Sie `--type spec`: Ein Change und ein Spec mit demselben Namen sind sonst ein ambiguous-item-Fehler. `openspec list` ohne `--specs` listet laufende Changes, nicht Specs - es zeigt nie, was das Projekt bereits abdeckt. Verwenden Sie den exakten Pfad einer bestehenden Fähigkeit, statt einen nahezu doppelten Namen einzuführen.
Die gefilterte Ansicht ist nur ein Überblick. Bevor Sie entscheiden, was bereits abgedeckt ist oder was sich ändern sollte, lesen Sie jeden relevanten Spec vollständig, einschließlich Szenarien, mit `openspec show "<spec-id>" --type spec` (gleiche `--store`-Regel). Jede hier aufgeführte Fähigkeit benötigt eine entsprechende Spec-Datei.

Jeder Change muss entweder mindestens eine Fähigkeit deklarieren (neu oder geändert) oder sich explizit von Specs abmelden: `openspec validate` lehnt einen Change mit null Deltas ab, es sei denn, die `.openspec.yaml` des Changes setzt `skip_specs: true`. Verwenden Sie `skip_specs: true` nur, wenn sich kein Verhalten auf Spec-Ebene ändert (reines Refactoring, Tooling, Doku) - Specs beschreiben Verhalten, daher sollte auch kein Spec sich ändern, wenn das Verhalten sich nicht ändert. Erfinden Sie keine Anforderung nur, um die Validierung zu erfüllen.

Halten Sie es prägnant (1-2 Seiten). Konzentrieren Sie sich auf das "Warum", nicht auf das "Wie" - Implementierungsdetails gehören in design.md.

Dies ist das Fundament - Specs, Design und Tasks bauen alle darauf auf.

Delta-Specs (spec.md)

Definiert, welches Verhalten sich ändert, mit einer Delta-Spec pro Fähigkeit, die das Proposal auflistet.

Jede Delta-Spec ist die spec.md innerhalb ihres Fähigkeiten-Ordners. openspec validate und openspec archive lehnen Delta-Abschnitte ab, die in einer anderen Datei unter specs/ geschrieben wurden, wie specs/user-auth.md, da archive diese nie zusammenführt.

Struktur

Die Vorlage, die der Agent als Ausgabeformat erhält (templates/spec.md):

# Spec Delta

## Purpose
<!-- Nur neue Fähigkeiten: ein oder zwei Sätze (50+ Zeichen) darüber, wofür diese Fähigkeit ist. Löschen Sie diesen Abschnitt für eine bestehende Fähigkeit. -->

## ADDED Requirements

### Requirement: <!-- Anforderungsname -->
<!-- Anforderungstext -->

#### Scenario: <!-- Szenarioname -->
- **WHEN** <!-- Bedingung -->
- **THEN** <!-- erwartetes Ergebnis -->

Anweisungen

Die Anweisung, die der Agent erhält, wenn er dieses Artefakt erstellt (aus schema.yaml):

Erstellen Sie Specifications-Dateien, die definieren, WAS das System tun soll.

Ein Spec ist ein Verhaltensvertrag, kein Implementierungsplan.

Gute Spec-Inhalte:
- Beobachtbares Verhalten, auf das Benutzer oder nachgelagerte Systeme vertrauen
- Eingaben, Ausgaben und Fehlerbedingungen
- Externe Randbedingungen (Sicherheit, Datenschutz, Zuverlässigkeit, Kompatibilität)
- Szenarien, die getestet oder explizit validiert werden können

Vermeiden Sie in Specs:
- Interne Klassen-/Funktionsnamen
- Bibliotheks- oder Framework-Auswahl
- Schritt-für-Schritt-Implementierungsdetails
- Detaillierte Ausführungspläne (diese gehören in design.md oder tasks.md)

Schnelltest: Wenn die Implementierung sich ändern kann, ohne das extern sichtbare Verhalten zu ändern, gehört sie wahrscheinlich nicht in den Spec.

Erstellen Sie eine Spec-Datei pro Fähigkeit, die im Abschnitt Capabilities des Proposals aufgelistet ist.
`<capability-path>` ist das Spec-Verzeichnis relativ zu `specs/` (zum Beispiel `user-auth` oder `identity/user-auth`). Behalten Sie den vollständigen Pfad:
- Neue Fähigkeiten: Verwenden Sie den exakten Pfad aus dem Proposal bei `specs/<capability-path>/spec.md`. Jedes neu im Proposal eingeführte Pfadsegment muss kebab-case sein. Folgen Sie der bestehenden Organisation des Projekts; fügen Sie keine neue Domänenebene hinzu, wenn das Projekt ein flaches Layout verwendet.
- Geänderte Fähigkeiten: Verwenden Sie den exakten bestehenden Pfad aus `openspec/specs/<capability-path>/`, wenn Sie das Delta bei `specs/<capability-path>/spec.md` erstellen. Führen Sie `openspec list --specs` aus, um diesen Pfad vor dem Schreiben des Deltas zu bestätigen, und fügen Sie `--store "<id>"` nur für einen registrierten eigenständigen Store an - ein falsch geschriebener oder erfundener Pfad zielt auf eine Fähigkeit ab, die nicht existiert, statt auf die gewünschte. Verschieben oder benennen Sie die Fähigkeit nicht um.

Schreiben Sie die Spec-Dateien nacheinander, damit der Benutzer den Fortschritt sieht und ein unterbrochener Lauf die bereits geschriebenen Dateien behält:
- Bevor Sie etwas schreiben, vergleichen Sie die Fähigkeiten, die das Proposal auflistet, mit den bereits existierenden `specs/<capability-path>/spec.md`-Dateien, und beginnen Sie mit der ersten Fähigkeit, die keine Datei hat. Schreiben Sie eine bestehende Datei nicht neu, es sei denn, der Benutzer bittet Sie darum.
- Sagen Sie vor jeder Datei in einer Zeile, welche Fähigkeit Sie schreiben.
- Schreiben Sie jede Datei, sobald Sie sie entworfen haben. Planen Sie nicht jede Datei, bevor Sie die erste schreiben.
- Stoppen Sie, wenn jede Fähigkeit, die das Proposal auflistet, ihre Datei hat.

Es muss mindestens eine Spec-Datei geben, es sei denn, die `.openspec.yaml` des Changes setzt `skip_specs: true` (keine Verhaltensänderung auf Spec-Ebene) - `openspec validate` lehnt einen Change mit null Delta ohne diesen Marker ab. Wenn das Proposal keine Fähigkeiten auflistet und `skip_specs` nicht gesetzt ist, überarbeiten Sie zuerst das Proposal.

Delta-Operationen (##-Überschriften verwenden):
- **ADDED Requirements**: Neue Fähigkeiten
- **MODIFIED Requirements**: Geändertes Verhalten - MUSS den vollständigen aktualisierten Inhalt enthalten
- **REMOVED Requirements**: Abgeschaffte Funktionen - MUSS **Reason** und **Migration** enthalten
- **RENAMED Requirements**: Nur Namensänderungen - FROM:/TO:-Format verwenden

Formatanforderungen:
- Jede Anforderung: `### Requirement: <name>` gefolgt von einer Beschreibung
- Verwenden Sie SHALL/MUST für normative Anforderungen (vermeiden Sie should/may)
- Jedes Szenario: `#### Scenario: <name>` mit WHEN/THEN-Format
- **KRITISCH**: Szenarien müssen genau 4 Hashtags (`####`) verwenden. Die Verwendung von 3 Hashtags oder Aufzählungspunkten schlägt stillschweigend fehl.
- Jede Anforderung muss mindestens ein Szenario haben.
- Jedes Szenario muss einen WHEN/GIVEN-Schritt (seinen Auslöser) und einen THEN-Schritt (seine Auswirkung) haben. Ein Szenario mit nur AND-Zeilen oder reiner Prosa zählt weiterhin als Szenario, aber `openspec validate` markiert es als Warnung: Die normale Validierung besteht weiterhin, aber `openspec validate --strict` schlägt damit fehl.
- Halten Sie die Beschreibung jeder Anforderung (den Text zwischen `### Requirement:` und ihrem ersten Szenario) auf 500 Zeichen oder weniger. `openspec validate` markiert längere Beschreibungen in ADDED-Anforderungen und im Haupt-Spec. Dies ist eine Warnung: Die normale Validierung besteht weiterhin, aber `openspec validate --strict` schlägt damit fehl. Bei der Erstellung einer neuen Anforderung geben Sie ein Verhalten pro Anforderung an: Verlegen Sie Beispiele und Randfälle in Szenarien, und teilen Sie eine Anforderung, die mehrere Verhaltensweisen abdeckt, in separate `### Requirement:`-Blöcke auf, jeweils mit eigenen Szenarien. Unter MODIFIED behalten Sie den bestehenden Anforderungsblock ganz; teilen, kürzen oder schreiben Sie bestehenden Text nie nur um der Länge willen neu. Teilen Sie eine bestehende lange Anforderung nur, wenn der Benutzer dies in einem für diesen Zweck gemachten Change anfordert: Unter MODIFIED behalten Sie ihre Überschrift und jedes Szenario und kürzen Sie ihre Beschreibung auf ein Verhalten, ohne ihre Bedeutung zu ändern, und fügen Sie dann jedes entfernte Verhalten als eigene ADDED-Anforderung mit eigenen Szenarien hinzu.

Nur neue Fähigkeiten: Der erste Abschnitt des Delta-Specs ist `## Purpose` - ein oder zwei Sätze (50+ Zeichen, oder `openspec validate --strict` meldet ihn als zu knapp), der beschreibt, wofür die Fähigkeit ist. Archive kopiert ihn in den Haupt-Spec, den es erstellt; ohne ihn bleibt der neue Haupt-Spec mit einem `TBD ... Update Purpose after archive`-Platzhalter zurück, der von Hand ausgefüllt werden muss. Fügen Sie `## Purpose` NICHT zu einem Delta für eine bestehende Fähigkeit hinzu - dieser Spec hat bereits einen und der des Deltas wird ignoriert. Um den Purpose einer bestehenden Fähigkeit zu ändern - einschließlich eines verbliebenen `TBD`-Platzhalters - bearbeiten Sie direkt `<planningHome.root>/openspec/specs/<capability-path>/spec.md`. `planningHome.root` stammt aus der `openspec instructions ... --json`-Antwort. Verwenden Sie es immer statt eines repo-relativen Pfads: Es löst sich zum Store auf, wann immer der Change in einem lebt - ob dies von `--store`, einem Projekt-`store:`-Zeiger oder einem globalen Standard-Store stammt - und sonst zum aktuellen Repository. Versuchen Sie nicht herauszufinden, welcher Fall zutrifft; das Feld hat es bereits.

MODIFIED-Anforderungen-Workflow:
1. Lokalisieren Sie die bestehende Anforderung in `<planningHome.root>/openspec/specs/<capability-path>/spec.md` (dieselbe store-basierte Wurzel wie oben)
2. Kopieren Sie den GESAMTEN Anforderungsblock (von `### Requirement:` bis alle Szenarien)
3. Fügen Sie unter `## MODIFIED Requirements` ein und bearbeiten Sie ihn, um das neue Verhalten widerzuspiegeln
4. Stellen Sie sicher, dass der Überschriftentext exakt übereinstimmt (leerraum-unempfindlich)

Häufige Fehlerquelle: Die Verwendung von MODIFIED mit teilweisem Inhalt verliert Details beim Archivieren. Wenn Sie neue Anliegen hinzufügen, ohne das bestehende Verhalten zu ändern, verwenden Sie stattdessen ADDED.

Beispiel (eine neue Fähigkeit, daher ist ihr erster Abschnitt `## Purpose`):
```
# Spec Delta

## Zweck

Ermöglicht es Benutzern, ihre Daten aus dem Produkt in einem portablen Format zu exportieren.

## HINZUGEFÜGTE Anforderungen

### Anforderung: Benutzer können Daten exportieren
Das System SOLL Benutzern ermöglichen, ihre Daten im CSV-Format zu exportieren.

#### Szenario: Erfolgreicher Export
- **WENN** der Benutzer auf die Schaltfläche „Export" klickt
- **DANN** lädt das System eine CSV-Datei mit allen Benutzerdaten herunter

## ENTFERNTE Anforderungen

### Anforderung: Legacy-Export
**Grund**: Durch neues Exportsystem ersetzt
**Migration**: Neuen Export-Endpunkt unter /api/v2/export verwenden
```

Specs sollten testbar sein - jedes Szenario ist ein potenzieller Testfall.

design.md

Erläutert, wie die Änderung umgesetzt wird. Wird nur erstellt, wenn die Änderung eines bedarf.

Struktur

Die Vorlage, die der Agent als Ausgabeformat erhält (templates/design.md):

# Design

## Kontext

<!-- Aktueller Zustand und Einschränkungen, die den Ansatz prägen. Siehe proposal.md für die Motivation - nicht wiederholen -->

## Ziele / Nicht-Ziele

**Ziele:**
<!-- Was dieses Design erreichen soll -->

**Nicht-Ziele:**
<!-- Was explizit außerhalb des Geltungsbereichs liegt -->

## Entscheidungen

<!-- Wichtige Desigmentscheidungen mit Begründung und berücksichtigten Alternativen -->

## Risiken / Abwägungen

<!-- Bekannte Risiken und Abwägungen -->

Anweisungen

Die Anweisung, die an den Agenten gesendet wird, wenn er dieses Artefakt erstellt (aus schema.yaml):

Erstellen Sie das Designdokument, das erklärt, WIE die Änderung umgesetzt wird.

Wann design.md eingefügt wird (nur erstellen, falls zutreffend):
- Übergreifende Änderung (mehrere Services/Module) oder neues architektonisches Muster
- Neue externe Abhängigkeit oder signifikante Änderungen am Datenmodell
- Sicherheits-, Leistungs- oder Migrationskomplexität
- Mehrdeutigkeit, die von technischen Entscheidungen vor der Programmierung profitiert

Abschnitte:
- **Kontext**: Nur der aktuelle Zustand und die Einschränkungen, die zur Erläuterung des Ansatzes erforderlich sind. Verweisen Sie für die Motivation auf die Proposal, statt sie zu wiederholen (z. B. „Siehe proposal.md - Warum").
- **Ziele / Nicht-Ziele**: Was dieses Design erreicht und explizit ausschließt. Wiederholen Sie nicht den Geltungsbereich der Proposal - fügen Sie nur Grenzen auf Designtiefe hinzu.
- **Entscheidungen**: Wichtige technische Wahlentscheidungen mit Begründung (warum X und nicht Y?). Berücksichtigte Alternativen für jede Entscheidung einbeziehen.
- **Risiken / Abwägungen**: Bekannte Einschränkungen, mögliche Fehlentwicklungen. Format: [Risiko] → Milderungsmaßnahme
- **Migrationsplan**: Schritte zur Bereitstellung, Rollback-Strategie (falls zutreffend)
- **Offene Fragen**: Unbekannte Faktoren, die sicher später beantwortet werden können, ohne die Specs, den Ansatz oder die Aufgabenaufteilung zu ändern. Auslassen, falls keine vorhanden.

Offene Fragen sind für tatsächlich verschiebbare Unbekannte, nicht für Entscheidungen, die Sie übersprungen haben. Wenn eine Frage die Specs, den gewählten Ansatz oder die Aufgabenaufteilung ändern würde, klären Sie sie jetzt - fragen Sie den Benutzer, anstatt zu raten.

Konzentrieren Sie sich auf Architektur und Ansatz, nicht auf die Implementierung im Detail.
Die Proposal behandelt das Warum und Was; das Design behandelt das Wie. Verweisen Sie auf die Proposal für die Motivation und, sobald geschrieben, auf die Specs für die Anforderungen - wenn ein Abschnitt nur wiederholen würde, verweisen Sie stattdessen darauf.

Gute Designdokumente erklären das „Warum" hinter technischen Entscheidungen.

tasks.md

Unterteilt die Implementierung in überprüfbare Aufgaben. apply verfolgt hier den Fortschritt.

Struktur

Die Vorlage, die der Agent als Ausgabeformat erhält (templates/tasks.md):

# Aufgaben

## 1. <!-- Aufgabengruppenname -->

- [ ] 1.1 <!-- Aufgabenbeschreibung -->
- [ ] 1.2 <!-- Aufgabenbeschreibung -->

## 2. <!-- Aufgabengruppenname -->

- [ ] 2.1 <!-- Aufgabenbeschreibung -->
- [ ] 2.2 <!-- Aufgabenbeschreibung -->

Anweisungen

Die Anweisung, die an den Agenten gesendet wird, wenn er dieses Artefakt erstellt (aus schema.yaml):

Erstellen Sie die Aufgabenliste, die die Implementierungsarbeit unterteilt.

Prüfen Sie vor dem Schreiben der Aufgaben die design.md auf offene Fragen. Wenn eine davon ändern würde, was gebaut wird, klären Sie diese zuerst mit dem Benutzer - übernehmen Sie keine nicht ausgesprochene Annahme in die Aufgabenliste.

**WICHTIG: Folgen Sie der Vorlage unten für nachverfolgbare Aufgaben.** Die Apply-Phase analysiert das Kontrollkästchen-Format, um den Fortschritt zu verfolgen. Ein Kästchen, das nur `x` enthält, zählt als erledigt, groß oder klein geschrieben und mit beliebigem Abstand, also ist auch `- [ x]` erledigt. Jede andere Markierung, einschließlich `- [~]`, `- [-]` und einem leeren `- []`, wird als unerledigt gelesen. Eine Zeile ohne Kontrollkästchen wird überhaupt nicht nachverfolgt.

Richtlinien:
- Gruppieren Sie verwandte nachverfolgbare Aufgaben unter ## nummerierten Überschriften
- Jede nachverfolgbare Aufgabe MUSS ein Kontrollkästchen sein: `- [ ] X.Y Aufgabenbeschreibung`
- Aufgaben sollten klein genug sein, um in einer Sitzung abgeschlossen zu werden
- Ordnen Sie Aufgaben nach Abhängigkeiten (was muss zuerst erledigt werden?)
- Verfolgen Sie Implementierungs- und Verifizierungsarbeit, die vor dem Archivieren abgeschlossen werden kann. Wenn der angeforderte Workflow Archivierung oder Arbeit umfasst, die diese Änderung archiviert erfordert, bewahren Sie diese Schritte als einfache Aufzählungspunkte in einem optionalen Abschnitt `## Workflow-Follow-up` am Ende der tasks.md auf. Diese Aufzählungspunkte sind Referenzinformationen außerhalb des nachverfolgten Aufgabenfortschritts.
- Jede Aufgabe MUSS angeben, wie der Abschluss verifiziert wird (ein Test, Befehl, beobachtbares Verhalten oder geliefertes Artefakt). Setzen Sie die Verifizierung in die Beschreibung des Kontrollkästchens dieser Aufgabe. Verwenden Sie eine separate Verifizierungsaufgabe nur, wenn sie eine breitere Integration oder Systemverhalten prüft, das mehrere Implementierungsaufgaben umfasst.
- Jede Aufgabengruppe MUSS die Tests und die Dokumentation bereitstellen, die ihre eigene Arbeit erfordert. Sammeln Sie NICHT Tests oder Dokumentation in einer finalen Gruppe - wenn eine späte Gruppe erstmals Arbeit einer früheren Gruppe ausführt, kaskadieren die Fehler zurück durch alle dazwischenliegenden Gruppen und erzwingen Nacharbeit. Eine Gruppe, deren Arbeit weder das eine noch das andere erfordert, wie z. B. Scaffolding oder Abhängigkeitseinrichtung, enthält auch keines von beiden. Eine finale Gruppe dient nur Integrationsprüfungen, nicht den Tests und der Dokumentation, die eine frühere Gruppe schuldete.

Beispiel:
```
# Aufgaben

## 1. Einrichtung

- [ ] 1.1 Neue Modulstruktur erstellen und verifizieren, dass die erwarteten Dateien vorhanden sind
- [ ] 1.2 Abhängigkeiten zur package.json hinzufügen und verifizieren, dass die Paketinstallation erfolgreich ist

## 2. Kernimplementierung

- [ ] 2.1 Datenexportfunktion implementieren und verifizieren, dass der Exporttest besteht
- [ ] 2.2 CSV-Formatierungsprogramme hinzufügen und verifizieren, dass die Komponententests Anführungszeichen und Trennzeichen abdecken
- [ ] 2.3 Export-API in docs/export.md dokumentieren und verifizieren, dass der dokumentierte Befehl wie geschrieben ausgeführt wird
```

Fügen Sie wenn zutreffend Workflow-Follow-up als einfache Aufzählungspunkte hinzu, zum Beispiel:
```
## Workflow-Follow-up

- Die Änderung archivieren, nachdem die Überprüfungsanforderungen des Projekts erfüllt sind.
- Das archivierte Ergebnis verifizieren.
```

Verweisen Sie für das, was gebaut werden muss, auf die Specs, für das, wie es gebaut werden muss, auf das Design.

Apply

Die Übergabe von der Planung zur Implementierung. Apply ist die Phase, die durch tasks.md arbeitet, kein Artefakt.

• Beginnt: sobald tasks.md existiert und mindestens eine Aufgabe auflistet.
• Verfolgt: die Kontrollkästchen in tasks.md. Das Abhaken ist der Fortschrittsnachweis.
• Endet: jedes Kontrollkästchen abgehakt. OpenSpec schlägt dann das Archivieren der Änderung vor.

Einstellungen

Die Apply-Einstellungen (aus schema.yaml):

apply:
  requires: [tasks]
  tracks: tasks.md
  # Anweisung: unten gezeigt

Anweisungen

Die Anweisung, die an den Agenten gesendet wird, wenn die Implementierung beginnt (aus schema.yaml):

Lesen Sie die Kontextdateien, arbeiten Sie anstehende Aufgaben ab und markieren Sie sie als erledigt, während Sie fortfahren.
Halten Sie an, wenn Sie auf Hindernisse stoßen oder Klärung benötigen.

schema.yaml

Die vollständige schema.yaml, mit ausgelassenen Anweisungskörpern. Jede wird vollständig in ihrem Abschnitt oben gezeigt.

name: spec-driven
version: 1
description: Standardmäßiger OpenSpec-Workflow - proposal → specs → design → tasks
artifacts:
  - id: proposal
    generates: proposal.md
    description: Ursprüngliches Proposaldokument, das die Änderung skizziert
    template: proposal.md
    # Anweisung: vollständig unter proposal.md oben gezeigt
    requires: []

  - id: specs
    generates: "specs/**/*.md"
    description: Detaillierte Spezifikationen für die Änderung
    template: spec.md
    # Anweisung: vollständig unter Delta-Specs oben gezeigt
    requires:
      - proposal

  - id: design
    generates: design.md
    description: Technisches Designdokument mit Implementierungsdetails
    template: design.md
    # Anweisung: vollständig unter design.md oben gezeigt
    requires:
      - proposal

  - id: tasks
    generates: tasks.md
    description: Implementierungscheckliste mit nachverfolgbaren Aufgaben
    template: tasks.md
    # Anweisung: vollständig unter tasks.md oben gezeigt
    requires:
      - specs
      - design

apply:
  requires: [tasks]
  tracks: tasks.md
  # Anweisung: vollständig unter Apply oben gezeigt