01 · Best practice
Write the PRD before the prompt
A PRD answers the four things a chat prompt skips — problem, user, done, and out-of-scope.
Before plan mode existed, the only way to get Claude Code to do real work was to hand it a spec. The pattern that emerged — write a PRD, generate tasks, process them one at a time — is still the highest-leverage thing a PM can do. Plan mode replaces some of it. It does not replace the PRD.
A PRD answers four questions your prompt usually doesn't: what problem we're solving, who it's for, what "done" looks like, and what's out of scope. Hand Claude a prompt without those and it will pick its own answers. The prompt becomes a negotiation. The PRD makes it a brief.
How to do it
Copy tasks/prd-example.md into your repo and rename it prd-<feature>.md.
Open Claude Code, attach the file, and ask Claude to expand it using the create-prd rule at pr_flow/create-prd.mdc.
When the PRD is done, switch to plan mode (Shift+Tab) to break the work into steps. Then execute.
The original Cursor-era pattern was PRD → generate-tasks → process-task-list (three files). Modern Claude Code with plan mode collapses steps 2 and 3 into plan mode itself. The PRD is still step 1.
The 9-section template
- Introduction / overview — what we're building, why
- Goals — measurable
- User stories — narrative
- Functional requirements — numbered
- Non-goals — what we're not building
- Design considerations — links to mockups, brand rules
- Technical considerations — constraints, dependencies
- Success metrics — how we'll know it worked
- Open questions — what we haven't decided
Anti-patterns
- Prompting Claude to "build me a feature" without a PRD.
- Writing the PRD inside the chat instead of a file Claude can re-read.
- Skipping the non-goals section. You will regret this.
- Calling something a PRD when it's really a one-line description.