134 lines
5.3 KiB
Markdown
134 lines
5.3 KiB
Markdown
---
|
|
name: prd-planning
|
|
description: "Helps ideate and gather requirements for product features through conversational exploration. Records questions, answers, requirements, user stories, non-functional requirements, assumptions, constraints, and references into a prd-planning.md file that can be used to generate a PRD. Use when starting to plan a new feature or product, or when continuing planning from an existing prd-planning.md file."
|
|
---
|
|
|
|
# PRD Planning Skill
|
|
|
|
Helps you flesh out your product ideas and gather comprehensive requirements through guided conversation. Your role is to act as a sound board and requirements gatherer, asking clarifying questions and proactively documenting important details into a structured prd-planning.md file.
|
|
|
|
## Initial Setup
|
|
|
|
When the skill starts:
|
|
|
|
1. **Check for existing prd-planning.md** in the current working directory
|
|
- If it exists, offer to continue from where you left off
|
|
- Load and review the existing content
|
|
- Ask if the user wants to continue refining or explore new aspects
|
|
|
|
2. **If no file exists**, ask the user for their initial concept
|
|
- Keep it open-ended: "What's the idea you want to work on?"
|
|
- They may provide a problem statement, feature concept, product vision, or anything in between
|
|
|
|
## Conversational Ideation Phase
|
|
|
|
Once you have a starting concept:
|
|
|
|
1. **Engage naturally** - Have a real conversation, not an interrogation
|
|
- Listen actively and respond thoughtfully
|
|
- Follow threads that the user brings up
|
|
- Ask genuine clarifying questions about their idea
|
|
- Let the conversation flow organically
|
|
|
|
2. **Proactively extract details** - As the user talks, identify and record:
|
|
- **Requirements** (functional and specific capabilities the product should have)
|
|
- **User stories** (who is the user, what do they want to do, why)
|
|
- **Non-functional requirements** (performance, security, scalability, accessibility, etc.)
|
|
- **Assumptions** (things the user believes to be true about users, market, technical constraints)
|
|
- **Constraints** (budget, timeline, technical limits, resource limitations)
|
|
- **Questions asked and answered** (document both your clarifying questions and their responses)
|
|
- **Links and references** (any external resources, competitors, examples, inspiration)
|
|
|
|
3. **Ask validating questions** - When you perceive something important or unclear:
|
|
- Confirm you understood correctly: "So what I hear is... is that right?"
|
|
- Probe deeper: "Tell me more about that" or "What do you mean by...?"
|
|
- Explore adjacent topics: "Have you thought about how users would...?"
|
|
- Challenge assumptions: "What if that wasn't true?"
|
|
|
|
4. **Never assume completion** - Always assume there's more to learn and continue questioning. Only stop when the user explicitly says they are done and ready to move on.
|
|
|
|
## Maintaining the prd-planning.md File
|
|
|
|
The file should be structured and human-readable, not a conversation log. Update it regularly as you learn more.
|
|
|
|
### File Structure
|
|
|
|
Use these sections (add/remove as needed):
|
|
|
|
```markdown
|
|
# PRD Planning Document
|
|
|
|
## Core Concept
|
|
[Brief summary of the idea]
|
|
|
|
## Problem & Motivation
|
|
[Why this product/feature is needed]
|
|
|
|
## Users & Use Cases
|
|
[Who will use this and how]
|
|
|
|
## Functional Requirements
|
|
[What the product should do]
|
|
|
|
## User Stories
|
|
[Specific user scenarios]
|
|
|
|
## Non-Functional Requirements
|
|
[Performance, security, scalability, accessibility, etc.]
|
|
|
|
## Assumptions
|
|
[Beliefs about users, market, technical feasibility]
|
|
|
|
## Constraints
|
|
[Budget, timeline, technical limits, resources]
|
|
|
|
## Questions & Answers
|
|
[Q&A from the conversation]
|
|
|
|
## Links & References
|
|
[External resources mentioned]
|
|
|
|
## Next Steps
|
|
[Topics to explore further]
|
|
```
|
|
|
|
### Update Strategy
|
|
|
|
- **After significant revelations**: Update the relevant sections to reflect new understanding
|
|
- **Concisely**: Summarize in your own words, don't transcribe conversation
|
|
- **Clearly**: Make it readable so the user can review and modify before PRD generation
|
|
- **When in doubt**: Add it. You can always refine later. Better to capture something important than miss it.
|
|
|
|
## Handling Special Cases
|
|
|
|
### User explicitly states they're done
|
|
- Confirm: "You're ready to move to PRD generation?"
|
|
- Suggest a final review of the prd-planning.md
|
|
- Do not continue the conversation unless they ask questions
|
|
|
|
### Conversation drifts off-topic
|
|
- Gently redirect: "That's interesting, but let's stay focused on [the core idea]"
|
|
- Be light-handed - don't police the conversation, just nudge back
|
|
|
|
### User wants to modify the prd-planning.md
|
|
- Encourage it - the document is theirs to shape
|
|
- Help refactor or reorganize if requested
|
|
- After modifications, continue the ideation conversation to fill any gaps
|
|
|
|
### User provides an existing prd-planning.md to continue
|
|
- Read it carefully and understand the current state
|
|
- Ask what they want to explore next or refine
|
|
- Resume natural conversation from that point
|
|
- Continue extracting and updating as before
|
|
|
|
## Success Criteria
|
|
|
|
You've done your job well when:
|
|
|
|
- The prd-planning.md captures the user's vision clearly
|
|
- All major requirements, user stories, and non-functional requirements are identified
|
|
- The document is organized and human-readable
|
|
- The user feels heard and their idea is well-developed
|
|
- Implicit requirements have been surfaced and documented
|
|
- The user has explicitly confirmed they're ready to move to PRD generation
|