Lesson #1483
← Back to Knowledge Board
spec-driven-development-required
- ID
- 1483
- Author
- Agent
- agent-claude
- Reviewed
- ✓ Yes
- Source authority
- 75 / 100
- Source
- Alle Agenten (claude/codex/or/gemini/cursor) müssen Spec-Driven-Development einhalten: erst Spec/Plan-Dokument, dann TDD-Tasks, dann Code
- Source issue
- —
- Created at
- 2026-05-12T14:06:41.352535+00:00
- Valid until
- —
- Deprecated at
- —
- Supersedes
- —
- Obsidian path
- /root/.claude/projects/-nvmetank1-projects/memory/feedback_spec_driven_development.md
- Obsidian hash
- b81b672438c2b72127781659eaba72c5
- Tags
- claude-memory,feedback
Content
**Rule:** Jede non-trivial-Task (>30 Zeilen oder cross-file) MUSS einen Spec + Plan in `docs/superpowers/{specs,plans}/` haben BEVOR Code geschrieben wird.
**Why:** User-Direktive 2026-05-12: "schauen dass agents immer Spec-Driven Development (SDD) einhalten". Ohne SDD: Agenten implementieren Lösungen die das eigentliche Problem nicht treffen, Refactors sind ad-hoc, Test-Coverage zufällig.
**Vorlage (proven pattern aus bugtest-stack):**
```
docs/
superpowers/
specs/
2026-05-12-feature-X-design.md ← WHAT (Requirements, Scope, Constraints, APIs)
plans/
2026-05-12-feature-X-phase1.md ← HOW (TDD-Tasks: failing-test → code → commit)
```
## SDD-Checkliste pro Agent-Task
**Pre-code (Spec phase):**
- [ ] Spec-Dokument in `docs/superpowers/specs/YYYY-MM-DD-<slug>-design.md` existiert
- [ ] Spec enthält: Goal, Non-Goals, API/Schema/UI-contracts, Acceptance criteria, Open Questions
- [ ] User-direktive oder Issue-Body referenziert die Spec
**Plan phase:**
- [ ] Plan-Dokument in `docs/superpowers/plans/YYYY-MM-DD-<slug>-phase1.md` existiert
- [ ] Tasks nummeriert, jeder mit: failing-test-vorschlag + minimal-code-vorschlag + commit-message-vorschlag
- [ ] Akzeptanz pro Task explizit (pytest-ausgabe, curl-output, screenshot)
**Code phase (per Task):**
- [ ] Failing-Test zuerst (red)
- [ ] Minimal Code (green)
- [ ] Refactor optional (blue)
- [ ] Commit mit Plan-Reference: `feat(scope): <one-line> — plan §3.2`
## Wann SDD übersprungen werden DARF
- Single-line bugfix mit obvious-fix (TypoX, falsche Import)
- Mechanical refactor (rename, search-replace) — keine Logik-Änderung
- Hotfix in Production-broken-state (dann SDD post-mortem within 24h)
- Stub/Skeleton-Creation (mkdir + leere __init__.py)
## Wo Spec dispatchet wird
Im Gitea-Issue-Body MUSS stehen:
```
## Spec
docs/superpowers/specs/2026-05-12-feature-X-design.md
## Plan
docs/superpowers/plans/2026-05-12-feature-X-phase1.md §3 (oder §1-§5)
```
Wenn die Spec-Files noch nicht existieren: dispatch-Comment sagt explizit
`@agent-claude` bitte Spec + Plan zuerst, dann re-dispatch.
## Handler-Enforcement
`/usr/local/lib/agent-handler-common.sh` `fetch_issue_context()` checkt
ob `docs/superpowers/specs/` oder `## Spec`/`## Plan` im Issue-Body —
wenn nicht, prepend Warning an den Prompt:
"⚠️ NO SPEC REFERENCED — start by writing one (siehe Memory feedback_spec_driven_development)".
## Bestehende guten Beispiele
- `bugtest-stack/docs/superpowers/specs/2026-05-12-bugtest-stack-design.md` + matching plan
- `bugtest-stack/docs/superpowers/plans/2026-05-12-bugtest-stack-phase1.md` (18 nummerierte TDD-Tasks)
## Anti-pattern (vermeiden)
- "@agent-codex bitte fix das" ohne Spec-link
- Sprung in Code ohne plan-Datei
- "tests/conftest.py" creation ohne Test-First-Erklärung was getestet wird
## Tooling
```bash
# Spec-Template erzeugen:
mkdir -p docs/superpowers/specs docs/superpowers/plans
cat > docs/superpowers/specs/$(date +%Y-%m-%d)-<slug>-design.md <<EOF
# <Feature Name> — Spec
## Goal
<one paragraph>
## Non-Goals
- ...
## API / Schema / UI contracts
- ...
## Acceptance criteria
- [ ] ...
## Open Questions
- ...
EOF
```
Plan-Template ähnlich, mit Tasks nummeriert + TDD-Steps.