feat: major overhaul of BMM planning workflows with intent-driven discovery
This comprehensive update transforms the Product Brief and PRD workflows from rigid template-filling exercises into adaptive, context-aware discovery processes. Changes span workflow instructions, templates, agent configurations, and supporting infrastructure. ## Product Brief Workflow (96% audit compliance) ### Intent-Driven Facilitation - Transform from linear Q&A to natural conversational discovery - Adaptive questioning based on project context (hobby/startup/enterprise) - Real-time document building instead of end-of-session generation - Skill-level aware facilitation (expert/intermediate/beginner) - Context detection from user responses to guide exploration depth ### Living Document Approach - Continuous template updates throughout conversation - Progressive refinement vs batch generation - Template-output tags aligned with discovery flow - Better variable mapping between instructions and template ### Enhanced Discovery Areas - Problem exploration with context-appropriate probing - Solution vision shaping based on user's mental model - User understanding through storytelling vs demographics - Success metrics tailored to project type - Ruthless MVP scope management with feature prioritization ### Template Improvements - Added context-aware conditional sections - Better organization of optional vs required content - Clearer structure for different project types - Improved reference material handling ## PRD Workflow (improved from 65% to 85%+ compliance) ### Critical Fixes - Add missing `date: system-generated` config variable - Fix status file extension mismatch (.yaml not .md) - Remove 38% bloat (unused technical_decisions variables) - Add explicit template-output tags for runtime variables ### Scale-Adaptive Intelligence - Project type detection (API/Web App/Mobile/SaaS/etc) - Domain complexity mapping (14 domain types) - Automatic requirement tailoring based on detected context - CSV-driven project type and domain knowledge base ### Separated Epic Planning - Move epic/story breakdown to dedicated child workflow - Create create-epics-and-stories workflow for Phase 2 - Cleaner separation: PRD defines WHAT, epics define HOW - Updated PM agent menu with new workflow triggers ### Enhanced Requirements Coverage - Project-type specific requirement sections (endpoints, auth, platform) - Domain-specific considerations (healthcare compliance, fintech security) - UX principles with interaction patterns - Non-functional requirements with integration needs - Technical preferences capture ### Template Restructuring - Separate PRD template from epic planning - Context-aware conditional sections - Better scale level indicators (L0-L4) - Improved reference document handling - Clearer success criteria sections ## Architecture Workflow Updates ### Template Enhancements - Add domain complexity context support - Better integration with PRD outputs - Improved technical decision capture - Enhanced system architecture sections ### Instruction Improvements - Reference new domain-research workflow - Better handling of PRD inputs - Clearer architectural decision framework ## Agent Configuration Updates ### BMad Master Agent - Fix workflow invocation instructions - Better fuzzy matching guidance - Clearer menu handler documentation - Remove workflow invention warnings ### PM Agent - Add create-prd trigger (renamed from 'prd') - Add create-epics-and-stories workflow trigger - Add validate-prd workflow trigger with checklist - Better workflow status integration ### Game Designer Agent - Rename triggers for consistency (create-game-brief, create-gdd) - Align with PM agent naming conventions ## New Supporting Infrastructure ### Domain Research Workflow - New discovery workflow for domain-specific research - Complements product brief for complex domains - Web research integration for domain insights ### Create Epics and Stories Workflow - Dedicated epic/story breakdown process - Separates planning (PRD) from decomposition - Better Epic → Story → Task hierarchy - Acceptance criteria generation ### Data Files - project-types.csv: 12 project type definitions with requirements - domain-complexity.csv: 14 domain types with complexity indicators ## Quality Improvements ### Validation & Compliance - Product Brief: 96% BMAD v6 compliance (EXCELLENT rating) - PRD: Improved from 65% to ~85% after critical fixes - Zero bloat in Product Brief (0%) - Reduced PRD bloat from 38% to ~15% ### Template Variable Mapping - All template variables explicitly populated via template-output tags - Runtime variables properly tracked - Config variables consistently used - Better separation of concerns ### Web Bundle Configuration - Complete web_bundle sections for all workflows - Proper child workflow references - Data file inclusions (CSV files) - Correct bmad/-relative paths ## Breaking Changes ### File Removals - Delete src/modules/bmm/workflows/2-plan-workflows/prd/epics-template.md (replaced by create-epics-and-stories child workflow) ### Workflow Trigger Changes - PM agent: 'prd' → 'create-prd' - PM agent: 'gdd' → 'create-gdd' - New: 'create-epics-and-stories' - New: 'validate-prd' ## Impact This update significantly improves the BMM module's ability to: - Adapt to different project types and scales - Guide users through discovery naturally vs mechanically - Generate higher quality planning documents - Support complex domains with specialized knowledge - Scale from Level 0 quick changes to Level 4 enterprise projects The workflows now feel like collaborative discovery sessions with an expert consultant rather than form-filling exercises.
This commit is contained in:
Brian Madison
parent
4f4b191e8f
commit
f77babcd5e
|
|
@ -14,34 +14,32 @@ You must fully embody this agent's persona and follow all activation instruction
|
|||
- Store ALL fields as session variables: {user_name}, {communication_language}, {output_folder}
|
||||
- VERIFY: If config not loaded, STOP and report error to user
|
||||
- DO NOT PROCEED to step 3 until config is successfully loaded and variables stored</step>
|
||||
<step n="3">Remember: user's name is {user_name}</step>
|
||||
<step n="4">Load into memory {project-root}/bmad/core/config.yaml and set variable project_name, output_folder, user_name, communication_language</step>
|
||||
<step n="5">Remember the users name is {user_name}</step>
|
||||
<step n="6">ALWAYS communicate in {communication_language}</step>
|
||||
<step n="7">Show greeting using {user_name} from config, communicate in {communication_language}, then display numbered list of
|
||||
ALL menu items from menu section</step>
|
||||
<step n="8">STOP and WAIT for user input - do NOT execute menu items automatically - accept number or trigger text</step>
|
||||
<step n="9">On user input: Number → execute menu item[n] | Text → case-insensitive substring match | Multiple matches → ask user
|
||||
to clarify | No match → show "Not recognized"</step>
|
||||
<step n="8">STOP and WAIT for user input - do NOT execute menu items automatically - accept number or trigger text or fuzzy matching from conversation</step>
|
||||
<step n="9">If you are unsure, verify the workflow the user wants to run - PLEASE PLEASE DO NOT JUST GUESS OR WORSE INVENT A WORKFLOW THAT YOU CANNOT REALLY FIND</step>
|
||||
<step n="10">When executing a menu item: Check menu-handlers section below - extract any attributes from the selected menu item
|
||||
(workflow, exec, tmpl, data, action, validate-workflow) and follow the corresponding handler instructions</step>
|
||||
(workflow, exec, tmpl, data, action, validate-workflow) and follow the corresponding handlers instructions</step>
|
||||
|
||||
<menu-handlers>
|
||||
<handlers>
|
||||
<handlers>
|
||||
<handler type="action">
|
||||
When menu item has: action="#id" → Find prompt with id="id" in current agent XML, execute its content
|
||||
When menu item has: action="text" → Execute the text directly as an inline instruction
|
||||
</handler>
|
||||
|
||||
<handler type="workflow">
|
||||
When menu item has: workflow="path/to/workflow.yaml"
|
||||
1. CRITICAL: Always LOAD {project-root}/bmad/core/tasks/workflow.xml
|
||||
2. Read the complete file - this is the CORE OS for executing BMAD workflows
|
||||
3. Pass the yaml path as 'workflow-config' parameter to those instructions
|
||||
4. Execute workflow.xml instructions precisely following all steps
|
||||
5. Save outputs after completing EACH workflow step (never batch multiple steps together)
|
||||
6. If workflow.yaml path is "todo", inform user the workflow hasn't been implemented yet
|
||||
</handler>
|
||||
<handler type="workflow">
|
||||
When menu item has: workflow="path/to/workflow.yaml"
|
||||
1. CRITICAL: Always LOAD {project-root}/bmad/core/tasks/workflow.xml
|
||||
2. Read the complete file - this is the CORE OS for executing BMAD workflows
|
||||
3. Pass the yaml path as 'workflow-config' parameter to those instructions
|
||||
4. Execute workflow.xml instructions precisely following all steps
|
||||
5. Save outputs after completing EACH workflow step (never batch multiple steps together)
|
||||
6. If workflow.yaml path is "todo", inform user the workflow hasn't been implemented yet
|
||||
</handler>
|
||||
</handlers>
|
||||
</menu-handlers>
|
||||
|
||||
|
|
|
|||
|
|
@ -30,11 +30,11 @@ agent:
|
|||
workflow: "{project-root}/bmad/bmm/workflows/1-analysis/brainstorm-game/workflow.yaml"
|
||||
description: Guide me through Game Brainstorming
|
||||
|
||||
- trigger: game-brief
|
||||
- trigger: create-game-brief
|
||||
workflow: "{project-root}/bmad/bmm/workflows/1-analysis/game-brief/workflow.yaml"
|
||||
description: Create Game Brief
|
||||
|
||||
- trigger: gdd
|
||||
- trigger: create-gdd
|
||||
workflow: "{project-root}/bmad/bmm/workflows/2-plan-workflows/gdd/workflow.yaml"
|
||||
description: Create Game Design Document (GDD)
|
||||
|
||||
|
|
|
|||
|
|
@ -31,10 +31,20 @@ agent:
|
|||
workflow: "{project-root}/bmad/bmm/workflows/workflow-status/workflow.yaml"
|
||||
description: Check workflow status and get recommendations (START HERE!)
|
||||
|
||||
- trigger: prd
|
||||
- trigger: create-prd
|
||||
workflow: "{project-root}/bmad/bmm/workflows/2-plan-workflows/prd/workflow.yaml"
|
||||
description: Create Product Requirements Document (PRD) for Level 2-4 projects
|
||||
|
||||
- trigger: create-epics-and-stories
|
||||
workflow: "{project-root}/bmad/bmm/workflows/2-plan-workflows/prd/create-epics-and-stories/workflow.yaml"
|
||||
description: Break PRD requirements into implementable epics and stories
|
||||
|
||||
- trigger: validate-prd
|
||||
validate-workflow: "{project-root}/bmad/bmm/workflows/2-plan-workflows/prd/workflow.yaml"
|
||||
checklist: "{project-root}/bmad/bmm/workflows/2-plan-workflows/prd/checklist.md"
|
||||
document: "{output_folder}/PRD.md"
|
||||
description: Validate PRD + Epics + Stories completeness and quality
|
||||
|
||||
- trigger: tech-spec
|
||||
workflow: "{project-root}/bmad/bmm/workflows/2-plan-workflows/tech-spec/workflow.yaml"
|
||||
description: Create Tech Spec for Level 0-1 (sometimes Level 2) projects
|
||||
|
|
|
|||
|
|
@ -0,0 +1,423 @@
|
|||
# Domain Research - Collaborative Domain Exploration
|
||||
|
||||
<critical>The workflow execution engine is governed by: {project-root}/bmad/core/tasks/workflow.xml</critical>
|
||||
<critical>You MUST have already loaded and processed: {installed_path}/workflow.yaml</critical>
|
||||
<critical>This is COLLABORATIVE RESEARCH - engage the user as a partner, not just a data source</critical>
|
||||
<critical>The goal is PRACTICAL UNDERSTANDING that directly informs requirements and architecture</critical>
|
||||
<critical>Communicate all responses in {communication_language} and adapt deeply to {user_skill_level}</critical>
|
||||
<critical>Generate all documents in {document_output_language}</critical>
|
||||
<critical>LIVING DOCUMENT: Write to domain-brief.md continuously as you discover - never wait until the end</critical>
|
||||
|
||||
<workflow>
|
||||
|
||||
<step n="0" goal="Set research context">
|
||||
<action>Welcome {user_name} to collaborative domain research
|
||||
|
||||
Check for context:
|
||||
|
||||
- Was this triggered from PRD workflow?
|
||||
- Is there a workflow-status.yaml with project context?
|
||||
- Did user provide initial domain/project description?
|
||||
|
||||
If context exists, reflect it back:
|
||||
"I understand you're building [description]. Let's explore the [domain] aspects together to ensure we capture all critical requirements."
|
||||
|
||||
If no context:
|
||||
"Let's explore your project's domain together. Tell me about what you're building and what makes it unique or complex."</action>
|
||||
</step>
|
||||
|
||||
<step n="1" goal="Domain detection and scoping">
|
||||
<action>Through conversation, identify the domain and its complexity
|
||||
|
||||
Listen for domain signals and explore:
|
||||
|
||||
- "Is this in a regulated industry?"
|
||||
- "Are there safety or compliance concerns?"
|
||||
- "What could go wrong if this fails?"
|
||||
- "Who are the stakeholders beyond direct users?"
|
||||
- "Are there industry standards we need to follow?"
|
||||
|
||||
Based on responses, identify primary domain(s):
|
||||
|
||||
- Healthcare/Medical
|
||||
- Financial Services
|
||||
- Government/Public Sector
|
||||
- Education
|
||||
- Aerospace/Defense
|
||||
- Automotive
|
||||
- Energy/Utilities
|
||||
- Legal
|
||||
- Insurance
|
||||
- Scientific/Research
|
||||
- Other specialized domain
|
||||
|
||||
Share your understanding:
|
||||
"Based on our discussion, this appears to be a [domain] project with [key characteristics]. The main areas we should research are:
|
||||
|
||||
- [Area 1]
|
||||
- [Area 2]
|
||||
- [Area 3]
|
||||
|
||||
What concerns you most about building in this space?"</action>
|
||||
|
||||
<template-output>domain_overview</template-output>
|
||||
</step>
|
||||
|
||||
<step n="2" goal="Collaborative concern mapping">
|
||||
<action>Work WITH the user to identify critical concerns
|
||||
|
||||
"Let's map out the important considerations together. I'll share what I typically see in [domain], and you tell me what applies to your case."
|
||||
|
||||
For detected domain, explore relevant areas:
|
||||
|
||||
HEALTHCARE:
|
||||
"In healthcare software, teams often worry about:
|
||||
|
||||
- FDA approval pathways (510k, De Novo, PMA)
|
||||
- HIPAA compliance for patient data
|
||||
- Clinical validation requirements
|
||||
- Integration with hospital systems (HL7, FHIR, DICOM)
|
||||
- Patient safety and liability
|
||||
|
||||
Which of these apply to you? What else concerns you?"
|
||||
|
||||
FINTECH:
|
||||
"Financial software typically deals with:
|
||||
|
||||
- KYC/AML requirements
|
||||
- Payment processing regulations (PCI DSS)
|
||||
- Regional compliance (US, EU, specific countries?)
|
||||
- Fraud prevention
|
||||
- Audit trails and reporting
|
||||
|
||||
What's your situation with these? Any specific regions?"
|
||||
|
||||
AEROSPACE:
|
||||
"Aerospace software often requires:
|
||||
|
||||
- DO-178C certification levels
|
||||
- Safety analysis (FMEA, FTA)
|
||||
- Simulation validation
|
||||
- Real-time performance guarantees
|
||||
- Export control (ITAR)
|
||||
|
||||
Which are relevant for your project?"
|
||||
|
||||
[Continue for other domains...]
|
||||
|
||||
Document concerns as the user shares them
|
||||
Ask follow-up questions to understand depth:
|
||||
|
||||
- "How critical is this requirement?"
|
||||
- "Is this a must-have for launch or can it come later?"
|
||||
- "Do you have expertise here or need guidance?"</action>
|
||||
|
||||
<template-output>concern_mapping</template-output>
|
||||
</step>
|
||||
|
||||
<step n="3" goal="Research key requirements together">
|
||||
<action>Conduct research WITH the user watching and contributing
|
||||
|
||||
"Let me research the current requirements for [specific concern]. You can guide me toward what's most relevant."
|
||||
|
||||
<WebSearch>{specific_requirement} requirements {date}</WebSearch>
|
||||
|
||||
Share findings immediately:
|
||||
"Here's what I found about [requirement]:
|
||||
|
||||
- [Key point 1]
|
||||
- [Key point 2]
|
||||
- [Key point 3]
|
||||
|
||||
Does this match your understanding? Anything surprising or concerning?"
|
||||
|
||||
For each major concern:
|
||||
|
||||
1. Research current standards/regulations
|
||||
2. Share findings with user
|
||||
3. Get their interpretation
|
||||
4. Note practical implications
|
||||
|
||||
If user has expertise:
|
||||
"You seem knowledgeable about [area]. What should I know that might not be in public documentation?"
|
||||
|
||||
If user is learning:
|
||||
"This might be new territory. Let me explain what this means practically for your development..."</action>
|
||||
|
||||
<template-output>regulatory_requirements</template-output>
|
||||
<template-output>industry_standards</template-output>
|
||||
</step>
|
||||
|
||||
<step n="4" goal="Identify practical implications">
|
||||
<action>Translate research into practical development impacts
|
||||
|
||||
"Based on what we've learned, here's what this means for your project:
|
||||
|
||||
ARCHITECTURE IMPLICATIONS:
|
||||
|
||||
- [How this affects system design]
|
||||
- [Required components or patterns]
|
||||
- [Performance or security needs]
|
||||
|
||||
DEVELOPMENT IMPLICATIONS:
|
||||
|
||||
- [Additional development effort]
|
||||
- [Special expertise needed]
|
||||
- [Testing requirements]
|
||||
|
||||
TIMELINE IMPLICATIONS:
|
||||
|
||||
- [Certification/approval timelines]
|
||||
- [Validation requirements]
|
||||
- [Documentation needs]
|
||||
|
||||
COST IMPLICATIONS:
|
||||
|
||||
- [Compliance costs]
|
||||
- [Required tools or services]
|
||||
- [Ongoing maintenance]
|
||||
|
||||
Does this align with your expectations? Any surprises we should dig into?"</action>
|
||||
|
||||
<template-output>practical_implications</template-output>
|
||||
</step>
|
||||
|
||||
<step n="5" goal="Discover domain-specific patterns">
|
||||
<action>Explore how others solve similar problems
|
||||
|
||||
"Let's look at how successful [domain] products handle these challenges."
|
||||
|
||||
<WebSearch>best {domain} software architecture patterns {date}</WebSearch>
|
||||
<WebSearch>{domain} software case studies {date}</WebSearch>
|
||||
|
||||
Discuss patterns:
|
||||
"I found these common approaches in [domain]:
|
||||
|
||||
Pattern 1: [Description]
|
||||
|
||||
- Pros: [Benefits]
|
||||
- Cons: [Tradeoffs]
|
||||
- When to use: [Conditions]
|
||||
|
||||
Pattern 2: [Description]
|
||||
|
||||
- Pros: [Benefits]
|
||||
- Cons: [Tradeoffs]
|
||||
- When to use: [Conditions]
|
||||
|
||||
Which resonates with your vision? Or are you thinking something different?"
|
||||
|
||||
If user proposes novel approach:
|
||||
"That's interesting and different from the standard patterns. Let's explore:
|
||||
|
||||
- What makes your approach unique?
|
||||
- What problem does it solve that existing patterns don't?
|
||||
- What are the risks?
|
||||
- How do we validate it?"</action>
|
||||
|
||||
<template-output>domain_patterns</template-output>
|
||||
<template-output if="novel approach">innovation_notes</template-output>
|
||||
</step>
|
||||
|
||||
<step n="6" goal="Risk assessment and mitigation">
|
||||
<action>Collaboratively identify and address risks
|
||||
|
||||
"Every [domain] project has risks. Let's think through yours:
|
||||
|
||||
REGULATORY RISKS:
|
||||
|
||||
- What if regulations change during development?
|
||||
- What if approval/certification takes longer?
|
||||
- What if we misinterpret requirements?
|
||||
|
||||
TECHNICAL RISKS:
|
||||
|
||||
- What if the domain requirements conflict with user experience?
|
||||
- What if performance requirements are harder than expected?
|
||||
- What if integrations are more complex?
|
||||
|
||||
MARKET RISKS:
|
||||
|
||||
- What if competitors move faster?
|
||||
- What if domain experts are hard to find?
|
||||
- What if users resist domain-mandated workflows?
|
||||
|
||||
For each risk you're concerned about, let's identify:
|
||||
|
||||
1. How likely is it?
|
||||
2. What's the impact if it happens?
|
||||
3. How can we mitigate it?
|
||||
4. What's our plan B?"</action>
|
||||
|
||||
<template-output>risk_assessment</template-output>
|
||||
</step>
|
||||
|
||||
<step n="7" goal="Create validation strategy">
|
||||
<action>Plan how to ensure domain requirements are met
|
||||
|
||||
"Let's plan how to validate that we're meeting [domain] requirements:
|
||||
|
||||
COMPLIANCE VALIDATION:
|
||||
|
||||
- How do we verify regulatory compliance?
|
||||
- Who needs to review/approve?
|
||||
- What documentation is required?
|
||||
|
||||
TECHNICAL VALIDATION:
|
||||
|
||||
- How do we prove the system works correctly?
|
||||
- What metrics matter?
|
||||
- What testing is required?
|
||||
|
||||
DOMAIN EXPERT VALIDATION:
|
||||
|
||||
- Who are the domain experts to involve?
|
||||
- When should they review?
|
||||
- What are their success criteria?
|
||||
|
||||
USER VALIDATION:
|
||||
|
||||
- How do we ensure it's still usable despite constraints?
|
||||
- What user testing is needed?
|
||||
- How do we balance domain requirements with UX?
|
||||
|
||||
What validation is most critical for your confidence?"</action>
|
||||
|
||||
<template-output>validation_strategy</template-output>
|
||||
</step>
|
||||
|
||||
<step n="8" goal="Document decision points">
|
||||
<action>Capture key decisions and rationale
|
||||
|
||||
"Let's document the important decisions we've made:
|
||||
|
||||
DOMAIN APPROACH:
|
||||
|
||||
- We're choosing [approach] because [rationale]
|
||||
- We're prioritizing [requirement] over [requirement] because [reason]
|
||||
- We're deferring [requirement] to Phase 2 because [justification]
|
||||
|
||||
COMPLIANCE STRATEGY:
|
||||
|
||||
- We'll pursue [pathway] for regulatory approval
|
||||
- We'll implement [standard] for industry compliance
|
||||
- We'll handle [requirement] by [approach]
|
||||
|
||||
RISK DECISIONS:
|
||||
|
||||
- We accept [risk] because [reason]
|
||||
- We'll mitigate [risk] through [approach]
|
||||
- We'll monitor [risk] by [method]
|
||||
|
||||
Any decisions you want to revisit or rationale to add?"</action>
|
||||
|
||||
<template-output>key_decisions</template-output>
|
||||
</step>
|
||||
|
||||
<step n="9" goal="Create actionable recommendations">
|
||||
<action>Synthesize research into specific recommendations
|
||||
|
||||
"Based on our research, here are my recommendations for your PRD and development:
|
||||
|
||||
MUST HAVE (Domain Critical):
|
||||
|
||||
1. [Specific requirement with why it's critical]
|
||||
2. [Specific requirement with why it's critical]
|
||||
3. [Specific requirement with why it's critical]
|
||||
|
||||
SHOULD HAVE (Domain Important):
|
||||
|
||||
1. [Requirement that's important but not blocking]
|
||||
2. [Requirement that's important but not blocking]
|
||||
|
||||
CONSIDER (Domain Nice-to-Have):
|
||||
|
||||
1. [Enhancement that would differentiate]
|
||||
2. [Enhancement that would differentiate]
|
||||
|
||||
DEVELOPMENT SEQUENCE:
|
||||
|
||||
1. First: [What to build first and why]
|
||||
2. Then: [What comes next and why]
|
||||
3. Later: [What can wait and why]
|
||||
|
||||
EXPERTISE NEEDED:
|
||||
|
||||
- [Domain expert role]: For [specific areas]
|
||||
- [Technical expert role]: For [specific requirements]
|
||||
|
||||
TIMELINE CONSIDERATIONS:
|
||||
|
||||
- Allow [time] for [process/approval]
|
||||
- Start [requirement] early because [reason]
|
||||
- [Requirement] can be parallel with development
|
||||
|
||||
Do these recommendations feel right? What would you adjust?"</action>
|
||||
|
||||
<template-output>recommendations</template-output>
|
||||
</step>
|
||||
|
||||
<step n="10" goal="Package for PRD integration">
|
||||
<action>Create clear handoff to PRD workflow
|
||||
|
||||
"I've captured everything in domain-brief.md. Here's the summary for your PRD:
|
||||
|
||||
DOMAIN: {identified_domain}
|
||||
COMPLEXITY: {high|medium}
|
||||
|
||||
KEY REQUIREMENTS TO INCORPORATE:
|
||||
|
||||
- [Requirement 1 - critical for domain]
|
||||
- [Requirement 2 - critical for domain]
|
||||
- [Requirement 3 - important consideration]
|
||||
|
||||
IMPACTS ON:
|
||||
|
||||
- Functional Requirements: [How domain affects features]
|
||||
- Non-Functional Requirements: [Performance, security, etc.]
|
||||
- Architecture: [System design considerations]
|
||||
- Development: [Process and timeline impacts]
|
||||
|
||||
REFERENCE DOCS:
|
||||
|
||||
- Full domain analysis: domain-brief.md
|
||||
- Regulations researched: [List with links]
|
||||
- Standards referenced: [List with links]
|
||||
|
||||
When you return to PRD, reference this brief for domain context.
|
||||
|
||||
Any final questions before we wrap up the domain research?"</action>
|
||||
|
||||
<template-output>summary_for_prd</template-output>
|
||||
</step>
|
||||
|
||||
<step n="11" goal="Close with next steps">
|
||||
<output>**✅ Domain Research Complete, {user_name}!**
|
||||
|
||||
We've explored the {domain} aspects of your project together and documented critical requirements.
|
||||
|
||||
**Created:**
|
||||
|
||||
- **domain-brief.md** - Complete domain analysis with requirements and recommendations
|
||||
|
||||
**Key Findings:**
|
||||
|
||||
- Primary domain: {domain}
|
||||
- Complexity level: {complexity}
|
||||
- Critical requirements: {count} identified
|
||||
- Risks identified: {count} with mitigation strategies
|
||||
|
||||
**Next Steps:**
|
||||
|
||||
1. Return to PRD workflow with this domain context
|
||||
2. Domain requirements will shape your functional requirements
|
||||
3. Reference domain-brief.md for detailed requirements
|
||||
|
||||
**Remember:**
|
||||
{most_important_finding}
|
||||
|
||||
The domain research will ensure your PRD captures not just what to build, but HOW to build it correctly for {domain}.
|
||||
</output>
|
||||
</step>
|
||||
|
||||
</workflow>
|
||||
|
|
@ -0,0 +1,180 @@
|
|||
# Domain Brief - {project_name}
|
||||
|
||||
Generated: {date}
|
||||
Domain: {primary_domain}
|
||||
Complexity: {complexity_level}
|
||||
|
||||
## Executive Summary
|
||||
|
||||
{brief_overview_of_domain_research_findings}
|
||||
|
||||
## Domain Overview
|
||||
|
||||
### Industry Context
|
||||
|
||||
{domain_overview}
|
||||
|
||||
### Regulatory Landscape
|
||||
|
||||
{regulatory_environment}
|
||||
|
||||
### Key Stakeholders
|
||||
|
||||
{stakeholder_analysis}
|
||||
|
||||
## Critical Concerns
|
||||
|
||||
### Compliance Requirements
|
||||
|
||||
{concern_mapping}
|
||||
|
||||
### Technical Constraints
|
||||
|
||||
{technical_limitations_from_domain}
|
||||
|
||||
### Safety/Risk Considerations
|
||||
|
||||
{safety_risk_factors}
|
||||
|
||||
## Regulatory Requirements
|
||||
|
||||
{regulatory_requirements}
|
||||
|
||||
## Industry Standards
|
||||
|
||||
{industry_standards}
|
||||
|
||||
## Practical Implications
|
||||
|
||||
### Architecture Impact
|
||||
|
||||
{architecture_implications}
|
||||
|
||||
### Development Impact
|
||||
|
||||
{development_implications}
|
||||
|
||||
### Timeline Impact
|
||||
|
||||
{timeline_implications}
|
||||
|
||||
### Cost Impact
|
||||
|
||||
{cost_implications}
|
||||
|
||||
## Domain Patterns
|
||||
|
||||
### Established Patterns
|
||||
|
||||
{domain_patterns}
|
||||
|
||||
### Innovation Opportunities
|
||||
|
||||
{innovation_notes}
|
||||
|
||||
## Risk Assessment
|
||||
|
||||
### Identified Risks
|
||||
|
||||
{risk_assessment}
|
||||
|
||||
### Mitigation Strategies
|
||||
|
||||
{mitigation_approaches}
|
||||
|
||||
## Validation Strategy
|
||||
|
||||
### Compliance Validation
|
||||
|
||||
{compliance_validation_approach}
|
||||
|
||||
### Technical Validation
|
||||
|
||||
{technical_validation_approach}
|
||||
|
||||
### Domain Expert Validation
|
||||
|
||||
{expert_validation_approach}
|
||||
|
||||
## Key Decisions
|
||||
|
||||
{key_decisions}
|
||||
|
||||
## Recommendations
|
||||
|
||||
### Must Have (Critical)
|
||||
|
||||
{critical_requirements}
|
||||
|
||||
### Should Have (Important)
|
||||
|
||||
{important_requirements}
|
||||
|
||||
### Consider (Nice-to-Have)
|
||||
|
||||
{optional_enhancements}
|
||||
|
||||
### Development Sequence
|
||||
|
||||
{recommended_sequence}
|
||||
|
||||
### Required Expertise
|
||||
|
||||
{expertise_needed}
|
||||
|
||||
## PRD Integration Guide
|
||||
|
||||
### Summary for PRD
|
||||
|
||||
{summary_for_prd}
|
||||
|
||||
### Requirements to Incorporate
|
||||
|
||||
- {requirement_1}
|
||||
- {requirement_2}
|
||||
- {requirement_3}
|
||||
|
||||
### Architecture Considerations
|
||||
|
||||
- {architecture_consideration_1}
|
||||
- {architecture_consideration_2}
|
||||
|
||||
### Development Considerations
|
||||
|
||||
- {development_consideration_1}
|
||||
- {development_consideration_2}
|
||||
|
||||
## References
|
||||
|
||||
### Regulations Researched
|
||||
|
||||
- {regulation_1_with_link}
|
||||
- {regulation_2_with_link}
|
||||
|
||||
### Standards Referenced
|
||||
|
||||
- {standard_1_with_link}
|
||||
- {standard_2_with_link}
|
||||
|
||||
### Additional Resources
|
||||
|
||||
- {resource_1}
|
||||
- {resource_2}
|
||||
|
||||
## Appendix
|
||||
|
||||
### Research Notes
|
||||
|
||||
{detailed_research_notes}
|
||||
|
||||
### Conversation Highlights
|
||||
|
||||
{key_discussion_points_with_user}
|
||||
|
||||
### Open Questions
|
||||
|
||||
{questions_requiring_further_research}
|
||||
|
||||
---
|
||||
|
||||
_This domain brief was created through collaborative research between {user_name} and the AI facilitator. It should be referenced during PRD creation and updated as new domain insights emerge._
|
||||
|
|
@ -0,0 +1,36 @@
|
|||
workflow:
|
||||
id: domain-research
|
||||
name: "Domain Research"
|
||||
module: bmm
|
||||
version: "6.0.0-alpha"
|
||||
description: "Collaborative exploration of domain-specific requirements, regulations, and patterns for complex projects"
|
||||
|
||||
environment:
|
||||
# Inherit from parent workflow or set defaults
|
||||
user_name: "partner"
|
||||
user_skill_level: "intermediate"
|
||||
communication_language: "English"
|
||||
document_output_language: "English"
|
||||
date: "{system.date}"
|
||||
|
||||
required_files:
|
||||
- instructions.md
|
||||
- template.md
|
||||
|
||||
optional_files:
|
||||
- domain-knowledge-base.md
|
||||
|
||||
outputs:
|
||||
- domain-brief.md
|
||||
|
||||
metadata:
|
||||
category: "analysis"
|
||||
complexity: "medium"
|
||||
estimated_time: "30-45 minutes"
|
||||
prerequisites:
|
||||
- "Basic project understanding"
|
||||
when_to_use:
|
||||
- "Complex regulated domains (healthcare, finance, aerospace)"
|
||||
- "Novel technical domains requiring deep understanding"
|
||||
- "Before PRD when domain expertise needed"
|
||||
- "When compliance and regulations matter"
|
||||
|
|
@ -1,21 +1,19 @@
|
|||
# Product Brief - Interactive Workflow Instructions
|
||||
# Product Brief - Context-Adaptive Discovery Instructions
|
||||
|
||||
<critical>The workflow execution engine is governed by: {project-root}/bmad/core/tasks/workflow.xml</critical>
|
||||
<critical>You MUST have already loaded and processed: {installed_path}/workflow.yaml</critical>
|
||||
<critical>Communicate all responses in {communication_language} and language MUST be tailored to {user_skill_level}</critical>
|
||||
<critical>This workflow uses INTENT-DRIVEN FACILITATION - adapt organically to what emerges</critical>
|
||||
<critical>The goal is DISCOVERING WHAT MATTERS through natural conversation, not filling a template</critical>
|
||||
<critical>Communicate all responses in {communication_language} and adapt deeply to {user_skill_level}</critical>
|
||||
<critical>Generate all documents in {document_output_language}</critical>
|
||||
|
||||
<critical>DOCUMENT OUTPUT: Concise, professional, strategically focused. Use tables/lists over prose. User skill level ({user_skill_level}) affects conversation style ONLY, not document content.</critical>
|
||||
<critical>LIVING DOCUMENT: Write to the document continuously as you discover - never wait until the end</critical>
|
||||
|
||||
<workflow>
|
||||
|
||||
<step n="0" goal="Validate workflow readiness" tag="workflow-status">
|
||||
<action>Check if {output_folder}/bmm-workflow-status.yaml exists</action>
|
||||
|
||||
<check if="status file not found">
|
||||
<output>No workflow status file found. Product Brief is optional - you can continue without status tracking.</output>
|
||||
<action>Set standalone_mode = true</action>
|
||||
</check>
|
||||
<action if="status file not found">Set standalone_mode = true</action>
|
||||
|
||||
<check if="status file found">
|
||||
<action>Load the FULL file: {output_folder}/bmm-workflow-status.yaml</action>
|
||||
|
|
@ -25,9 +23,10 @@
|
|||
<action>Find first non-completed workflow (next expected workflow)</action>
|
||||
|
||||
<check if="project_level < 2">
|
||||
<output>Note: Product Brief is most valuable for Level 2+ projects. Your project is Level {{project_level}}.</output>
|
||||
<output>You may want to skip directly to technical planning instead.</output>
|
||||
</check>
|
||||
<output>**Note: Level {{project_level}} Project**
|
||||
|
||||
Product Brief is most valuable for Level 2+ projects, but can help clarify vision for any project.</output>
|
||||
</check>
|
||||
|
||||
<check if="product-brief status is file path (already completed)">
|
||||
<output>⚠️ Product Brief already completed: {{product-brief status}}</output>
|
||||
|
|
@ -38,7 +37,7 @@
|
|||
</check>
|
||||
</check>
|
||||
|
||||
<check if="product-brief is not the next expected workflow (latter items are completed already in the list)">
|
||||
<check if="product-brief is not the next expected workflow">
|
||||
<output>⚠️ Next expected workflow: {{next_workflow}}. Product Brief is out of sequence.</output>
|
||||
<ask>Continue with Product Brief anyway? (y/n)</ask>
|
||||
<check if="n">
|
||||
|
|
@ -51,241 +50,427 @@
|
|||
</check>
|
||||
</step>
|
||||
|
||||
<step n="1" goal="Initialize product brief session">
|
||||
<action>Welcome the user in {communication_language} to the Product Brief creation process</action>
|
||||
<action>Explain this is a collaborative process to define their product vision and strategic foundation</action>
|
||||
<action>Ask the user to provide the project name for this product brief</action>
|
||||
<step n="1" goal="Begin the journey and understand context">
|
||||
<action>Welcome {user_name} warmly in {communication_language}
|
||||
|
||||
Adapt your tone to {user_skill_level}:
|
||||
|
||||
- Expert: "Let's define your product vision. What are you building?"
|
||||
- Intermediate: "I'm here to help shape your product vision. Tell me about your idea."
|
||||
- Beginner: "Hi! I'm going to help you figure out exactly what you want to build. Let's start with your idea - what got you excited about this?"
|
||||
|
||||
Start with open exploration:
|
||||
|
||||
- What sparked this idea?
|
||||
- What are you hoping to build?
|
||||
- Who is this for - yourself, a business, users you know?
|
||||
|
||||
CRITICAL: Listen for context clues that reveal their situation:
|
||||
|
||||
- Personal/hobby project (fun, learning, small audience)
|
||||
- Startup/solopreneur (market opportunity, competition matters)
|
||||
- Enterprise/corporate (stakeholders, compliance, strategic alignment)
|
||||
- Technical enthusiasm (implementation focused)
|
||||
- Business opportunity (market/revenue focused)
|
||||
- Problem frustration (solution focused)
|
||||
|
||||
Based on their initial response, sense:
|
||||
|
||||
- How formal/casual they want to be
|
||||
- Whether they think in business or technical terms
|
||||
- If they have existing materials to share
|
||||
- Their confidence level with the domain</action>
|
||||
|
||||
<ask>What's the project name, and what got you excited about building this?</ask>
|
||||
|
||||
<action>From even this first exchange, create initial document sections</action>
|
||||
<template-output>project_name</template-output>
|
||||
</step>
|
||||
|
||||
<step n="1" goal="Gather available inputs and context">
|
||||
<action>Explore what existing materials the user has available to inform the brief</action>
|
||||
<action>Offer options for input sources: market research, brainstorming results, competitive analysis, initial ideas, or starting fresh</action>
|
||||
<action>If documents are provided, load and analyze them to extract key insights, themes, and patterns</action>
|
||||
<action>Engage the user about their core vision: what problem they're solving, who experiences it most acutely, and what sparked this product idea</action>
|
||||
<action>Build initial understanding through conversational exploration rather than rigid questioning</action>
|
||||
|
||||
<template-output>initial_context</template-output>
|
||||
</step>
|
||||
|
||||
<step n="2" goal="Choose collaboration mode">
|
||||
<ask>How would you like to work through the brief?
|
||||
|
||||
**1. Interactive Mode** - We'll work through each section together, discussing and refining as we go
|
||||
|
||||
**2. YOLO Mode** - I'll generate a complete draft based on our conversation so far, then we'll refine it together
|
||||
|
||||
Which approach works best for you?</ask>
|
||||
|
||||
<action>Store the user's preference for mode</action>
|
||||
<template-output>collaboration_mode</template-output>
|
||||
</step>
|
||||
|
||||
<step n="3" goal="Define the problem statement" if="collaboration_mode == 'interactive'">
|
||||
<action>Guide deep exploration of the problem: current state frustrations, quantifiable impact (time/money/opportunities), why existing solutions fall short, urgency of solving now</action>
|
||||
<action>Challenge vague statements and push for specificity with probing questions</action>
|
||||
<action>Help the user articulate measurable pain points with evidence</action>
|
||||
<action>Craft a compelling, evidence-based problem statement</action>
|
||||
|
||||
<template-output>problem_statement</template-output>
|
||||
</step>
|
||||
|
||||
<step n="4" goal="Develop the proposed solution" if="collaboration_mode == 'interactive'">
|
||||
<action>Shape the solution vision by exploring: core approach to solving the problem, key differentiators from existing solutions, why this will succeed, ideal user experience</action>
|
||||
<action>Focus on the "what" and "why", not implementation details - keep it strategic</action>
|
||||
<action>Help articulate compelling differentiators that make this solution unique</action>
|
||||
<action>Craft a clear, inspiring solution vision</action>
|
||||
|
||||
<template-output>proposed_solution</template-output>
|
||||
</step>
|
||||
|
||||
<step n="5" goal="Identify target users" if="collaboration_mode == 'interactive'">
|
||||
<action>Guide detailed definition of primary users: demographic/professional profile, current problem-solving methods, specific pain points, goals they're trying to achieve</action>
|
||||
<action>Explore secondary user segments if applicable and define how their needs differ</action>
|
||||
<action>Push beyond generic personas like "busy professionals" - demand specificity and actionable details</action>
|
||||
<action>Create specific, actionable user profiles that inform product decisions</action>
|
||||
|
||||
<template-output>primary_user_segment</template-output>
|
||||
<template-output>secondary_user_segment</template-output>
|
||||
</step>
|
||||
|
||||
<step n="6" goal="Establish goals and success metrics" if="collaboration_mode == 'interactive'">
|
||||
<action>Guide establishment of SMART goals across business objectives and user success metrics</action>
|
||||
<action>Explore measurable business outcomes (user acquisition targets, cost reductions, revenue goals)</action>
|
||||
<action>Define user success metrics focused on behaviors and outcomes, not features (task completion time, return frequency)</action>
|
||||
<action>Help formulate specific, measurable goals that distinguish between business and user success</action>
|
||||
<action>Identify top 3-5 Key Performance Indicators that will track product success</action>
|
||||
|
||||
<template-output>business_objectives</template-output>
|
||||
<template-output>user_success_metrics</template-output>
|
||||
<template-output>key_performance_indicators</template-output>
|
||||
</step>
|
||||
|
||||
<step n="7" goal="Define MVP scope" if="collaboration_mode == 'interactive'">
|
||||
<action>Be ruthless about MVP scope - identify absolute MUST-HAVE features for launch that validate the core hypothesis</action>
|
||||
<action>For each proposed feature, probe why it's essential vs nice-to-have</action>
|
||||
<action>Identify tempting features that need to wait for v2 - what adds complexity without core value</action>
|
||||
<action>Define what constitutes a successful MVP launch with clear criteria</action>
|
||||
<action>Challenge scope creep aggressively and push for true minimum viability</action>
|
||||
<action>Clearly separate must-haves from nice-to-haves</action>
|
||||
|
||||
<template-output>core_features</template-output>
|
||||
<template-output>out_of_scope</template-output>
|
||||
<template-output>mvp_success_criteria</template-output>
|
||||
</step>
|
||||
|
||||
<step n="8" goal="Assess financial impact and ROI" if="collaboration_mode == 'interactive'">
|
||||
<action>Explore financial considerations: development investment, revenue potential, cost savings opportunities, break-even timing, budget alignment</action>
|
||||
<action>Investigate strategic alignment: company OKRs, strategic objectives, key initiatives supported, opportunity cost of NOT doing this</action>
|
||||
<action>Help quantify financial impact where possible - both tangible and intangible value</action>
|
||||
<action>Connect this product to broader company strategy and demonstrate strategic value</action>
|
||||
|
||||
<template-output>financial_impact</template-output>
|
||||
<template-output>company_objectives_alignment</template-output>
|
||||
<template-output>strategic_initiatives</template-output>
|
||||
</step>
|
||||
|
||||
<step n="9" goal="Explore post-MVP vision" optional="true" if="collaboration_mode == 'interactive'">
|
||||
<action>Guide exploration of post-MVP future: Phase 2 features, expansion opportunities, long-term vision (1-2 years)</action>
|
||||
<action>Ensure MVP decisions align with future direction while staying focused on immediate goals</action>
|
||||
|
||||
<template-output>phase_2_features</template-output>
|
||||
<template-output>long_term_vision</template-output>
|
||||
<template-output>expansion_opportunities</template-output>
|
||||
</step>
|
||||
|
||||
<step n="10" goal="Document technical considerations" if="collaboration_mode == 'interactive'">
|
||||
<action>Capture technical context as preferences, not final decisions</action>
|
||||
<action>Explore platform requirements: web/mobile/desktop, browser/OS support, performance needs, accessibility standards</action>
|
||||
<action>Investigate technology preferences or constraints: frontend/backend frameworks, database needs, infrastructure requirements</action>
|
||||
<action>Identify existing systems requiring integration</action>
|
||||
<action>Check for technical-preferences.yaml file if available</action>
|
||||
<action>Note these are initial thoughts for PM and architect to consider during planning</action>
|
||||
|
||||
<template-output>platform_requirements</template-output>
|
||||
<template-output>technology_preferences</template-output>
|
||||
<template-output>architecture_considerations</template-output>
|
||||
</step>
|
||||
|
||||
<step n="11" goal="Identify constraints and assumptions" if="collaboration_mode == 'interactive'">
|
||||
<action>Guide realistic expectations setting around constraints: budget/resource limits, timeline pressures, team size/expertise, technical limitations</action>
|
||||
<action>Explore assumptions being made about: user behavior, market conditions, technical feasibility</action>
|
||||
<action>Document constraints clearly and list assumptions that need validation during development</action>
|
||||
|
||||
<template-output>constraints</template-output>
|
||||
<template-output>key_assumptions</template-output>
|
||||
</step>
|
||||
|
||||
<step n="12" goal="Assess risks and open questions" optional="true" if="collaboration_mode == 'interactive'">
|
||||
<action>Facilitate honest risk assessment: what could derail the project, impact if risks materialize</action>
|
||||
<action>Document open questions: what still needs figuring out, what needs more research</action>
|
||||
<action>Help prioritize risks by impact and likelihood</action>
|
||||
<action>Frame unknowns as opportunities to prepare, not just worries</action>
|
||||
|
||||
<template-output>key_risks</template-output>
|
||||
<template-output>open_questions</template-output>
|
||||
<template-output>research_areas</template-output>
|
||||
</step>
|
||||
|
||||
<!-- YOLO Mode - Generate everything then refine -->
|
||||
<step n="3" goal="Generate complete brief draft" if="collaboration_mode == 'yolo'">
|
||||
<action>Based on initial context and any provided documents, generate a complete product brief covering all sections</action>
|
||||
<action>Make reasonable assumptions where information is missing</action>
|
||||
<action>Flag areas that need user validation with [NEEDS CONFIRMATION] tags</action>
|
||||
|
||||
<template-output>problem_statement</template-output>
|
||||
<template-output>proposed_solution</template-output>
|
||||
<template-output>primary_user_segment</template-output>
|
||||
<template-output>secondary_user_segment</template-output>
|
||||
<template-output>business_objectives</template-output>
|
||||
<template-output>user_success_metrics</template-output>
|
||||
<template-output>key_performance_indicators</template-output>
|
||||
<template-output>core_features</template-output>
|
||||
<template-output>out_of_scope</template-output>
|
||||
<template-output>mvp_success_criteria</template-output>
|
||||
<template-output>phase_2_features</template-output>
|
||||
<template-output>long_term_vision</template-output>
|
||||
<template-output>expansion_opportunities</template-output>
|
||||
<template-output>financial_impact</template-output>
|
||||
<template-output>company_objectives_alignment</template-output>
|
||||
<template-output>strategic_initiatives</template-output>
|
||||
<template-output>platform_requirements</template-output>
|
||||
<template-output>technology_preferences</template-output>
|
||||
<template-output>architecture_considerations</template-output>
|
||||
<template-output>constraints</template-output>
|
||||
<template-output>key_assumptions</template-output>
|
||||
<template-output>key_risks</template-output>
|
||||
<template-output>open_questions</template-output>
|
||||
<template-output>research_areas</template-output>
|
||||
|
||||
<action>Present the complete draft to the user</action>
|
||||
<ask>Here's the complete brief draft. What would you like to adjust or refine?</ask>
|
||||
</step>
|
||||
|
||||
<step n="4" goal="Refine brief sections" repeat="until-approved" if="collaboration_mode == 'yolo'">
|
||||
<ask>Which section would you like to refine?
|
||||
1. Problem Statement
|
||||
2. Proposed Solution
|
||||
3. Target Users
|
||||
4. Goals and Metrics
|
||||
5. MVP Scope
|
||||
6. Post-MVP Vision
|
||||
7. Financial Impact and Strategic Alignment
|
||||
8. Technical Considerations
|
||||
9. Constraints and Assumptions
|
||||
10. Risks and Questions
|
||||
11. Save and continue</ask>
|
||||
|
||||
<action>Work with user to refine selected section</action>
|
||||
<action>Update relevant template outputs</action>
|
||||
</step>
|
||||
|
||||
<!-- Final steps for both modes -->
|
||||
<step n="13" goal="Create executive summary">
|
||||
<action>Synthesize all sections into a compelling executive summary</action>
|
||||
<action>Include:
|
||||
- Product concept in 1-2 sentences
|
||||
- Primary problem being solved
|
||||
- Target market identification
|
||||
- Key value proposition</action>
|
||||
|
||||
<template-output>executive_summary</template-output>
|
||||
|
||||
<action>If they mentioned existing documents (research, brainstorming, etc.):
|
||||
|
||||
- Load and analyze these materials
|
||||
- Extract key themes and insights
|
||||
- Reference these naturally in conversation: "I see from your research that..."
|
||||
- Use these to accelerate discovery, not repeat questions</action>
|
||||
|
||||
<template-output>initial_vision</template-output>
|
||||
</step>
|
||||
|
||||
<step n="14" goal="Compile supporting materials">
|
||||
<action>If research documents were provided, create a summary of key findings</action>
|
||||
<action>Document any stakeholder input received during the process</action>
|
||||
<action>Compile list of reference documents and resources</action>
|
||||
<step n="2" goal="Discover the problem worth solving">
|
||||
<action>Guide problem discovery through natural conversation
|
||||
|
||||
<template-output>research_summary</template-output>
|
||||
<template-output>stakeholder_input</template-output>
|
||||
<template-output>references</template-output>
|
||||
</step>
|
||||
DON'T ask: "What problem does this solve?"
|
||||
|
||||
<step n="15" goal="Final review and handoff">
|
||||
<action>Generate the complete product brief document</action>
|
||||
<action>Review all sections for completeness and consistency</action>
|
||||
<action>Flag any areas that need PM attention with [PM-TODO] tags</action>
|
||||
DO explore conversationally based on their context:
|
||||
|
||||
<ask>The product brief is complete! Would you like to:
|
||||
For hobby projects:
|
||||
|
||||
1. Review the entire document
|
||||
2. Make final adjustments
|
||||
3. Generate an executive summary version (3-page limit)
|
||||
4. Save and prepare for handoff to PM
|
||||
- "What's annoying you that this would fix?"
|
||||
- "What would this make easier or more fun?"
|
||||
- "Show me what the experience is like today without this"
|
||||
|
||||
This brief will serve as the primary input for creating the Product Requirements Document (PRD).</ask>
|
||||
For business ventures:
|
||||
|
||||
<check if="user chooses option 3 (executive summary)">
|
||||
<action>Create condensed 3-page executive brief focusing on: problem statement, proposed solution, target users, MVP scope, financial impact, and strategic alignment</action>
|
||||
<action>Save as: {output_folder}/product-brief-executive-{{project_name}}-{{date}}.md</action>
|
||||
- "Walk me through the frustration your users face today"
|
||||
- "What's the cost of this problem - time, money, opportunities?"
|
||||
- "Who's suffering most from this? Tell me about them"
|
||||
- "What solutions have people tried? Why aren't they working?"
|
||||
|
||||
For enterprise:
|
||||
|
||||
- "What's driving the need for this internally?"
|
||||
- "Which teams/processes are most affected?"
|
||||
- "What's the business impact of not solving this?"
|
||||
- "Are there compliance or strategic drivers?"
|
||||
|
||||
Listen for depth cues:
|
||||
|
||||
- Brief answers → dig deeper with follow-ups
|
||||
- Detailed passion → let them flow, capture everything
|
||||
- Uncertainty → help them explore with examples
|
||||
- Multiple problems → help prioritize the core issue
|
||||
|
||||
Adapt your response:
|
||||
|
||||
- If they struggle: offer analogies, examples, frameworks
|
||||
- If they're clear: validate and push for specifics
|
||||
- If they're technical: explore implementation challenges
|
||||
- If they're business-focused: quantify impact</action>
|
||||
|
||||
<action>Immediately capture what emerges - even if preliminary</action>
|
||||
<template-output>problem_statement</template-output>
|
||||
|
||||
<check if="user mentioned metrics, costs, or business impact">
|
||||
<action>Explore the measurable impact of the problem</action>
|
||||
<template-output>problem_impact</template-output>
|
||||
</check>
|
||||
|
||||
<template-output>final_brief</template-output>
|
||||
<template-output>executive_brief</template-output>
|
||||
<check if="user mentioned current solutions or competitors">
|
||||
<action>Understand why existing solutions fall short</action>
|
||||
<template-output>existing_solutions_gaps</template-output>
|
||||
</check>
|
||||
|
||||
<action>Reflect understanding: "So the core issue is {{problem_summary}}, and {{impact_if_mentioned}}. Let me capture that..."</action>
|
||||
</step>
|
||||
|
||||
<step n="3" goal="Shape the solution vision">
|
||||
<action>Transition naturally from problem to solution
|
||||
|
||||
Based on their energy and context, explore:
|
||||
|
||||
For builders/makers:
|
||||
|
||||
- "How do you envision this working?"
|
||||
- "Walk me through the experience you want to create"
|
||||
- "What's the 'magic moment' when someone uses this?"
|
||||
|
||||
For business minds:
|
||||
|
||||
- "What's your unique approach to solving this?"
|
||||
- "How is this different from what exists today?"
|
||||
- "What makes this the RIGHT solution now?"
|
||||
|
||||
For enterprise:
|
||||
|
||||
- "What would success look like for the organization?"
|
||||
- "How does this fit with existing systems/processes?"
|
||||
- "What's the transformation you're enabling?"
|
||||
|
||||
Go deeper based on responses:
|
||||
|
||||
- If innovative → explore the unique angle
|
||||
- If standard → focus on execution excellence
|
||||
- If technical → discuss key capabilities
|
||||
- If user-focused → paint the journey
|
||||
|
||||
Web research when relevant:
|
||||
|
||||
- If they mention competitors → research current solutions
|
||||
- If they claim innovation → verify uniqueness
|
||||
- If they reference trends → get current data</action>
|
||||
|
||||
<action if="competitor or market mentioned">
|
||||
<WebSearch>{{competitor/market}} latest features 2024</WebSearch>
|
||||
<action>Use findings to sharpen differentiation discussion</action>
|
||||
</action>
|
||||
|
||||
<template-output>proposed_solution</template-output>
|
||||
|
||||
<check if="unique differentiation discussed">
|
||||
<template-output>key_differentiators</template-output>
|
||||
</check>
|
||||
|
||||
<action>Continue building the living document</action>
|
||||
</step>
|
||||
|
||||
<step n="4" goal="Understand the people who need this">
|
||||
<action>Discover target users through storytelling, not demographics
|
||||
|
||||
Facilitate based on project type:
|
||||
|
||||
Personal/hobby:
|
||||
|
||||
- "Who else would love this besides you?"
|
||||
- "Tell me about someone who would use this"
|
||||
- Keep it light and informal
|
||||
|
||||
Startup/business:
|
||||
|
||||
- "Describe your ideal first customer - not demographics, but their situation"
|
||||
- "What are they doing today without your solution?"
|
||||
- "What would make them say 'finally, someone gets it!'?"
|
||||
- "Are there different types of users with different needs?"
|
||||
|
||||
Enterprise:
|
||||
|
||||
- "Which roles/departments will use this?"
|
||||
- "Walk me through their current workflow"
|
||||
- "Who are the champions vs skeptics?"
|
||||
- "What about indirect stakeholders?"
|
||||
|
||||
Push beyond generic personas:
|
||||
|
||||
- Not: "busy professionals" → "Sales reps who waste 2 hours/day on data entry"
|
||||
- Not: "tech-savvy users" → "Developers who know Docker but hate configuring it"
|
||||
- Not: "small businesses" → "Shopify stores doing $10-50k/month wanting to scale"
|
||||
|
||||
For each user type that emerges:
|
||||
|
||||
- Current behavior/workflow
|
||||
- Specific frustrations
|
||||
- What they'd value most
|
||||
- Their technical comfort level</action>
|
||||
|
||||
<template-output>primary_user_segment</template-output>
|
||||
|
||||
<check if="multiple user types mentioned">
|
||||
<action>Explore secondary users only if truly different needs</action>
|
||||
<template-output>secondary_user_segment</template-output>
|
||||
</check>
|
||||
|
||||
<check if="user journey or workflow discussed">
|
||||
<template-output>user_journey</template-output>
|
||||
</check>
|
||||
</step>
|
||||
|
||||
<step n="5" goal="Define what success looks like" repeat="adapt-to-context">
|
||||
<action>Explore success measures that match their context
|
||||
|
||||
For personal projects:
|
||||
|
||||
- "How will you know this is working well?"
|
||||
- "What would make you proud of this?"
|
||||
- Keep metrics simple and meaningful
|
||||
|
||||
For startups:
|
||||
|
||||
- "What metrics would convince you this is taking off?"
|
||||
- "What user behaviors show they love it?"
|
||||
- "What business metrics matter most - users, revenue, retention?"
|
||||
- Push for specific targets: "100 users" not "lots of users"
|
||||
|
||||
For enterprise:
|
||||
|
||||
- "How will the organization measure success?"
|
||||
- "What KPIs will stakeholders care about?"
|
||||
- "What are the must-hit metrics vs nice-to-haves?"
|
||||
|
||||
Only dive deep into metrics if they show interest
|
||||
Skip entirely for pure hobby projects
|
||||
Focus on what THEY care about measuring</action>
|
||||
|
||||
<check if="metrics or goals discussed">
|
||||
<template-output>success_metrics</template-output>
|
||||
|
||||
<check if="business objectives mentioned">
|
||||
<template-output>business_objectives</template-output>
|
||||
</check>
|
||||
|
||||
<check if="KPIs matter to them">
|
||||
<template-output>key_performance_indicators</template-output>
|
||||
</check>
|
||||
</check>
|
||||
|
||||
<action>Keep the document growing with each discovery</action>
|
||||
</step>
|
||||
|
||||
<step n="6" goal="Discover the MVP scope">
|
||||
<critical>Focus on FEATURES not epics - that comes in Phase 2</critical>
|
||||
|
||||
<action>Guide MVP scoping based on their maturity
|
||||
|
||||
For experimental/hobby:
|
||||
|
||||
- "What's the ONE thing this must do to be useful?"
|
||||
- "What would make a fun first version?"
|
||||
- Embrace simplicity
|
||||
|
||||
For business ventures:
|
||||
|
||||
- "What's the smallest version that proves your hypothesis?"
|
||||
- "What features would make early adopters say 'good enough'?"
|
||||
- "What's tempting to add but would slow you down?"
|
||||
- Be ruthless about scope creep
|
||||
|
||||
For enterprise:
|
||||
|
||||
- "What's the pilot scope that demonstrates value?"
|
||||
- "Which capabilities are must-have for initial rollout?"
|
||||
- "What can we defer to Phase 2?"
|
||||
|
||||
Use this framing:
|
||||
|
||||
- Core features: "Without this, the product doesn't work"
|
||||
- Nice-to-have: "This would be great, but we can launch without it"
|
||||
- Future vision: "This is where we're headed eventually"
|
||||
|
||||
Challenge feature creep:
|
||||
|
||||
- "Do we need that for launch, or could it come later?"
|
||||
- "What if we started without that - what breaks?"
|
||||
- "Is this core to proving the concept?"</action>
|
||||
|
||||
<template-output>core_features</template-output>
|
||||
|
||||
<check if="scope creep discussed">
|
||||
<template-output>out_of_scope</template-output>
|
||||
</check>
|
||||
|
||||
<check if="future features mentioned">
|
||||
<template-output>future_vision_features</template-output>
|
||||
</check>
|
||||
|
||||
<check if="success criteria for MVP mentioned">
|
||||
<template-output>mvp_success_criteria</template-output>
|
||||
</check>
|
||||
</step>
|
||||
|
||||
<step n="7" goal="Explore relevant context dimensions" repeat="until-natural-end">
|
||||
<critical>Only explore what emerges naturally - skip what doesn't matter</critical>
|
||||
|
||||
<action>Based on the conversation so far, selectively explore:
|
||||
|
||||
IF financial aspects emerged:
|
||||
|
||||
- Development investment needed
|
||||
- Revenue potential or cost savings
|
||||
- ROI timeline
|
||||
- Budget constraints
|
||||
<check if="discussed">
|
||||
<template-output>financial_considerations</template-output>
|
||||
</check>
|
||||
|
||||
IF market competition mentioned:
|
||||
|
||||
- Competitive landscape
|
||||
- Market opportunity size
|
||||
- Differentiation strategy
|
||||
- Market timing
|
||||
<check if="discussed">
|
||||
<WebSearch>{{market}} size trends 2024</WebSearch>
|
||||
<template-output>market_analysis</template-output>
|
||||
</check>
|
||||
|
||||
IF technical preferences surfaced:
|
||||
|
||||
- Platform choices (web/mobile/desktop)
|
||||
- Technology stack preferences
|
||||
- Integration needs
|
||||
- Performance requirements
|
||||
<check if="discussed">
|
||||
<template-output>technical_preferences</template-output>
|
||||
</check>
|
||||
|
||||
IF organizational context emerged:
|
||||
|
||||
- Strategic alignment
|
||||
- Stakeholder buy-in needs
|
||||
- Change management considerations
|
||||
- Compliance requirements
|
||||
<check if="discussed">
|
||||
<template-output>organizational_context</template-output>
|
||||
</check>
|
||||
|
||||
IF risks or concerns raised:
|
||||
|
||||
- Key risks and mitigation
|
||||
- Critical assumptions
|
||||
- Open questions needing research
|
||||
<check if="discussed">
|
||||
<template-output>risks_and_assumptions</template-output>
|
||||
</check>
|
||||
|
||||
IF timeline pressures mentioned:
|
||||
|
||||
- Launch timeline
|
||||
- Critical milestones
|
||||
- Dependencies
|
||||
<check if="discussed">
|
||||
<template-output>timeline_constraints</template-output>
|
||||
</check>
|
||||
|
||||
Skip anything that hasn't naturally emerged
|
||||
Don't force sections that don't fit their context</action>
|
||||
</step>
|
||||
|
||||
<step n="8" goal="Refine and complete the living document">
|
||||
<action>Review what's been captured with the user
|
||||
|
||||
"Let me show you what we've built together..."
|
||||
|
||||
Present the actual document sections created so far
|
||||
|
||||
- Not a summary, but the real content
|
||||
- Shows the document has been growing throughout
|
||||
|
||||
Ask:
|
||||
"Looking at this, what stands out as most important to you?"
|
||||
"Is there anything critical we haven't explored?"
|
||||
"Does this capture your vision?"
|
||||
|
||||
Based on their response:
|
||||
|
||||
- Refine sections that need more depth
|
||||
- Add any missing critical elements
|
||||
- Remove or simplify sections that don't matter
|
||||
- Ensure the document fits THEIR needs, not a template</action>
|
||||
|
||||
<action>Make final refinements based on feedback</action>
|
||||
<template-output>final_refinements</template-output>
|
||||
|
||||
<action>Create executive summary that captures the essence</action>
|
||||
<template-output>executive_summary</template-output>
|
||||
</step>
|
||||
<step n="9" goal="Complete and save the product brief">
|
||||
<action>The document has been building throughout our conversation
|
||||
Now ensure it's complete and well-organized</action>
|
||||
|
||||
<check if="research documents were provided">
|
||||
<action>Append summary of incorporated research</action>
|
||||
<template-output>supporting_materials</template-output>
|
||||
</check>
|
||||
|
||||
<action>Ensure the document structure makes sense for what was discovered:
|
||||
|
||||
- Hobbyist projects might be 2-3 pages focused on problem/solution/features
|
||||
- Startup ventures might be 5-7 pages with market analysis and metrics
|
||||
- Enterprise briefs might be 10+ pages with full strategic context
|
||||
|
||||
The document should reflect their world, not force their world into a template</action>
|
||||
|
||||
<ask>Your product brief is ready! Would you like to:
|
||||
|
||||
1. Review specific sections together
|
||||
2. Make any final adjustments
|
||||
3. Save and move forward
|
||||
|
||||
What feels right?</ask>
|
||||
|
||||
<action>Make any requested refinements</action>
|
||||
<template-output>final_document</template-output>
|
||||
</step>
|
||||
|
||||
<step n="16" goal="Update status file on completion" tag="workflow-status">
|
||||
<check if="standalone_mode != true">
|
||||
<action>Load the FULL file: {output_folder}/bmm-workflow-status.yaml</action>
|
||||
<action>Find workflow_status key "product-brief"</action>
|
||||
|
|
@ -299,34 +484,23 @@ This brief will serve as the primary input for creating the Product Requirements
|
|||
|
||||
<output>**✅ Product Brief Complete, {user_name}!**
|
||||
|
||||
**Brief Document:**
|
||||
Your product vision has been captured in a document that reflects what matters most for your {{context_type}} project.
|
||||
|
||||
- Product brief saved to {output_folder}/bmm-product-brief-{{project_name}}-{{date}}.md
|
||||
**Document saved:** {output_folder}/bmm-product-brief-{{project_name}}-{{date}}.md
|
||||
|
||||
{{#if standalone_mode != true}}
|
||||
**Status Updated:**
|
||||
**What's next:** {{next_workflow}} ({{next_agent}} agent)
|
||||
|
||||
- Progress tracking updated: product-brief marked complete
|
||||
- Next workflow: {{next_workflow}}
|
||||
{{else}}
|
||||
**Note:** Running in standalone mode (no progress tracking)
|
||||
{{/if}}
|
||||
|
||||
**Next Steps:**
|
||||
|
||||
{{#if standalone_mode != true}}
|
||||
|
||||
- **Next workflow:** {{next_workflow}} ({{next_agent}} agent)
|
||||
- **Optional:** Gather additional stakeholder input or run research workflows before proceeding
|
||||
|
||||
Check status anytime with: `workflow-status`
|
||||
The next phase will take your brief and create the detailed planning artifacts needed for implementation.
|
||||
{{else}}
|
||||
Since no workflow is in progress:
|
||||
**Next steps:**
|
||||
|
||||
- Refer to the BMM workflow guide if unsure what to do next
|
||||
- Or run `workflow-init` to create a workflow path and get guided next steps
|
||||
- Run `workflow-init` to set up guided workflow tracking
|
||||
- Or proceed directly to the PRD workflow if you know your path
|
||||
{{/if}}
|
||||
</output>
|
||||
</step>
|
||||
|
||||
Remember: This brief captures YOUR vision. It grew from our conversation, not from a rigid template. It's ready to guide the next phase of bringing your idea to life.
|
||||
</output>
|
||||
</step>
|
||||
|
||||
</workflow>
|
||||
|
|
|
|||
|
|
@ -2,7 +2,7 @@
|
|||
|
||||
**Date:** {{date}}
|
||||
**Author:** {{user_name}}
|
||||
**Status:** Draft for PM Review
|
||||
**Context:** {{context_type}}
|
||||
|
||||
---
|
||||
|
||||
|
|
@ -12,154 +12,170 @@
|
|||
|
||||
---
|
||||
|
||||
## Problem Statement
|
||||
## Core Vision
|
||||
|
||||
### Problem Statement
|
||||
|
||||
{{problem_statement}}
|
||||
|
||||
---
|
||||
{{#if problem_impact}}
|
||||
|
||||
## Proposed Solution
|
||||
### Problem Impact
|
||||
|
||||
{{problem_impact}}
|
||||
{{/if}}
|
||||
|
||||
{{#if existing_solutions_gaps}}
|
||||
|
||||
### Why Existing Solutions Fall Short
|
||||
|
||||
{{existing_solutions_gaps}}
|
||||
{{/if}}
|
||||
|
||||
### Proposed Solution
|
||||
|
||||
{{proposed_solution}}
|
||||
|
||||
{{#if key_differentiators}}
|
||||
|
||||
### Key Differentiators
|
||||
|
||||
{{key_differentiators}}
|
||||
{{/if}}
|
||||
|
||||
---
|
||||
|
||||
## Target Users
|
||||
|
||||
### Primary User Segment
|
||||
### Primary Users
|
||||
|
||||
{{primary_user_segment}}
|
||||
|
||||
### Secondary User Segment
|
||||
{{#if secondary_user_segment}}
|
||||
|
||||
### Secondary Users
|
||||
|
||||
{{secondary_user_segment}}
|
||||
{{/if}}
|
||||
|
||||
{{#if user_journey}}
|
||||
|
||||
### User Journey
|
||||
|
||||
{{user_journey}}
|
||||
{{/if}}
|
||||
|
||||
---
|
||||
|
||||
## Goals and Success Metrics
|
||||
{{#if success_metrics}}
|
||||
|
||||
## Success Metrics
|
||||
|
||||
{{success_metrics}}
|
||||
|
||||
{{#if business_objectives}}
|
||||
|
||||
### Business Objectives
|
||||
|
||||
{{business_objectives}}
|
||||
{{/if}}
|
||||
|
||||
### User Success Metrics
|
||||
{{#if key_performance_indicators}}
|
||||
|
||||
{{user_success_metrics}}
|
||||
|
||||
### Key Performance Indicators (KPIs)
|
||||
### Key Performance Indicators
|
||||
|
||||
{{key_performance_indicators}}
|
||||
|
||||
---
|
||||
|
||||
## Strategic Alignment and Financial Impact
|
||||
|
||||
### Financial Impact
|
||||
|
||||
{{financial_impact}}
|
||||
|
||||
### Company Objectives Alignment
|
||||
|
||||
{{company_objectives_alignment}}
|
||||
|
||||
### Strategic Initiatives
|
||||
|
||||
{{strategic_initiatives}}
|
||||
{{/if}}
|
||||
{{/if}}
|
||||
|
||||
---
|
||||
|
||||
## MVP Scope
|
||||
|
||||
### Core Features (Must Have)
|
||||
### Core Features
|
||||
|
||||
{{core_features}}
|
||||
|
||||
{{#if out_of_scope}}
|
||||
|
||||
### Out of Scope for MVP
|
||||
|
||||
{{out_of_scope}}
|
||||
{{/if}}
|
||||
|
||||
{{#if mvp_success_criteria}}
|
||||
|
||||
### MVP Success Criteria
|
||||
|
||||
{{mvp_success_criteria}}
|
||||
{{/if}}
|
||||
|
||||
{{#if future_vision_features}}
|
||||
|
||||
### Future Vision
|
||||
|
||||
{{future_vision_features}}
|
||||
{{/if}}
|
||||
|
||||
---
|
||||
|
||||
## Post-MVP Vision
|
||||
{{#if market_analysis}}
|
||||
|
||||
### Phase 2 Features
|
||||
## Market Context
|
||||
|
||||
{{phase_2_features}}
|
||||
{{market_analysis}}
|
||||
{{/if}}
|
||||
|
||||
### Long-term Vision
|
||||
{{#if financial_considerations}}
|
||||
|
||||
{{long_term_vision}}
|
||||
## Financial Considerations
|
||||
|
||||
### Expansion Opportunities
|
||||
{{financial_considerations}}
|
||||
{{/if}}
|
||||
|
||||
{{expansion_opportunities}}
|
||||
{{#if technical_preferences}}
|
||||
|
||||
## Technical Preferences
|
||||
|
||||
{{technical_preferences}}
|
||||
{{/if}}
|
||||
|
||||
{{#if organizational_context}}
|
||||
|
||||
## Organizational Context
|
||||
|
||||
{{organizational_context}}
|
||||
{{/if}}
|
||||
|
||||
{{#if risks_and_assumptions}}
|
||||
|
||||
## Risks and Assumptions
|
||||
|
||||
{{risks_and_assumptions}}
|
||||
{{/if}}
|
||||
|
||||
{{#if timeline_constraints}}
|
||||
|
||||
## Timeline
|
||||
|
||||
{{timeline_constraints}}
|
||||
{{/if}}
|
||||
|
||||
{{#if supporting_materials}}
|
||||
|
||||
## Supporting Materials
|
||||
|
||||
{{supporting_materials}}
|
||||
{{/if}}
|
||||
|
||||
---
|
||||
|
||||
## Technical Considerations
|
||||
_This Product Brief captures the vision and requirements for {{project_name}}._
|
||||
|
||||
### Platform Requirements
|
||||
_It was created through collaborative discovery and reflects the unique needs of this {{context_type}} project._
|
||||
|
||||
{{platform_requirements}}
|
||||
|
||||
### Technology Preferences
|
||||
|
||||
{{technology_preferences}}
|
||||
|
||||
### Architecture Considerations
|
||||
|
||||
{{architecture_considerations}}
|
||||
|
||||
---
|
||||
|
||||
## Constraints and Assumptions
|
||||
|
||||
### Constraints
|
||||
|
||||
{{constraints}}
|
||||
|
||||
### Key Assumptions
|
||||
|
||||
{{key_assumptions}}
|
||||
|
||||
---
|
||||
|
||||
## Risks and Open Questions
|
||||
|
||||
### Key Risks
|
||||
|
||||
{{key_risks}}
|
||||
|
||||
### Open Questions
|
||||
|
||||
{{open_questions}}
|
||||
|
||||
### Areas Needing Further Research
|
||||
|
||||
{{research_areas}}
|
||||
|
||||
---
|
||||
|
||||
## Appendices
|
||||
|
||||
### A. Research Summary
|
||||
|
||||
{{research_summary}}
|
||||
|
||||
### B. Stakeholder Input
|
||||
|
||||
{{stakeholder_input}}
|
||||
|
||||
### C. References
|
||||
|
||||
{{references}}
|
||||
|
||||
---
|
||||
|
||||
_This Product Brief serves as the foundational input for Product Requirements Document (PRD) creation._
|
||||
|
||||
_Next Steps: Handoff to Product Manager for PRD development using the `workflow prd` command._
|
||||
{{#if next_workflow}}
|
||||
_Next: {{next_workflow}} will transform this brief into detailed planning artifacts._
|
||||
{{else}}
|
||||
_Next: Use the PRD workflow to create detailed product requirements from this brief._
|
||||
{{/if}}
|
||||
|
|
|
|||
|
|
@ -1,117 +1,349 @@
|
|||
# PRD Workflow Validation Checklist
|
||||
# PRD + Epics + Stories Validation Checklist
|
||||
|
||||
**Purpose**: Validate PRD workflow outputs are complete, consistent, and ready for next phase.
|
||||
**Purpose**: Comprehensive validation that PRD, epics, and stories form a complete, implementable product plan.
|
||||
|
||||
**Scope**: Levels 2-4 software projects
|
||||
**Scope**: Validates the complete planning output (PRD.md + epics.md) for Levels 2-4 software projects
|
||||
|
||||
**Expected Outputs**: PRD.md, epics.md, updated bmm-workflow-status.md
|
||||
**Expected Outputs**:
|
||||
|
||||
- PRD.md with complete requirements
|
||||
- epics.md with detailed epic and story breakdown
|
||||
- Updated bmm-workflow-status.yaml
|
||||
|
||||
---
|
||||
|
||||
## 1. Output Files Exist
|
||||
## 1. PRD Document Completeness
|
||||
|
||||
- [ ] PRD.md created in output folder
|
||||
- [ ] epics.md created in output folder (separate file)
|
||||
- [ ] bmm-workflow-status.md updated
|
||||
- [ ] No unfilled {{template_variables}}
|
||||
### Core Sections Present
|
||||
|
||||
- [ ] Executive Summary with vision alignment
|
||||
- [ ] Product magic essence clearly articulated
|
||||
- [ ] Project classification (type, domain, complexity)
|
||||
- [ ] Success criteria defined
|
||||
- [ ] Product scope (MVP, Growth, Vision) clearly delineated
|
||||
- [ ] Functional requirements comprehensive and numbered
|
||||
- [ ] Non-functional requirements (when applicable)
|
||||
- [ ] References section with source documents
|
||||
|
||||
### Project-Specific Sections
|
||||
|
||||
- [ ] **If complex domain:** Domain context and considerations documented
|
||||
- [ ] **If innovation:** Innovation patterns and validation approach documented
|
||||
- [ ] **If API/Backend:** Endpoint specification and authentication model included
|
||||
- [ ] **If Mobile:** Platform requirements and device features documented
|
||||
- [ ] **If SaaS B2B:** Tenant model and permission matrix included
|
||||
- [ ] **If UI exists:** UX principles and key interactions documented
|
||||
|
||||
### Quality Checks
|
||||
|
||||
- [ ] No unfilled template variables ({{variable}})
|
||||
- [ ] All variables properly populated with meaningful content
|
||||
- [ ] Product magic woven throughout (not just stated once)
|
||||
- [ ] Language is clear, specific, and measurable
|
||||
- [ ] Project type correctly identified and sections match
|
||||
- [ ] Domain complexity appropriately addressed
|
||||
|
||||
---
|
||||
|
||||
## 2. PRD.md Core Quality
|
||||
## 2. Functional Requirements Quality
|
||||
|
||||
### Requirements Coverage
|
||||
### FR Format and Structure
|
||||
|
||||
- [ ] Functional requirements describe WHAT capabilities (not HOW to implement)
|
||||
- [ ] Each FR has unique identifier (FR001, FR002, etc.)
|
||||
- [ ] Non-functional requirements (if any) have business justification
|
||||
- [ ] Requirements are testable and verifiable
|
||||
- [ ] Each FR has unique identifier (FR-001, FR-002, etc.)
|
||||
- [ ] FRs describe WHAT capabilities, not HOW to implement
|
||||
- [ ] FRs are specific and measurable
|
||||
- [ ] FRs are testable and verifiable
|
||||
- [ ] FRs focus on user/business value
|
||||
- [ ] No technical implementation details in FRs (those belong in architecture)
|
||||
|
||||
### User Journeys
|
||||
### FR Completeness
|
||||
|
||||
- [ ] User journeys reference specific FR numbers
|
||||
- [ ] Journeys show complete user paths through system
|
||||
- [ ] Success outcomes are clear
|
||||
- [ ] All MVP scope features have corresponding FRs
|
||||
- [ ] Growth features documented (even if deferred)
|
||||
- [ ] Vision features captured for future reference
|
||||
- [ ] Domain-mandated requirements included
|
||||
- [ ] Innovation requirements captured with validation needs
|
||||
- [ ] Project-type specific requirements complete
|
||||
|
||||
### Strategic Focus
|
||||
### FR Organization
|
||||
|
||||
- [ ] PRD focuses on WHAT and WHY (not technical HOW)
|
||||
- [ ] No specific technology choices in PRD (those belong in technical-decisions.md)
|
||||
- [ ] Goals are outcome-focused, not implementation-focused
|
||||
- [ ] FRs organized by capability/feature area (not by tech stack)
|
||||
- [ ] Related FRs grouped logically
|
||||
- [ ] Dependencies between FRs noted when critical
|
||||
- [ ] Priority/phase indicated (MVP vs Growth vs Vision)
|
||||
|
||||
---
|
||||
|
||||
## 3. epics.md Story Quality
|
||||
## 3. Epics Document Completeness
|
||||
|
||||
### Story Format
|
||||
### Required Files
|
||||
|
||||
- [ ] All stories follow user story format: "As a [role], I want [capability], so that [benefit]"
|
||||
- [ ] Each story has numbered acceptance criteria
|
||||
- [ ] Prerequisites/dependencies explicitly stated
|
||||
|
||||
### Story Sequencing (CRITICAL)
|
||||
|
||||
- [ ] **Epic 1 establishes foundation** (infrastructure, initial deployable functionality)
|
||||
- Exception noted if adding to existing app
|
||||
- [ ] **Vertical slices**: Each story delivers complete, testable functionality (not horizontal layers)
|
||||
- [ ] **No forward dependencies**: No story depends on work from a LATER story or epic
|
||||
- [ ] Stories are sequentially ordered within each epic
|
||||
- [ ] Each story leaves system in working state
|
||||
|
||||
### Coverage
|
||||
|
||||
- [ ] All FRs from PRD.md are covered by stories in epics.md
|
||||
- [ ] epics.md exists in output folder
|
||||
- [ ] Epic list in PRD.md matches epics in epics.md (titles and count)
|
||||
- [ ] All epics have detailed breakdown sections
|
||||
|
||||
### Epic Quality
|
||||
|
||||
- [ ] Each epic has clear goal and value proposition
|
||||
- [ ] Each epic includes complete story breakdown
|
||||
- [ ] Stories follow proper user story format: "As a [role], I want [goal], so that [benefit]"
|
||||
- [ ] Each story has numbered acceptance criteria
|
||||
- [ ] Prerequisites/dependencies explicitly stated per story
|
||||
- [ ] Stories are AI-agent sized (completable in 2-4 hour session)
|
||||
|
||||
---
|
||||
|
||||
## 4. Cross-Document Consistency
|
||||
## 4. FR Coverage Validation (CRITICAL)
|
||||
|
||||
- [ ] Epic titles consistent between PRD.md and epics.md
|
||||
- [ ] FR references in user journeys exist in requirements section
|
||||
- [ ] Terminology consistent across documents
|
||||
### Complete Traceability
|
||||
|
||||
- [ ] **Every FR from PRD.md is covered by at least one story in epics.md**
|
||||
- [ ] Each story references relevant FR numbers
|
||||
- [ ] No orphaned FRs (requirements without stories)
|
||||
- [ ] No orphaned stories (stories without FR connection)
|
||||
- [ ] Coverage matrix verified (can trace FR → Epic → Stories)
|
||||
|
||||
### Coverage Quality
|
||||
|
||||
- [ ] Stories sufficiently decompose FRs into implementable units
|
||||
- [ ] Complex FRs broken into multiple stories appropriately
|
||||
- [ ] Simple FRs have appropriately scoped single stories
|
||||
- [ ] Non-functional requirements reflected in story acceptance criteria
|
||||
- [ ] Domain requirements embedded in relevant stories
|
||||
|
||||
---
|
||||
|
||||
## 5. Story Sequencing Validation (CRITICAL)
|
||||
|
||||
### Epic 1 Foundation Check
|
||||
|
||||
- [ ] **Epic 1 establishes foundational infrastructure**
|
||||
- [ ] Epic 1 delivers initial deployable functionality
|
||||
- [ ] Epic 1 creates baseline for subsequent epics
|
||||
- [ ] Exception: If adding to existing app, foundation requirement adapted appropriately
|
||||
|
||||
### Vertical Slicing
|
||||
|
||||
- [ ] **Each story delivers complete, testable functionality** (not horizontal layers)
|
||||
- [ ] No "build database" or "create UI" stories in isolation
|
||||
- [ ] Stories integrate across stack (data + logic + presentation when applicable)
|
||||
- [ ] Each story leaves system in working/deployable state
|
||||
|
||||
### No Forward Dependencies
|
||||
|
||||
- [ ] **No story depends on work from a LATER story or epic**
|
||||
- [ ] Stories within each epic are sequentially ordered
|
||||
- [ ] Each story builds only on previous work
|
||||
- [ ] Dependencies flow backward only (can reference earlier stories)
|
||||
- [ ] Parallel tracks clearly indicated if stories are independent
|
||||
|
||||
### Value Delivery Path
|
||||
|
||||
- [ ] Each epic delivers significant end-to-end value
|
||||
- [ ] Epic sequence shows logical product evolution
|
||||
- [ ] User can see value after each epic completion
|
||||
- [ ] MVP scope clearly achieved by end of designated epics
|
||||
|
||||
---
|
||||
|
||||
## 6. Scope Management
|
||||
|
||||
### MVP Discipline
|
||||
|
||||
- [ ] MVP scope is genuinely minimal and viable
|
||||
- [ ] Core features list contains only true must-haves
|
||||
- [ ] Each MVP feature has clear rationale for inclusion
|
||||
- [ ] No obvious scope creep in "must-have" list
|
||||
|
||||
### Future Work Captured
|
||||
|
||||
- [ ] Growth features documented for post-MVP
|
||||
- [ ] Vision features captured to maintain long-term direction
|
||||
- [ ] Out-of-scope items explicitly listed
|
||||
- [ ] Deferred features have clear reasoning for deferral
|
||||
|
||||
### Clear Boundaries
|
||||
|
||||
- [ ] Stories marked as MVP vs Growth vs Vision
|
||||
- [ ] Epic sequencing aligns with MVP → Growth progression
|
||||
- [ ] No confusion about what's in vs out of initial scope
|
||||
|
||||
---
|
||||
|
||||
## 7. Research and Context Integration
|
||||
|
||||
### Source Document Integration
|
||||
|
||||
- [ ] **If product brief exists:** Key insights incorporated into PRD
|
||||
- [ ] **If domain brief exists:** Domain requirements reflected in FRs and stories
|
||||
- [ ] **If research documents exist:** Research findings inform requirements
|
||||
- [ ] **If competitive analysis exists:** Differentiation strategy clear in PRD
|
||||
- [ ] All source documents referenced in PRD References section
|
||||
|
||||
### Research Continuity to Architecture
|
||||
|
||||
- [ ] Domain complexity considerations documented for architects
|
||||
- [ ] Technical constraints from research captured
|
||||
- [ ] Regulatory/compliance requirements clearly stated
|
||||
- [ ] Integration requirements with existing systems documented
|
||||
- [ ] Performance/scale requirements informed by research data
|
||||
|
||||
### Information Completeness for Next Phase
|
||||
|
||||
- [ ] PRD provides sufficient context for architecture decisions
|
||||
- [ ] Epics provide sufficient detail for technical design
|
||||
- [ ] Stories have enough acceptance criteria for implementation
|
||||
- [ ] Non-obvious business rules documented
|
||||
- [ ] Edge cases and special scenarios captured
|
||||
|
||||
---
|
||||
|
||||
## 8. Cross-Document Consistency
|
||||
|
||||
### Terminology Consistency
|
||||
|
||||
- [ ] Same terms used across PRD and epics for concepts
|
||||
- [ ] Feature names consistent between documents
|
||||
- [ ] Epic titles match between PRD and epics.md
|
||||
- [ ] No contradictions between PRD and epics
|
||||
|
||||
---
|
||||
### Alignment Checks
|
||||
|
||||
## 5. Readiness for Next Phase
|
||||
|
||||
**Adapt based on project level from bmm-workflow-status.md:**
|
||||
|
||||
### If Level 2:
|
||||
|
||||
- [ ] PRD provides sufficient context for tech-spec workflow (lightweight solutioning)
|
||||
- [ ] Epic structure supports 5-15 story implementation scope
|
||||
|
||||
### If Level 3-4:
|
||||
|
||||
- [ ] PRD provides sufficient context for create-architecture workflow
|
||||
- [ ] Epic structure supports phased delivery approach
|
||||
- [ ] Clear value delivery path through epic sequence
|
||||
- [ ] Success metrics in PRD align with story outcomes
|
||||
- [ ] Product magic articulated in PRD reflected in epic goals
|
||||
- [ ] Technical preferences in PRD align with story implementation hints
|
||||
- [ ] Scope boundaries consistent across all documents
|
||||
|
||||
---
|
||||
|
||||
## 6. Critical Failures (Auto-Fail)
|
||||
## 9. Readiness for Implementation
|
||||
|
||||
- [ ] ❌ **No epics.md file** (two-file output is required)
|
||||
- [ ] ❌ **Epic 1 doesn't establish foundation** (violates core principle)
|
||||
- [ ] ❌ **Stories have forward dependencies** (would break sequential implementation)
|
||||
### Architecture Readiness (Next Phase)
|
||||
|
||||
- [ ] PRD provides sufficient context for architecture workflow
|
||||
- [ ] Technical constraints and preferences documented
|
||||
- [ ] Integration points identified
|
||||
- [ ] Performance/scale requirements specified
|
||||
- [ ] Security and compliance needs clear
|
||||
|
||||
### Development Readiness
|
||||
|
||||
- [ ] Stories are specific enough to estimate
|
||||
- [ ] Acceptance criteria are testable
|
||||
- [ ] Technical unknowns identified and flagged
|
||||
- [ ] Dependencies on external systems documented
|
||||
- [ ] Data requirements specified
|
||||
|
||||
### Level-Appropriate Detail
|
||||
|
||||
**If Level 2:**
|
||||
|
||||
- [ ] PRD supports lightweight tech-spec workflow
|
||||
- [ ] 5-15 story scope reasonable for project size
|
||||
- [ ] Complexity appropriate for small team/solo dev
|
||||
|
||||
**If Level 3-4:**
|
||||
|
||||
- [ ] PRD supports full architecture workflow
|
||||
- [ ] Epic structure supports phased delivery
|
||||
- [ ] Scope appropriate for team-based development
|
||||
- [ ] Clear value delivery through epic sequence
|
||||
|
||||
---
|
||||
|
||||
## 10. Quality and Polish
|
||||
|
||||
### Writing Quality
|
||||
|
||||
- [ ] Language is clear and free of jargon (or jargon is defined)
|
||||
- [ ] Sentences are concise and specific
|
||||
- [ ] No vague statements ("should be fast", "user-friendly")
|
||||
- [ ] Measurable criteria used throughout
|
||||
- [ ] Professional tone appropriate for stakeholder review
|
||||
|
||||
### Document Structure
|
||||
|
||||
- [ ] Sections flow logically
|
||||
- [ ] Headers and numbering consistent
|
||||
- [ ] Cross-references accurate (FR numbers, section references)
|
||||
- [ ] Formatting consistent throughout
|
||||
- [ ] Tables/lists formatted properly
|
||||
|
||||
### Completeness Indicators
|
||||
|
||||
- [ ] No [TODO] or [TBD] markers remain
|
||||
- [ ] No placeholder text
|
||||
- [ ] All sections have substantive content
|
||||
- [ ] Optional sections either complete or omitted (not half-done)
|
||||
|
||||
---
|
||||
|
||||
## Critical Failures (Auto-Fail)
|
||||
|
||||
If ANY of these are true, validation FAILS:
|
||||
|
||||
- [ ] ❌ **No epics.md file exists** (two-file output required)
|
||||
- [ ] ❌ **Epic 1 doesn't establish foundation** (violates core sequencing principle)
|
||||
- [ ] ❌ **Stories have forward dependencies** (breaks sequential implementation)
|
||||
- [ ] ❌ **Stories not vertically sliced** (horizontal layers block value delivery)
|
||||
- [ ] ❌ **Technical decisions in PRD** (should be in technical-decisions.md)
|
||||
- [ ] ❌ **Epics don't cover all FRs** (orphaned requirements)
|
||||
- [ ] ❌ **User journeys don't reference FR numbers** (missing traceability)
|
||||
- [ ] ❌ **FRs contain technical implementation details** (should be in architecture)
|
||||
- [ ] ❌ **No FR traceability to stories** (can't validate coverage)
|
||||
- [ ] ❌ **Template variables unfilled** (incomplete document)
|
||||
|
||||
---
|
||||
|
||||
## Validation Notes
|
||||
## Validation Summary
|
||||
|
||||
**Document any findings:**
|
||||
**Total Validation Points:** ~85
|
||||
|
||||
- Strengths:
|
||||
- Issues to address:
|
||||
- Recommended actions:
|
||||
### Scoring Guide
|
||||
|
||||
**Ready for next phase?** [Yes / No - explain]
|
||||
- **Pass Rate ≥ 95% (81+/85):** ✅ EXCELLENT - Ready for architecture phase
|
||||
- **Pass Rate 85-94% (72-80/85):** ⚠️ GOOD - Minor fixes needed
|
||||
- **Pass Rate 70-84% (60-71/85):** ⚠️ FAIR - Important issues to address
|
||||
- **Pass Rate < 70% (<60/85):** ❌ POOR - Significant rework required
|
||||
|
||||
### Critical Issue Threshold
|
||||
|
||||
- **0 Critical Failures:** Proceed to fixes
|
||||
- **1+ Critical Failures:** STOP - Must fix critical issues first
|
||||
|
||||
---
|
||||
|
||||
_Adapt this checklist based on actual outputs. Not all sections may apply to every project._
|
||||
## Validation Execution Notes
|
||||
|
||||
**When validating:**
|
||||
|
||||
1. **Load ALL documents:**
|
||||
- PRD.md (required)
|
||||
- epics.md (required)
|
||||
- product-brief.md (if exists)
|
||||
- domain-brief.md (if exists)
|
||||
- research documents (if referenced)
|
||||
|
||||
2. **Validate in order:**
|
||||
- Check critical failures first (immediate stop if any found)
|
||||
- Verify PRD completeness
|
||||
- Verify epics completeness
|
||||
- Cross-reference FR coverage (most important)
|
||||
- Check sequencing (second most important)
|
||||
- Validate research integration
|
||||
- Check polish and quality
|
||||
|
||||
3. **Report findings:**
|
||||
- List critical failures prominently
|
||||
- Group issues by severity
|
||||
- Provide specific line numbers/sections
|
||||
- Suggest concrete fixes
|
||||
- Highlight what's working well
|
||||
|
||||
4. **Provide actionable next steps:**
|
||||
- If validation passes: "Ready for architecture workflow"
|
||||
- If minor issues: "Fix [X] items then re-validate"
|
||||
- If major issues: "Rework [sections] then re-validate"
|
||||
- If critical failures: "Must fix critical items before proceeding"
|
||||
|
||||
---
|
||||
|
||||
**Remember:** This validation ensures the entire planning phase is complete and the implementation phase has everything needed to succeed. Be thorough but fair - the goal is quality, not perfection.
|
||||
|
|
|
|||
|
|
@ -0,0 +1,395 @@
|
|||
# Epic and Story Decomposition - Bite-Sized Implementation Planning
|
||||
|
||||
<critical>The workflow execution engine is governed by: {project-root}/bmad/core/tasks/workflow.xml</critical>
|
||||
<critical>You MUST have already loaded and processed: {installed_path}/workflow.yaml</critical>
|
||||
<critical>This workflow transforms requirements into BITE-SIZED STORIES for limited context agents</critical>
|
||||
<critical>EVERY story must be completable by a single limited context window dev agent in one session</critical>
|
||||
<critical>Communicate all responses in {communication_language} and adapt deeply to {user_skill_level}</critical>
|
||||
<critical>Generate all documents in {document_output_language}</critical>
|
||||
<critical>LIVING DOCUMENT: Write to epics.md continuously as you work - never wait until the end</critical>
|
||||
|
||||
<workflow>
|
||||
|
||||
<step n="0" goal="Load context and requirements">
|
||||
<action>Welcome the {user_name} to the project inception high level epic and story planning.
|
||||
|
||||
Load required documents:
|
||||
|
||||
1. PRD.md (must exist - fuzzy match on name, might be a folder with an index and smaller sharded files also)
|
||||
2. domain-brief.md (if exists)
|
||||
3. product-brief.md (if exists)
|
||||
|
||||
Extract from PRD:
|
||||
|
||||
- Functional requirements
|
||||
- Non-functional requirements
|
||||
- Domain considerations
|
||||
- Project type
|
||||
- MVP scope vs growth features
|
||||
|
||||
If continuing from PRD workflow:
|
||||
"Great! Now let's break down your requirements into actionable epics and bite-sized stories that development agents can implement independently."
|
||||
|
||||
If starting fresh:
|
||||
"I'll help you transform your PRD into organized epics with implementable stories. Each story will be small enough for a single dev agent to complete in one session."</action>
|
||||
</step>
|
||||
|
||||
<step n="1" goal="Form epics from natural groupings">
|
||||
<action>Transform requirements into epics organically
|
||||
|
||||
INTENT: Find natural boundaries that make sense for THIS product
|
||||
|
||||
Look at the requirements and find patterns:
|
||||
|
||||
- Features that work together
|
||||
- User journeys that connect
|
||||
- Technical systems that relate
|
||||
- Business capabilities that group
|
||||
- Domain requirements that cluster (compliance, validation, etc.)
|
||||
|
||||
Examples of natural epic formation:
|
||||
|
||||
- Auth features → "User Management" epic
|
||||
- Payment features → "Monetization" epic
|
||||
- Social features → "Community" epic
|
||||
- Admin features → "Administration" epic
|
||||
- Compliance requirements → "Regulatory Compliance" epic
|
||||
- API endpoints → "API Infrastructure" epic
|
||||
|
||||
But let the product guide you - don't force standard patterns
|
||||
|
||||
Each epic should:
|
||||
|
||||
- Have a clear business goal
|
||||
- Be independently valuable
|
||||
- Contain 3-8 related features
|
||||
- Be completable in 1-2 sprints
|
||||
|
||||
Name epics based on value, not technical components:
|
||||
GOOD: "User Onboarding", "Content Discovery", "Team Collaboration"
|
||||
NOT: "Database", "Frontend", "API"
|
||||
|
||||
If domain considerations exist:
|
||||
|
||||
- Create dedicated compliance/validation epics
|
||||
- Note special expertise needed per epic
|
||||
- Flag epics with regulatory dependencies
|
||||
|
||||
Present epic groupings conversationally:
|
||||
"Based on your requirements, I see these natural epic groupings:
|
||||
|
||||
1. [Epic Name] - [Brief description]
|
||||
2. [Epic Name] - [Brief description]
|
||||
3. [Epic Name] - [Brief description]
|
||||
|
||||
Does this organization make sense for how you think about the product?"</action>
|
||||
|
||||
<template-output>epics_structure</template-output>
|
||||
</step>
|
||||
|
||||
<step n="2" goal="Decompose into bite-sized stories">
|
||||
<critical>Small vertical sliced small stories are best for agentic dumb developers to implement without forgetting things</critical>
|
||||
|
||||
<action>Break each epic into small, implementable stories
|
||||
|
||||
INTENT: Create stories that one dev agent can complete independently
|
||||
|
||||
For each epic, decompose into stories that are:
|
||||
|
||||
- Small enough for single context window
|
||||
- Clear enough for autonomous implementation
|
||||
- Independent enough to develop in parallel when possible
|
||||
- Specific enough to have clear acceptance criteria
|
||||
|
||||
GOOD story examples:
|
||||
|
||||
- "Create login API endpoint that accepts email/password and returns JWT"
|
||||
- "Build user profile component with avatar upload to S3"
|
||||
- "Add password reset email template and sending logic"
|
||||
- "Implement rate limiting on auth endpoints (5 attempts per minute)"
|
||||
- "Create HIPAA-compliant audit log for patient data access"
|
||||
- "Build FDA 21 CFR Part 11 electronic signature component"
|
||||
|
||||
BAD story examples:
|
||||
|
||||
- "Build complete authentication system" (too big)
|
||||
- "Handle user management" (too vague)
|
||||
- "Make it secure" (not specific)
|
||||
- "Integrate everything" (requires multiple contexts)
|
||||
|
||||
Story format:
|
||||
"As a [user type], I want [specific feature], so that [clear value]"
|
||||
|
||||
Technical notes to include:
|
||||
|
||||
- Affected files/components if known
|
||||
- Required endpoints/methods
|
||||
- Data structures needed
|
||||
- Specific validation rules
|
||||
- Compliance requirements if applicable
|
||||
- Dependencies on other stories
|
||||
|
||||
Domain-aware story creation:
|
||||
|
||||
- For healthcare: Include specific regulations per story
|
||||
- For fintech: Note PCI/security requirements per story
|
||||
- For govtech: Flag accessibility needs per story
|
||||
- For aerospace: Include safety/validation requirements
|
||||
|
||||
Check each story:
|
||||
|
||||
- Can this be explained in <1000 words?
|
||||
- Can one agent complete without another's output?
|
||||
- Is the scope crystal clear?
|
||||
- Are success criteria obvious?
|
||||
- Are domain requirements specified?
|
||||
|
||||
If too big → split into smaller stories
|
||||
If too vague → add specifics
|
||||
If dependent → note the dependency clearly
|
||||
If domain-critical → flag compliance needs</action>
|
||||
|
||||
<template-output>epic_1_stories</template-output>
|
||||
<template-output>epic_2_stories</template-output>
|
||||
<template-output>epic_3_stories</template-output>
|
||||
|
||||
<!-- Continue for each epic discovered -->
|
||||
</step>
|
||||
|
||||
<step n="3" goal="Sequence for smart implementation">
|
||||
<action>Order stories for successful development
|
||||
|
||||
INTENT: Create a logical flow that minimizes blockers and maximizes progress
|
||||
|
||||
Consider dependencies:
|
||||
TECHNICAL:
|
||||
|
||||
- Authentication before protected features
|
||||
- Data models before business logic
|
||||
- Core features before enhancements
|
||||
- API before frontend that uses it
|
||||
|
||||
DOMAIN:
|
||||
|
||||
- Compliance infrastructure before features
|
||||
- Validation framework before clinical features
|
||||
- Audit logging before financial transactions
|
||||
- Safety systems before operational features
|
||||
|
||||
PRACTICAL:
|
||||
|
||||
- What gives visible progress early?
|
||||
- What reduces risk soonest?
|
||||
- What enables parallel work?
|
||||
- What delivers value fastest?
|
||||
|
||||
Create implementation phases:
|
||||
|
||||
Phase 1 - Foundation:
|
||||
|
||||
- Core data models
|
||||
- Authentication/authorization
|
||||
- Basic infrastructure
|
||||
- Essential APIs
|
||||
- Compliance foundation (if domain requires)
|
||||
|
||||
Phase 2 - Core Features:
|
||||
|
||||
- MVP functionality
|
||||
- Key user flows
|
||||
- Basic UI/UX
|
||||
- Critical integrations
|
||||
- Domain validations (if applicable)
|
||||
|
||||
Phase 3 - Enhancement:
|
||||
|
||||
- Polish and refinement
|
||||
- Additional features
|
||||
- Performance optimization
|
||||
- Extended functionality
|
||||
- Advanced compliance features
|
||||
|
||||
Phase 4 - Growth:
|
||||
|
||||
- Analytics and monitoring
|
||||
- Advanced features
|
||||
- Scaling preparations
|
||||
- Nice-to-have additions
|
||||
|
||||
For complex domains, add gates:
|
||||
|
||||
- "Gate: Security audit before payment processing"
|
||||
- "Gate: Clinical validation before patient features"
|
||||
- "Gate: Compliance review before launch"
|
||||
|
||||
Present the sequencing conversationally:
|
||||
"Here's a smart implementation order:
|
||||
|
||||
**Phase 1 (Foundation) - Week 1-2:**
|
||||
|
||||
- Story 1.1: [Description]
|
||||
- Story 1.2: [Description] (can parallel with 1.1)
|
||||
- Story 1.3: [Description] (depends on 1.1)
|
||||
|
||||
**Phase 2 (Core) - Week 3-4:**
|
||||
[Continue...]
|
||||
|
||||
This gives you something working by [milestone] and allows [X] stories to run in parallel."</action>
|
||||
|
||||
<template-output>implementation_sequence</template-output>
|
||||
<template-output>development_phases</template-output>
|
||||
<template-output>dependency_graph</template-output>
|
||||
</step>
|
||||
|
||||
<step n="4" goal="Validate story sizing and clarity">
|
||||
<action>Review all stories for dev agent compatibility
|
||||
|
||||
Run through each story and verify:
|
||||
|
||||
SIZE CHECK:
|
||||
|
||||
- Story description < 500 words
|
||||
- Clear inputs and outputs defined
|
||||
- Single responsibility principle
|
||||
- No hidden complexity
|
||||
|
||||
CLARITY CHECK:
|
||||
|
||||
- Acceptance criteria explicit
|
||||
- Technical approach clear
|
||||
- No ambiguous requirements
|
||||
- Success measurable
|
||||
|
||||
DEPENDENCY CHECK:
|
||||
|
||||
- Dependencies documented
|
||||
- Can start with clear inputs
|
||||
- Outputs well-defined
|
||||
- Parallel opportunities noted
|
||||
|
||||
DOMAIN CHECK (if applicable):
|
||||
|
||||
- Compliance requirements stated
|
||||
- Validation criteria defined
|
||||
- Regulatory references included
|
||||
- Special expertise noted
|
||||
|
||||
If any issues found:
|
||||
"Story [X] seems too large. Let me split it:
|
||||
|
||||
- [Smaller story 1]
|
||||
- [Smaller story 2]"
|
||||
|
||||
"Story [Y] needs clarification on [aspect]. How should we handle [specific question]?"
|
||||
|
||||
Final validation:
|
||||
"All stories are now sized for 200k context limits.
|
||||
|
||||
- Total stories: [count]
|
||||
- Can run in parallel: [count]
|
||||
- Sequential dependencies: [count]
|
||||
- Estimated completion: [timeframe]"</action>
|
||||
|
||||
<template-output>story_validation</template-output>
|
||||
</step>
|
||||
|
||||
<step n="5" goal="Create development guidance">
|
||||
<action>Add practical guidance for implementation teams
|
||||
|
||||
Create quick reference for development:
|
||||
|
||||
GETTING STARTED:
|
||||
"Start with Phase 1 stories - multiple can run in parallel.
|
||||
Key files to create first: [list]
|
||||
Recommended agent allocation: [suggestion]"
|
||||
|
||||
DOMAIN GUIDANCE (if applicable):
|
||||
"Critical compliance checkpoints:
|
||||
|
||||
- After story [X]: Run [validation]
|
||||
- Before story [Y]: Review [regulation]
|
||||
- Throughout: Maintain [audit trail]"
|
||||
|
||||
TECHNICAL NOTES:
|
||||
"Architecture decisions needed:
|
||||
|
||||
- [Decision 1] affects stories [A, B, C]
|
||||
- [Decision 2] blocks story [D]
|
||||
|
||||
Consider these patterns:
|
||||
|
||||
- [Pattern] for [epic]
|
||||
- [Pattern] for [requirement]"
|
||||
|
||||
RISK MITIGATION:
|
||||
"Watch out for:
|
||||
|
||||
- [Risk] in story [X]
|
||||
- [Complexity] in epic [Y]
|
||||
- [Dependency] between [A] and [B]"
|
||||
|
||||
SUCCESS METRICS:
|
||||
"You'll know Phase 1 is complete when:
|
||||
|
||||
- [Measurable outcome]
|
||||
- [Testable feature]
|
||||
- [Validation passed]"</action>
|
||||
|
||||
<template-output>implementation_guidance</template-output>
|
||||
</step>
|
||||
|
||||
<step n="6" goal="Finalize and prepare handoff">
|
||||
<action>Complete the epics document and prepare for development
|
||||
|
||||
Review what we've created:
|
||||
"We've successfully decomposed your requirements into:
|
||||
|
||||
- [x] epics
|
||||
- [Y] total stories
|
||||
- [Z] phases of development
|
||||
|
||||
Every story is sized for a single dev agent to complete independently."
|
||||
|
||||
Highlight key achievements:
|
||||
|
||||
- Stories respect 200k context limit
|
||||
- Dependencies clearly mapped
|
||||
- Domain requirements integrated
|
||||
- Parallel development enabled
|
||||
|
||||
Save completed epics.md with:
|
||||
|
||||
- Full epic descriptions
|
||||
- All stories with acceptance criteria
|
||||
- Implementation sequence
|
||||
- Development phases
|
||||
- Dependency notes
|
||||
- Domain compliance requirements (if applicable)</action>
|
||||
|
||||
<output>**✅ Epic Decomposition Complete, {user_name}!**
|
||||
|
||||
Your requirements are now organized into **{epic_count} epics** with **{story_count} bite-sized stories**.
|
||||
|
||||
**Created:**
|
||||
|
||||
- **epics.md** - Complete epic breakdown with implementable stories
|
||||
|
||||
**Key Stats:**
|
||||
|
||||
- Average story size: Fits in 200k context
|
||||
- Parallel stories: {parallel_count} can run simultaneously
|
||||
- Sequential chains: {sequential_count} dependency chains
|
||||
- Estimated velocity: {velocity_estimate}
|
||||
|
||||
**Next Steps:**
|
||||
|
||||
1. Review epics.md for the complete breakdown
|
||||
2. Start Phase 1 implementation with parallel stories
|
||||
3. Use story IDs for tracking progress
|
||||
|
||||
Each story is crafted for a single dev agent to complete autonomously. No monoliths, no confusion, just clear implementation paths.
|
||||
|
||||
Ready to begin development with any story marked "can start immediately"!</output>
|
||||
</step>
|
||||
|
||||
</workflow>
|
||||
|
|
@ -0,0 +1,43 @@
|
|||
# Epic and Story Decomposition Workflow
|
||||
name: create-epics-and-stories
|
||||
description: "Transform PRD requirements into bite-sized stories organized in epics for 200k context dev agents"
|
||||
author: "BMad"
|
||||
|
||||
# Critical variables from config
|
||||
config_source: "{project-root}/bmad/bmm/config.yaml"
|
||||
project_name: "{config_source}:project_name"
|
||||
output_folder: "{config_source}:output_folder"
|
||||
user_name: "{config_source}:user_name"
|
||||
communication_language: "{config_source}:communication_language"
|
||||
document_output_language: "{config_source}:document_output_language"
|
||||
user_skill_level: "{config_source}:user_skill_level"
|
||||
date: system-generated
|
||||
|
||||
# Workflow components
|
||||
installed_path: "{project-root}/bmad/bmm/workflows/2-plan-workflows/prd/create-epics-and-stories"
|
||||
instructions: "{installed_path}/instructions.md"
|
||||
template: "{installed_path}/epics-template.md"
|
||||
|
||||
# Input files (from parent PRD workflow)
|
||||
prd_file: "{output_folder}/PRD.md"
|
||||
|
||||
# Output files
|
||||
default_output_file: "{output_folder}/epics.md"
|
||||
|
||||
# Optional input documents
|
||||
recommended_inputs:
|
||||
- prd: "{output_folder}/PRD.md"
|
||||
- product_brief: "{output_folder}/product-brief.md"
|
||||
- domain_brief: "{output_folder}/domain-brief.md"
|
||||
|
||||
standalone: true
|
||||
|
||||
web_bundle:
|
||||
name: "create-epics-and-stories"
|
||||
description: "Transform PRD requirements into bite-sized stories organized in epics for 200k context dev agents"
|
||||
author: "BMad"
|
||||
instructions: "bmad/bmm/workflows/2-plan-workflows/prd/create-epics-and-stories/instructions.md"
|
||||
template: "bmad/bmm/workflows/2-plan-workflows/prd/create-epics-and-stories/epics-template.md"
|
||||
web_bundle_files:
|
||||
- "bmad/bmm/workflows/2-plan-workflows/prd/create-epics-and-stories/instructions.md"
|
||||
- "bmad/bmm/workflows/2-plan-workflows/prd/create-epics-and-stories/epics-template.md"
|
||||
|
|
@ -0,0 +1,13 @@
|
|||
domain,signals,complexity,key_concerns,required_knowledge,suggested_workflow,web_searches,special_sections
|
||||
healthcare,"medical,diagnostic,clinical,FDA,patient,treatment,HIPAA,therapy,pharma,drug",high,"FDA approval;Clinical validation;HIPAA compliance;Patient safety;Medical device classification;Liability","Regulatory pathways;Clinical trial design;Medical standards;Data privacy;Integration requirements","domain-research","FDA software medical device guidance {date};HIPAA compliance software requirements;Medical software standards {date};Clinical validation software","clinical_requirements;regulatory_pathway;validation_methodology;safety_measures"
|
||||
fintech,"payment,banking,trading,investment,crypto,wallet,transaction,KYC,AML,funds,fintech",high,"Regional compliance;Security standards;Audit requirements;Fraud prevention;Data protection","KYC/AML requirements;PCI DSS;Open banking;Regional laws (US/EU/APAC);Crypto regulations","domain-research","fintech regulations {date};payment processing compliance {date};open banking API standards;cryptocurrency regulations {date}","compliance_matrix;security_architecture;audit_requirements;fraud_prevention"
|
||||
govtech,"government,federal,civic,public sector,citizen,municipal,voting",high,"Procurement rules;Security clearance;Accessibility (508);FedRAMP;Privacy;Transparency","Government procurement;Security frameworks;Accessibility standards;Privacy laws;Open data requirements","domain-research","government software procurement {date};FedRAMP compliance requirements;section 508 accessibility;government security standards","procurement_compliance;security_clearance;accessibility_standards;transparency_requirements"
|
||||
edtech,"education,learning,student,teacher,curriculum,assessment,K-12,university,LMS",medium,"Student privacy (COPPA/FERPA);Accessibility;Content moderation;Age verification;Curriculum standards","Educational privacy laws;Learning standards;Accessibility requirements;Content guidelines;Assessment validity","domain-research","educational software privacy {date};COPPA FERPA compliance;WCAG education requirements;learning management standards","privacy_compliance;content_guidelines;accessibility_features;curriculum_alignment"
|
||||
aerospace,"aircraft,spacecraft,aviation,drone,satellite,propulsion,flight,radar,navigation",high,"Safety certification;DO-178C compliance;Performance validation;Simulation accuracy;Export controls","Aviation standards;Safety analysis;Simulation validation;ITAR/export controls;Performance requirements","domain-research + technical-model","DO-178C software certification;aerospace simulation standards {date};ITAR export controls software;aviation safety requirements","safety_certification;simulation_validation;performance_requirements;export_compliance"
|
||||
automotive,"vehicle,car,autonomous,ADAS,automotive,driving,EV,charging",high,"Safety standards;ISO 26262;V2X communication;Real-time requirements;Certification","Automotive standards;Functional safety;V2X protocols;Real-time systems;Testing requirements","domain-research","ISO 26262 automotive software;automotive safety standards {date};V2X communication protocols;EV charging standards","safety_standards;functional_safety;communication_protocols;certification_requirements"
|
||||
scientific,"research,algorithm,simulation,modeling,computational,analysis,data science,ML,AI",medium,"Reproducibility;Validation methodology;Peer review;Performance;Accuracy;Computational resources","Scientific method;Statistical validity;Computational requirements;Domain expertise;Publication standards","technical-model","scientific computing best practices {date};research reproducibility standards;computational modeling validation;peer review software","validation_methodology;accuracy_metrics;reproducibility_plan;computational_requirements"
|
||||
legaltech,"legal,law,contract,compliance,litigation,patent,attorney,court",high,"Legal ethics;Bar regulations;Data retention;Attorney-client privilege;Court system integration","Legal practice rules;Ethics requirements;Court filing systems;Document standards;Confidentiality","domain-research","legal technology ethics {date};law practice management software requirements;court filing system standards;attorney client privilege technology","ethics_compliance;data_retention;confidentiality_measures;court_integration"
|
||||
insuretech,"insurance,claims,underwriting,actuarial,policy,risk,premium",high,"Insurance regulations;Actuarial standards;Data privacy;Fraud detection;State compliance","Insurance regulations by state;Actuarial methods;Risk modeling;Claims processing;Regulatory reporting","domain-research","insurance software regulations {date};actuarial standards software;insurance fraud detection;state insurance compliance","regulatory_requirements;risk_modeling;fraud_detection;reporting_compliance"
|
||||
energy,"energy,utility,grid,solar,wind,power,electricity,oil,gas",high,"Grid compliance;NERC standards;Environmental regulations;Safety requirements;Real-time operations","Energy regulations;Grid standards;Environmental compliance;Safety protocols;SCADA systems","domain-research","energy sector software compliance {date};NERC CIP standards;smart grid requirements;renewable energy software standards","grid_compliance;safety_protocols;environmental_compliance;operational_requirements"
|
||||
gaming,"game,player,gameplay,level,character,multiplayer,quest",redirect,"REDIRECT TO GAME WORKFLOWS","Game design","game-brief","NA","NA"
|
||||
general,"",low,"Standard requirements;Basic security;User experience;Performance","General software practices","continue","software development best practices {date}","standard_requirements"
|
||||
|
|
|
@ -1,47 +1,33 @@
|
|||
# PRD Workflow Instructions
|
||||
# PRD Workflow - Intent-Driven Product Planning
|
||||
|
||||
<critical>The workflow execution engine is governed by: {project-root}/bmad/core/tasks/workflow.xml</critical>
|
||||
<critical>You MUST have already loaded and processed: {installed_path}/workflow.yaml</critical>
|
||||
<critical>Communicate all responses in {communication_language} and language MUST be tailored to {user_skill_level}</critical>
|
||||
<critical>This workflow uses INTENT-DRIVEN PLANNING - adapt organically to product type and context</critical>
|
||||
<critical>Communicate all responses in {communication_language} and adapt deeply to {user_skill_level}</critical>
|
||||
<critical>Generate all documents in {document_output_language}</critical>
|
||||
<critical>This workflow is for Level 2-4 projects. Level 0-1 use tech-spec workflow.</critical>
|
||||
<critical>Produces TWO outputs: PRD.md (strategic) and epics.md (tactical implementation)</critical>
|
||||
<critical>TECHNICAL NOTES: If ANY technical details, preferences, or constraints are mentioned during PRD discussions, append them to {technical_decisions_file}. If file doesn't exist, create it from {technical_decisions_template}</critical>
|
||||
|
||||
<critical>DOCUMENT OUTPUT: Concise, clear, actionable requirements. Use tables/lists over prose. User skill level ({user_skill_level}) affects conversation style ONLY, not document content.</critical>
|
||||
<critical>LIVING DOCUMENT: Write to PRD.md continuously as you discover - never wait until the end</critical>
|
||||
<critical>GUIDING PRINCIPLE: Find and weave the product's magic throughout - what makes it special should inspire every section</critical>
|
||||
|
||||
<workflow>
|
||||
|
||||
<step n="0" goal="Validate workflow readiness" tag="workflow-status">
|
||||
<action>Check if {output_folder}/bmm-workflow-status.yaml exists</action>
|
||||
<action>Check if {status_file} exists</action>
|
||||
|
||||
<check if="status file not found">
|
||||
<output>No workflow status file found. PRD workflow can run standalone or as part of BMM workflow path.</output>
|
||||
<output>**Recommended:** Run `workflow-init` first for project context tracking and workflow sequencing.</output>
|
||||
<ask>Continue in standalone mode or exit to run workflow-init? (continue/exit)</ask>
|
||||
<check if="continue">
|
||||
<action>Set standalone_mode = true</action>
|
||||
</check>
|
||||
<check if="exit">
|
||||
<action>Exit workflow</action>
|
||||
</check>
|
||||
</check>
|
||||
<action if="status file not found">Set standalone_mode = true</action>
|
||||
|
||||
<check if="status file found">
|
||||
<action>Load the FULL file: {output_folder}/bmm-workflow-status.yaml</action>
|
||||
<action>Load the FULL file: {status_file}</action>
|
||||
<action>Parse workflow_status section</action>
|
||||
<action>Check status of "prd" workflow</action>
|
||||
<action>Get project_level from YAML metadata</action>
|
||||
<action>Find first non-completed workflow (next expected workflow)</action>
|
||||
|
||||
<check if="project_level < 2">
|
||||
<output>**Incorrect Workflow for Level {{project_level}}**
|
||||
<output>**Level {{project_level}} Project - Redirecting**
|
||||
|
||||
PRD is for Level 2-4 projects. Level 0-1 should use tech-spec directly.
|
||||
|
||||
**Correct workflow:** `tech-spec` (Architect agent)
|
||||
</output>
|
||||
<action>Exit and redirect to tech-spec</action>
|
||||
Level 0-1 projects use tech-spec workflow for simpler planning.
|
||||
PRD is for Level 2-4 projects that need comprehensive requirements.</output>
|
||||
<action>Exit and suggest tech-spec workflow</action>
|
||||
</check>
|
||||
|
||||
<check if="prd status is file path (already completed)">
|
||||
|
|
@ -53,379 +39,367 @@ PRD is for Level 2-4 projects. Level 0-1 should use tech-spec directly.
|
|||
</check>
|
||||
</check>
|
||||
|
||||
<check if="prd is not the next expected workflow">
|
||||
<output>⚠️ Next expected workflow: {{next_workflow}}. PRD is out of sequence.</output>
|
||||
<ask>Continue with PRD anyway? (y/n)</ask>
|
||||
<check if="n">
|
||||
<output>Exiting. Run {{next_workflow}} instead.</output>
|
||||
<action>Exit workflow</action>
|
||||
</check>
|
||||
</check>
|
||||
|
||||
<action>Set standalone_mode = false</action>
|
||||
</check>
|
||||
</step>
|
||||
|
||||
<step n="1" goal="Initialize PRD context">
|
||||
<step n="1" goal="Discovery - Project, Domain, and Vision">
|
||||
<action>Welcome {user_name} and begin comprehensive discovery, and then start to GATHER ALL CONTEXT:
|
||||
1. Check workflow-status.yaml for project_context (if exists)
|
||||
2. Look for existing documents (Product Brief, Domain Brief, research)
|
||||
3. Detect project type AND domain complexity
|
||||
|
||||
<action>Use {{project_level}} from status data</action>
|
||||
<action>Check for existing PRD.md in {output_folder}</action>
|
||||
Load references:
|
||||
{installed_path}/project-types.csv
|
||||
{installed_path}/domain-complexity.csv
|
||||
|
||||
<check if="PRD.md exists">
|
||||
<ask>Found existing PRD.md. Would you like to:
|
||||
1. Continue where you left off
|
||||
2. Modify existing sections
|
||||
3. Start fresh (will archive existing file)
|
||||
</ask>
|
||||
<action if="option 1">Load existing PRD and skip to first incomplete section</action>
|
||||
<action if="option 2">Load PRD and ask which section to modify</action>
|
||||
<action if="option 3">Archive existing PRD and start fresh</action>
|
||||
Through natural conversation:
|
||||
"Tell me about what you want to build - what problem does it solve and for whom?"
|
||||
|
||||
DUAL DETECTION:
|
||||
Project type signals: API, mobile, web, CLI, SDK, SaaS
|
||||
Domain complexity signals: medical, finance, government, education, aerospace
|
||||
|
||||
SPECIAL ROUTING:
|
||||
If game detected → Suggest game-brief and GDD workflows
|
||||
If complex domain detected → Offer domain research options:
|
||||
A) Run domain-research workflow (thorough)
|
||||
B) Quick web search (basic)
|
||||
C) User provides context
|
||||
D) Continue with general knowledge
|
||||
|
||||
CAPTURE THE MAGIC EARLY with a few questions such as for example: "What excites you most about this product?", "What would make users love this?", "What's the moment that will make people go 'wow'?"
|
||||
|
||||
This excitement becomes the thread woven throughout the PRD.</action>
|
||||
|
||||
<template-output>vision_alignment</template-output>
|
||||
<template-output>project_classification</template-output>
|
||||
<template-output>project_type</template-output>
|
||||
<template-output>domain_type</template-output>
|
||||
<template-output>complexity_level</template-output>
|
||||
<check if="complex domain">
|
||||
<template-output>domain_context_summary</template-output>
|
||||
</check>
|
||||
|
||||
<action>Load PRD template: {prd_template}</action>
|
||||
<action>Load epics template: {epics_template}</action>
|
||||
|
||||
<ask>Do you have a Product Brief? (Strongly recommended for Level 3-4, helpful for Level 2)</ask>
|
||||
|
||||
<check if="yes">
|
||||
<action>Load and review product brief: {output_folder}/product-brief.md</action>
|
||||
<action>Extract key elements: problem statement, target users, success metrics, MVP scope, constraints</action>
|
||||
</check>
|
||||
|
||||
<check if="no and level >= 3">
|
||||
<warning>Product Brief is strongly recommended for Level 3-4 projects. Consider running the product-brief workflow first.</warning>
|
||||
<ask>Continue without Product Brief? (y/n)</ask>
|
||||
<action if="no">Exit to allow Product Brief creation</action>
|
||||
</check>
|
||||
|
||||
<template-output>product_magic_essence</template-output>
|
||||
<template-output>product_brief_path</template-output>
|
||||
<template-output>domain_brief_path</template-output>
|
||||
<template-output>research_documents</template-output>
|
||||
</step>
|
||||
|
||||
<step n="2" goal="Goals and Background Context">
|
||||
<step n="2" goal="Success Definition">
|
||||
<action>Define what winning looks like for THIS specific product
|
||||
|
||||
**Goals** - What success looks like for this project
|
||||
INTENT: Meaningful success criteria, not generic metrics
|
||||
|
||||
<check if="product brief exists">
|
||||
<action>Review goals from product brief and refine for PRD context</action>
|
||||
Adapt to context:
|
||||
|
||||
- Consumer: User love, engagement, retention
|
||||
- B2B: ROI, efficiency, adoption
|
||||
- Developer tools: Developer experience, community
|
||||
- Regulated: Compliance, safety, validation
|
||||
|
||||
Make it specific:
|
||||
|
||||
- NOT: "10,000 users"
|
||||
- BUT: "100 power users who rely on it daily"
|
||||
|
||||
- NOT: "99.9% uptime"
|
||||
- BUT: "Zero data loss during critical operations"
|
||||
|
||||
Weave in the magic:
|
||||
|
||||
- "Success means users experience [that special moment] and [desired outcome]"</action>
|
||||
|
||||
<template-output>success_criteria</template-output>
|
||||
<check if="business focus">
|
||||
<template-output>business_metrics</template-output>
|
||||
</check>
|
||||
|
||||
<check if="no product brief">
|
||||
<action>Gather goals through discussion with user, use probing questions and converse until you are ready to propose that you have enough information to proceed</action>
|
||||
</check>
|
||||
|
||||
Create a bullet list of single-line desired outcomes that capture user and project goals.
|
||||
|
||||
**Scale guidance:**
|
||||
|
||||
- Level 2: 2-3 core goals
|
||||
- Level 3: 3-5 strategic goals
|
||||
- Level 4: 5-7 comprehensive goals
|
||||
|
||||
<template-output>goals</template-output>
|
||||
|
||||
**Background Context** - Why this matters now
|
||||
|
||||
<check if="product brief exists">
|
||||
<action>Summarize key context from brief without redundancy</action>
|
||||
</check>
|
||||
|
||||
<check if="no product brief">
|
||||
<action>Gather context through discussion</action>
|
||||
</check>
|
||||
|
||||
Write 1-2 paragraphs covering:
|
||||
|
||||
- What problem this solves and why
|
||||
- Current landscape or need
|
||||
- Key insights from discovery/brief (if available)
|
||||
|
||||
<template-output>background_context</template-output>
|
||||
|
||||
</step>
|
||||
|
||||
<step n="3" goal="Requirements - Functional and Non-Functional">
|
||||
<step n="3" goal="Scope Definition">
|
||||
<action>Smart scope negotiation - find the sweet spot
|
||||
|
||||
**Functional Requirements** - What the system must do
|
||||
The Scoping Game:
|
||||
|
||||
Draft functional requirements as numbered items with FR prefix.
|
||||
1. "What must work for this to be useful?" → MVP
|
||||
2. "What makes it competitive?" → Growth
|
||||
3. "What's the dream version?" → Vision
|
||||
|
||||
**Scale guidance:**
|
||||
Challenge scope creep conversationally:
|
||||
|
||||
- Level 2: 8-15 FRs (focused MVP set)
|
||||
- Level 3: 12-25 FRs (comprehensive product)
|
||||
- Level 4: 20-35 FRs (enterprise platform)
|
||||
- "Could that wait until after launch?"
|
||||
- "Is that essential for proving the concept?"
|
||||
|
||||
**Format:**
|
||||
For complex domains:
|
||||
|
||||
- FR001: [Clear capability statement]
|
||||
- FR002: [Another capability]
|
||||
|
||||
**Focus on:**
|
||||
|
||||
- User-facing capabilities
|
||||
- Core system behaviors
|
||||
- Integration requirements
|
||||
- Data management needs
|
||||
|
||||
Group related requirements logically.
|
||||
|
||||
<invoke-task halt="true">{project-root}/bmad/core/tasks/adv-elicit.xml</invoke-task>
|
||||
|
||||
<template-output>functional_requirements</template-output>
|
||||
|
||||
**Non-Functional Requirements** - How the system must perform
|
||||
|
||||
Draft non-functional requirements with NFR prefix.
|
||||
|
||||
**Scale guidance:**
|
||||
|
||||
- Level 2: 1-3 NFRs (critical MVP only)
|
||||
- Level 3: 2-5 NFRs (production quality)
|
||||
- Level 4: 3-7+ NFRs (enterprise grade)
|
||||
|
||||
<template-output>non_functional_requirements</template-output>
|
||||
- Include compliance minimums in MVP
|
||||
- Note regulatory gates between phases</action>
|
||||
|
||||
<template-output>mvp_scope</template-output>
|
||||
<template-output>growth_features</template-output>
|
||||
<template-output>vision_features</template-output>
|
||||
</step>
|
||||
|
||||
<step n="4" goal="User Journeys - scale-adaptive" optional="level == 2">
|
||||
<step n="4" goal="Domain-Specific Exploration" optional="true">
|
||||
<action>Only if complex domain detected or domain-brief exists
|
||||
|
||||
**Journey Guidelines (scale-adaptive):**
|
||||
Synthesize domain requirements that will shape everything:
|
||||
|
||||
- **Level 2:** 1 simple journey (primary use case happy path)
|
||||
- **Level 3:** 2-3 detailed journeys (complete flows with decision points)
|
||||
- **Level 4:** 3-5 comprehensive journeys (all personas and edge cases)
|
||||
- Regulatory requirements
|
||||
- Compliance needs
|
||||
- Industry standards
|
||||
- Safety/risk factors
|
||||
- Required validations
|
||||
- Special expertise needed
|
||||
|
||||
<check if="level == 2">
|
||||
<ask>Would you like to document a user journey for the primary use case? (recommended but optional)</ask>
|
||||
<check if="yes">
|
||||
Create 1 simple journey showing the happy path.
|
||||
</check>
|
||||
These inform:
|
||||
|
||||
- What features are mandatory
|
||||
- What NFRs are critical
|
||||
- How to sequence development
|
||||
- What validation is required</action>
|
||||
|
||||
<check if="complex domain">
|
||||
<template-output>domain_considerations</template-output>
|
||||
</check>
|
||||
</step>
|
||||
|
||||
<step n="5" goal="Innovation Discovery" optional="true">
|
||||
<action>Identify truly novel patterns if applicable
|
||||
|
||||
Listen for innovation signals:
|
||||
|
||||
- "Nothing like this exists"
|
||||
- "We're rethinking how [X] works"
|
||||
- "Combining [A] with [B] for the first time"
|
||||
|
||||
Explore deeply:
|
||||
|
||||
- What makes it unique?
|
||||
- What assumption are you challenging?
|
||||
- How do we validate it?
|
||||
- What's the fallback?
|
||||
|
||||
<WebSearch if="novel">{concept} innovations {date}</WebSearch></action>
|
||||
|
||||
<check if="innovation detected">
|
||||
<template-output>innovation_patterns</template-output>
|
||||
<template-output>validation_approach</template-output>
|
||||
</check>
|
||||
</step>
|
||||
|
||||
<step n="6" goal="Project-Specific Deep Dive">
|
||||
<action>Based on detected project type, dive deep into specific needs
|
||||
|
||||
Load project type requirements from CSV and expand naturally.
|
||||
|
||||
FOR API/BACKEND:
|
||||
|
||||
- Map out endpoints, methods, parameters
|
||||
- Define authentication and authorization
|
||||
- Specify error codes and rate limits
|
||||
- Document data schemas
|
||||
|
||||
FOR MOBILE:
|
||||
|
||||
- Platform requirements (iOS/Android/both)
|
||||
- Device features needed
|
||||
- Offline capabilities
|
||||
- Store compliance
|
||||
|
||||
FOR SAAS B2B:
|
||||
|
||||
- Multi-tenant architecture
|
||||
- Permission models
|
||||
- Subscription tiers
|
||||
- Critical integrations
|
||||
|
||||
[Continue for other types...]
|
||||
|
||||
Always relate back to the product magic:
|
||||
"How does [requirement] enhance [the special thing]?"</action>
|
||||
|
||||
<template-output>project_type_requirements</template-output>
|
||||
|
||||
<!-- Dynamic sections based on project type -->
|
||||
<check if="API/Backend project">
|
||||
<template-output>endpoint_specification</template-output>
|
||||
<template-output>authentication_model</template-output>
|
||||
</check>
|
||||
|
||||
<check if="level >= 3">
|
||||
Map complete user flows with decision points, alternatives, and edge cases.
|
||||
<check if="Mobile project">
|
||||
<template-output>platform_requirements</template-output>
|
||||
<template-output>device_features</template-output>
|
||||
</check>
|
||||
|
||||
<template-output>user_journeys</template-output>
|
||||
|
||||
<check if="level >= 3">
|
||||
<invoke-task halt="true">{project-root}/bmad/core/tasks/adv-elicit.xml</invoke-task>
|
||||
<check if="SaaS B2B project">
|
||||
<template-output>tenant_model</template-output>
|
||||
<template-output>permission_matrix</template-output>
|
||||
</check>
|
||||
|
||||
</step>
|
||||
|
||||
<step n="5" goal="UX and UI Vision - high-level overview" optional="level == 2 and minimal UI">
|
||||
<step n="7" goal="UX Principles" optional="true">
|
||||
<action>Only if product has a UI
|
||||
|
||||
**Purpose:** Capture essential UX/UI information needed for epic and story planning. A dedicated UX workflow will provide deeper design detail later.
|
||||
Light touch on UX - not full design:
|
||||
|
||||
<check if="level == 2 and minimal UI">
|
||||
<action>For backend-heavy or minimal UI projects, keep this section very brief or skip</action>
|
||||
- Visual personality
|
||||
- Key interaction patterns
|
||||
- Critical user flows
|
||||
|
||||
"How should this feel to use?"
|
||||
"What's the vibe - professional, playful, minimal?"
|
||||
|
||||
Connect to the magic:
|
||||
"The UI should reinforce [the special moment] through [design approach]"</action>
|
||||
|
||||
<check if="has UI">
|
||||
<template-output>ux_principles</template-output>
|
||||
<template-output>key_interactions</template-output>
|
||||
</check>
|
||||
|
||||
**Gather high-level UX/UI information:**
|
||||
|
||||
1. **UX Principles** (2-4 key principles that guide design decisions)
|
||||
- What core experience qualities matter most?
|
||||
- Any critical accessibility or usability requirements?
|
||||
|
||||
2. **Platform & Screens**
|
||||
- Target platforms (web, mobile, desktop)
|
||||
- Core screens/views users will interact with
|
||||
- Key interaction patterns or navigation approach
|
||||
|
||||
3. **Design Constraints**
|
||||
- Existing design systems or brand guidelines
|
||||
- Technical UI constraints (browser support, etc.)
|
||||
|
||||
<note>Keep responses high-level. Detailed UX planning happens in the UX workflow after PRD completion.</note>
|
||||
|
||||
<invoke-task halt="true">{project-root}/bmad/core/tasks/adv-elicit.xml</invoke-task>
|
||||
|
||||
<template-output>ux_principles</template-output>
|
||||
<template-output>ui_design_goals</template-output>
|
||||
|
||||
</step>
|
||||
|
||||
<step n="6" goal="Epic List - High-level delivery sequence">
|
||||
<step n="8" goal="Functional Requirements Synthesis">
|
||||
<action>Transform everything discovered into clear functional requirements
|
||||
|
||||
**Epic Structure** - Major delivery milestones
|
||||
Pull together:
|
||||
|
||||
Create high-level epic list showing logical delivery sequence.
|
||||
- Core features from scope
|
||||
- Domain-mandated features
|
||||
- Project-type specific needs
|
||||
- Innovation requirements
|
||||
|
||||
**Epic Sequencing Rules:**
|
||||
Organize by capability, not technology:
|
||||
|
||||
1. **Epic 1 MUST establish foundation**
|
||||
- Project infrastructure (repo, CI/CD, core setup)
|
||||
- Initial deployable functionality
|
||||
- Development workflow established
|
||||
- Exception: If adding to existing app, Epic 1 can be first major feature
|
||||
- User Management (not "auth system")
|
||||
- Content Discovery (not "search algorithm")
|
||||
- Team Collaboration (not "websockets")
|
||||
|
||||
2. **Subsequent Epics:**
|
||||
- Each delivers significant, end-to-end, fully deployable increment
|
||||
- Build upon previous epics (no forward dependencies)
|
||||
- Represent major functional blocks
|
||||
- Prefer fewer, larger epics over fragmentation
|
||||
Each requirement should:
|
||||
|
||||
**Scale guidance:**
|
||||
- Be specific and measurable
|
||||
- Connect to user value
|
||||
- Include acceptance criteria
|
||||
- Note domain constraints
|
||||
|
||||
- Level 2: 1-2 epics, 5-15 stories total
|
||||
- Level 3: 2-5 epics, 15-40 stories total
|
||||
- Level 4: 5-10 epics, 40-100+ stories total
|
||||
|
||||
**For each epic provide:**
|
||||
|
||||
- Epic number and title
|
||||
- Single-sentence goal statement
|
||||
- Estimated story count
|
||||
|
||||
**Example:**
|
||||
|
||||
- **Epic 1: Project Foundation & User Authentication**
|
||||
- **Epic 2: Core Task Management**
|
||||
|
||||
<ask>Review the epic list. Does the sequence make sense? Any epics to add, remove, or resequence?</ask>
|
||||
<action>Refine epic list based on feedback</action>
|
||||
<invoke-task halt="true">{project-root}/bmad/core/tasks/adv-elicit.xml</invoke-task>
|
||||
|
||||
<template-output>epic_list</template-output>
|
||||
The magic thread:
|
||||
Highlight which requirements deliver the special experience</action>
|
||||
|
||||
<template-output>functional_requirements_complete</template-output>
|
||||
</step>
|
||||
|
||||
<step n="7" goal="Out of Scope - Clear boundaries and future additions">
|
||||
<step n="9" goal="Non-Functional Requirements Discovery">
|
||||
<action>Only document NFRs that matter for THIS product
|
||||
|
||||
**Out of Scope** - What we're NOT doing (now)
|
||||
Performance: Only if user-facing impact
|
||||
Security: Only if handling sensitive data
|
||||
Scale: Only if growth expected
|
||||
Accessibility: Only if broad audience
|
||||
Integration: Only if connecting systems
|
||||
|
||||
Document what is explicitly excluded from this project:
|
||||
For each NFR:
|
||||
|
||||
- Features/capabilities deferred to future phases
|
||||
- Adjacent problems not being solved
|
||||
- Integrations or platforms not supported
|
||||
- Scope boundaries that need clarification
|
||||
- Why it matters for THIS product
|
||||
- Specific measurable criteria
|
||||
- Domain-driven requirements
|
||||
|
||||
This helps prevent scope creep and sets clear expectations.
|
||||
|
||||
<template-output>out_of_scope</template-output>
|
||||
Skip categories that don't apply!</action>
|
||||
|
||||
<!-- Only output sections that were discussed -->
|
||||
<check if="performance matters">
|
||||
<template-output>performance_requirements</template-output>
|
||||
</check>
|
||||
<check if="security matters">
|
||||
<template-output>security_requirements</template-output>
|
||||
</check>
|
||||
<check if="scale matters">
|
||||
<template-output>scalability_requirements</template-output>
|
||||
</check>
|
||||
<check if="accessibility matters">
|
||||
<template-output>accessibility_requirements</template-output>
|
||||
</check>
|
||||
<check if="integration matters">
|
||||
<template-output>integration_requirements</template-output>
|
||||
</check>
|
||||
<check if="no NFRs discussed">
|
||||
<template-output>no_nfrs</template-output>
|
||||
</check>
|
||||
</step>
|
||||
|
||||
<step n="8" goal="Finalize PRD.md">
|
||||
<step n="10" goal="Review PRD and transition to epics">
|
||||
<action>Review the PRD we've built together
|
||||
|
||||
<action>Review all PRD sections for completeness and consistency</action>
|
||||
<action>Ensure all placeholders are filled</action>
|
||||
<action>Save final PRD.md to {default_output_file}</action>
|
||||
"Let's review what we've captured:
|
||||
|
||||
**PRD.md is complete!** Strategic document ready.
|
||||
- Vision: [summary]
|
||||
- Success: [key metrics]
|
||||
- Scope: [MVP highlights]
|
||||
- Requirements: [count] functional, [count] non-functional
|
||||
- Special considerations: [domain/innovation]
|
||||
|
||||
Now we'll create the tactical implementation guide in epics.md.
|
||||
Does this capture your product vision?"
|
||||
|
||||
After confirmation:
|
||||
"Excellent! Now we need to break these requirements into implementable epics and stories.
|
||||
|
||||
For the epic breakdown, you have two options:
|
||||
|
||||
1. Start a new session focused on epics (recommended for complex projects)
|
||||
2. Continue here (I'll transform requirements into epics now)
|
||||
|
||||
Which would you prefer?"
|
||||
|
||||
If new session:
|
||||
"To start epic planning in a new session:
|
||||
|
||||
1. Save your work here
|
||||
2. Start fresh and run: workflow epics-stories
|
||||
3. It will load your PRD and create the epic breakdown
|
||||
|
||||
This keeps each session focused and manageable."
|
||||
|
||||
If continue:
|
||||
"Let's continue with epic breakdown here..."
|
||||
[Proceed with epics-stories subworkflow]
|
||||
Set project_level and target_scale based on project analysis
|
||||
Generate epic_details for the epics breakdown document</action>
|
||||
|
||||
<template-output>prd_summary</template-output>
|
||||
<template-output>project_level</template-output>
|
||||
<template-output>target_scale</template-output>
|
||||
<template-output>epic_details</template-output>
|
||||
</step>
|
||||
|
||||
<step n="9" goal="Epic Details - Full story breakdown in epics.md">
|
||||
|
||||
<critical>Now we create epics.md - the tactical implementation roadmap</critical>
|
||||
<critical>This is a SEPARATE FILE from PRD.md</critical>
|
||||
|
||||
<action>Load epics template: {epics_template}</action>
|
||||
<action>Initialize epics.md with project metadata</action>
|
||||
|
||||
For each epic from the epic list, expand with full story details:
|
||||
|
||||
**Epic Expansion Process:**
|
||||
|
||||
1. **Expanded Goal** (2-3 sentences)
|
||||
- Describe the epic's objective and value delivery
|
||||
- Explain how it builds on previous work
|
||||
|
||||
2. **Story Breakdown**
|
||||
|
||||
**Critical Story Requirements:**
|
||||
- **Vertical slices** - Each story delivers complete, testable functionality
|
||||
- **Sequential** - Stories must be logically ordered within epic
|
||||
- **No forward dependencies** - No story depends on work from a later story/epic
|
||||
- **AI-agent sized** - Completable in single focused session (2-4 hours)
|
||||
- **Value-focused** - Minimize pure enabler stories; integrate technical work into value delivery
|
||||
|
||||
**Story Format:**
|
||||
|
||||
```
|
||||
**Story [EPIC.N]: [Story Title]**
|
||||
|
||||
As a [user type],
|
||||
I want [goal/desire],
|
||||
So that [benefit/value].
|
||||
|
||||
**Acceptance Criteria:**
|
||||
1. [Specific testable criterion]
|
||||
2. [Another specific criterion]
|
||||
3. [etc.]
|
||||
|
||||
**Prerequisites:** [Any dependencies on previous stories]
|
||||
```
|
||||
|
||||
3. **Story Sequencing Within Epic:**
|
||||
- Start with foundational/setup work if needed
|
||||
- Build progressively toward epic goal
|
||||
- Each story should leave system in working state
|
||||
- Final stories complete the epic's value delivery
|
||||
|
||||
**Process each epic:**
|
||||
|
||||
<repeat for-each="epic in epic_list">
|
||||
|
||||
<ask>Ready to break down {{epic_title}}? (y/n)</ask>
|
||||
|
||||
<action>Discuss epic scope and story ideas with user</action>
|
||||
<action>Draft story list ensuring vertical slices and proper sequencing</action>
|
||||
<action>For each story, write user story format and acceptance criteria</action>
|
||||
<action>Verify no forward dependencies exist</action>
|
||||
|
||||
<template-output file="epics.md">{{epic_title}}\_details</template-output>
|
||||
|
||||
<ask>Review {{epic_title}} stories. Any adjustments needed?</ask>
|
||||
|
||||
<action if="yes">Refine stories based on feedback</action>
|
||||
|
||||
</repeat>
|
||||
|
||||
<action>Save complete epics.md to {epics_output_file}</action>
|
||||
|
||||
**Epic Details complete!** Implementation roadmap ready.
|
||||
|
||||
</step>
|
||||
|
||||
<step n="10" goal="Update status and complete" tag="workflow-status">
|
||||
<step n="11" goal="Complete PRD and suggest next steps">
|
||||
<template-output>product_magic_summary</template-output>
|
||||
|
||||
<check if="standalone_mode != true">
|
||||
<action>Load the FULL file: {output_folder}/bmm-workflow-status.yaml</action>
|
||||
<action>Find workflow_status key "prd"</action>
|
||||
<critical>ONLY write the file path as the status value - no other text, notes, or metadata</critical>
|
||||
<action>Load the FULL file: {status_file}</action>
|
||||
<action>Update workflow_status["prd"] = "{default_output_file}"</action>
|
||||
<action>Save file, preserving ALL comments and structure including STATUS DEFINITIONS</action>
|
||||
|
||||
<action>Find first non-completed workflow in workflow_status (next workflow to do)</action>
|
||||
<action>Determine next agent from path file based on next workflow</action>
|
||||
<action>Save file, preserving ALL comments and structure</action>
|
||||
</check>
|
||||
|
||||
<output>**✅ PRD Workflow Complete, {user_name}!**
|
||||
<output>**✅ PRD Complete, {user_name}!**
|
||||
|
||||
**Deliverables Created:**
|
||||
Your product requirements are documented and ready for implementation.
|
||||
|
||||
1. ✅ bmm-PRD.md - Strategic product requirements document
|
||||
2. ✅ bmm-epics.md - Tactical implementation roadmap with story breakdown
|
||||
**Created:**
|
||||
|
||||
- **PRD.md** - Complete requirements adapted to {project_type} and {domain}
|
||||
|
||||
**Next Steps:**
|
||||
|
||||
- **Next required:** {{next_workflow}} ({{next_agent}} agent)
|
||||
- **Optional:** Review PRD and epics with stakeholders, or run `create-design` if you have UI requirements
|
||||
1. **Epic Breakdown** (Required)
|
||||
Run: `workflow create-epics-and-stories` to decompose requirements into implementable stories
|
||||
|
||||
Check status anytime with: `workflow-status`
|
||||
2. **UX Design** (If UI exists)
|
||||
Run: `workflow ux-design` for detailed user experience design
|
||||
|
||||
Would you like to:
|
||||
|
||||
1. Review/refine any section
|
||||
2. Proceed to next phase
|
||||
3. Exit and review documents
|
||||
</output>
|
||||
3. **Architecture** (Recommended)
|
||||
Run: `workflow create-architecture` for technical architecture decisions
|
||||
|
||||
The magic of your product - {product_magic_summary} - is woven throughout the PRD and will guide all subsequent work.
|
||||
</output>
|
||||
</step>
|
||||
|
||||
</workflow>
|
||||
|
|
|
|||
|
|
@ -1,62 +1,237 @@
|
|||
# {{project_name}} Product Requirements Document (PRD)
|
||||
# {{project_name}} - Product Requirements Document
|
||||
|
||||
**Author:** {{user_name}}
|
||||
**Date:** {{date}}
|
||||
**Project Level:** {{project_level}}
|
||||
**Target Scale:** {{target_scale}}
|
||||
**Version:** 1.0
|
||||
|
||||
---
|
||||
|
||||
## Goals and Background Context
|
||||
## Executive Summary
|
||||
|
||||
### Goals
|
||||
{{vision_alignment}}
|
||||
|
||||
{{goals}}
|
||||
### What Makes This Special
|
||||
|
||||
### Background Context
|
||||
|
||||
{{background_context}}
|
||||
{{product_magic_essence}}
|
||||
|
||||
---
|
||||
|
||||
## Requirements
|
||||
## Project Classification
|
||||
|
||||
### Functional Requirements
|
||||
**Technical Type:** {{project_type}}
|
||||
**Domain:** {{domain_type}}
|
||||
**Complexity:** {{complexity_level}}
|
||||
|
||||
{{functional_requirements}}
|
||||
{{project_classification}}
|
||||
|
||||
### Non-Functional Requirements
|
||||
{{#if domain_context_summary}}
|
||||
|
||||
{{non_functional_requirements}}
|
||||
### Domain Context
|
||||
|
||||
{{domain_context_summary}}
|
||||
{{/if}}
|
||||
|
||||
---
|
||||
|
||||
## User Journeys
|
||||
## Success Criteria
|
||||
|
||||
{{user_journeys}}
|
||||
{{success_criteria}}
|
||||
|
||||
{{#if business_metrics}}
|
||||
|
||||
### Business Metrics
|
||||
|
||||
{{business_metrics}}
|
||||
{{/if}}
|
||||
|
||||
---
|
||||
|
||||
## UX Design Principles
|
||||
## Product Scope
|
||||
|
||||
### MVP - Minimum Viable Product
|
||||
|
||||
{{mvp_scope}}
|
||||
|
||||
### Growth Features (Post-MVP)
|
||||
|
||||
{{growth_features}}
|
||||
|
||||
### Vision (Future)
|
||||
|
||||
{{vision_features}}
|
||||
|
||||
---
|
||||
|
||||
{{#if domain_considerations}}
|
||||
|
||||
## Domain-Specific Requirements
|
||||
|
||||
{{domain_considerations}}
|
||||
|
||||
This section shapes all functional and non-functional requirements below.
|
||||
{{/if}}
|
||||
|
||||
---
|
||||
|
||||
{{#if innovation_patterns}}
|
||||
|
||||
## Innovation & Novel Patterns
|
||||
|
||||
{{innovation_patterns}}
|
||||
|
||||
### Validation Approach
|
||||
|
||||
{{validation_approach}}
|
||||
{{/if}}
|
||||
|
||||
---
|
||||
|
||||
{{#if project_type_requirements}}
|
||||
|
||||
## {{project_type}} Specific Requirements
|
||||
|
||||
{{project_type_requirements}}
|
||||
|
||||
{{#if endpoint_specification}}
|
||||
|
||||
### API Specification
|
||||
|
||||
{{endpoint_specification}}
|
||||
{{/if}}
|
||||
|
||||
{{#if authentication_model}}
|
||||
|
||||
### Authentication & Authorization
|
||||
|
||||
{{authentication_model}}
|
||||
{{/if}}
|
||||
|
||||
{{#if platform_requirements}}
|
||||
|
||||
### Platform Support
|
||||
|
||||
{{platform_requirements}}
|
||||
{{/if}}
|
||||
|
||||
{{#if device_features}}
|
||||
|
||||
### Device Capabilities
|
||||
|
||||
{{device_features}}
|
||||
{{/if}}
|
||||
|
||||
{{#if tenant_model}}
|
||||
|
||||
### Multi-Tenancy Architecture
|
||||
|
||||
{{tenant_model}}
|
||||
{{/if}}
|
||||
|
||||
{{#if permission_matrix}}
|
||||
|
||||
### Permissions & Roles
|
||||
|
||||
{{permission_matrix}}
|
||||
{{/if}}
|
||||
{{/if}}
|
||||
|
||||
---
|
||||
|
||||
{{#if ux_principles}}
|
||||
|
||||
## User Experience Principles
|
||||
|
||||
{{ux_principles}}
|
||||
|
||||
---
|
||||
### Key Interactions
|
||||
|
||||
## User Interface Design Goals
|
||||
|
||||
{{ui_design_goals}}
|
||||
{{key_interactions}}
|
||||
{{/if}}
|
||||
|
||||
---
|
||||
|
||||
## Epic List
|
||||
## Functional Requirements
|
||||
|
||||
{{epic_list}}
|
||||
|
||||
> **Note:** Detailed epic breakdown with full story specifications is available in [epics.md](./epics.md)
|
||||
{{functional_requirements_complete}}
|
||||
|
||||
---
|
||||
|
||||
## Out of Scope
|
||||
## Non-Functional Requirements
|
||||
|
||||
{{out_of_scope}}
|
||||
{{#if performance_requirements}}
|
||||
|
||||
### Performance
|
||||
|
||||
{{performance_requirements}}
|
||||
{{/if}}
|
||||
|
||||
{{#if security_requirements}}
|
||||
|
||||
### Security
|
||||
|
||||
{{security_requirements}}
|
||||
{{/if}}
|
||||
|
||||
{{#if scalability_requirements}}
|
||||
|
||||
### Scalability
|
||||
|
||||
{{scalability_requirements}}
|
||||
{{/if}}
|
||||
|
||||
{{#if accessibility_requirements}}
|
||||
|
||||
### Accessibility
|
||||
|
||||
{{accessibility_requirements}}
|
||||
{{/if}}
|
||||
|
||||
{{#if integration_requirements}}
|
||||
|
||||
### Integration
|
||||
|
||||
{{integration_requirements}}
|
||||
{{/if}}
|
||||
|
||||
{{#if no_nfrs}}
|
||||
_No specific non-functional requirements identified for this project type._
|
||||
{{/if}}
|
||||
|
||||
---
|
||||
|
||||
## Implementation Planning
|
||||
|
||||
### Epic Breakdown Required
|
||||
|
||||
Requirements must be decomposed into epics and bite-sized stories (200k context limit).
|
||||
|
||||
**Next Step:** Run `workflow epics-stories` to create the implementation breakdown.
|
||||
|
||||
---
|
||||
|
||||
## References
|
||||
|
||||
{{#if product_brief_path}}
|
||||
|
||||
- Product Brief: {{product_brief_path}}
|
||||
{{/if}}
|
||||
{{#if domain_brief_path}}
|
||||
- Domain Brief: {{domain_brief_path}}
|
||||
{{/if}}
|
||||
{{#if research_documents}}
|
||||
- Research: {{research_documents}}
|
||||
{{/if}}
|
||||
|
||||
---
|
||||
|
||||
## Next Steps
|
||||
|
||||
1. **Epic & Story Breakdown** - Run: `workflow epics-stories`
|
||||
2. **UX Design** (if UI) - Run: `workflow ux-design`
|
||||
3. **Architecture** - Run: `workflow create-architecture`
|
||||
|
||||
---
|
||||
|
||||
_This PRD captures the essence of {{project_name}} - {{product_magic_summary}}_
|
||||
|
||||
_Created through collaborative discovery between {{user_name}} and AI facilitator._
|
||||
|
|
|
|||
|
|
@ -0,0 +1,11 @@
|
|||
project_type,detection_signals,key_questions,required_sections,skip_sections,web_search_triggers,innovation_signals
|
||||
api_backend,"API,REST,GraphQL,backend,service,endpoints","Endpoints needed?;Authentication method?;Data formats?;Rate limits?;Versioning?;SDK needed?","endpoint_specs;auth_model;data_schemas;error_codes;rate_limits;api_docs","ux_ui;visual_design;user_journeys","framework best practices;OpenAPI standards","API composition;New protocol"
|
||||
mobile_app,"iOS,Android,app,mobile,iPhone,iPad","Native or cross-platform?;Offline needed?;Push notifications?;Device features?;Store compliance?","platform_reqs;device_permissions;offline_mode;push_strategy;store_compliance","desktop_features;cli_commands","app store guidelines;platform requirements","Gesture innovation;AR/VR features"
|
||||
saas_b2b,"SaaS,B2B,platform,dashboard,teams,enterprise","Multi-tenant?;Permission model?;Subscription tiers?;Integrations?;Compliance?","tenant_model;rbac_matrix;subscription_tiers;integration_list;compliance_reqs","cli_interface;mobile_first","compliance requirements;integration guides","Workflow automation;AI agents"
|
||||
developer_tool,"SDK,library,package,npm,pip,framework","Language support?;Package managers?;IDE integration?;Documentation?;Examples?","language_matrix;installation_methods;api_surface;code_examples;migration_guide","visual_design;store_compliance","package manager best practices;API design patterns","New paradigm;DSL creation"
|
||||
cli_tool,"CLI,command,terminal,bash,script","Interactive or scriptable?;Output formats?;Config method?;Shell completion?","command_structure;output_formats;config_schema;scripting_support","visual_design;ux_principles;touch_interactions","CLI design patterns;shell integration","Natural language CLI;AI commands"
|
||||
web_app,"website,webapp,browser,SPA,PWA","SPA or MPA?;Browser support?;SEO needed?;Real-time?;Accessibility?","browser_matrix;responsive_design;performance_targets;seo_strategy;accessibility_level","native_features;cli_commands","web standards;WCAG guidelines","New interaction;WebAssembly use"
|
||||
game,"game,player,gameplay,level,character","REDIRECT TO GAME WORKFLOWS","game-brief;GDD","most_sections","game design patterns","Novel mechanics;Genre mixing"
|
||||
desktop_app,"desktop,Windows,Mac,Linux,native","Cross-platform?;Auto-update?;System integration?;Offline?","platform_support;system_integration;update_strategy;offline_capabilities","web_seo;mobile_features","desktop guidelines;platform requirements","Desktop AI;System automation"
|
||||
iot_embedded,"IoT,embedded,device,sensor,hardware","Hardware specs?;Connectivity?;Power constraints?;Security?;OTA updates?","hardware_reqs;connectivity_protocol;power_profile;security_model;update_mechanism","visual_ui;browser_support","IoT standards;protocol specs","Edge AI;New sensors"
|
||||
blockchain_web3,"blockchain,crypto,DeFi,NFT,smart contract","Chain selection?;Wallet integration?;Gas optimization?;Security audit?","chain_specs;wallet_support;smart_contracts;security_audit;gas_optimization","traditional_auth;centralized_db","blockchain standards;security patterns","Novel tokenomics;DAO structure"
|
||||
|
|
|
@ -19,14 +19,10 @@ instructions: "{installed_path}/instructions.md"
|
|||
|
||||
# Templates
|
||||
prd_template: "{installed_path}/prd-template.md"
|
||||
epics_template: "{installed_path}/epics-template.md"
|
||||
|
||||
# Output files
|
||||
status_file: "{output_folder}/bmm-workflow-status.md"
|
||||
status_file: "{output_folder}/bmm-workflow-status.yaml"
|
||||
default_output_file: "{output_folder}/PRD.md"
|
||||
epics_output_file: "{output_folder}/epics.md"
|
||||
technical_decisions_file: "{output_folder}/technical-decisions.md"
|
||||
technical_decisions_template: "{project-root}/bmad/bmm/_module-installer/assets/technical-decisions.md"
|
||||
|
||||
# Recommended input documents
|
||||
recommended_inputs:
|
||||
|
|
@ -40,7 +36,15 @@ web_bundle:
|
|||
description: "Unified PRD workflow for project levels 2-4. Produces strategic PRD and tactical epic breakdown. Hands off to architecture workflow for technical design. Note: Level 0-1 use tech-spec workflow."
|
||||
author: "BMad"
|
||||
instructions: "bmad/bmm/workflows/2-plan-workflows/prd/instructions.md"
|
||||
validation: "bmad/bmm/workflows/2-plan-workflows/prd/checklist.md"
|
||||
web_bundle_files:
|
||||
- "bmad/bmm/workflows/2-plan-workflows/prd/instructions.md"
|
||||
- "bmad/bmm/workflows/2-plan-workflows/prd/prd-template.md"
|
||||
- "bmad/bmm/workflows/2-plan-workflows/prd/epics-template.md"
|
||||
- "bmad/bmm/workflows/2-plan-workflows/prd/project-types.csv"
|
||||
- "bmad/bmm/workflows/2-plan-workflows/prd/domain-complexity.csv"
|
||||
- "bmad/bmm/workflows/2-plan-workflows/prd/checklist.md"
|
||||
- "bmad/bmm/workflows/2-plan-workflows/prd/create-epics-and-stories/workflow.yaml"
|
||||
- "bmad/bmm/workflows/2-plan-workflows/prd/create-epics-and-stories/instructions.md"
|
||||
- "bmad/bmm/workflows/2-plan-workflows/prd/create-epics-and-stories/epics-template.md"
|
||||
child_workflows:
|
||||
- create-epics-and-stories: "bmad/bmm/workflows/2-plan-workflows/prd/create-epics-and-stories/workflow.yaml"
|
||||
|
|
|
|||
|
|
@ -1,4 +1,4 @@
|
|||
# Decision Architecture
|
||||
# Architecture
|
||||
|
||||
## Executive Summary
|
||||
|
||||
|
|
|
|||
|
|
@ -35,7 +35,7 @@
|
|||
<check if="project_level < 3">
|
||||
<output>**Note: Level {{project_level}} Project**
|
||||
|
||||
Decision Architecture is typically for Level 3-4 projects, but can be used for any project that needs architectural planning.
|
||||
The Detailed Architecture is typically for Level 3-4 projects, but can be used for any project that needs architectural planning.
|
||||
|
||||
For Level {{project_level}}, we'll keep the architecture appropriately scoped.
|
||||
</output>
|
||||
|
|
@ -70,11 +70,11 @@ For Level {{project_level}}, we'll keep the architecture appropriately scoped.
|
|||
|
||||
Decision Architecture works from your Product Requirements Document (PRD).
|
||||
|
||||
Looking for: bmm-PRD.md, PRD.md, or product-requirements.md in {output_folder}
|
||||
Looking for: _PRD_, PRD.md, or prd/index.md + files in {output_folder}
|
||||
|
||||
Please run the PRD workflow first to define your requirements.
|
||||
|
||||
Run: `workflow prd`
|
||||
Architect: `create-prd`
|
||||
</output>
|
||||
<action>Exit workflow - PRD required</action>
|
||||
</check>
|
||||
|
|
@ -82,7 +82,7 @@ Run: `workflow prd`
|
|||
</step>
|
||||
|
||||
<step n="1" goal="Load and understand project context">
|
||||
<action>Load the PRD using fuzzy matching: {prd_file}</action>
|
||||
<action>Load the PRD using fuzzy matching: {prd_file}, if the PRD is mulitple files in a folder, load the index file and all files associated with the PRD</action>
|
||||
<action>Load epics file using fuzzy matching: {epics_file}</action>
|
||||
|
||||
<action>Check for UX specification using fuzzy matching:
|
||||
|
|
@ -96,7 +96,7 @@ Run: `workflow prd`
|
|||
<action>Extract and understand from PRD: - Functional Requirements (what it must do) - Non-Functional Requirements (performance, security, compliance, etc.) - Epic structure and user stories - Acceptance criteria - Any technical constraints mentioned
|
||||
</action>
|
||||
|
||||
<action>Count and assess project scale: - Number of epics: {{epic_count}} - Number of stories: {{story_count}} - Complexity indicators (real-time, multi-tenant, regulated, etc.) - UX complexity level (if UX spec exists)
|
||||
<action>Count and assess project scale: - Number of epics: {{epic_count}} - Number of stories: {{story_count}} - Complexity indicators (real-time, multi-tenant, regulated, etc.) - UX complexity level (if UX spec exists) - Novel features
|
||||
</action>
|
||||
|
||||
<action>Reflect understanding back to {user_name}:
|
||||
|
|
@ -135,8 +135,8 @@ I see {{epic_count}} epics with {{story_count}} total stories.
|
|||
</action>
|
||||
</check>
|
||||
|
||||
<action>Search for relevant starter templates:
|
||||
<WebSearch>{{primary_technology}} starter template CLI create command latest 2024</WebSearch>
|
||||
<action>Search for relevant starter templates with websearch, examples:
|
||||
<WebSearch>{{primary_technology}} starter template CLI create command latest {date}</WebSearch>
|
||||
<WebSearch>{{primary_technology}} boilerplate generator latest options</WebSearch>
|
||||
</action>
|
||||
|
||||
|
|
@ -206,7 +206,7 @@ I see {{epic_count}} epics with {{story_count}} total stories.
|
|||
|
||||
<check if="no_starter_found_or_applicable">
|
||||
<action>Note: No standard starter template found for this project type.
|
||||
Will need to make all architectural decisions explicitly.</action>
|
||||
We will make all architectural decisions explicitly.</action>
|
||||
</check>
|
||||
|
||||
<template-output>starter_template_decision</template-output>
|
||||
|
|
@ -285,34 +285,39 @@ Let's work through the remaining {{remaining_count}} decisions."
|
|||
<action>Present the decision based on mode:
|
||||
<check if="mode == 'EXPERT'">
|
||||
"{{Decision_Category}}: {{Specific_Decision}}
|
||||
Options: {{concise_option_list_with_tradeoffs}}
|
||||
Recommendation: {{recommendation}} for {{reason}}"
|
||||
</check>
|
||||
|
||||
<check if="mode == 'INTERMEDIATE'">
|
||||
"Next decision: {{Human_Friendly_Category}}
|
||||
Options: {{concise_option_list_with_tradeoffs}}
|
||||
|
||||
We need to choose {{Specific_Decision}}.
|
||||
Recommendation: {{recommendation}} for {{reason}}"
|
||||
|
||||
Common options:
|
||||
{{option_list_with_brief_explanations}}
|
||||
</check>
|
||||
|
||||
For your project, {{recommendation}} would work well because {{reason}}."
|
||||
</check>
|
||||
<check if="mode == 'INTERMEDIATE'">
|
||||
"Next decision: {{Human_Friendly_Category}}
|
||||
|
||||
<check if="mode == 'BEGINNER'">
|
||||
"Let's talk about {{Human_Friendly_Category}}.
|
||||
We need to choose {{Specific_Decision}}.
|
||||
|
||||
{{Educational_Context_About_Why_This_Matters}}
|
||||
Common options:
|
||||
{{option_list_with_brief_explanations}}
|
||||
|
||||
Think of it like {{real_world_analogy}}.
|
||||
For your project, {{recommendation}} would work well because {{reason}}."
|
||||
|
||||
Your main options:
|
||||
{{friendly_options_with_pros_cons}}
|
||||
</check>
|
||||
|
||||
My suggestion: {{recommendation}}
|
||||
This is good for you because {{beginner_friendly_reason}}."
|
||||
</check>
|
||||
<check if="mode == 'BEGINNER'">
|
||||
"Let's talk about {{Human_Friendly_Category}}.
|
||||
|
||||
{{Educational_Context_About_Why_This_Matters}}
|
||||
|
||||
Think of it like {{real_world_analogy}}.
|
||||
|
||||
Your main options:
|
||||
{{friendly_options_with_pros_cons}}
|
||||
|
||||
My suggestion: {{recommendation}}
|
||||
This is good for you because {{beginner_friendly_reason}}."
|
||||
|
||||
</check>
|
||||
|
||||
</action>
|
||||
|
||||
|
|
@ -365,11 +370,7 @@ Provided by Starter: {{yes_if_from_starter}}
|
|||
</action>
|
||||
|
||||
<check if="{user_skill_level} == 'beginner'">
|
||||
<action>Explain why these matter:
|
||||
"These are rules that EVERY part of your app must follow.
|
||||
If we don't decide now, each AI agent will do it differently,
|
||||
and your app won't work properly when the pieces come together."
|
||||
</action>
|
||||
<action>Explain why these matter why its critical to go through and decide these things now.</action>
|
||||
</check>
|
||||
|
||||
<template-output>cross_cutting_decisions</template-output>
|
||||
|
|
|
|||
|
|
@ -19,7 +19,7 @@ recommended_inputs:
|
|||
- ux_spec: "UX specification with interface designs and interaction patterns (optional)"
|
||||
|
||||
# Input file references (fuzzy matched from output folder)
|
||||
prd_file: "{output_folder}/bmm-PRD.md or PRD.md or product-requirements.md"
|
||||
prd_file: "{output_folder}/*PRD*, PRD.md, or prd/index.md + files"
|
||||
epics_file: "{output_folder}/bmm-epics.md or epics.md or user-stories.md"
|
||||
ux_spec_file: "{output_folder}/ux-spec.md or ux-specification.md or user-experience.md"
|
||||
|
||||
|
|
|
|||
Loading…
Reference in New Issue