Product Spec Writer
Write feature specifications and PRDs from problem statements with user stories and acceptance criteria
Engineers keep asking 'what should happen when...' and you don't have an answer because the spec doesn't cover edge cases. Your feature specs describe the happy path but leave engineers guessing on error states, empty states, and permission boundaries.
Who it's for: product managers writing feature specs that engineering can build from, product owners defining sprint-ready user stories, UX designers specifying interaction details and edge cases, product designers documenting design decisions and constraints, technical writers creating detailed feature documentation
Example
"Write a feature spec for our new notification system" → Complete spec with problem statement, user stories, detailed acceptance criteria covering happy and error paths, wireframe descriptions, notification type matrix, and measurable success criteria
CLAUDE.md Template
New here? 3-minute setup guide → | Already set up? Copy the template below.
npx ccplaybooks add product-spec-writer# Product Spec Writer
Write a feature specification or product requirements document (PRD).
## Workflow
### 1. Understand the Feature
Accept any of:
- A feature name ("SSO support")
- A problem statement ("Enterprise customers keep asking for centralized auth")
- A user request ("Users want to export their data as CSV")Get new playbooks like this one
One email a week with new Claude Code workflows. Free, like everything here.
No spam. Unsubscribe anytime.
What This Does
Turns feature ideas, problem statements, or vague requests into structured PRDs. Generates problem statements, goals, non-goals, user stories, prioritized requirements (P0/P1/P2), success metrics, acceptance criteria, and open questions — all through a conversational process.
Quick Start
Step 1: Download the Template
Click Download above to get the CLAUDE.md file.
Step 2: Set Up Your Project
Create a project folder and place the template inside:
product-specs/
├── CLAUDE.md
├── specs/ # Generated PRDs
└── research/ # Supporting research
Step 3: Start Working
claude
Say: "Write a spec for SSO support — enterprise customers keep asking for centralized auth"
What Gets Produced
| Section | Details |
|---|---|
| Problem Statement | User problem, who's affected, cost of not solving |
| Goals | 3-5 specific, measurable outcomes |
| Non-Goals | What's explicitly out of scope (prevents scope creep) |
| User Stories | "As a [user], I want [capability] so that [benefit]" |
| Requirements | Must-Have (P0), Nice-to-Have (P1), Future (P2) |
| Success Metrics | Leading and lagging indicators with targets |
| Acceptance Criteria | Given/When/Then format |
| Open Questions | Tagged by who needs to answer |
Tips
- Be opinionated about scope — a tight, well-defined spec beats an expansive vague one
- If the idea is too big, suggest breaking it into phases and spec the first phase
- Success metrics should be specific and measurable, not vague
- Non-goals are as important as goals — they prevent scope creep
Example Prompts
"Write a spec for SSO support"
"Create a PRD for CSV data export"
"Spec out our onboarding flow redesign"
"Turn this user request into a feature spec: users want bulk operations"