Expert PRD (Product Requirements Document) writer for the AI era. Use when users want to create PRDs, spec documents, product specifications, feature specs, or technical requirements documents. Also use when users ask to review/improve existing PRDs, want PRD templates, need guidance on product documentation, or mention writing product specs. Handles both traditional and AI-specific product features with emphasis on decision-making over documentation.
/plugin marketplace add breethomas/pm-thought-partner/plugin install breethomas-pm-thought-partner@breethomas/pm-thought-partnerThis skill inherits all available tools. When active, it can use any tool Claude has access to.
references/before-after.mdreferences/prd-template.mdThis 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 thresholdsCreating algorithmic art using p5.js with seeded randomness and interactive parameter exploration. Use this when users request creating art using code, generative art, algorithmic art, flow fields, or particle systems. Create original algorithmic art rather than copying existing artists' work to avoid copyright violations.
Applies Anthropic's official brand colors and typography to any sort of artifact that may benefit from having Anthropic's look-and-feel. Use it when brand colors or style guidelines, visual formatting, or company design standards apply.
Create beautiful visual art in .png and .pdf documents using design philosophy. You should use this skill when the user asks to create a poster, piece of art, design, or other static piece. Create original visual designs, never copying existing artists' work to avoid copyright violations.