메뉴
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.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
| 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.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.