# PRD Template — Feature (5 Sections)

> Template for `/plan feature` mode. Used by SKILL.md Phase 3 to generate feature PRDs.
> Fill each `{{placeholder}}` with data gathered during the Q&A waves.
> Delete this instruction block before saving the final PRD.

---

# Feature: {{feature-name}}

**Date:** {{YYYY-MM-DD}}
**Author:** {{user}} + Claude (AI-assisted planning)
**Status:** Draft
**Appetite:** {{1w|2w|6w}}
**Parent Project:** {{project-name or "standalone"}}

## 1. Problem & Motivation

### What
{{What we're building — clear, concise description}}

### Why
{{Business driver, user feedback, or technical necessity — from Wave 1 Q2}}

### Who
{{Target users — existing personas or new audience — from Wave 1 Q3}}

### Evidence Baseline
> The premise, measured. One row per claim the plan rests on. A claim that did not reproduce stays here, marked `hypothesis`.

| Claim | Command | Result | Measured (date / SHA) |
|-------|---------|--------|-----------------------|
| {{premise}} | `{{command}}` | {{result}} | {{YYYY-MM-DD @ sha}} |

## 2. Solution & Scope

### In-Scope
- [ ] {{scope-item-1}}
- [ ] {{scope-item-2}}
- [ ] {{scope-item-3}}

### Out-of-Scope
- {{excluded-1 — why}}
- {{excluded-2 — why}}

### First Real Use / Kill
{{The first use outside tests, who triggers it and by when (e.g. "first committed manifest in a consumer repo by YYYY-MM-DD"). If it has not happened by then: re-shape or kill (mvp-scope Circuit Breaker), never silent carry-over.}}

## User Stories

> Optional intent layer — emitted only when the Wave-1 story toggle is "yes". Leave blank or delete this section if §3/§3.A acceptance criteria already capture the intent. Stories are the "who/why"; acceptance criteria are the "verify".

### US-1 (→ {{Feature Area}})
**Als** {{Persona}} **möchte ich** {{Capability}}, **damit** {{Nutzen}}.
- ↳ AC: {{§3 / §3.A reference to ≥1 acceptance criterion}}

### US-2 (→ {{Feature Area}})
**Als** {{Persona}} **möchte ich** {{Capability}}, **damit** {{Nutzen}}.
- ↳ AC: {{§3 / §3.A reference to ≥1 acceptance criterion}}

> **Alternative form (job-story / JTBD):** if the Wave-1 toggle selected "Ja (job-story)" instead of "Ja (Als/möchte/damit)", emit each story in this shape instead of US-1/US-2 above — use ONE form consistently across the whole section, never mix:
>
> ### US-1 (→ {{Feature Area}})
> **When** {{situation}}, **I want** {{motivation}}, **so I can** {{outcome}}.
> - ↳ AC: {{§3 / §3.A reference to ≥1 acceptance criterion}}

## 3. Acceptance Criteria

### {{Feature Area 1}}
```gherkin
Given {{precondition}}
When {{action}}
Then {{expected result}}
```

### {{Feature Area 2}}
```gherkin
Given {{precondition}}
When {{action}}
Then {{expected result}}
```

### {{Edge Case / Error Handling}}
```gherkin
Given {{error condition}}
When {{action}}
Then {{graceful handling}}
```

> Under every scenario block, add one line `Oracle: {{who or what other than the author shows it holds — the installed artifact read back, the platform's own output, an independent process, a calibration fixture with known answers, a consumer-repo run}}`. Use `Oracle: n/a — {{reason}}` only when no such judge exists. The author's unit test against a fake is not an oracle.

### External Acceptance
> Criteria whose oracle cannot run inside the implementing session. Each row becomes its own `[Abnahme]` issue (SKILL.md § 6.1), which the implementing issue does not close.

| Criterion | Oracle | Owner | Not before | Pass condition | Fallback if it cannot run |
|-----------|--------|-------|------------|----------------|---------------------------|
| {{AC ref}} | {{command / observation}} | {{owner}} | {{YYYY-MM-DD}} | {{pass}} | {{fallback}} |

## 3.A Acceptance Criteria (EARS)

> Optional companion to Section 3 — translates each Feature Area's acceptance criteria into EARS-shaped statements for deterministic vitest stub generation by `/write-executable-plan`. Leave blank if Section 3's narrative Gherkin suffices.

### Feature Area 1 — {{name}}

**Ubiquitous** (always-true invariants — no trigger, no state):
- The {{system}} shall {{response}}.

**State-driven** (`While …`):
- While {{precondition}}, the {{system}} shall {{response}}.

**Event-driven** (`When …`):
- When {{trigger}}, the {{system}} shall {{response}}.

**Optional feature** (`Where …`):
- Where {{feature enabled}}, the {{system}} shall {{response}}.

**Unwanted behaviour** (`If … then …`):
- If {{unwanted condition}}, then the {{system}} shall {{response}}.

### Feature Area 2 — {{name}}

[repeat pattern]

### Edge Case / Error Handling

[repeat pattern, typically focused on Unwanted + Optional]

## 4. Technical Notes

### Affected Files
- `{{file-path-1}}` — {{what changes}}
- `{{file-path-2}}` — {{what changes}}

### Architecture
{{High-level approach — patterns to follow, components to modify}}

### Data Model Changes
{{New tables, columns, migrations — or "None"}}

### API Changes
{{New endpoints, modified contracts — or "None"}}

## 5. Risks & Dependencies

| Risk | Impact | Mitigation | Triage |
|------|--------|------------|--------|
| {{risk-1}} | {{impact}} | {{mitigation}} | {{Triage: Defer\|Implement\|Reject\|Experiment}} |

### Dependencies
- {{dependency-1}}: {{status}}
- {{open-issue-ref}}: {{relationship}}