mirror of
https://github.com/bmadcode/BMAD-METHOD.git
synced 2025-12-29 16:14:59 +00:00
Major Enhancements:
- Installation path is now fully configurable, allowing users to specify custom installation directories during setup
- Default installation location changed to .bmad (hidden directory) for cleaner project root organization
Web Bundle Improvements:
- All web bundles (single agent and team) now include party mode support for multi-agent collaboration!
- Advanced elicitation capabilities integrated into standalone agents
- All bundles enhanced with party mode agent manifests
- Added default-party.csv files to bmm, bmgd, and cis module teams
- The default party file is what will be used with single agent bundles. teams can customize for different party configurations before web bundling through a setting in the team yaml file
- New web bundle outputs for all agents (analyst, architect, dev, pm, sm, tea, tech-writer, ux-designer, game-*, creative-squad)
Phase 4 Workflow Updates (In Progress):
- Initiated shift to separate phase 4 implementation artifacts from documentation
- Phase 4 implementation artifacts (stories, code review, sprint plan, context files) will move to dedicated location outside docs folder
- Installer questions and configuration added for artifact path selection
- Updated workflow.yaml files for code-review, sprint-planning, story-context, epic-tech-context, and retrospective workflows to support this, but still might require some udpates
Additional Changes:
- New agent and action command header models for standardization
- Enhanced web-bundle-activation-steps fragment
- Updated web-bundler.js to support new structure
- VS Code settings updated for new .bmad directory
- Party mode instructions and workflow enhanced for better orchestration
IDE Installer Updates:
- Show version number of installer in cli
- improved Installer UX
- Gemini TOML Improved to have clear loading instructions with @ commands
- All tools agent launcher mds improved to use a central file template critical indication isntead of hardcoding in 2 different locations.
This commit is contained in:
350
.bmad/bmm/workflows/2-plan-workflows/prd/checklist.md
Normal file
350
.bmad/bmm/workflows/2-plan-workflows/prd/checklist.md
Normal file
@@ -0,0 +1,350 @@
|
||||
# PRD + Epics + Stories Validation Checklist
|
||||
|
||||
**Purpose**: Comprehensive validation that PRD, epics, and stories form a complete, implementable product plan.
|
||||
|
||||
**Scope**: Validates the complete planning output (PRD.md + epics.md) for Levels 2-4 software projects
|
||||
|
||||
**Expected Outputs**:
|
||||
|
||||
- PRD.md with complete requirements
|
||||
- epics.md with detailed epic and story breakdown
|
||||
- Updated bmm-workflow-status.yaml
|
||||
|
||||
---
|
||||
|
||||
## 1. PRD Document Completeness
|
||||
|
||||
### 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. Functional Requirements Quality
|
||||
|
||||
### FR Format and Structure
|
||||
|
||||
- [ ] 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)
|
||||
|
||||
### FR Completeness
|
||||
|
||||
- [ ] 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
|
||||
|
||||
### FR Organization
|
||||
|
||||
- [ ] 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 Document Completeness
|
||||
|
||||
### Required Files
|
||||
|
||||
- [ ] 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. FR Coverage Validation (CRITICAL)
|
||||
|
||||
### 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
|
||||
|
||||
- [ ] 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
|
||||
|
||||
---
|
||||
|
||||
## 9. Readiness for 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
|
||||
|
||||
### Track-Appropriate Detail
|
||||
|
||||
**If BMad Method:**
|
||||
|
||||
- [ ] PRD supports full architecture workflow
|
||||
- [ ] Epic structure supports phased delivery
|
||||
- [ ] Scope appropriate for product/platform development
|
||||
- [ ] Clear value delivery through epic sequence
|
||||
|
||||
**If Enterprise Method:**
|
||||
|
||||
- [ ] PRD addresses enterprise requirements (security, compliance, multi-tenancy)
|
||||
- [ ] Epic structure supports extended planning phases
|
||||
- [ ] Scope includes security, devops, and test strategy considerations
|
||||
- [ ] Clear value delivery with enterprise gates
|
||||
|
||||
---
|
||||
|
||||
## 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)
|
||||
- [ ] ❌ **Epics don't cover all FRs** (orphaned requirements)
|
||||
- [ ] ❌ **FRs contain technical implementation details** (should be in architecture)
|
||||
- [ ] ❌ **No FR traceability to stories** (can't validate coverage)
|
||||
- [ ] ❌ **Template variables unfilled** (incomplete document)
|
||||
|
||||
---
|
||||
|
||||
## Validation Summary
|
||||
|
||||
**Total Validation Points:** ~85
|
||||
|
||||
### Scoring Guide
|
||||
|
||||
- **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
|
||||
|
||||
---
|
||||
|
||||
## 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,52 @@
|
||||
# {{project_name}} - Epic Breakdown
|
||||
|
||||
**Author:** {{user_name}}
|
||||
**Date:** {{date}}
|
||||
**Project Level:** {{project_level}}
|
||||
**Target Scale:** {{target_scale}}
|
||||
|
||||
---
|
||||
|
||||
## Overview
|
||||
|
||||
This document provides the complete epic and story breakdown for {{project_name}}, decomposing the requirements from the [PRD](./PRD.md) into implementable stories.
|
||||
|
||||
{{epics_summary}}
|
||||
|
||||
---
|
||||
|
||||
<!-- Repeat for each epic (N = 1, 2, 3...) -->
|
||||
|
||||
## Epic {{N}}: {{epic_title_N}}
|
||||
|
||||
{{epic_goal_N}}
|
||||
|
||||
<!-- Repeat for each story (M = 1, 2, 3...) within epic N -->
|
||||
|
||||
### Story {{N}}.{{M}}: {{story_title_N_M}}
|
||||
|
||||
As a {{user_type}},
|
||||
I want {{capability}},
|
||||
So that {{value_benefit}}.
|
||||
|
||||
**Acceptance Criteria:**
|
||||
|
||||
**Given** {{precondition}}
|
||||
**When** {{action}}
|
||||
**Then** {{expected_outcome}}
|
||||
|
||||
**And** {{additional_criteria}}
|
||||
|
||||
**Prerequisites:** {{dependencies_on_previous_stories}}
|
||||
|
||||
**Technical Notes:** {{implementation_guidance}}
|
||||
|
||||
<!-- End story repeat -->
|
||||
|
||||
---
|
||||
|
||||
<!-- End epic repeat -->
|
||||
|
||||
---
|
||||
|
||||
_For implementation: Use the `create-story` workflow to generate individual story implementation plans from this epic breakdown._
|
||||
@@ -0,0 +1,169 @@
|
||||
# Epic and Story Decomposition - Intent-Based 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 development agents</critical>
|
||||
<critical>EVERY story must be completable by a single dev agent in one focused session</critical>
|
||||
<critical>Communicate all responses in {communication_language} and adapt 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>
|
||||
<critical>Input documents specified in workflow.yaml input_file_patterns - workflow engine handles fuzzy matching, whole vs sharded document discovery automatically</critical>
|
||||
|
||||
<workflow>
|
||||
|
||||
<step n="1" goal="Load PRD and extract requirements">
|
||||
<action>Welcome {user_name} to epic and story planning
|
||||
|
||||
Load required documents (fuzzy match, handle both whole and sharded):
|
||||
|
||||
- PRD.md (required)
|
||||
- domain-brief.md (if exists)
|
||||
- product-brief.md (if exists)
|
||||
|
||||
Extract from PRD:
|
||||
|
||||
- All functional requirements
|
||||
- Non-functional requirements
|
||||
- Domain considerations and compliance needs
|
||||
- Project type and complexity
|
||||
- MVP vs growth vs vision scope boundaries
|
||||
|
||||
Understand the context:
|
||||
|
||||
- What makes this product special (the magic)
|
||||
- Technical constraints
|
||||
- User types and their goals
|
||||
- Success criteria</action>
|
||||
</step>
|
||||
|
||||
<step n="2" goal="Propose epic structure from natural groupings">
|
||||
<action>Analyze requirements and identify natural epic boundaries
|
||||
|
||||
INTENT: Find organic groupings that make sense for THIS product
|
||||
|
||||
Look for natural patterns:
|
||||
|
||||
- Features that work together cohesively
|
||||
- User journeys that connect
|
||||
- Business capabilities that cluster
|
||||
- Domain requirements that relate (compliance, validation, security)
|
||||
- Technical systems that should be built together
|
||||
|
||||
Name epics based on VALUE, not technical layers:
|
||||
|
||||
- Good: "User Onboarding", "Content Discovery", "Compliance Framework"
|
||||
- Avoid: "Database Layer", "API Endpoints", "Frontend"
|
||||
|
||||
Each epic should:
|
||||
|
||||
- Have clear business goal and user value
|
||||
- Be independently valuable
|
||||
- Contain 3-8 related capabilities
|
||||
- Be deliverable in cohesive phase
|
||||
|
||||
For greenfield projects:
|
||||
|
||||
- First epic MUST establish foundation (project setup, core infrastructure, deployment pipeline)
|
||||
- Foundation enables all subsequent work
|
||||
|
||||
For complex domains:
|
||||
|
||||
- Consider dedicated compliance/regulatory epics
|
||||
- Group validation and safety requirements logically
|
||||
- Note expertise requirements
|
||||
|
||||
Present proposed epic structure showing:
|
||||
|
||||
- Epic titles with clear value statements
|
||||
- High-level scope of each epic
|
||||
- Suggested sequencing
|
||||
- Why this grouping makes sense</action>
|
||||
|
||||
<template-output>epics_summary</template-output>
|
||||
<invoke-task halt="true">{project-root}/.bmad/core/tasks/adv-elicit.xml</invoke-task>
|
||||
</step>
|
||||
|
||||
<step n="3" goal="Decompose each epic into bite-sized stories" repeat="for-each-epic">
|
||||
<action>Break down Epic {{N}} into small, implementable stories
|
||||
|
||||
INTENT: Create stories sized for single dev agent completion
|
||||
|
||||
For each epic, generate:
|
||||
|
||||
- Epic title as `epic_title_{{N}}`
|
||||
- Epic goal/value as `epic_goal_{{N}}`
|
||||
- All stories as repeated pattern `story_title_{{N}}_{{M}}` for each story M
|
||||
|
||||
CRITICAL for Epic 1 (Foundation):
|
||||
|
||||
- Story 1.1 MUST be project setup/infrastructure initialization
|
||||
- Sets up: repo structure, build system, deployment pipeline basics, core dependencies
|
||||
- Creates foundation for all subsequent stories
|
||||
- Note: Architecture workflow will flesh out technical details
|
||||
|
||||
Each story should follow BDD-style acceptance criteria:
|
||||
|
||||
**Story Pattern:**
|
||||
As a [user type],
|
||||
I want [specific capability],
|
||||
So that [clear value/benefit].
|
||||
|
||||
**Acceptance Criteria using BDD:**
|
||||
Given [precondition or initial state]
|
||||
When [action or trigger]
|
||||
Then [expected outcome]
|
||||
|
||||
And [additional criteria as needed]
|
||||
|
||||
**Prerequisites:** Only previous stories (never forward dependencies)
|
||||
|
||||
**Technical Notes:** Implementation guidance, affected components, compliance requirements
|
||||
|
||||
Ensure stories are:
|
||||
|
||||
- Vertically sliced (deliver complete functionality, not just one layer)
|
||||
- Sequentially ordered (logical progression, no forward dependencies)
|
||||
- Independently valuable when possible
|
||||
- Small enough for single-session completion
|
||||
- Clear enough for autonomous implementation
|
||||
|
||||
For each story in epic {{N}}, output variables following this pattern:
|
||||
|
||||
- story*title*{{N}}_1, story_title_{{N}}\_2, etc.
|
||||
- Each containing: user story, BDD acceptance criteria, prerequisites, technical notes</action>
|
||||
|
||||
<template-output>epic*title*{{N}}</template-output>
|
||||
<template-output>epic*goal*{{N}}</template-output>
|
||||
|
||||
<action>For each story M in epic {{N}}, generate story content</action>
|
||||
<template-output>story*title*{{N}}\_{{M}}</template-output>
|
||||
|
||||
<invoke-task halt="true">{project-root}/.bmad/core/tasks/adv-elicit.xml</invoke-task>
|
||||
</step>
|
||||
|
||||
<step n="4" goal="Review and finalize epic breakdown">
|
||||
<action>Review the complete epic breakdown for quality and completeness
|
||||
|
||||
Validate:
|
||||
|
||||
- All functional requirements from PRD are covered by stories
|
||||
- Epic 1 establishes proper foundation
|
||||
- All stories are vertically sliced
|
||||
- No forward dependencies exist
|
||||
- Story sizing is appropriate for single-session completion
|
||||
- BDD acceptance criteria are clear and testable
|
||||
- Domain/compliance requirements are properly distributed
|
||||
- Sequencing enables incremental value delivery
|
||||
|
||||
Confirm with {user_name}:
|
||||
|
||||
- Epic structure makes sense
|
||||
- Story breakdown is actionable
|
||||
- Dependencies are clear
|
||||
- BDD format provides clarity
|
||||
- Ready for architecture and implementation phases</action>
|
||||
|
||||
<template-output>epic_breakdown_summary</template-output>
|
||||
</step>
|
||||
|
||||
</workflow>
|
||||
@@ -0,0 +1,45 @@
|
||||
# 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
|
||||
|
||||
# Input requirements
|
||||
recommended_inputs:
|
||||
- prd: "Product Requirements Document with FRs and NFRs"
|
||||
- product_brief: "Product Brief with vision and goals (optional)"
|
||||
- domain_brief: "Domain-specific requirements and context (optional)"
|
||||
|
||||
# Smart input file references - handles both whole docs and sharded docs
|
||||
# Priority: Whole document first, then sharded version
|
||||
input_file_patterns:
|
||||
prd:
|
||||
whole: "{output_folder}/*prd*.md"
|
||||
sharded: "{output_folder}/*prd*/index.md"
|
||||
|
||||
product_brief:
|
||||
whole: "{output_folder}/*product*brief*.md"
|
||||
sharded: "{output_folder}/*product*brief*/index.md"
|
||||
|
||||
domain_brief:
|
||||
whole: "{output_folder}/*domain*brief*.md"
|
||||
sharded: "{output_folder}/*domain*brief*/index.md"
|
||||
|
||||
# Module path and component files
|
||||
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"
|
||||
|
||||
# Output configuration
|
||||
default_output_file: "{output_folder}/epics.md"
|
||||
|
||||
standalone: true
|
||||
@@ -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"
|
||||
|
408
.bmad/bmm/workflows/2-plan-workflows/prd/instructions.md
Normal file
408
.bmad/bmm/workflows/2-plan-workflows/prd/instructions.md
Normal file
@@ -0,0 +1,408 @@
|
||||
# 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>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>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>
|
||||
<critical>Input documents specified in workflow.yaml input_file_patterns - workflow engine handles fuzzy matching, whole vs sharded document discovery automatically</critical>
|
||||
|
||||
<workflow>
|
||||
|
||||
<step n="0" goal="Validate workflow readiness" tag="workflow-status">
|
||||
<action>Check if {status_file} exists</action>
|
||||
|
||||
<action if="status file not found">Set standalone_mode = true</action>
|
||||
|
||||
<check if="status file found">
|
||||
<action>Load the FULL file: {status_file}</action>
|
||||
<action>Parse workflow_status section</action>
|
||||
<action>Check status of "prd" workflow</action>
|
||||
<action>Get project_track from YAML metadata</action>
|
||||
<action>Find first non-completed workflow (next expected workflow)</action>
|
||||
|
||||
<check if="project_track is Quick Flow">
|
||||
<output>**Quick Flow Track - Redirecting**
|
||||
|
||||
Quick Flow projects use tech-spec workflow for implementation-focused planning.
|
||||
PRD is for BMad Method and Enterprise Method tracks that need comprehensive requirements.</output>
|
||||
<action>Exit and suggest tech-spec workflow</action>
|
||||
</check>
|
||||
|
||||
<check if="prd status is file path (already completed)">
|
||||
<output>⚠️ PRD already completed: {{prd status}}</output>
|
||||
<ask>Re-running will overwrite the existing PRD. Continue? (y/n)</ask>
|
||||
<check if="n">
|
||||
<output>Exiting. Use workflow-status to see your next step.</output>
|
||||
<action>Exit workflow</action>
|
||||
</check>
|
||||
</check>
|
||||
|
||||
<action>Set standalone_mode = false</action>
|
||||
</check>
|
||||
</step>
|
||||
|
||||
<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
|
||||
|
||||
Load references:
|
||||
{installed_path}/project-types.csv
|
||||
{installed_path}/domain-complexity.csv
|
||||
|
||||
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 → Inform user that game development requires the BMGD module (BMad Game Development)
|
||||
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>
|
||||
<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="Success Definition">
|
||||
<action>Define what winning looks like for THIS specific product
|
||||
|
||||
INTENT: Meaningful success criteria, not generic metrics
|
||||
|
||||
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>
|
||||
<invoke-task halt="true">{project-root}/.bmad/core/tasks/adv-elicit.xml</invoke-task>
|
||||
</step>
|
||||
|
||||
<step n="3" goal="Scope Definition">
|
||||
<action>Smart scope negotiation - find the sweet spot
|
||||
|
||||
The Scoping Game:
|
||||
|
||||
1. "What must work for this to be useful?" → MVP
|
||||
2. "What makes it competitive?" → Growth
|
||||
3. "What's the dream version?" → Vision
|
||||
|
||||
Challenge scope creep conversationally:
|
||||
|
||||
- "Could that wait until after launch?"
|
||||
- "Is that essential for proving the concept?"
|
||||
|
||||
For complex domains:
|
||||
|
||||
- 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>
|
||||
<invoke-task halt="true">{project-root}/.bmad/core/tasks/adv-elicit.xml</invoke-task>
|
||||
</step>
|
||||
|
||||
<step n="4" goal="Domain-Specific Exploration" optional="true">
|
||||
<action>Only if complex domain detected or domain-brief exists
|
||||
|
||||
Synthesize domain requirements that will shape everything:
|
||||
|
||||
- Regulatory requirements
|
||||
- Compliance needs
|
||||
- Industry standards
|
||||
- Safety/risk factors
|
||||
- Required validations
|
||||
- Special expertise needed
|
||||
|
||||
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="Mobile project">
|
||||
<template-output>platform_requirements</template-output>
|
||||
<template-output>device_features</template-output>
|
||||
</check>
|
||||
|
||||
<check if="SaaS B2B project">
|
||||
<template-output>tenant_model</template-output>
|
||||
<template-output>permission_matrix</template-output>
|
||||
</check>
|
||||
</step>
|
||||
|
||||
<step n="7" goal="UX Principles" if="project has UI or UX">
|
||||
<action>Only if product has a UI
|
||||
|
||||
Light touch on UX - not full design:
|
||||
|
||||
- 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>
|
||||
</step>
|
||||
|
||||
<step n="8" goal="Functional Requirements Synthesis">
|
||||
<action>Transform everything discovered into clear functional requirements
|
||||
|
||||
Pull together:
|
||||
|
||||
- Core features from scope
|
||||
- Domain-mandated features
|
||||
- Project-type specific needs
|
||||
- Innovation requirements
|
||||
|
||||
Organize by capability, not technology:
|
||||
|
||||
- User Management (not "auth system")
|
||||
- Content Discovery (not "search algorithm")
|
||||
- Team Collaboration (not "websockets")
|
||||
|
||||
Each requirement should:
|
||||
|
||||
- Be specific and measurable
|
||||
- Connect to user value
|
||||
- Include acceptance criteria
|
||||
- Note domain constraints
|
||||
|
||||
The magic thread:
|
||||
Highlight which requirements deliver the special experience</action>
|
||||
|
||||
<template-output>functional_requirements_complete</template-output>
|
||||
<invoke-task halt="true">{project-root}/.bmad/core/tasks/adv-elicit.xml</invoke-task>
|
||||
</step>
|
||||
|
||||
<step n="9" goal="Non-Functional Requirements Discovery">
|
||||
<action>Only document NFRs that matter for THIS product
|
||||
|
||||
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
|
||||
|
||||
For each NFR:
|
||||
|
||||
- Why it matters for THIS product
|
||||
- Specific measurable criteria
|
||||
- Domain-driven requirements
|
||||
|
||||
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>
|
||||
</step>
|
||||
|
||||
<step n="10" goal="Review PRD and transition to epics">
|
||||
<action>Review the PRD we've built together
|
||||
|
||||
"Let's review what we've captured:
|
||||
|
||||
- Vision: [summary]
|
||||
- Success: [key metrics]
|
||||
- Scope: [MVP highlights]
|
||||
- Requirements: [count] functional, [count] non-functional
|
||||
- Special considerations: [domain/innovation]
|
||||
|
||||
Does this capture your product vision?"</action>
|
||||
|
||||
<template-output>prd_summary</template-output>
|
||||
<invoke-task halt="true">{project-root}/.bmad/core/tasks/adv-elicit.xml</invoke-task>
|
||||
|
||||
<action>After PRD review and refinement complete:
|
||||
|
||||
"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_track based on workflow status (BMad Method or Enterprise Method)
|
||||
Generate epic_details for the epics breakdown document</action>
|
||||
|
||||
<template-output>project_track</template-output>
|
||||
<template-output>epic_details</template-output>
|
||||
</step>
|
||||
|
||||
<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: {status_file}</action>
|
||||
<action>Update workflow_status["prd"] = "{default_output_file}"</action>
|
||||
<action>Save file, preserving ALL comments and structure</action>
|
||||
</check>
|
||||
|
||||
<output>**✅ PRD Complete, {user_name}!**
|
||||
|
||||
Your product requirements are documented and ready for implementation.
|
||||
|
||||
**Created:**
|
||||
|
||||
- **PRD.md** - Complete requirements adapted to {project_type} and {domain}
|
||||
|
||||
**Next Steps:**
|
||||
|
||||
1. **Epic Breakdown** (Required)
|
||||
Run: `workflow create-epics-and-stories` to decompose requirements into implementable stories
|
||||
|
||||
2. **UX Design** (If UI exists)
|
||||
Run: `workflow ux-design` for detailed user experience design
|
||||
|
||||
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>
|
||||
237
.bmad/bmm/workflows/2-plan-workflows/prd/prd-template.md
Normal file
237
.bmad/bmm/workflows/2-plan-workflows/prd/prd-template.md
Normal file
@@ -0,0 +1,237 @@
|
||||
# {{project_name}} - Product Requirements Document
|
||||
|
||||
**Author:** {{user_name}}
|
||||
**Date:** {{date}}
|
||||
**Version:** 1.0
|
||||
|
||||
---
|
||||
|
||||
## Executive Summary
|
||||
|
||||
{{vision_alignment}}
|
||||
|
||||
### What Makes This Special
|
||||
|
||||
{{product_magic_essence}}
|
||||
|
||||
---
|
||||
|
||||
## Project Classification
|
||||
|
||||
**Technical Type:** {{project_type}}
|
||||
**Domain:** {{domain_type}}
|
||||
**Complexity:** {{complexity_level}}
|
||||
|
||||
{{project_classification}}
|
||||
|
||||
{{#if domain_context_summary}}
|
||||
|
||||
### Domain Context
|
||||
|
||||
{{domain_context_summary}}
|
||||
{{/if}}
|
||||
|
||||
---
|
||||
|
||||
## Success Criteria
|
||||
|
||||
{{success_criteria}}
|
||||
|
||||
{{#if business_metrics}}
|
||||
|
||||
### Business Metrics
|
||||
|
||||
{{business_metrics}}
|
||||
{{/if}}
|
||||
|
||||
---
|
||||
|
||||
## 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
|
||||
|
||||
{{key_interactions}}
|
||||
{{/if}}
|
||||
|
||||
---
|
||||
|
||||
## Functional Requirements
|
||||
|
||||
{{functional_requirements_complete}}
|
||||
|
||||
---
|
||||
|
||||
## Non-Functional Requirements
|
||||
|
||||
{{#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._
|
||||
11
.bmad/bmm/workflows/2-plan-workflows/prd/project-types.csv
Normal file
11
.bmad/bmm/workflows/2-plan-workflows/prd/project-types.csv
Normal file
@@ -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"
|
||||
|
46
.bmad/bmm/workflows/2-plan-workflows/prd/workflow.yaml
Normal file
46
.bmad/bmm/workflows/2-plan-workflows/prd/workflow.yaml
Normal file
@@ -0,0 +1,46 @@
|
||||
# Product Requirements Document (PRD) Workflow
|
||||
name: prd
|
||||
description: "Unified PRD workflow for BMad Method and Enterprise Method tracks. Produces strategic PRD and tactical epic breakdown. Hands off to architecture workflow for technical design. Note: Quick Flow track uses tech-spec workflow."
|
||||
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"
|
||||
instructions: "{installed_path}/instructions.md"
|
||||
|
||||
# Templates
|
||||
prd_template: "{installed_path}/prd-template.md"
|
||||
|
||||
# Output files
|
||||
status_file: "{output_folder}/bmm-workflow-status.yaml"
|
||||
default_output_file: "{output_folder}/PRD.md"
|
||||
|
||||
# Recommended input documents
|
||||
recommended_inputs:
|
||||
- product_brief: "{output_folder}/product-brief.md"
|
||||
- market_research: "{output_folder}/market-research.md"
|
||||
|
||||
# Smart input file references - handles both whole docs and sharded docs
|
||||
# Priority: Whole document first, then sharded version
|
||||
input_file_patterns:
|
||||
product_brief:
|
||||
whole: "{output_folder}/*brief*.md"
|
||||
sharded: "{output_folder}/*brief*/index.md"
|
||||
|
||||
research:
|
||||
whole: "{output_folder}/*research*.md"
|
||||
sharded: "{output_folder}/*research*/index.md"
|
||||
|
||||
document_project:
|
||||
sharded: "{output_folder}/docs/index.md"
|
||||
|
||||
standalone: true
|
||||
Reference in New Issue
Block a user