webdevtodayjason BMAD Method: PRD, Architecture, Epic, and Story Creation
This skill implements the BMAD (Breakthrough Method for Agile AI Driven Development) approach to creating high-quality, context-rich product requirements documents, architecture documents, epics, and user stories.
Core Principles
- Human-in-the-Loop Refinement: Work collaboratively with the user, asking clarifying questions
- Context-Rich Documentation: Provide deep context, not generic AI-generated content
- Hyper-Detailed Stories: Each story should contain everything needed for implementation
- No Generic Output: Avoid bland, average responses - dig deep and be specific
Document Hierarchy
Project Brief (optional)
↓
PRD (Product Requirements Document)
↓
Architecture Document
↓
Epics (High-level feature groups: #1.0, #2.0, etc.)
↓
User Stories (Detailed stories: 1.1, 1.2, 2.1, 2.2, etc.)
Creating a Project Brief (Optional but Recommended)
Purpose
A project brief provides strategic context before diving into detailed requirements.
Structure
# Project Brief: [Project Name]
## Executive Summary
[2-3 paragraphs: What is this? Why are we building it?]
## Market Context
- Target Audience
- Market Opportunity
- Competitive Landscape
## Business Objectives
- Primary Goals
- Success Criteria
- Key Metrics
## Constraints & Assumptions
- Budget/Timeline
- Technical Constraints
- Known Limitations
## Stakeholders
- Key Decision Makers
- Primary Users
- Technical Team
Best Practices for Project Briefs
- Keep it concise (2-5 pages max)
- Focus on WHY before WHAT
- Include competitive analysis if relevant
- Reference supporting documents (don't inline massive content)
- Update as understanding evolves
Creating a PRD (Product Requirements Document)
Purpose
The PRD is the single source of truth for what will be built. It bridges business needs and technical implementation.
PRD Structure
# Product Requirements Document: [Product Name]
## 1. Goals and Background Context
### Problem Statement
[Describe the core problem being solved]
### Vision
[High-level vision for the product]
### Success Criteria
[How will we measure success?]
### Target Users
[Who are we building this for?]
### Out of Scope
[What are we explicitly NOT building in this version?]
## 2. Functional Requirements (FRs)
### FR-1: [Requirement Name]
**Description**: [Detailed description]
**Priority**: [Must Have / Should Have / Nice to Have]
**User Story Reference**: [Links to relevant epics/stories]
[Repeat for each functional requirement]
## 3. Non-Functional Requirements (NFRs)
### Performance
- Response time targets
- Throughput requirements
- Scalability goals
### Security
- Authentication/authorization requirements
- Data protection needs
- Compliance requirements
### Reliability
- Uptime targets
- Error handling
- Backup/recovery
### Usability
- Accessibility standards
- Browser/device support
- User experience goals
### Technical Constraints
- Technology stack requirements
- Integration requirements
- Infrastructure needs
## 4. Epics and User Stories (High-Level)
### Epic #1.0: [Epic Name]
**Description**: [High-level description of this feature area]
**Business Value**: [Why is this important?]
**Stories**:
- 1.1: [Brief story description]
- 1.2: [Brief story description]
- 1.3: [Brief story description]
### Epic #2.0: [Epic Name]
[Repeat structure]
## 5. User Interface Design Goals (if applicable)
### Design Principles
[Key UI/UX principles]
### Key Flows
[Critical user journeys]
### Design References
[Mockups, wireframes, design system references]
## 6. Success Metrics and KPIs
### Primary Metrics
[How will we measure success?]
### Secondary Metrics
[Additional success indicators]
### Instrumentation Needs
[What analytics/logging do we need?]
## 7. Dependencies and Risks
### External Dependencies
[Third-party services, APIs, etc.]
### Technical Risks
[Known technical challenges]
### Mitigation Strategies
[How we'll address risks]
## 8. Release Strategy
### MVP (Minimum Viable Product)
[What's included in first release?]
### Future Phases
[What comes next?]
### Rollout Plan
[How will we deploy?]
PRD Best Practices
Start with Discovery Questions
- What problem are we solving?
- Who are the users?
- What are the business goals?
- What are the constraints?
- What does success look like?
Be Specific, Not Generic
- Avoid vague language
- Include concrete examples
- Reference specific use cases
- Provide context and rationale
Collaborate and Iterate
- Ask clarifying questions
- Challenge assumptions
- Validate understanding
- Refine based on feedback
Make It Actionable
- Clear, testable requirements
- Prioritized features
- Defined success criteria
- Traceable to business goals
Include Context for Decision-Making
- Why decisions were made
- Alternatives considered
- Tradeoffs accepted
- Assumptions documented
Creating Architecture Documents
Purpose
The Architecture Document translates the PRD into a technical blueprint. It defines HOW the system will be built, what technologies will be used, and how components will interact.
Architecture Document Structure
# Architecture Document: [Product Name]
## 1. Executive Summary
### Overview
[High-level architectural approach and key decisions]
### Architecture Principles
[Core principles guiding this architecture]
- Scalability
- Maintainability
- Security-first
- Cost-effectiveness
[etc.]
### Key Technologies
[Major technology choices and why]
## 2. System Context
### System Boundaries
[What's inside vs outside the system]
### External Dependencies
[Third-party services, APIs, external systems]
### Integration Points
[How this system connects with other systems]
### Users and Actors
[Who/what interacts with the system]
## 3. High-Level Architecture
### Architecture Diagram
[ASCII diagram or reference to diagram file]
┌─────────────┐ │ Client │ └──────┬──────┘ │ ┌──────▼──────────────────────┐ │ Load Balancer │ └──────┬──────────────────────┘ │ ┌──────▼──────────┐ ┌─────────────┐ │ App Server │──│ Cache │ └──────┬──────────┘ └─────────────┘ │ ┌──────▼──────────┐ │ Database │ └─────────────────┘
### Architecture Pattern
[MVC, Microservices, Event-Driven, Layered, etc.]
### Component Overview
[Major system components and their responsibilities]
## 4. Technology Stack
### Frontend
- **Framework**: [React, Vue, Angular, etc.]
- **State Management**: [Redux, Zustand, Context API, etc.]
- **Styling**: [Tailwind, CSS Modules, styled-components, etc.]
- **Build Tools**: [Vite, Webpack, etc.]
- **Testing**: [Jest, Vitest, Cypress, etc.]
**Rationale**: [Why these choices?]
### Backend
- **Language**: [Node.js, Python, Go, etc.]
- **Framework**: [Express, FastAPI, Django, etc.]
- **API Style**: [REST, GraphQL, gRPC, etc.]
- **Authentication**: [JWT, OAuth2, Session-based, etc.]
- **Testing**: [Jest, pytest, etc.]
**Rationale**: [Why these choices?]
### Database
- **Primary Database**: [PostgreSQL, MongoDB, MySQL, etc.]
- **Caching Layer**: [Redis, Memcached, etc.]
- **Search Engine**: [Elasticsearch, Algolia, etc.] (if applicable)
- **Message Queue**: [RabbitMQ, Kafka, SQS, etc.] (if applicable)
**Rationale**: [Why these choices?]
### Infrastructure
- **Hosting**: [AWS, GCP, Azure, Vercel, etc.]
- **Container Orchestration**: [Docker, Kubernetes, ECS, etc.]
- **CI/CD**: [GitHub Actions, GitLab CI, Jenkins, etc.]
- **Monitoring**: [DataDog, New Relic, Prometheus, etc.]
- **Logging**: [CloudWatch, ELK Stack, etc.]
**Rationale**: [Why these choices?]
### Third-Party Services
- **Payment**: [Stripe, PayPal, etc.]
- **Email**: [SendGrid, AWS SES, etc.]
- **File Storage**: [S3, Cloudinary, etc.]
- **Analytics**: [Google Analytics, Mixpanel, etc.]
[etc.]
## 5. Data Architecture
### Data Model Overview
[High-level description of key entities and relationships]
### Entity Relationship Diagram
User ──< UserProfile │ │ └──< Order ──< OrderItem >── Product │ └──< Payment
### Key Entities
#### User
```typescript
interface User {
id: string;
email: string;
passwordHash: string;
createdAt: Date;
updatedAt: Date;
role: 'admin' | 'user';
}
[Repeat for each key entity]
Data Flow
[How data moves through the system]
- User submits form
- API validates data
- Data stored in primary database
- Cache updated
- Event published to message queue
- Background job processes event
Data Storage Strategy
- Hot Data: [Redis cache, short TTL]
- Warm Data: [Primary database]
- Cold Data: [S3 archival storage]
Backup and Recovery
- Backup Frequency: [Daily automated backups]
- Retention: [30 days]
- Recovery Time Objective (RTO): [4 hours]
- Recovery Point Objective (RPO): [1 hour]
6. API Design
API Architecture
[REST, GraphQL, gRPC, etc.]
Authentication & Authorization
- Method: [JWT tokens, OAuth2, API keys]
- Token Expiry: [15 minutes access, 7 days refresh]
- Permission Model: [RBAC, ABAC, etc.]
API Endpoints
User Management
POST /api/v1/auth/register
POST /api/v1/auth/login
POST /api/v1/auth/refresh
GET /api/v1/users/:id
PUT /api/v1/users/:id
DELETE /api/v1/users/:id
[Document key endpoints with request/response examples]
Example: User Registration
POST /api/v1/auth/register
Request:
{
"email": "user@example.com",
"password": "SecurePass123!",
"name": "John Doe"
}
Response (201):
{
"id": "user_123",
"email": "user@example.com",
"name": "John Doe",
"createdAt": "2024-10-16T10:30:00Z"
}
Error Response (400):
{
"error": "INVALID_EMAIL",
"message": "Email address is invalid"
}
API Versioning Strategy
[How APIs will be versioned: URL, header, etc.]
Rate Limiting
- Anonymous: 100 requests/hour
- Authenticated: 1000 requests/hour
- Premium: 10000 requests/hour
7. Security Architecture
Security Principles
[Security-first mindset, defense in depth, etc.]
Authentication
[How users authenticate]
Authorization
[How permissions are enforced]
Data Encryption
- In Transit: TLS 1.3
- At Rest: AES-256 encryption
- Sensitive Data: Additional field-level encryption
Security Measures
- SQL Injection: Parameterized queries, ORM
- XSS: Content Security Policy, input sanitization
- CSRF: CSRF tokens, SameSite cookies
- Secrets Management: AWS Secrets Manager / Vault
- DDoS Protection: CloudFlare, rate limiting
Compliance
[GDPR, HIPAA, SOC2, etc. requirements]
8. Performance & Scalability
Performance Requirements
- API Response Time: < 200ms (p95)
- Page Load Time: < 2s (p95)
- Database Query Time: < 50ms (p95)
- Time to First Byte: < 100ms
Scaling Strategy
Horizontal Scaling
[How system scales out]
- Load balancer distributes traffic
- Stateless application servers
- Database read replicas
Vertical Scaling
[When/how to scale up]
Auto-scaling Rules
- Scale Out: CPU > 70% for 5 minutes
- Scale In: CPU < 30% for 10 minutes
- Min Instances: 2
- Max Instances: 10
Caching Strategy
- Browser Cache: Static assets (1 year)
- CDN Cache: Images, CSS, JS (1 week)
- API Cache: Redis (5 minutes)
- Database Cache: Query results (varies)
Performance Optimization
- Database: Indexing strategy, query optimization
- Frontend: Code splitting, lazy loading, image optimization
- Backend: Connection pooling, async processing
- Network: CDN, compression, HTTP/2
9. Reliability & Monitoring
Availability Target
- SLA: 99.9% uptime (8.7 hours downtime/year)
- Monitoring: 24/7 automated monitoring
- Alerting: PagerDuty for critical issues
Error Handling
- User-Facing Errors: Friendly messages, no stack traces
- API Errors: Consistent error format
- Logging: Structured logs to centralized system
- Error Tracking: Sentry for exception tracking
Health Checks
GET /health
Response: { "status": "healthy", "version": "1.2.3" }
GET /health/ready
Response: { "database": "ok", "cache": "ok", "queue": "ok" }
Monitoring Metrics
- Application: Error rate, response time, throughput
- Infrastructure: CPU, memory, disk, network
- Business: User signups, conversion rate, revenue
- Custom: Feature usage, queue depth, etc.
Alerting Thresholds
- Critical: Error rate > 1%, response time > 2s
- Warning: Error rate > 0.1%, response time > 1s
- Info: Deployments, configuration changes
10. Deployment Architecture
Environments
- Development: Local developer machines
- Staging: Mirrors production, for testing
- Production: Live environment
CI/CD Pipeline
Code Push → Tests → Build → Deploy to Staging → Manual Approval → Deploy to Production
Deployment Strategy
- Method: Blue-green deployment / Rolling deployment
- Rollback Plan: Automated rollback on health check failure
- Database Migrations: Run before deployment, backwards compatible
Infrastructure as Code
- Tool: Terraform / CloudFormation
- Version Control: All infrastructure in Git
- Environment Parity: Staging mirrors production
11. Technical Constraints & Decisions
Technology Constraints
[Existing systems, team expertise, licensing, etc.]
Key Technical Decisions
Decision: Use PostgreSQL over MongoDB
Context: Need for complex queries and data relationships Options Considered: PostgreSQL, MongoDB, MySQL Decision: PostgreSQL Rationale: ACID compliance, robust querying, team expertise Tradeoffs: Slightly more complex schema changes
[Repeat for each major decision]
Assumptions
[Technical assumptions being made]
Risks & Mitigation
[Technical risks and how to address them]
12. Development Guidelines
Code Organization
[Folder structure, naming conventions]
Coding Standards
- Style Guide: [ESLint config, Prettier, etc.]
- Testing Requirements: [80% coverage minimum]
- Code Review: [Required before merge]
- Documentation: [JSDoc for public APIs]
Git Workflow
- Branching: Git Flow / Trunk-based
- Commit Messages: Conventional Commits
- PR Requirements: Tests passing, reviewed, no conflicts
Development Environment Setup
[How developers get started]
13. Testing Strategy
Testing Pyramid
- Unit Tests: 70% coverage
- Integration Tests: 20% coverage
- E2E Tests: 10% coverage
Test Types
- Unit: Individual functions/components
- Integration: API endpoints, database interactions
- E2E: Critical user journeys
- Performance: Load testing with k6/JMeter
- Security: OWASP Top 10, penetration testing
Test Environments
- Local: Developer machines
- CI: Automated on every commit
- Staging: Full test suite before production
14. Future Considerations
Technical Debt
[Known technical debt and plans to address]
Scalability Roadmap
[How architecture will evolve as system grows]
Feature Roadmap Impact
[How planned features will affect architecture]
Technology Evolution
[Planned technology updates/migrations]
15. Appendices
Glossary
[Technical terms and definitions]
References
- [Link to PRD]
- [Link to API documentation]
- [Link to design system]
- [External documentation]
Decision Log
[Record of all significant architectural decisions]
Open Questions
[Architectural questions that need resolution]
### Architecture Document Best Practices
1. **Keep It Updated**
- Architecture evolves with the system
- Update as decisions are made
- Version control all changes
2. **Be Pragmatic**
- Choose "boring" technology when possible
- Over-engineering is a risk
- Start simple, add complexity as needed
3. **Document Decisions**
- Record why decisions were made
- Document alternatives considered
- Note tradeoffs accepted
4. **Think About Operations**
- How will it be deployed?
- How will it be monitored?
- How will it be debugged?
5. **Consider the Team**
- Use technologies team knows
- Document unfamiliar patterns
- Plan for knowledge transfer
6. **Security First**
- Security is not an afterthought
- Design for security from day one
- Document security measures
7. **Performance Matters**
- Define performance requirements
- Plan for scale from the start
- Monitor and optimize continuously
### Common Architecture Pitfalls to Avoid
1. **Over-Engineering**: Building for problems you don't have yet
2. **Under-Engineering**: Ignoring known scale/performance requirements
3. **Technology Resume Building**: Choosing tech for learning, not fit
4. **Ignoring Operations**: Not considering deployment, monitoring, debugging
5. **No Clear Ownership**: Unclear who owns what component
6. **Tight Coupling**: Components too dependent on each other
7. **No Testing Strategy**: Testing as an afterthought
## Creating Epics
### Purpose
Epics group related user stories into logical feature areas. They represent high-level capabilities.
### Epic Structure
```markdown
# Epic #[X.0]: [Epic Name]
## Overview
[High-level description of this epic]
## Business Value
[Why is this epic important? What business goal does it support?]
## User Benefit
[How does this benefit end users?]
## Success Criteria
[How will we know this epic is complete and successful?]
## User Stories
- [X.1]: [Story title]
- [X.2]: [Story title]
- [X.3]: [Story title]
## Dependencies
- [Other epics or external dependencies]
## Estimated Effort
[T-shirt sizing: S/M/L/XL or story points]
## Priority
[Must Have / Should Have / Nice to Have]
## Target Release
[Which release/sprint?]
Epic Numbering Convention
- #1.0: First major epic
- #2.0: Second major epic
- Stories within Epic #1.0: 1.1, 1.2, 1.3, etc.
- Stories within Epic #2.0: 2.1, 2.2, 2.3, etc.
Epic Best Practices
- Keep Epics Cohesive: Stories within an epic should be related
- Define Clear Boundaries: Epic should represent a complete feature area
- Include Business Context: Always explain the "why"
- Size Appropriately: An epic should be deliverable in 1-3 sprints
- Make Them Testable: Define clear success criteria
Creating User Stories
Purpose
User stories are detailed, implementable units of work. They should contain EVERYTHING a developer needs to build the feature.
User Story Structure
# Story [X.Y]: [Story Title]
## Story Metadata
- **Epic**: #[X.0] [Epic Name]
- **Priority**: [Must Have / Should Have / Nice to Have]
- **Estimated Effort**: [Story points or hours]
- **Status**: [Draft / Approved / In Progress / Done]
- **Assigned To**: [Developer name or TBD]
## User Story Statement
As a [type of user],
I want to [action/goal],
So that [benefit/value].
## Context and Background
[Detailed background information. Why are we building this? What problem does it solve? Include relevant context from the PRD and architecture.]
### Related Requirements
- **FR-[X]**: [Functional requirement this story addresses]
- **NFR-[X]**: [Non-functional requirements this story must satisfy]
### User Journey Context
[How does this story fit into the broader user experience?]
## Detailed Description
[Comprehensive description of what needs to be built. Be specific about:
- What UI elements are needed
- What data is processed
- What business logic is required
- How it integrates with other components
- What APIs or services are called]
## Acceptance Criteria
### Functional Criteria
1. **Given** [precondition]
**When** [action]
**Then** [expected result]
2. **Given** [precondition]
**When** [action]
**Then** [expected result]
[Continue for all scenarios]
### Non-Functional Criteria
- **Performance**: [Response time, load capacity]
- **Security**: [Authentication, authorization, data protection]
- **Accessibility**: [WCAG compliance, keyboard navigation]
- **Browser Support**: [Which browsers/versions]
- **Error Handling**: [Expected error scenarios and handling]
## Technical Implementation Guidance
### Architecture Context
[Relevant excerpts from architecture document: where this fits in the system, what patterns to use, what services to call]
### Data Model
[What data structures are involved? Database schema changes?]
### API Endpoints (if applicable)
```http
GET /api/[endpoint]
POST /api/[endpoint]
[Expected request/response formats]
Key Technical Considerations
- [Integration points]
- [External dependencies]
- [Performance considerations]
- [Security requirements]
- [Error scenarios to handle]
UI/UX Specifications (if applicable)
Visual Design
[Mockups, wireframes, or detailed descriptions]
Interaction Design
[User flows, state transitions, animations]
Responsive Behavior
[How it adapts to different screen sizes]
Accessibility Requirements
[ARIA labels, keyboard navigation, screen reader support]
Testing Requirements
Unit Tests
[What unit tests are needed?]
Integration Tests
[What integration scenarios to test?]
End-to-End Tests
[What user flows to test end-to-end?]
Edge Cases
[Unusual scenarios to test]
Dependencies
Blocked By
[What must be completed before this story can start?]
Blocks
[What other stories depend on this?]
External Dependencies
[Third-party services, APIs, etc.]
Definition of Done
- Code written and meets acceptance criteria
- Unit tests written and passing
- Integration tests written and passing
- Code reviewed and approved
- Documentation updated
- Deployed to staging environment
- QA tested and approved
- Deployed to production
- Monitored for 24 hours with no issues
Questions and Clarifications
Open Questions
[Questions that need to be answered before implementation]
Assumptions
[Assumptions being made]
Risks
[Known risks or concerns]
Notes
Implementation Notes
[Additional notes for developers]
Design Decisions
[Key decisions made and why]
Future Enhancements
[Things to consider for future iterations]
### User Story Best Practices
1. **Include Full Context**: Developer should understand WHY and HOW, not just WHAT
2. **Be Hyper-Detailed**: More detail is better than less
3. **Make It Self-Contained**: Story should have everything needed to implement
4. **Use Clear Acceptance Criteria**: Given/When/Then format
5. **Include Technical Guidance**: Reference architecture, patterns, conventions
6. **Define Done Clearly**: Checklist of what "done" means
7. **Size Appropriately**: One story = one developer = 1-5 days of work
8. **Make It Testable**: Clear, verifiable acceptance criteria
## BMAD Workflow Guidelines
### When Creating Documentation
1. **Ask Probing Questions**
- Don't assume - validate understanding
- Challenge vague requirements
- Dig deeper into motivations
- Understand constraints
2. **Iterate and Refine**
- Present draft for feedback
- Incorporate changes
- Validate alignment
- Confirm understanding
3. **Provide Options**
- Present alternatives when appropriate
- Explain tradeoffs
- Help user make informed decisions
- Document decisions made
4. **Maintain Context**
- Connect stories to epics
- Link requirements to business goals
- Show relationships between components
- Reference relevant architecture
### Quality Standards
1. **Specificity Over Generality**
- Concrete examples, not abstract concepts
- Specific numbers, not ranges
- Named entities, not "the system"
2. **Completeness**
- All edge cases considered
- All integration points identified
- All NFRs addressed
- All dependencies documented
3. **Clarity**
- No ambiguous language
- No jargon without explanation
- Clear, scannable structure
- Consistent terminology
4. **Actionability**
- Testable acceptance criteria
- Clear definition of done
- Prioritized features
- Assigned ownership
## Document Naming Conventions
### Files
- Project Brief: `docs/brief.md` or `docs/briefs/[feature-name].md`
- PRD: `docs/prd.md` or `docs/prd/[feature-name].md`
- Architecture: `docs/architecture.md`
- Epics: `docs/epics/[epic-number]-[epic-name].md`
- Stories: `docs/stories/[epic].[story]-[story-name].md`
### Examples
- `docs/brief.md`
- `docs/prd.md`
- `docs/epics/1.0-user-authentication.md`
- `docs/stories/1.1-login-form.md`
- `docs/stories/1.2-password-reset.md`
## Common Pitfalls to Avoid
1. **Being Too Generic**: Avoid bland, cookie-cutter language
2. **Insufficient Detail**: Stories should be comprehensive
3. **Missing Context**: Always explain the "why"
4. **Vague Acceptance Criteria**: Be specific and testable
5. **Ignoring NFRs**: Performance, security, etc. matter
6. **No Prioritization**: Everything can't be P0
7. **Missing Dependencies**: Identify what blocks what
8. **Unclear Definition of Done**: Be explicit
## Example Workflow
### User Request: "I need a PRD for a task management app"
**Claude's Approach:**
1. **Discovery Phase**
Before I create the PRD, let me ask some key questions:
- Who are the primary users? (individuals, teams, enterprises?)
- What's the core problem you're solving? (too many tools, complexity, etc?)
- What are the must-have features for MVP?
- What are your key success metrics?
- Any technical constraints? (platform, integrations, etc)
- What's your target timeline?
2. **Draft PRD Creation**
- Create comprehensive PRD following structure above
- Include specific details based on answers
- Flag areas needing more input
3. **Refinement**
- Present draft for feedback
- Ask follow-up questions on unclear areas
- Iterate based on feedback
4. **Epic and Story Creation**
- Break PRD into logical epics
- Create detailed user stories
- Ensure complete context in each story
## Integration with Development
### Handoff to Architecture
Once PRD is complete, architect should:
- Design system architecture
- Define technology stack
- Plan data models
- Identify integration points
### Handoff to Development
Stories should contain:
- Full PRD context relevant to the story
- Architecture excerpts relevant to implementation
- Clear technical guidance
- Complete acceptance criteria
### Quality Assurance
QA should use stories to:
- Write test cases from acceptance criteria
- Validate against NFRs
- Verify edge cases
- Check definition of done
## Tips for Success
1. **Start Simple, Add Depth**: Begin with structure, then add detail
2. **Use Templates Consistently**: Maintain structure across documents
3. **Link Everything**: Create traceability from brief → PRD → epic → story
4. **Version Control**: Track changes and decisions
5. **Review Regularly**: PRDs and stories should evolve
6. **Validate Often**: Check understanding with stakeholders
7. **Be Pragmatic**: Perfect is the enemy of good enough
## When to Use This Skill
Use this skill when:
- User requests a PRD, architecture document, epic, or user story
- User asks for product planning or technical architecture documentation
- User mentions "BMAD" or "agile planning"
- User needs help structuring requirements or technical design
- User wants detailed, context-rich documentation
- User is planning a software project or feature
- User needs system architecture, API design, or technology stack documentation
## When NOT to Use This Skill
Don't use for:
- Quick bug fixes (use simpler formats)
- Documentation that's not product/planning related
- When user explicitly asks for different format
- Non-software projects (unless requested)
---
**Remember**: The BMAD method is about creating high-quality, context-rich documentation through human-AI collaboration. Always ask questions, iterate, and ensure deep understanding before finalizing any document.