Documentation-First PRD Creation
Create Product Requirements Documents (PRDs) guiding development through user-facing content. Includes milestone tracking, progress logs, and implementation planning.
name: prd-create description: Create documentation-first PRDs that guide development through user-facing content category: project-management
PRD Creation Slash Command
Instructions
You are helping create a Product Requirements Document (PRD) for a new feature. This process involves two main components:
- GitHub Issue: Short, immutable concept description that links to the detailed PRD
- PRD File: Project management document with milestone tracking, progress logs, and implementation plan
Process
Step 1: Understand the Feature Concept
Ask the user to describe the feature idea to understand the core concept and scope.
Step 2: Create GitHub Issue FIRST
Create the GitHub issue immediately to get the issue ID. This ID is required for proper PRD file naming.
IMPORTANT: Add the "PRD" label to the issue for discoverability.
Step 3: Create PRD File with Correct Naming
Create the PRD file using the actual GitHub issue ID: prds/[issue-id]-[feature-name].md
Step 4: Update GitHub Issue with PRD Link
Add the PRD file link to the GitHub issue description now that the filename is known.
Step 5: Create PRD as a Project Management Document
Work through the PRD template focusing on project management, milestone tracking, and implementation planning. Documentation updates should be included as part of the implementation milestones.
Key Principle: Focus on 5-10 major milestones rather than exhaustive task lists. Each milestone should represent meaningful progress that can be clearly validated.
Consider Including (when applicable to the project/feature):
- Tests - If the project has tests, include a milestone for test coverage of new functionality
- Documentation - If the feature is user-facing, include a milestone for docs following existing project patterns
Good Milestones Examples:
- [ ] Core functionality implemented and working
- [ ] Tests passing for new functionality (if project has test suite)
- [ ] Documentation complete following existing patterns (if user-facing feature)
- [ ] Integration with existing systems working
- [ ] Feature ready for user testing
Avoid Micro-Tasks:
- ❌ Update README.md file
- ❌ Write test for function X
- ❌ Fix typo in documentation
- ❌ Individual file modifications
Milestone Characteristics:
- Meaningful: Represents significant progress toward completion
- Testable: Clear success criteria that can be validated
- User-focused: Relates to user value or feature capability
- Manageable: Can be completed in reasonable timeframe
GitHub Issue Template (Keep Short & Stable)
Initial Issue Creation (without PRD link):
## PRD: [Feature Name]
**Problem**: [1-2 sentence problem description]
**Solution**: [1-2 sentence solution overview]
**Detailed PRD**: Will be added after PRD file creation
**Priority**: [High/Medium/Low]
Don't forget to add the "PRD" label to the issue after creation.
Issue Update (after PRD file created):
## PRD: [Feature Name]
**Problem**: [1-2 sentence problem description]
**Solution**: [1-2 sentence solution overview]
**Detailed PRD**: See [prds/[actual-issue-id]-[feature-name].md](https://github.com/vfarcic/dot-ai/blob/main/prds/[actual-issue-id]-[feature-name].md)
**Priority**: [High/Medium/Low]
Discussion Guidelines
PRD Planning Questions
- Problem Understanding: "What specific problem does this feature solve for users?"
- User Impact: "Walk me through the complete user journey — what will change for them?"
- Technical Scope: "What are the core technical changes required?"
- Documentation Impact: "Which existing docs need updates? What new docs are needed?"
- Integration Points: "How does this feature integrate with existing systems?"
- Success Criteria: "How will we know this feature is working well?"
- Implementation Phases: "How can we deliver value incrementally?"
- Risk Assessment: "What are the main risks and how do we mitigate them?"
- Dependencies: "What other systems or features does this depend on?"
- Validation Strategy: "How will we test and validate the implementation?"
Discussion Tips:
- Clarify ambiguity: If something isn't clear, ask follow-up questions until you understand
- Challenge assumptions: Help the user think through edge cases, alternatives, and unintended consequences
- Prioritize ruthlessly: Help distinguish between must-have and nice-to-have based on user impact
- Think about users: Always bring the conversation back to user value, experience, and outcomes
- Consider feasibility: While not diving into implementation details, ensure scope is realistic
- Focus on major milestones: Create 5-10 meaningful milestones rather than exhaustive micro-tasks
- Think cross-functionally: Consider impact on different teams, systems, and stakeholders
Note: If any gh command fails with "command not found", inform the user that GitHub CLI is required and provide the installation link: https://cli.github.com/
Workflow
- Concept Discussion: Get the basic idea and validate the need
- Create GitHub Issue FIRST: Short, stable concept description to get issue ID
- Create PRD File: Detailed document using actual issue ID:
prds/[issue-id]-[feature-name].md - Update GitHub Issue: Add link to PRD file now that filename is known
- Section-by-Section Discussion: Work through each template section systematically
- Milestone Definition: Define 5-10 major milestones that represent meaningful progress
- Review & Validation: Ensure completeness and clarity
CRITICAL: Steps 2-4 must happen in this exact order to avoid the chicken-and-egg problem of needing the issue ID for the filename.
Update ROADMAP.md (If It Exists)
After creating the PRD, check if docs/ROADMAP.md exists. If it does, add the new feature to the appropriate timeframe section based on PRD priority:
- High Priority → Short-term section
- Medium Priority → Medium-term section
- Low Priority → Long-term section
Format: - [Brief feature description] (PRD #[issue-id])
The ROADMAP.md update will be included in the commit at the end of the workflow (Option 2).
Next Steps After PRD Creation
After completing the PRD, present the user with numbered options:
✅ PRD Created Successfully!
**PRD File**: prds/[issue-id]-[feature-name].md
**GitHub Issue**: #[issue-id]
What would you like to do next?
**1. Start working on this PRD now**
Begin implementation immediately (recommended if you're ready to start)
**2. Commit and push PRD for later**
Save the PRD and work on it later (will use [skip ci] flag)
Please enter 1 or 2:
Option 1: Start Working Now
If user chooses option 1, first commit and push the PRD (same as Option 2), then instruct them:
PRD committed and pushed.
To start working on this PRD, run /prd-start [issue-id]
Option 2: Commit and Push for Later
If user chooses option 2:
# Stage the PRD file (and ROADMAP.md if it was updated)
git add prds/[issue-id]-[feature-name].md
# If docs/ROADMAP.md exists and was updated, include it:
# git add docs/ROADMAP.md
# Commit with skip CI flag to avoid unnecessary CI runs
git commit -m "docs(prd-[issue-id]): create PRD #[issue-id] - [feature-name] [skip ci]
- Created PRD for [brief feature description]
- Defined [X] major milestones
- Documented problem, solution, and success criteria
- Added to ROADMAP.md ([timeframe] section)
- Ready for implementation"
# Pull latest and push to main
git pull --rebase origin main && git push origin main
Confirmation Message:
✅ PRD committed and pushed to main
The PRD is now available in the repository. To start working on it later, execute:
prd-start [issue-id]
Important Notes
- Option 1: Best when you have time to begin implementation immediately
- Option 2: Best when creating multiple PRDs or planning future work
- Skip CI flag: Always use
[skip ci]when committing PRD-only changes - Issue reference: Include issue number in commit message for traceability
Related skills
API Documentation Generator
Automatically generates OpenAPI/Swagger API documentation.
Technical Writer
Writes clear technical documentation following top style guides.
API Reference Creator
Automates API reference documentation creation with code generation and validation following technical documentation best practices.