create-prd

Anti-Pattern: “Premature PRD”

Jumping straight to document generation produces generic, placeholder-heavy output. Even a “simple” feature has unstated assumptions about users, scope, and success criteria. The exploration steps exist to surface those assumptions — skip them and the PRD will need a full rewrite.

Process

1. Understand the request

Read the user’s feature request. If unclear, ask for a one-sentence description of what the feature does and who it’s for.

2. Choose exploration path

Ask the user:

How would you like to explore this feature?

(A) Discuss interactively — I’ll ask questions one at a time to build understanding (B) Provide prepared material — share docs, notes, or context you already have

Path A: Discuss interactively

• One question per message — build on previous answers
• Focus on: target users, desired behavior, scope boundaries, success criteria, constraints
• Prefer multiple-choice questions; open-ended when choices aren’t obvious
• Continue until the user signals readiness or you have enough to draft

Path B: Prepared material

• Read everything provided (docs, notes, prior art, screenshots)
• Only ask follow-ups if genuine gaps exist — don’t re-ask what’s already answered
• Summarize your understanding in 3–5 bullets
• Ask: “Continue with this understanding, or discuss further?”
  • If “discuss further” → switch to Path A

3. Confirm readiness

4. Generate PRD

Load the PRD template and fill every section with specifics from the exploration.

Writing guidelines:

• Explicit and unambiguous — write for junior developers and AI agents
• Number all requirements (FR-1, FR-2, …)
• Acceptance criteria must be verifiable, not vague (good: “Button displays ‘Save’ text”; bad: “Button looks good”)
• No placeholders — if a section genuinely doesn’t apply, write “N/A” with a brief reason
• Reference the user’s own language and examples from the exploration

5. Approve and deliver

Ask:

Approve this PRD? Deliver as:

(A) GitHub issue — creates an issue for tracking (B) Local file — saves to prds/

Or request edits.

Option A: GitHub issue

gh issue create --title "PRD: [Feature Name]" --body "$PRD_CONTENT"

Print the issue URL. Mention /prd-to-issues for decomposing the PRD into implementation issues.

Option B: Local file

Save to prds/[feature-name].md. Print the file path.