Generate PRD
Path Resolution
- Read
workflow.jsonin the project root - If it exists and
docsRepois".": this IS the docs repo — use local paths - If it exists and
docsRepois a repo name: resolve viapwsh .claude/skills/tool-worktree/scripts/resolve-repo.ps1 <docsRepo>to get the docs root path. Templates at<resolved>/templates/, output to<resolved>/prd/ - If no
workflow.json: templates attemplates/, output todocs/prd/
Instructions
- Resolve paths (see Path Resolution above)
- Read the template at
<templates>/prd.md - Ask clarifying questions if the user hasn't provided enough context:
- What problem are we solving?
- Who is the target user?
- What are the key goals?
- Generate the PRD by filling in the template sections based on:
- User's description of the feature/product
- Existing codebase context (read relevant code if applicable)
- Domain knowledge from the project
- Save the PRD to
<output>/[slug].md(create the directory if needed) - Be opinionated — fill in non-goals, constraints, and success metrics based on what you know. The user can refine.
Quality Checklist
- Problem statement is specific, not vague
- Goals are measurable (numbers, percentages, or clear criteria)
- Non-goals are listed (at least 2)
- User stories follow "As a... I want... So that..." format
- Requirements have acceptance criteria
- Success metrics have current vs. target values
- Open questions are flagged (don't guess — ask)
Tips
- Link to related RFCs or ADRs if they exist
- Reference existing code patterns when defining requirements
- Keep it concise — a PRD should be scannable in 5 minutes