prd

name	prd
description	Produces a PRD.md (scope, user stories, testable acceptance criteria, edge cases, out-of-scope) from an attested product brief; primes the editorial + accessibility + ai gates. Use after the product brief to spec what to build.

prd

The requirements producer of the product domain — it turns an attested PRODUCT-BRIEF.md (the why/who) into a PRD.md (the what): scope, user stories, testable acceptance criteria, edge cases, and an explicit out-of-scope. A vague PRD is a vague build, so the bar is that every acceptance criterion is testable and ambiguity is removed before the build starts. Verified by Attestation — a named owner attests the spec is sound and owns it; a downstream build of the PRD is then verified by that domain's mode (software=Test, content=Review, data=Measurement). prd runs after product-brief, not instead of it.

What this does / does not do

Does: resolve the prd sub_target, read the attested product brief, and write a PRD.md with scope + user stories + testable acceptance criteria + edge cases + out-of-scope, grounded in the brief's problem and success metric; write a prd receipt. Does not: decide the problem/persona/success metric (that is product-brief, the prerequisite), build the thing (the relevant domain's executor does), run the gate verdict (the editorial/accessibility/ai gates do — this primes them), or invent users/data (assumptions are flagged, never fabricated).

When NOT to use

• There is no attested PRODUCT-BRIEF.md yet — run product-brief first; a PRD with no problem/success contract is solution-first and unanchored.
• A current, committed PRD.md already fits and nothing changed — editing it beats rewriting a contract the build is judged against.
• The work is the problem framing / success metric itself — that is product-brief, not prd.
• The user wants the PRD judged/attested or built — that is the gates + the Attestation owner + the build domain, not prd.

Reference Routing

Situation	Reference
The PRD.md contract template	references/prd-template.md
Per-sub_target must-declares · overlay · vocabulary	../acceptance/sub-targets.md · ../acceptance/overlay.md · ../vocabulary.md
The upstream product contract	the attested PRODUCT-BRIEF.md (from product-brief)

Inputs

• The attested PRODUCT-BRIEF.md (problem, persona, success metric, non-goals) — the prerequisite contract.
• The product domain pack (../vocabulary.md, ../acceptance/) + state/intake.json.
• Mode B only: an existing PRD / ticket set to normalize into a testable PRD.

How to do it

1. Anchor on the brief: load PRODUCT-BRIEF.md; if absent, stop and route to product-brief (ordering: brief before PRD). Carry the problem, persona, and success metric forward as the frame.
2. Scope: state what is in scope this round, traceable to the brief's success metric; defer the rest.
3. User stories: as a [persona], I want [capability], so that [outcome] — each tied to the persona and a slice of the success metric, not a feature wishlist.
4. Testable acceptance criteria: per story, Given/When/Then (or equivalent) that a build can be checked against. Remove ambiguity — a criterion a reasonable engineer could satisfy two different ways is rewritten.
5. Edge cases: the off-happy-path conditions (empty, error, limit, concurrent, permission) each story has to handle, so they are decided here, not discovered in the build.
6. Out-of-scope: explicit, inherited from and extending the brief's non-goals, so scope is bounded.
7. Write PRD.md from references/prd-template.md; name the attestation owner; flag any market/user assumption (record_type alert) rather than stating it as fact (the ai/compliance gates).

Gate (before marking complete)

• A PRODUCT-BRIEF.md exists and the PRD is anchored to its problem + success metric.
• Every acceptance criterion is testable (a build can pass/fail it unambiguously).
• Each user story ties to the persona and the success metric. - [ ] Edge cases are enumerated per story.
• Out-of-scope is explicit. - [ ] An attestation owner is named.
• AI-assisted synthesis is disclosed; no fabricated user quotes/data (the ai gate).

A gate failure is fixed before lock, not waived — these mirror the editorial/accessibility/ai gates.

Output

• PRD.md at the product root (or product/PRD.md / prd/PRD.md if that dir exists) — persistence: Spec-Anchored. Scope · user stories · testable acceptance criteria · edge cases · out-of-scope · traceability to the brief's success metric · attestation owner.
• receipt (<workspace>/receipts/prd-receipt-<ts>.json): base schema + sub_target, scope, user_stories, acceptance_criteria_testable, edge_cases, out_of_scope, prd_path, attested_by, gate_checks. persistence: Spec-Anchored.

Proactive Triggers

• An acceptance criterion that can't fail: rewrite it until a build can be checked against it — an untestable criterion is the vague-PRD failure mode.
• A user story with no persona / no outcome: tie it to the brief's persona and success metric, or cut it.
• No PRODUCT-BRIEF.md: stop and run product-brief first; do not write a PRD on an unstated problem.

Completion Criteria

Done when: a PRD.md exists anchored to an attested brief, with scoped user stories, testable acceptance criteria, enumerated edge cases, an explicit out-of-scope, and a named attestation owner; a prd receipt records the gate checks.

Not done if: there is no product brief; any acceptance criterion is untestable; stories lack a persona or outcome; edge cases or out-of-scope are missing; or user data was fabricated rather than flagged.

Next step: the relevant domain's executor builds against the PRD; that build is verified by the domain's mode (Test/Review/Measurement); the named owner attests the PRD itself (Attestation).

Related Skills

• product-brief: the prerequisite — decides the problem/persona/success metric/non-goals. prd turns that attested brief into testable requirements. Always run product-brief first.
• specify: writes the pipeline task card (the work's what/why); prd writes the product requirements the card and build are scoped against. Complementary — a PRD can seed several task cards.
• decompose: breaks a locked card into waves; prd is upstream of that, at the product-decision layer.