一键导入
product-planning
Use when specs/product/ is empty or incomplete to create mission.md, roadmap.md and tech-stack.md through incremental brainstorming and validation.
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
菜单
Use when specs/product/ is empty or incomplete to create mission.md, roadmap.md and tech-stack.md through incremental brainstorming and validation.
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Use when creating or developing, before writing code or implementation plans - refines rough ideas into fully-formed designs through collaborative questioning, alternative exploration, and incremental validation. Don't use during clear 'mechanical' processes
Use when partner provides a complete implementation plan to execute in controlled batches with review checkpoints - loads plan, reviews critically, executes tasks in batches, reports for review between batches
Use when implementation is complete, all tests pass, and you need to decide how to integrate the work - guides completion of development work by presenting structured options for merge, PR, or cleanup
Automatically creates user-facing changelogs from git commits by analyzing commit history, categorizing changes, and transforming technical commits into clear, customer-friendly release notes. Turns hours of manual changelog writing into minutes of automated generation.
Use after implementation complete to verify all tasks done, update roadmap, run full test suite, and create final report - ensures implementation completeness before finishing development branch
Use during Phase 2 of spec creation to gather detailed requirements through one-question-at-a-time dialogue - analyzes product context, asks targeted questions, requests visual assets, identifies reusability opportunities, and documents all findings
| name | product-planning |
| description | Use when specs/product/ is empty or incomplete to create mission.md, roadmap.md and tech-stack.md through incremental brainstorming and validation. |
Creates product foundation through collaborative dialogue:
specs/product/ folderls -la specs/product/ 2>/dev/null
for file in mission.md roadmap.md tech-stack.md; do
[ -f "specs/product/$file" ] && echo "Found: $file"
done
If files exist:
Found: [list files]
Options:
1. Review and update
2. Start fresh (backs up existing)
Your preference?
If option 1 (review and update) selected: Use the current files as context for Step 2
If option 2 (Start fresh) selected:
# Create backup with timestamp
BACKUP_DIR="specs/product.backup.$(date +%Y%m%d-%H%M%S)"
if [ -d "specs/product" ]; then
if ! cp -r specs/product "$BACKUP_DIR"; then
echo "Warning: Could not create backup. Proceeding anyway."
else
echo "✅ Backed up existing docs to $BACKUP_DIR"
fi
fi
Use brainstorming approach - not rigid questions:
Let's explore your product vision.
Start with the big picture - what are you building?
Wait for response.
Then explore naturally:
ONE question at a time. Follow the conversation.
Present multiple choice when helpful:
For your target users, which sounds right:
1. Individual developers (personal projects)
2. Small teams 2-10 people (collaboration)
3. Enterprise teams (complex workflows)
4. Mix of these (describe)
Or open-ended for exploration:
Tell me about your users:
- Who are they?
- When do they use your product?
- What frustrates them today?
Continue until you understand:
Announce:
Based on our conversation, here's the mission document.
I'll show section by section - let me know if anything needs adjustment.
Present in chunks (150-200 words each):
Section 1: Pitch
## Pitch
[Product] is a [type] that helps [users] [solve problem]
by providing [value proposition].
[2-3 sentences expanding on this]
Does this capture your vision?
Wait. Adjust if needed.
Section 2: Users
## Users
### Primary Customers
[2-3 customer segments]
### User Personas
**[Persona]** ([context])
- Role: [description]
- Pain Points: [problems]
- Goals: [outcomes]
Accurate?
Wait. Adjust if needed.
Continue for remaining sections:
mkdir -p specs/product
cat > specs/product/mission.md <<'EOF'
# Product Mission
[Approved content from Step 3]
EOF
Propose feature ordering:
Development roadmap - features ordered by:
- Technical dependencies
- Value delivery path
- MVP to full product
1. [ ] [Feature] — [Description] `[Effort]`
Why first: [Reasoning]
2. [ ] [Feature] — [Description] `[Effort]`
Why next: [Reasoning]
[Continue for all features]
Does this ordering make sense?
Effort scale:
XS: 1 dayS: 2-3 daysM: 1 weekL: 2 weeksXL: 3+ weeksWait. Adjust if needed.
cat > specs/product/roadmap.md <<'EOF'
# Product Roadmap
[Approved roadmap from Step 5]
> Notes
> - Ordered by dependencies and value
> - Each item is complete, testable feature
> - Check off as specs are implemented
EOF
Ask about technical approach: First check if there's any existing tech stack information in CLAUDE.md or project docs that should be considered.
Tech stack - do you have preferences?
1. Use my usual stack (check global CLAUDE.md)
2. This project uses: [specify]
3. Ask about each layer
Which?
If option 3, ask naturally:
Frontend framework?
1. React + TypeScript
2. Vue + TypeScript
3. Other (specify)
Continue through layers as needed.
Present tech stack:
## Frontend
[Technologies with purpose]
## Backend
[Technologies with purpose]
## Database
[Technologies with purpose]
Complete and accurate?
cat > specs/product/tech-stack.md <<'EOF'
# Tech Stack
[Approved tech stack from Step 7]
EOF
🎉 Product documentation complete!
Created:
✅ specs/product/mission.md
✅ specs/product/roadmap.md
✅ specs/product/tech-stack.md
Ready to create first spec: [First roadmap item]
Continue?
After each section:
[Present content]
Does this look right?
✓ Yes, continue
✎ Adjust [explain what]
⟲ Rethink this section
If adjustment needed:
Never:
Always:
Called by:
sdd-orchestrator when no product docs existMay use:
Returns to:
sdd-orchestrator after docs createdCreates:
specs/product/mission.mdspecs/product/roadmap.mdspecs/product/tech-stack.md