From bette-think
Generates 5-stage PRDs for complex features with 15-25 AI behavior examples, rollout plans, gates, and checklists. Invoke via /spec --deep full-prd for deep work.
How this skill is triggered — by the user, by Claude, or both
Slash command
/bette-think:prd-writerThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
> **DEEP REFERENCE SKILL**
DEEP REFERENCE SKILL
For most PRD work, start with
/spec --feature(Lite PRD flow). Use this skill via/spec --deep full-prdwhen you need:
- The full 5-stage evolution (Planning → Kickoff → Solution Review → Launch Ready → Impact Review)
- 15-25 behavior examples for AI features
- Detailed rollout planning with gates
- Complete quality checklists
This skill creates modern, decision-focused PRDs that work with AI prototyping tools while maintaining strategic clarity. Based on proven practices from leading tech companies including OpenAI.
PRDs are about decisions, not documentation.
A great PRD in 2025:
The fatal flaw of bad PRDs: They say a lot without deciding anything. "Improve engagement" is a hope, not a specification.
Even with AI prototyping tools (Cursor, Replit, v0), PRDs remain critical because prototypes don't specify:
Key insight: When building fast becomes easy (thanks to AI), knowing what to build becomes even more important.
Old flow (linear): PRD → Design → Build → Test
New flow (cyclical): Idea → Quick Prototype → PRD → Refined Prototype → Ship
Prototypes as discovery tools:
PRDs as prototype constraints:
The feedback loop:
Teams that skip PRDs typically:
The PRD is your insurance policy against these failures.
Every great PRD must include these elements:
For AI features, add these critical elements:
The defining characteristic of AI PRDs: tons of concrete examples
Include 15-25 labeled examples showing:
Format for each example:
User Input: [specific query or scenario]
Good Response: [desired AI behavior]
Bad Response: [what to avoid]
Reject: [when to refuse]
Reference model: OpenAI's Model Spec is the gold standard - filled with concrete examples, not abstract principles.
Critical principle: Don't treat PRDs as one-and-done. They evolve through the product lifecycle.
Lightweight exploration document:
Purpose: Build shared understanding and get alignment to proceed
Decision to build - now add structure:
Purpose: Set boundaries and success criteria before detailed design
Detailed specification ready for engineering:
Purpose: Engineering can build to this spec
Pre-ship checklist completion:
Purpose: Safe, measurable launch
Learning and iteration:
Purpose: Close the loop and capture learnings
Why: LLMs create verbose, decision-free documentation that says nothing
Instead:
Bad (vague): "Improve user engagement" Good (specific): "P50 reply time drops ≥10% vs control group"
Bad (generic): "Generate helpful replies" Good (actionable): "For simple questions (<10 words), respond within 2s with contextually relevant suggestions based on last 3 messages"
Bad (hopeful): "Reduce support tickets" Good (measurable): "Decrease returns-related support tickets by 15-20% (from baseline 18% to 14.4-14.8%) measured over 30-day post-implementation window"
Every section should answer a decision:
Before considering a PRD complete, verify:
Strategic Clarity
Measurability
Actionability
Risk Management
Rollout Precision
Decision Quality
Symptom: Long paragraphs explaining context with no actionable outcomes
Fix: Every paragraph should end with a decision or a specific example
Symptom: "Improve engagement", "Increase satisfaction", "Reduce costs"
Fix: "P50 engagement time increases ≥15%", "NPS increases from 42 to 48+", "Server costs decrease $12K/month"
Symptom: "Start small, then ramp" or "Three-phase approach"
Fix: "Week 1: 5% US users, Week 2: Graduate if p<0.05 and +10% metric, Week 3: Scale to 25%"
Symptom: "Generate helpful replies" or "Provide good recommendations"
Fix: 25 labeled examples showing good/bad/reject cases with specific inputs and outputs
Symptom: PRD written once, never updated, gathering dust
Fix: Update PRD at each stage, link to results, annex learnings from production
When using AI tools in development, ensure:
Before Prototyping
During Prototyping
After Prototyping
Before Engineering
When creating PRDs, use this structure:
Title: [Feature Name]
Owner: [Name/Team]
Status: [Planning/Kickoff/Solution Review/Launch Ready/Shipped]
Last Updated: [Date]
Focus on:
Focus on:
Focus on:
Focus on:
When reviewing a PRD, assess these dimensions:
Ask: "Can engineering build from this without asking questions?" If no, the PRD needs more specificity.
For additional guidance, see:
references/prd-template.md - Complete template with examplesreferences/ai-examples.md - 50+ AI behavior examplesreferences/before-after.md - Real PRD transformationsreferences/metrics-library.md - Common metrics with thresholdsnpx claudepluginhub breethomas/bette-think --plugin bette-thinkUse this skill when the user asks to "write a PRD", "write a spec", "product requirements document", "generate a PRD", "turn this into a spec", "create product requirements", "write acceptance criteria", or explicitly asks for a PRD or product specification. This skill writes a full PRD. For a chained workflow with JTBD analysis, OST framing, and prototype-ready spec, use the /write-prd command instead. Do NOT use this skill if the user only wants to evaluate an idea strategically — use strategy-stack or the pre-mortem skill for that.
Provides PRD templates (lean, comprehensive, Amazon PR/FAQ, Google) for problem statements, metrics, requirements, user stories, and specs. Use for feature documentation and team alignment.
Generates Product Requirements Documents (PRDs) with user stories, success metrics, scope, technical considerations, and risks for product features.