Menu
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.
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
Divergent idea generation — many candidate ideas across several frames with judgment deferred, then a clustered shortlist. Use to open a solution space wide, or /brainstorm. Not for developing one idea (ideate) or picking one (propose).
Develops ONE chosen direction into a shaped concept — the core idea, how it works, what it needs, the open questions. Use to deepen a single idea, or /ideate. Not for generating many (brainstorm) or deciding among them (propose).
Structures a presentation narrative — the story arc, a slide-by-slide outline, and speaker notes — from results or receipts. Use to shape a talk or deck, or /present. Not for prose reports (report) or rendering visuals (asset).
Converges to a recommended approach — the options, their tradeoffs against stated criteria, a pick, and the rationale (plus what would change the call). Use to decide among approaches, or /propose. Not for generating options (brainstorm) or deep-diving one (ideate).
Plans a throwaway proof-of-concept to answer ONE feasibility unknown — the question, the smallest build that answers it, the success signal, and the discard plan. Use to de-risk before committing, or /prototype. Not for the real build (executor) or deciding (propose).
Produces a REDTEAM-FINDINGS.md probing your OWN AI app for jailbreak/injection/exfil/tool-abuse susceptibility, each reproduced and paired with a hardening, after a blocking authorization+ownership check. Use to red-team an owned AI system defensively.
| 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. |
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.
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).
PRODUCT-BRIEF.md yet — run product-brief first; a PRD with no problem/success
contract is solution-first and unanchored.PRD.md already fits and nothing changed — editing it beats rewriting a contract the
build is judged against.product-brief, not prd.prd.| 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) |
PRODUCT-BRIEF.md (problem, persona, success metric, non-goals) — the prerequisite contract.../vocabulary.md, ../acceptance/) + state/intake.json.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.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).A gate failure is fixed before lock, not waived — these mirror the editorial/accessibility/ai gates.
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.<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.product-brief first; do not write a PRD on an unstated problem.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).
prd turns
that attested brief into testable requirements. Always run product-brief first.prd writes the product requirements
the card and build are scoped against. Complementary — a PRD can seed several task cards.prd is upstream of that, at the product-decision layer.