Loading skill
Install any skill in seconds. Free to start, no credit card required.
Get Started Free →Extract a product idea through guided questions and generate a PRD. Use when the user says 'write a PRD', 'spec this feature', 'turn this idea into a brief'. Not for a non-product initiative like hiring or partnerships (use `initiative-kickoff` once shipped); not for checking existing projects' status (use `project-health`).
.claude/skills/davekilleen-product-brief/SKILL.md| Test case | Without → With | Effect | Δ tokens | Δ turns |
|---|---|---|---|---|
| case-01 | ✗→✓ | ▲ Improved | 522% | 0% |
| case-02 | ✗→✓ | ▲ Improved | 188% | 0% |
| case-03 | ✗→✓ | ▲ Improved | 99% | 0% |
| case-07 | ✗→✓ | ▲ Improved | 148% | 0% |
| case-09 | ✗→✓ | ▲ Improved | 459% | 0% |
Extract product ideas from your head through guided questioning, then generate a detailed Product Requirements Document (PRD). Designed for product people who have a vision but need help articulating it clearly.
You have an idea for a product or feature in your mind, but struggle to explain it comprehensively. This command acts as your product thought partner — asking the right questions to extract what you're envisioning, then structuring it into a PRD ready for a team to execute.
/product-brief [initial idea]Examples:
/product-brief Add a notification system to our app/product-brief Build a customer feedback portal/product-brief Create an onboarding flow for new users/product-brief (prompts you for the idea)If no idea is provided: Ask: "What product or feature are you thinking about?"
If idea is provided: Start with whatever the user provides:
Display:
markdown## Initial Idea [User's description] --- **Next:** I'll ask a few questions to understand this better.
Important: Ask questions conversationally, not as a survey. 2-3 questions at a time, then wait for answers before asking more.
Question Strategy:
Round 1 (Critical Context):
Round 2 (Constraints & Scope): Based on Round 1 answers, ask about:
Round 3 (User Experience):
Round 4 (Success & Validation):
Adaptive questioning: If user mentions stakeholders, budget, or other context early, adjust questions accordingly. Don't ask what you already know.
After each round, acknowledge answers briefly and transition naturally: > "Got it. That helps me understand X]. A few more questions about Y]..."
Before moving forward, confirm you captured the vision correctly:
markdown## What I Heard **The Problem:** [Synthesized problem statement] **Target Users:** [Who this is for] **Core Value:** [The main benefit/outcome] **Key Constraints:** [Timeline, technical, scope boundaries] **Assumptions to Validate:** [Things we're assuming but should test] --- **Does this capture your vision? Type "yes" to continue or correct anything above.**
If user corrects, update and re-confirm.
User triggers with: spec doc or create spec
Generate structured product spec:
markdown# Product Spec: [Feature/Product Name] **Date:** YYYY-MM-DD **Owner:** [User's name] **Status:** Draft --- ## Executive Summary [2-3 sentence pitch: what this is and why it matters] --- ## Problem Statement ### Current Situation [What exists today] ### Pain Points - [Specific pain 1] - [Specific pain 2] - [Specific pain 3] ### Impact of Inaction [What happens if we don't build this] --- ## Target Audience ### Primary Users [Who will use this most] ### Secondary Users [Who else benefits] ### User Characteristics - [Key trait 1] - [Key trait 2] - [Key trait 3] --- ## Solution Overview [High-level description of what we're building] --- ## Key Features & Functionality ### Must Have (MVP) 1. **[Feature 1]** - Description - Why it's critical 2. **[Feature 2]** - Description - Why it's critical ### Should Have (Phase 2) 1. **[Feature 3]** - Description - Why it's valuable ### Nice to Have (Future) 1. **[Feature 4]** - Description - Why it's desirable --- ## Success Metrics ### Primary Metric [The one number that matters most] ### Secondary Metrics - [Metric 2] - [Metric 3] ### Leading Indicators [Early signals of success/failure] --- ## Assumptions & Risks ### Key Assumptions 1. [Assumption 1] - How to validate: [Test method] 2. [Assumption 2] - How to validate: [Test method] ### Risks 1. **[Risk 1]** — [Mitigation strategy] 2. **[Risk 2]** — [Mitigation strategy] --- ## Dependencies ### Technical - [System/API/service dependency] ### Team - [Who needs to be involved] ### External - [Third-party dependencies] --- ## Out of Scope Explicitly not included: - [Thing 1] - [Thing 2] - [Thing 3] --- ## Open Questions - [ ] [Question 1] - [ ] [Question 2] - [ ] [Question 3] --- **Next Steps:** - Type `prioritize` to rank features by effort/impact - Type `design flows` to create detailed user flows - Type `create prd` to generate final PRD - Type `back` to revise anything above
User triggers with: prioritize
Create effort/impact matrix:
markdown## Feature Prioritization | Feature | Impact | Effort | Priority | Rationale | |---------|--------|--------|----------|-----------| | [Feature 1] | High | Low | P0 | [Why] | | [Feature 2] | High | Medium | P0 | [Why] | | [Feature 3] | Medium | Low | P1 | [Why] | | [Feature 4] | Low | High | P2 | [Why] | ### Recommended MVP Scope Based on high impact + reasonable effort: 1. [Feature 1] 2. [Feature 2] 3. [Feature 3] **Estimated Effort:** [X weeks/sprints] --- **Next:** - Type `design flows` to create user flows - Type `create prd` to generate final PRD - Type `back` to revise spec
User triggers with: design flows
Create detailed user flows and screen specs:
markdown## User Flows & Screen Specifications ### Flow 1: [Primary User Journey] **Entry Point:** [How user arrives] **Steps:** #### Step 1: [Screen Name] **Layout:** - [Header elements] - [Main content area] - [Actions/buttons] **User Actions:** - Click [X] → [Outcome] - Enter [Y] → [Validation rules] - Cancel → [State change] **Navigation:** - Success → [Next screen] - Error → [Error state] - Back → [Previous screen] **Validation Rules:** - [Field 1]: [Rules] - [Field 2]: [Rules] **States:** - Default: [Description] - Loading: [What user sees] - Error: [Error message] - Success: [Confirmation] --- #### Step 2: [Next Screen] [Same structure as Step 1] --- ### Flow 2: [Secondary Journey] [Same structure as Flow 1] --- **Next:** - Type `create prd` to generate final PRD - Type `back` to revise flows
User triggers with: create prd or generate prd
Generate comprehensive PRD combining all previous phases:
markdown# Product Requirements Document ## [Product/Feature Name] **Author:** [User name] **Date:** YYYY-MM-DD **Status:** Draft **Last Updated:** YYYY-MM-DD --- ## Document Control | Version | Date | Author | Changes | |---------|------|--------|---------| | 0.1 | YYYY-MM-DD | [Name] | Initial draft | --- ## Executive Summary [2-3 paragraphs covering: what, why, who, success] --- ## Background & Context ### Current State [What exists today] ### Problem Statement [The problem we're solving] ### Opportunity [Why now, why us] --- ## Goals & Success Metrics ### Primary Objective [The main goal] ### Success Metrics **Primary:** - [Metric 1]: [Target] **Secondary:** - [Metric 2]: [Target] - [Metric 3]: [Target] **Leading Indicators:** - [Early signal 1] - [Early signal 2] --- ## Target Users ### Primary Audience [Detailed description] ### Use Cases 1. **[Use Case 1]** - As a [user type] - I want to [action] - So that [benefit] 2. **[Use Case 2]** - As a [user type] - I want to [action] - So that [benefit] --- ## Solution Overview [Comprehensive description of what we're building] --- ## Functional Requirements ### Must Have (P0) #### Requirement 1: [Name] - **Description:** [What it does] - **Acceptance Criteria:** - [ ] [Criterion 1] - [ ] [Criterion 2] - [ ] [Criterion 3] - **User Story:** As a [X], I want [Y], so that [Z] #### Requirement 2: [Name] [Same structure] ### Should Have (P1) [Same structure as Must Have] ### Nice to Have (P2) [Same structure as Must Have] --- ## User Experience ### User Flows [Reference to flows from Phase 6, or create if skipped] ### Key Screens [High-level screen descriptions] ### Interaction Patterns [How users interact with the feature] --- ## Technical Requirements ### Performance - [Requirement 1] - [Requirement 2] ### Security - [Requirement 1] - [Requirement 2] ### Integration Points - [System 1]: [What needs to connect] - [System 2]: [What needs to connect] ### Data Requirements - [What data is collected] - [Where it's stored] - [How it's used] --- ## Design Requirements ### Visual Design - [Style guide compliance] - [Responsive requirements] - [Accessibility standards] ### Content Requirements - [Copy needs] - [Translation needs] - [Asset requirements] --- ## Dependencies & Constraints ### Dependencies - **Technical:** [List] - **Team:** [Who needs to be involved] - **External:** [Third parties] ### Constraints - **Timeline:** [Dates/milestones] - **Budget:** [If applicable] - **Technical:** [Platform limitations] --- ## Assumptions & Risks ### Assumptions 1. [Assumption 1] - **Validation method:** [How to test] - **Impact if wrong:** [Consequence] 2. [Assumption 2] - **Validation method:** [How to test] - **Impact if wrong:** [Consequence] ### Risks | Risk | Likelihood | Impact | Mitigation | |------|------------|--------|------------| | [Risk 1] | High/Med/Low | High/Med/Low | [Strategy] | | [Risk 2] | High/Med/Low | High/Med/Low | [Strategy] | --- ## Out of Scope Explicitly not included in this version: - [Item 1] — [Why/when it might be included] - [Item 2] — [Why/when it might be included] - [Item 3] — [Why/when it might be included] --- ## Open Questions - [ ] [Question 1] — Owner: [Name], Due: [Date] - [ ] [Question 2] — Owner: [Name], Due: [Date] - [ ] [Question 3] — Owner: [Name], Due: [Date] --- ## Timeline & Milestones | Milestone | Target Date | Status | |-----------|-------------|--------| | PRD Complete | [Date] | In Progress | | Design Complete | [Date] | Not Started | | Dev Complete | [Date] | Not Started | | QA Complete | [Date] | Not Started | | Launch | [Date] | Not Started | --- ## Stakeholders | Name | Role | Involvement | |------|------|-------------| | [Name] | [Role] | [What they do] | | [Name] | [Role] | [What they do] | --- ## Appendix ### Research [Link to user research, competitive analysis, etc.] ### Design Mockups [Links to designs when available] ### Technical Specs [Links to technical documentation] --- **Document Status:** Ready for Review **Next Actions:** - [ ] Review with stakeholders - [ ] Refine based on feedback - [ ] Get approval to proceed - [ ] Hand off to design/engineering --- *This PRD was generated using the /product-brief command. Update as needed.*
After generating the PRD:
04-Projects/[Product Name]/04-Projects/[Product Name]/PRD.mdPeople/Internal/ or People/External/markdown## ✅ PRD Created **Saved to:** `04-Projects/[Product Name]/PRD.md` **Next Steps:** 1. Review and refine the PRD 2. Share with stakeholders for feedback 3. Use `/project-health` to track progress 4. Create tasks in 03-Tasks/Tasks.md when ready to execute **Want to:** - Revise any section → Just tell me what to change - Create tasks from this PRD → Say "create tasks" - Share with stakeholders → I can draft an email
At any phase, users can:
back or previous — Return to previous phaseskip to prd — Jump directly to final PRDrevise [section] — Edit specific sectionstart over — Begin from scratchsave — Save current progressGood: > "Interesting. If this is for enterprise customers, how do we handle single sign-on? Or is that something we're punting to Phase 2?"
Bad: > "Question 7: Please describe your authentication strategy."
User: /product-brief Add notifications to our app
Dex:
markdown## Initial Idea Add notifications to our app --- Great, let's flesh this out. A few questions to start: 1. What type of notifications are we talking about — push notifications, in-app alerts, email, or all three? 2. What specific events should trigger notifications? 3. Who are these notifications for — all users, or specific roles?
User: "Push notifications for now. We want to notify sales reps when a lead takes an action in the product."
Dex:
markdownGot it — push notifications for sales reps when leads are active. That helps narrow it. A few more questions: 1. What actions count as notification-worthy? (e.g., login, feature usage, upgrade intent) 2. Should there be any filtering or preferences? Like "only notify me about my accounts"? 3. What's the business outcome we're driving here — faster response time, more engagement, closing deals faster?
Conversation continues through phases until PRD is complete]
Use /product-brief when:
Don't use it for:
The PRD isn't set in stone. After creation:
Dex will update the PRD file directly and maintain version history.
Before finalizing the PRD, verify:
If any are missing, prompt user to fill gaps before finalizing.
Update System/usage_log.md to mark product brief as used.
Analytics (Silent):
Call track_event with event_name product_brief_created.
This only fires if the user has opted into analytics. No action needed if it returns "analytics_disabled".
Other measured skills in the registry, with their headline benchmark lift.