Rule: Generating a Product Requirements Document (PRD)
When to use
Use this skill when the task is primarily about product and this guidance is the most relevant operating rule set.
When not to use
Do not use this skill as the primary guide when another skill has a tighter domain fit for the requested output.
Trigger cues
- Request explicitly references
create-prd or this source file.
- Request language includes terms like: create, prd.
- Keywords include: PRD, success metrics, goals/non-goals, user journey, roadmap, launch memo, BDD, Gherkin, acceptance criteria.
Routing boundary
- Primary for problem definition, PRD scope, metrics, BDD acceptance criteria, and product narrative.
- Do not use as primary for deep UI styling or low-level code implementation.
Inputs required
- Goal or task request
- Current constraints (time, scope, platform, risk)
- Existing artifacts (code, docs, screenshots, metrics) when available
- Source of truth:
subagents/product manager/create-prd.md
Instructions
- Read references/source.md first.
- Extract the non-negotiable rules and translate them into a short execution checklist.
- Include unambiguous BDD/Gherkin scenarios (
Given / When / Then) under Acceptance Criteria as a bridge to implementation test suites.
- Apply the checklist to the current task, produce concrete outputs, and avoid abstract recommendations.
- Validate outcomes with evidence (tests, screenshots, logs, diffs, or written audit findings).
- Record decisions and tradeoffs so another engineer can continue without re-discovery.
Completion gate
Before reporting completion, verify the applicable binary contracts in evals/cases.json: explicit problem and measurable outcome, non-goals, unambiguous Given / When / Then acceptance behavior, and visible unknowns rather than invented facts.
Output format
- Primary decision/output: Problem scope, measurable outcomes, BDD/Gherkin acceptance criteria, and what not to build yet.
- Summary: one-paragraph decision or result
- Actions: compact checklist with owners and status
- Evidence: links/paths to artifacts proving completion
1---2name: create-prd3description: Trigger: PRD, product requirements, spec, problem framing, project scoping, roadmap. Scope: Creating and updating product requirement documents and framing problem scopes. Boundary: Excludes code implementation, design mocks, or CI/CD config.4---56# Rule: Generating a Product Requirements Document (PRD)78## When to use910Use this skill when the task is primarily about product and this guidance is the most relevant operating rule set.1112## When not to use1314Do not use this skill as the primary guide when another skill has a tighter domain fit for the requested output.1516## Trigger cues1718- Request explicitly references `create-prd` or this source file.19- Request language includes terms like: create, prd.20- Keywords include: PRD, success metrics, goals/non-goals, user journey, roadmap, launch memo, BDD, Gherkin, acceptance criteria.2122## Routing boundary2324- Primary for problem definition, PRD scope, metrics, BDD acceptance criteria, and product narrative.25- Do not use as primary for deep UI styling or low-level code implementation.2627## Inputs required2829- Goal or task request30- Current constraints (time, scope, platform, risk)31- Existing artifacts (code, docs, screenshots, metrics) when available32- Source of truth: `subagents/product manager/create-prd.md`3334## Instructions35361. Read [references/source.md](references/source.md) first.372. Extract the non-negotiable rules and translate them into a short execution checklist.383. Include unambiguous BDD/Gherkin scenarios (`Given / When / Then`) under Acceptance Criteria as a bridge to implementation test suites.394. Apply the checklist to the current task, produce concrete outputs, and avoid abstract recommendations.405. Validate outcomes with evidence (tests, screenshots, logs, diffs, or written audit findings).416. Record decisions and tradeoffs so another engineer can continue without re-discovery.4243## Completion gate4445Before reporting completion, verify the applicable binary contracts in `evals/cases.json`: explicit problem and measurable outcome, non-goals, unambiguous `Given / When / Then` acceptance behavior, and visible unknowns rather than invented facts.4647## Output format4849- Primary decision/output: Problem scope, measurable outcomes, BDD/Gherkin acceptance criteria, and what not to build yet.50- Summary: one-paragraph decision or result51- Actions: compact checklist with owners and status52- Evidence: links/paths to artifacts proving completion
coreyone