# PRD Template (Structured Intake)

This is the input template for Mode C of `/fluent-use-case-discover`. A BA, PM, or stakeholder fills this out before the spec wizard runs. The skill validates the PRD, maps fields to spec sections, and produces a pre-seeded `spec.md` with a gap report.

**Purpose:** Faster path to a Business Spec when requirements are already partially known. Replaces the 12-phase interactive wizard with a structured form + validation + gap-fill.

**Design principle:** This template is intentionally domain-agnostic. It captures business intent in business language. Domain-specific mapping (entity types, orchestrability, workflow validation) happens during spec generation, not here.

---

## Template

```markdown
# PRD: [Feature Name]

## Meta

| Field | Value |
|-------|-------|
| **Author** | [name or team] |
| **Date** | YYYY-MM-DD |
| **Priority** | P0 / P1 / P2 / P3 |
| **Target Account** | [account or environment name] |
| **Requested By** | [stakeholder, team, or business driver] |

## 1. Feature Overview

<!-- 3-5 sentences: What does this feature do? Who does it serve? What business problem does it solve? -->

## 2. Business Requirements

| ID | Requirement | Notes |
|----|-------------|-------|
| BR-001 | [Requirement description] | |
| BR-002 | [Requirement description] | |
| BR-003 | [Requirement description] | |

## 3. Actors & Trigger

<!-- Who interacts with this feature? Use business roles, not system roles. -->

| Actor | Role | Actions |
|-------|------|---------|
| [e.g., Store Associate] | Warehouse staff | Picks items, confirms ready |
| [e.g., Operations Manager] | Back-office | Monitors orders, resolves exceptions |
| [e.g., WMS] | External system | Receives fulfilment requests |

**Trigger:** [What starts this feature? e.g., "New home delivery order placed", "Scheduled batch at 6am daily"]

## 4. Integrations

<!-- External systems involved. Leave empty if none. -->

| System | Direction | What Is Exchanged |
|--------|-----------|-------------------|
| [e.g., WMS] | Outbound (we send to them) | Fulfilment details — items, quantities, destination |
| [e.g., Carrier API] | Outbound | Shipment booking request |
| [e.g., POS] | Inbound (they send to us) | Order creation payload |

## 5. Success Criteria

<!-- What does success look like? Measurable outcomes where possible. -->

- [e.g., Reduce order fulfilment time from 4 hours to 1 hour]
- [e.g., Eliminate manual carrier selection for 90% of orders]
- [e.g., Zero orders stuck in processing for more than 30 minutes]

## 6. Out of Scope

- [Item explicitly excluded from this effort]
- [Item explicitly excluded from this effort]

## 7. Assumptions

- [Assumption about the environment, data, dependencies, or user behaviour]
- [Assumption about the environment, data, dependencies, or user behaviour]

## 8. Constraints

<!-- Non-functional requirements, hard limits, or guardrails. Leave empty if none. -->

- [e.g., Must not break existing home delivery flow]
- [e.g., Must handle 500 orders/hour at peak]
- [e.g., Must go live before Black Friday]

## 9. Acceptance Criteria

<!-- High-level proof that the feature works. Given/When/Then preferred, bullets also fine. -->

1. Given [precondition], When [action], Then [expected result]
2. Given [precondition], When [action], Then [expected result]

## 10. Open Questions

<!-- Anything unresolved. Leave empty if fully scoped. -->

- [e.g., What is the SLA for WMS response time?]
- [e.g., Should partial picks be allowed?]

## Attachments / References

<!-- Links to Jira tickets, Confluence pages, screenshots, meeting notes, existing specs. -->

- [link or file path]
```

---

## PRD-to-Spec Section Mapping

This table describes how the spec wizard maps PRD sections to spec sections during generation. The stakeholder does not need to know this — it is reference for the skill.

| PRD Section | Maps to Spec Section | Auto-seedable? | Notes |
|---|---|---|---|
| Feature Overview | §1 Problem Statement + §2 Feature Summary | Yes | Wizard splits overview into problem + summary + type |
| Business Requirements | §7 Business Rules | Partial | Flat rules need condition/action expansion |
| Actors & Trigger | §4 Actors & Triggers | Yes | Wizard maps business roles to platform roles |
| — | §4a Roles & Permissions | No | Wizard infers from actors, confirms interactively |
| — | §5 Use Cases | No | PRD has rules, not flows. Wizard expands interactively. |
| — | §5a User Journey Diagrams | No | Auto-generated from expanded use cases |
| — | §6 Entity Model | No | Wizard infers entities from requirements + actors, validates against environment |
| Integrations | §8 Integrations | Partial | Direction + data seeded, failure handling needs expansion |
| — | §9 User Actions | No | Wizard infers from actors + requirements |
| — | §9a UI / Frontend | No | Wizard asks if UI work is needed |
| Success Criteria | §2 Feature Summary (KPIs) | Yes | Direct mapping to success metrics |
| Out of Scope | §3 Scope | Yes | Out-of-scope seeds directly; in-scope inferred from requirements |
| Assumptions | §11 Assumptions | Yes | Direct mapping |
| Constraints | §10 Constraints & Risks | Partial | Constraints seed directly, risks need expansion |
| Acceptance Criteria | §13 Acceptance Criteria | Partial | Draft criteria seeded, may need Given/When/Then refinement |
| Open Questions | §12 Open Questions | Yes | Direct mapping, wizard adds blocking-section references |

## Gap Classification

After mapping, each spec section gets a gap status:

| Status | Meaning | Action |
|---|---|---|
| **SEEDED** | Fully populated from PRD | No further questions needed |
| **PARTIAL** | Some data from PRD, needs expansion | Ask targeted questions (not full phase) |
| **EMPTY** | No PRD data maps here | Run the full phase interactively OR mark as assumption |
| **VALIDATED** | Seeded + confirmed against live environment | Highest confidence |
