External/BMAD-METHOD
1
0
Fork 0
mirror of https://github.com/bmadcode/BMAD-METHOD.git synced 2025-12-17 17:55:34 +00:00
Code Issues Packages Projects Releases Wiki Activity

convert create epics and stories and implementation readiness to the new workflow step format

Browse Source
This commit is contained in:
Brian Madison 2025-12-02 19:21:31 -06:00
parent 6365a63dff
commit aa30ef3e79
21 changed files with 2143 additions and 1231 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

80
src/modules/bmm/workflows/3-solutioning/create-epics-and-stories/epics-template.md
View File

@ -1,80 +0,0 @@
# {{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.
**Living Document Notice:** This is the initial version. It will be updated after UX Design and Architecture workflows add interaction and technical details to stories.
{{epics_summary}}
---
## Functional Requirements Inventory
{{fr_inventory}}
---
## FR Coverage Map
{{fr_coverage_map}}
---
<!-- 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 -->
---
## FR Coverage Matrix
{{fr_coverage_matrix}}
---
## Summary
{{epic_breakdown_summary}}
---
_For implementation: Use the `create-story` workflow to generate individual story implementation plans from this epic breakdown._
_This document will be updated after UX Design and Architecture workflows to incorporate interaction details and technical decisions._

387
src/modules/bmm/workflows/3-solutioning/create-epics-and-stories/instructions.md
View File

@ -1,387 +0,0 @@
# Epic and Story Creation with Full Technical Context
<critical>The workflow execution engine is governed by: {project-root}/{bmad_folder}/core/tasks/workflow.xml</critical>
<critical>You MUST have already loaded and processed: {installed_path}/workflow.yaml</critical>
<critical>PREREQUISITES: PRD.md AND Architecture.md MUST be completed before running this workflow</critical>
<critical>UX Design.md is highly recommended if the product has user interfaces</critical>
<critical>EVERY story must be completable by a single dev agent in one focused session</critical>
<critical>⚠️ EPIC STRUCTURE PRINCIPLE: Each epic MUST deliver USER VALUE, not just technical capability. Epics are NOT organized by technical layers (database, API, frontend). Each epic should result in something USERS can actually use or benefit from. Exception: Foundation/setup stories at the start of first epic are acceptable.</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>
<critical>⚠️ ABSOLUTELY NO TIME ESTIMATES - NEVER mention hours, days, weeks, months, or ANY time-based predictions. AI has fundamentally changed development speed - what once took teams weeks/months can now be done by one person in hours. DO NOT give ANY time estimates whatsoever.</critical>
<critical>⚠️ CHECKPOINT PROTOCOL: After EVERY <template-output> tag, you MUST follow workflow.xml substep 2c: SAVE content to file immediately → SHOW checkpoint separator (━━━━━━━━━━━━━━━━━━━━━━━) → DISPLAY generated content → PRESENT options [a]Advanced Elicitation/[c]Continue/[p]Party-Mode/[y]YOLO → WAIT for user response. Never batch saves or skip checkpoints.</critical>
<workflow>
<step n="0" goal="Validate prerequisites and load all context">
<action>Welcome {user_name} to comprehensive epic and story creation</action>
<action>**CRITICAL PREREQUISITE VALIDATION:**</action>
<action>Verify required documents exist and are complete:
1. **PRD.md** - Contains functional requirements (FRs) and product scope
2. **Architecture.md** - Contains technical decisions, API contracts, data models
3. **UX Design.md** (if UI exists) - Contains interaction patterns, mockups, user flows
Missing any required document means this workflow cannot proceed successfully.</action>
<check if="!prd_content">
<output>❌ **PREREQUISITE FAILED: PRD.md not found**
The PRD is required to define what functionality needs to be built.
Please complete the PRD workflow first, then run this workflow again.</output>
<exit workflow="Missing required PRD document"/>
</check>
<check if="!architecture_content">
<output>❌ **PREREQUISITE FAILED: Architecture.md not found**
The Architecture document is required to provide technical implementation context for stories.
Please complete the Architecture workflow first, then run this workflow again.</output>
<exit workflow="Missing required Architecture document"/>
</check>
<action>List the documents loaded</action>
<action>**LOAD ALL CONTEXT DOCUMENTS:**</action>
<action>Load and analyze PRD.md:
Extract ALL functional requirements:
- Complete FR inventory (FR1, FR2, FR3...)
- Non-functional requirements and constraints
- Project scope boundaries (MVP vs growth vs vision)
- User types and their goals
- Success criteria
- Technical constraints
- Compliance requirements
**FR Inventory Creation:**
List every functional requirement with description for coverage tracking.
</action>
<action>Load and analyze Architecture.md:
Extract ALL technical implementation context relevant to the PRD functional requirements and project needs:
Scan comprehensively for any technical details needed to create complete user stories, including but not limited to:
- Technology stack decisions and framework choices
- API design, contracts, and integration patterns
- Data models, schemas, and relationships
- Authentication, authorization, and security patterns
- Performance requirements and scaling approaches
- Error handling, logging, and monitoring strategies
- Deployment architecture and infrastructure considerations
- Any other technical decisions, patterns, or constraints that impact implementation
Focus on extracting whatever technical context exists in the Architecture document that will be needed to create comprehensive, actionable user stories for all PRD requirements.
</action>
<action if="UX Design Exists">
Load and analyze UX Design.md:
Extract ALL user experience context relevant to the PRD functional requirements and project needs:
Scan comprehensively for any user experience details needed to create complete user stories, including but not limited to:
- User flows, journey patterns, and interaction design
- Screen layouts, components, and visual specifications
- Interaction patterns, behaviors, and micro-interactions
- Responsive design and mobile-first considerations
- Accessibility requirements and inclusive design patterns
- Animations, transitions, and feedback mechanisms
- Error states, validation patterns, and user guidance
- Any other UX/UI decisions, patterns, or specifications that impact implementation
Focus on extracting whatever user experience context exists in the UX document that will be needed to create comprehensive, actionable user stories for all PRD requirements.
</action>
<template-output>context_validation</template-output>
<template-output>fr_inventory</template-output>
</step>
<step n="1" goal="Design epic structure with full technical context">
<action>**STRATEGIC EPIC PLANNING WITH COMPLETE CONTEXT:**</action>
<action>Now that you have ALL available context (PRD + Architecture + UX), design epics that deliver incremental user value while leveraging the technical design decisions.
**EPIC DESIGN PRINCIPLES:**
1. **User-Value First**: Each epic must enable users to accomplish something meaningful
2. **Leverage Architecture**: Build upon the technical decisions already made
3. **Incremental Delivery**: Each epic should be independently valuable
4. **Logical Dependencies**: Dependencies should flow naturally, not artificially
**USE YOUR FULL CONTEXT:**
From PRD: Group related functional requirements that deliver user outcomes
From Architecture: Respect technical boundaries and integration points
From UX: Design around user journeys and interaction flows
**VALID EPIC EXAMPLES:**
✅ **CORRECT - User Value with Technical Context:**
- Epic 1: Foundation Setup (infrastructure, deployment, core services)
- Epic 2: User Authentication & Profile Management (register, login, profile management)
- Epic 3: Content Creation & Management (create, edit, publish, organize content)
- Epic 4: Content Discovery & Interaction (browse, search, share, comment)
❌ **WRONG - Technical Layer Breakdown:**
- Epic 1: Database Schema & Models
- Epic 2: REST API Endpoints
- Epic 3: Frontend Components
- Epic 4: Authentication Service
**PRESENT YOUR EPIC STRUCTURE:**
For each proposed epic, provide:
- **Epic Title**: Value-based, not technical
- **User Value Statement**: What users can accomplish after this epic
- **PRD Coverage**: Which FRs this epic addresses
- **Technical Context**: How this leverages Architecture decisions
- **UX Integration**: How this incorporates user experience patterns (if available)
- **Dependencies**: What must come before (natural dependencies only)
**FOUNDATION EPIC GUIDELINES:**
For Epic 1, include technical foundation based on Architecture:
- Project setup and build system
- Core infrastructure and deployment pipeline
- Database schema setup
- Basic authentication foundation
- API framework setup
This enables all subsequent user-facing epics.
</action>
<template-output>epics_structure_plan</template-output>
<template-output>epics_technical_context</template-output>
</step>
<step n="2" goal="Create detailed stories with complete implementation context" repeat="for-each-epic">
<action>**EPIC {{N}} - COMPREHENSIVE STORY CREATION:**</action>
<action>For Epic {{N}}: {{epic_title}}, create bite-sized stories that incorporate ALL available context.
**STORY CREATION WITH FULL CONTEXT:**
For each story, you now have the complete picture:
- **WHAT to build** (from PRD FRs)
- **HOW to build it** (from Architecture decisions)
- **HOW users interact** (from UX patterns, if available)
**TRANSFORM STRATEGIC REQUIREMENTS INTO TACTICAL IMPLEMENTATION:**
PRD says: "Users can create accounts"
Architecture says: "Use PostgreSQL with bcrypt hashing, JWT tokens, rate limiting"
UX says: "Modal dialog with email/password fields, real-time validation, loading states"
Your story becomes: Specific implementation details with exact acceptance criteria
**STORY PATTERN FOR EACH EPIC {{N}}:**
**Epic Goal:** {{epic_goal}}
For each story M in Epic {{N}}:
- **User Story**: As a [user type], I want [specific capability], So that [value/benefit]
- **Acceptance Criteria**: BDD format with COMPLETE implementation details
- **Technical Implementation**: Specific guidance from Architecture
- **User Experience**: Exact interaction patterns from UX (if available)
- **Prerequisites**: Only previous stories, never forward dependencies
**DETAILED ACCEPTANCE CRITERIA GUIDELINES:**
Include ALL implementation specifics:
**From Architecture:**
- Exact API endpoints and contracts
- Database operations and validations
- Authentication/authorization requirements
- Error handling patterns
- Performance requirements
- Security considerations
- Integration points with other systems
**From UX (if available):**
- Specific screen/page references
- Interaction patterns and behaviors
- Form validation rules and error messages
- Responsive behavior
- Accessibility requirements
- Loading states and transitions
- Success/error feedback patterns
**From PRD:**
- Business rules and constraints
- User types and permissions
- Compliance requirements
- Success criteria
**STORY SIZING PRINCIPLE:**
Each story must be completable by a single dev agent in one focused session. If a story becomes too large, break it down further while maintaining user value.
**EXAMPLE RICH STORY:**
**Story:** User Registration with Email Verification
As a new user, I want to create an account using my email address, So that I can access the platform's features.
**Acceptance Criteria:**
Given I am on the landing page
When I click the "Sign Up" button
Then the registration modal opens (UX Mockup 3.2)
And I see email and password fields with proper labels
And the email field validates RFC 5322 format in real-time
And the password field shows strength meter (red→yellow→green)
And I see "Password must be 8+ chars with 1 uppercase, 1 number, 1 special"
When I submit valid registration data
Then POST /api/v1/auth/register is called (Architecture section 4.1)
And the user record is created in users table with bcrypt hash (Architecture 6.2)
And a verification email is sent via SendGrid (Architecture 7.3)
And I see "Check your email for verification link" message
And I cannot log in until email is verified
**Technical Notes:**
- Use PostgreSQL users table (Architecture section 6.2)
- Implement rate limiting: 3 attempts per hour per IP (Architecture 8.1)
- Return JWT token on successful verification (Architecture 5.2)
- Log registration events to audit_events table (Architecture 9.4)
- Form validation follows UX Design patterns (UX section 4.1)
**Prerequisites:** Epic 1.1 - Foundation Setup Complete
</action>
<action>**Generate all stories for Epic {{N}}**</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*{{N}}*{{M}}</template-output>
<action>**EPIC {{N}} COMPLETION REVIEW:**</action>
<output>**Epic {{N}} Complete: {{epic_title}}**
Stories Created: {{count}}
**FR Coverage:** {{list of FRs covered by this epic}}
**Technical Context Used:** {{Architecture sections referenced}}
{{if ux_design_content}}
**UX Patterns Incorporated:** {{UX sections referenced}}
{{/if}}
Ready for checkpoint validation.</output>
<template-output>epic\_{{N}}\_complete</template-output>
</step>
<step n="3" goal="Final validation and coverage matrix">
<action>**COMPREHENSIVE VALIDATION WITH FULL CONTEXT:**</action>
<action>Review the complete epic and story breakdown for quality and completeness using ALL available context.
**FR COVERAGE VALIDATION:**
Create complete FR Coverage Matrix showing every PRD functional requirement mapped to specific stories:
- **FR1:** [description] → Epic X, Story X.Y (with implementation details)
- **FR2:** [description] → Epic Y, Story Y.A (with implementation details)
- **FR3:** [description] → Epic Z, Story Z.B (with implementation details)
- ...
**CRITICAL VALIDATION:** Every single FR from the PRD must be covered by at least one story with complete acceptance criteria.
**ARCHITECTURE INTEGRATION VALIDATION:**
Verify that Architecture decisions are properly implemented:
- All API endpoints from Architecture are covered in stories
- Data models from Architecture are properly created and populated
- Authentication/authorization patterns are consistently applied
- Performance requirements are addressed in relevant stories
- Security measures are implemented where required
- Error handling follows Architecture patterns
- Integration points between systems are properly handled
**UX INTEGRATION VALIDATION** {{if ux_design_content}}:
Verify that UX design patterns are properly implemented:
- User flows follow the designed journey
- Screen layouts and components match specifications
- Interaction patterns work as designed
- Responsive behavior matches breakpoints
- Accessibility requirements are met
- Error states and feedback patterns are implemented
- Form validation follows UX guidelines
- Loading states and transitions are implemented
{{/if}}
**STORY QUALITY VALIDATION:**
- All stories are sized for single dev agent completion
- Acceptance criteria are specific and testable
- Technical implementation guidance is clear
- User experience details are incorporated
- No forward dependencies exist
- Epic sequence delivers incremental value
- Foundation epic properly enables subsequent work
**FINAL QUALITY CHECK:**
Answer these critical questions:
1. **User Value:** Does each epic deliver something users can actually do/use?
2. **Completeness:** Are ALL PRD functional requirements covered?
3. **Technical Soundness:** Do stories properly implement Architecture decisions?
4. **User Experience:** {{if ux_design_content}} Do stories follow UX design patterns? {{/if}}
5. **Implementation Ready:** Can dev agents implement these stories autonomously?
</action>
<output>**✅ EPIC AND STORY CREATION COMPLETE**
**Output Generated:** epics.md with comprehensive implementation details
**Full Context Incorporated:**
- ✅ PRD functional requirements and scope
- ✅ Architecture technical decisions and contracts
{{if ux_design_content}}
- ✅ UX Design interaction patterns and specifications
{{/if}}
**FR Coverage:** {{count}} functional requirements mapped to {{story_count}} stories
**Epic Structure:** {{epic_count}} epics delivering incremental user value
**Ready for Phase 4:** Sprint Planning and Development Implementation
</output>
<template-output>final_validation</template-output>
<template-output>fr_coverage_matrix</template-output>
</step>
</workflow>

258
src/modules/bmm/workflows/3-solutioning/create-epics-and-stories/steps/step-01-validate-prerequisites.md Normal file
View File

@ -0,0 +1,258 @@
---
name: 'step-01-validate-prerequisites'
description: 'Validate required documents exist and extract all requirements for epic and story creation'
# Path Definitions
workflow_path: '{project-root}/{bmad_folder}/bmm/workflows/3-solutioning/create-epics-and-stories'
# File References
thisStepFile: '{workflow_path}/steps/step-01-validate-prerequisites.md'
nextStepFile: '{workflow_path}/steps/step-02-design-epics.md'
workflowFile: '{workflow_path}/workflow.md'
outputFile: '{output_folder}/epics.md'
epicsTemplate: '{workflow_path}/templates/epics-template.md'
# Task References
advancedElicitationTask: '{project-root}/.bmad/core/tasks/advanced-elicitation.xml'
partyModeWorkflow: '{project-root}/.bmad/core/workflows/party-mode/workflow.md'
# Template References
epicsTemplate: '{workflow_path}/templates/epics-template.md'
---
# Step 1: Validate Prerequisites and Extract Requirements
## STEP GOAL:
To validate that all required input documents exist and extract all requirements (FRs, NFRs, and additional requirements from UX/Architecture) needed for epic and story creation.
## MANDATORY EXECUTION RULES (READ FIRST):
### Universal Rules:
- 🛑 NEVER generate content without user input
- 📖 CRITICAL: Read the complete step file before taking any action
- 🔄 CRITICAL: When loading next step with 'C', ensure entire file is read
- 📋 YOU ARE A FACILITATOR, not a content generator
### Role Reinforcement:
- ✅ You are a product strategist and technical specifications writer
- ✅ If you already have been given communication or persona patterns, continue to use those while playing this new role
- ✅ We engage in collaborative dialogue, not command-response
- ✅ You bring requirements extraction expertise
- ✅ User brings their product vision and context
### Step-Specific Rules:
- 🎯 Focus ONLY on extracting and organizing requirements
- 🚫 FORBIDDEN to start creating epics or stories in this step
- 💬 Extract requirements from ALL available documents
- 🚪 POPULATE the template sections exactly as needed
## EXECUTION PROTOCOLS:
- 🎯 Extract requirements systematically from all documents
- 💾 Populate {outputFile} with extracted requirements
- 📖 Update frontmatter with extraction progress
- 🚫 FORBIDDEN to load next step until user selects 'C' and requirements are extracted
## REQUIREMENTS EXTRACTION PROCESS:
### 1. Welcome and Overview
Welcome {user_name} to comprehensive epic and story creation!
**CRITICAL PREREQUISITE VALIDATION:**
Verify required documents exist and are complete:
1. **PRD.md** - Contains requirements (FRs and NFRs) and product scope
2. **Architecture.md** - Contains technical decisions, API contracts, data models
3. **UX Design.md** (if UI exists) - Contains interaction patterns, mockups, user flows
### 2. Document Discovery and Validation
Search for required documents using these patterns (sharded means a large document was split into multiple small files with an index.md into a folder) - if the whole document is found, use that instead of the sharded version:
**PRD Document Search Priority:**
1. `{output_folder}/*prd*.md` (whole document)
2. `{output_folder}/*prd*/index.md` (sharded version)
**Architecture Document Search Priority:**
1. `{output_folder}/*architecture*.md` (whole document)
2. `{output_folder}/*architecture*/index.md` (sharded version)
**UX Design Document Search (Optional):**
1. `{output_folder}/*ux*.md` (whole document)
2. `{output_folder}/*ux*/index.md` (sharded version)
Ask the user if there are any other documents, or if what you have found is all there is [Yes/No]. Wait for user confirmation. Once confirmed, create the {outputFile} from the {epicsTemplate} and in the front matter list the files in the array of `inputDocuments: []`.
### 3. Extract Functional Requirements (FRs)
From the PRD document (full or sharded), extract ALL functional requirements:
**Extraction Method:**
- Look for numbered items like "FR1:", "Functional Requirement 1:", or similar
- Identify requirement statements that describe what the system must DO
- Include user actions, system behaviors, and business rules
**Format the FR list as:**
```
FR1: [Clear, testable requirement description]
FR2: [Clear, testable requirement description]
...
```
### 4. Extract Non-Functional Requirements (NFRs)
From the PRD document, extract ALL non-functional requirements:
**Extraction Method:**
- Look for performance, security, usability, reliability requirements
- Identify constraints and quality attributes
- Include technical standards and compliance requirements
**Format the NFR list as:**
```
NFR1: [Performance/Security/Usability requirement]
NFR2: [Performance/Security/Usability requirement]
...
```
### 5. Extract Additional Requirements from Architecture
Review the Architecture document for technical requirements that impact epic and story creation:
**Look for:**
- **Starter Template**: Does Architecture specify a starter/greenfield template? If YES, document this for Epic 1 Story 1
- Infrastructure and deployment requirements
- Integration requirements with external systems
- Data migration or setup requirements
- Monitoring and logging requirements
- API versioning or compatibility requirements
- Security implementation requirements
**IMPORTANT**: If a starter template is mentioned in Architecture, note it prominently. This will impact Epic 1 Story 1.
**Format Additional Requirements as:**
```
- [Technical requirement from Architecture that affects implementation]
- [Infrastructure setup requirement]
- [Integration requirement]
...
```
### 6. Extract Additional Requirements from UX (if exists)
Review the UX document for requirements that affect epic and story creation:
**Look for:**
- Responsive design requirements
- Accessibility requirements
- Browser/device compatibility
- User interaction patterns that need implementation
- Animation or transition requirements
- Error handling UX requirements
**Add these to Additional Requirements list.**
### 7. Load and Initialize Template
Load {epicsTemplate} and initialize {outputFile}:
1. Copy the entire template to {outputFile}
2. Replace {{project_name}} with the actual project name
3. Replace placeholder sections with extracted requirements:
- {{fr_list}} → extracted FRs
- {{nfr_list}} → extracted NFRs
- {{additional_requirements}} → extracted additional requirements
4. Leave {{requirements_coverage_map}} and {{epics_list}} as placeholders for now
### 8. Present Extracted Requirements
Display to user:
**Functional Requirements Extracted:**
- Show count of FRs found
- Display the first few FRs as examples
- Ask if any FRs are missing or incorrectly captured
**Non-Functional Requirements Extracted:**
- Show count of NFRs found
- Display key NFRs
- Ask if any constraints were missed
**Additional Requirements:**
- Summarize technical requirements from Architecture
- Summarize UX requirements (if applicable)
- Verify completeness
### 9. Get User Confirmation
Ask: "Do these extracted requirements accurately represent what needs to be built? Any additions or corrections?"
Update the requirements based on user feedback until confirmation is received.
## CONTENT TO SAVE TO DOCUMENT:
After extraction and confirmation, update {outputFile} with:
- Complete FR list in {{fr_list}} section
- Complete NFR list in {{nfr_list}} section
- All additional requirements in {{additional_requirements}} section
### 10. Present MENU OPTIONS
Display: `**Confirm the Requirements are complete and correct to [C] continue:**`
#### EXECUTION RULES:
- ALWAYS halt and wait for user input after presenting menu
- ONLY proceed to next step when user selects 'C'
- User can chat or ask questions - always respond and then end with display again of the menu option
#### Menu Handling Logic:
- IF C: Save all to {outputFile}, update frontmatter, only then load, read entire file, then execute {nextStepFile}
- IF Any other comments or queries: help user respond then [Redisplay Menu Options](#10-present-menu-options)
## CRITICAL STEP COMPLETION NOTE
ONLY WHEN C is selected and all requirements are saved to document and frontmatter is updated, will you then load, read entire file, then execute {nextStepFile} to execute and begin epic design step.
---
## 🚨 SYSTEM SUCCESS/FAILURE METRICS
### ✅ SUCCESS:
- All required documents found and validated
- All FRs extracted and formatted correctly
- All NFRs extracted and formatted correctly
- Additional requirements from Architecture/UX identified
- Template initialized with requirements
- User confirms requirements are complete and accurate
### ❌ SYSTEM FAILURE:
- Missing required documents
- Incomplete requirements extraction
- Template not properly initialized
- Not saving requirements to output file
**Master Rule:** Skipping steps, optimizing sequences, or not following exact instructions is FORBIDDEN and constitutes SYSTEM FAILURE.

232
src/modules/bmm/workflows/3-solutioning/create-epics-and-stories/steps/step-02-design-epics.md Normal file
View File

@ -0,0 +1,232 @@
---
name: 'step-02-design-epics'
description: 'Design and approve the epics_list that will organize all requirements into user-value-focused epics'
# Path Definitions
workflow_path: '{project-root}/{bmad_folder}/bmm/workflows/3-solutioning/create-epics-and-stories'
# File References
thisStepFile: '{workflow_path}/steps/step-02-design-epics.md'
nextStepFile: '{workflow_path}/steps/step-03-create-stories.md'
workflowFile: '{workflow_path}/workflow.md'
outputFile: '{output_folder}/epics.md'
# Task References
advancedElicitationTask: '{project-root}/.bmad/core/tasks/advanced-elicitation.xml'
partyModeWorkflow: '{project-root}/.bmad/core/workflows/party-mode/workflow.md'
# Template References
epicsTemplate: '{workflow_path}/templates/epics-template.md'
---
# Step 2: Design Epic List
## STEP GOAL:
To design and get approval for the epics_list that will organize all requirements into user-value-focused epics.
## MANDATORY EXECUTION RULES (READ FIRST):
### Universal Rules:
- 🛑 NEVER generate content without user input
- 📖 CRITICAL: Read the complete step file before taking any action
- 🔄 CRITICAL: When loading next step with 'C', ensure entire file is read
- 📋 YOU ARE A FACILITATOR, not a content generator
### Role Reinforcement:
- ✅ You are a product strategist and technical specifications writer
- ✅ If you already have been given communication or persona patterns, continue to use those while playing this new role
- ✅ We engage in collaborative dialogue, not command-response
- ✅ You bring product strategy and epic design expertise
- ✅ User brings their product vision and priorities
### Step-Specific Rules:
- 🎯 Focus ONLY on creating the epics_list
- 🚫 FORBIDDEN to create individual stories in this step
- 💬 Organize epics around user value, not technical layers
- 🚪 GET explicit approval for the epics_list
- 🔗 **CRITICAL: Each epic must be standalone and enable future epics without requiring future epics to function**
## EXECUTION PROTOCOLS:
- 🎯 Design epics collaboratively based on extracted requirements
- 💾 Update {{epics_list}} in {outputFile}
- 📖 Document the FR coverage mapping
- 🚫 FORBIDDEN to load next step until user approves epics_list
## EPIC DESIGN PROCESS:
### 1. Review Extracted Requirements
Load {outputFile} and review:
- **Functional Requirements:** Count and review FRs from Step 1
- **Non-Functional Requirements:** Review NFRs that need to be addressed
- **Additional Requirements:** Review technical and UX requirements
### 2. Explain Epic Design Principles
**EPIC DESIGN PRINCIPLES:**
1. **User-Value First**: Each epic must enable users to accomplish something meaningful
2. **Requirements Grouping**: Group related FRs that deliver cohesive user outcomes
3. **Incremental Delivery**: Each epic should deliver value independently
4. **Logical Flow**: Natural progression from user's perspective
5. **🔗 Dependency-Free Within Epic**: Stories within an epic must NOT depend on future stories
**⚠️ CRITICAL PRINCIPLE:**
Organize by USER VALUE, not technical layers:
**✅ CORRECT Epic Examples (Standalone & Enable Future Epics):**
- Epic 1: User Authentication & Profiles (users can register, login, manage profiles) - **Standalone: Complete auth system**
- Epic 2: Content Creation (users can create, edit, publish content) - **Standalone: Uses auth, creates content**
- Epic 3: Social Interaction (users can follow, comment, like content) - **Standalone: Uses auth + content**
- Epic 4: Search & Discovery (users can find content and other users) - **Standalone: Uses all previous**
**❌ WRONG Epic Examples (Technical Layers or Dependencies):**
- Epic 1: Database Setup (creates all tables upfront) - **No user value**
- Epic 2: API Development (builds all endpoints) - **No user value**
- Epic 3: Frontend Components (creates reusable components) - **No user value**
- Epic 4: Deployment Pipeline (CI/CD setup) - **No user value**
**🔗 DEPENDENCY RULES:**
- Each epic must deliver COMPLETE functionality for its domain
- Epic 2 must not require Epic 3 to function
- Epic 3 can build upon Epic 1 & 2 but must stand alone
### 3. Design Epic Structure Collaboratively
**Step A: Identify User Value Themes**
- Look for natural groupings in the FRs
- Identify user journeys or workflows
- Consider user types and their goals
**Step B: Propose Epic Structure**
For each proposed epic:
1. **Epic Title**: User-centric, value-focused
2. **User Outcome**: What users can accomplish after this epic
3. **FR Coverage**: Which FR numbers this epic addresses
4. **Implementation Notes**: Any technical or UX considerations
**Step C: Create the epics_list**
Format the epics_list as:
```
## Epic List
### Epic 1: [Epic Title]
[Epic goal statement - what users can accomplish]
**FRs covered:** FR1, FR2, FR3, etc.
### Epic 2: [Epic Title]
[Epic goal statement - what users can accomplish]
**FRs covered:** FR4, FR5, FR6, etc.
[Continue for all epics]
```
### 4. Present Epic List for Review
Display the complete epics_list to user with:
- Total number of epics
- FR coverage per epic
- User value delivered by each epic
- Any natural dependencies
### 5. Create Requirements Coverage Map
Create {{requirements_coverage_map}} showing how each FR maps to an epic:
```
### FR Coverage Map
FR1: Epic 1 - [Brief description]
FR2: Epic 1 - [Brief description]
FR3: Epic 2 - [Brief description]
...
```
This ensures no FRs are missed.
### 6. Collaborative Refinement
Ask user:
- "Does this epic structure align with your product vision?"
- "Are all user outcomes properly captured?"
- "Should we adjust any epic groupings?"
- "Are there natural dependencies we've missed?"
### 7. Get Final Approval
**CRITICAL:** Must get explicit user approval:
"Do you approve this epic structure for proceeding to story creation?"
If user wants changes:
- Make the requested adjustments
- Update the epics_list
- Re-present for approval
- Repeat until approval is received
## CONTENT TO UPDATE IN DOCUMENT:
After approval, update {outputFile}:
1. Replace {{epics_list}} placeholder with the approved epic list
2. Replace {{requirements_coverage_map}} with the coverage map
3. Ensure all FRs are mapped to epics
### 8. Present MENU OPTIONS
Display: "**Select an Option:** [A] Advanced Elicitation [P] Party Mode [C] Continue"
#### Menu Handling Logic:
- IF A: Execute {advancedElicitationTask}
- IF P: Execute {partyModeWorkflow}
- IF C: Save approved epics_list to {outputFile}, update frontmatter, then only then load, read entire file, then execute {nextStepFile}
- IF Any other comments or queries: help user respond then [Redisplay Menu Options](#8-present-menu-options)
#### EXECUTION RULES:
- ALWAYS halt and wait for user input after presenting menu
- ONLY proceed to next step when user selects 'C'
- After other menu items execution completes, redisplay the menu
- User can chat or ask questions - always respond when conversation ends, redisplay the menu options
## CRITICAL STEP COMPLETION NOTE
ONLY WHEN C is selected and the approved epics_list is saved to document, will you then load, read entire file, then execute {nextStepFile} to execute and begin story creation step.
---
## 🚨 SYSTEM SUCCESS/FAILURE METRICS
### ✅ SUCCESS:
- Epics designed around user value
- All FRs mapped to specific epics
- epics_list created and formatted correctly
- Requirements coverage map completed
- User gives explicit approval for epic structure
- Document updated with approved epics
### ❌ SYSTEM FAILURE:
- Epics organized by technical layers
- Missing FRs in coverage map
- No user approval obtained
- epics_list not saved to document
**Master Rule:** Skipping steps, optimizing sequences, or not following exact instructions is FORBIDDEN and constitutes SYSTEM FAILURE.

271
src/modules/bmm/workflows/3-solutioning/create-epics-and-stories/steps/step-03-create-stories.md Normal file
View File

@ -0,0 +1,271 @@
---
name: 'step-03-create-stories'
description: 'Generate all epics with their stories following the template structure'
# Path Definitions
workflow_path: '{project-root}/{bmad_folder}/bmm/workflows/3-solutioning/create-epics-and-stories'
# File References
thisStepFile: '{workflow_path}/steps/step-03-create-stories.md'
nextStepFile: '{workflow_path}/steps/step-04-final-validation.md'
workflowFile: '{workflow_path}/workflow.md'
outputFile: '{output_folder}/epics.md'
# Task References
advancedElicitationTask: '{project-root}/.bmad/core/tasks/advanced-elicitation.xml'
partyModeWorkflow: '{project-root}/.bmad/core/workflows/party-mode/workflow.md'
# Template References
epicsTemplate: '{workflow_path}/templates/epics-template.md'
---
# Step 3: Generate Epics and Stories
## STEP GOAL:
To generate all epics with their stories based on the approved epics_list, following the template structure exactly.
## MANDATORY EXECUTION RULES (READ FIRST):
### Universal Rules:
- 🛑 NEVER generate content without user input
- 📖 CRITICAL: Read the complete step file before taking any action
- 🔄 CRITICAL: Process epics sequentially
- 📋 YOU ARE A FACILITATOR, not a content generator
### Role Reinforcement:
- ✅ You are a product strategist and technical specifications writer
- ✅ If you already have been given communication or persona patterns, continue to use those while playing this new role
- ✅ We engage in collaborative dialogue, not command-response
- ✅ You bring story creation and acceptance criteria expertise
- ✅ User brings their implementation priorities and constraints
### Step-Specific Rules:
- 🎯 Generate stories for each epic following the template exactly
- 🚫 FORBIDDEN to deviate from template structure
- 💬 Each story must have clear acceptance criteria
- 🚪 ENSURE each story is completable by a single dev agent
- 🔗 **CRITICAL: Stories MUST NOT depend on future stories within the same epic**
## EXECUTION PROTOCOLS:
- 🎯 Generate stories collaboratively with user input
- 💾 Append epics and stories to {outputFile} following template
- 📖 Process epics one at a time in sequence
- 🚫 FORBIDDEN to skip any epic or rush through stories
## STORY GENERATION PROCESS:
### 1. Load Approved Epic Structure
Load {outputFile} and review:
- Approved epics_list from Step 2
- FR coverage map
- All requirements (FRs, NFRs, additional)
- Template structure at the end of the document
### 2. Explain Story Creation Approach
**STORY CREATION GUIDELINES:**
For each epic, create stories that:
- Follow the exact template structure
- Are sized for single dev agent completion
- Have clear user value
- Include specific acceptance criteria
- Reference requirements being fulfilled
**🚨 DATABASE/ENTITY CREATION PRINCIPLE:**
Create tables/entities ONLY when needed by the story:
- ❌ WRONG: Epic 1 Story 1 creates all 50 database tables
- ✅ RIGHT: Each story creates/alters ONLY the tables it needs
**🔗 STORY DEPENDENCY PRINCIPLE:**
Stories must be independently completable in sequence:
- ❌ WRONG: Story 1.2 requires Story 1.3 to be completed first
- ✅ RIGHT: Each story can be completed based only on previous stories
- ❌ WRONG: "Wait for Story 1.4 to be implemented before this works"
- ✅ RIGHT: "This story works independently and enables future stories"
**STORY FORMAT (from template):**
```
### Story {N}.{M}: {story_title}
As a {user_type},
I want {capability},
So that {value_benefit}.
**Acceptance Criteria:**
**Given** {precondition}
**When** {action}
**Then** {expected_outcome}
**And** {additional_criteria}
```
**✅ GOOD STORY EXAMPLES:**
_Epic 1: User Authentication_
- Story 1.1: User Registration with Email
- Story 1.2: User Login with Password
- Story 1.3: Password Reset via Email
_Epic 2: Content Creation_
- Story 2.1: Create New Blog Post
- Story 2.2: Edit Existing Blog Post
- Story 2.3: Publish Blog Post
**❌ BAD STORY EXAMPLES:**
- Story: "Set up database" (no user value)
- Story: "Create all models" (too large, no user value)
- Story: "Build authentication system" (too large)
- Story: "Login UI (depends on Story 1.3 API endpoint)" (future dependency!)
- Story: "Edit post (requires Story 1.4 to be implemented first)" (wrong order!)
### 3. Process Epics Sequentially
For each epic in the approved epics_list:
#### A. Epic Overview
Display:
- Epic number and title
- Epic goal statement
- FRs covered by this epic
- Any NFRs or additional requirements relevant
#### B. Story Breakdown
Work with user to break down the epic into stories:
- Identify distinct user capabilities
- Ensure logical flow within the epic
- Size stories appropriately
#### C. Generate Each Story
For each story in the epic:
1. **Story Title**: Clear, action-oriented
2. **User Story**: Complete the As a/I want/So that format
3. **Acceptance Criteria**: Write specific, testable criteria
**AC Writing Guidelines:**
- Use Given/When/Then format
- Each AC should be independently testable
- Include edge cases and error conditions
- Reference specific requirements when applicable
#### D. Collaborative Review
After writing each story:
- Present the story to user
- Ask: "Does this story capture the requirement correctly?"
- "Is the scope appropriate for a single dev session?"
- "Are the acceptance criteria complete and testable?"
#### E. Append to Document
When story is approved:
- Append it to {outputFile} following template structure
- Use correct numbering (Epic N, Story M)
- Maintain proper markdown formatting
### 4. Epic Completion
After all stories for an epic are complete:
- Display epic summary
- Show count of stories created
- Verify all FRs for the epic are covered
- Get user confirmation to proceed to next epic
### 5. Repeat for All Epics
Continue the process for each epic in the approved list, processing them in order (Epic 1, Epic 2, etc.).
### 6. Final Document Completion
After all epics and stories are generated:
- Verify the document follows template structure exactly
- Ensure all placeholders are replaced
- Confirm all FRs are covered
- Check formatting consistency
## TEMPLATE STRUCTURE COMPLIANCE:
The final {outputFile} must follow this structure exactly:
1. **Overview** section with project name
2. **Requirements Inventory** with all three subsections populated
3. **FR Coverage Map** showing requirement to epic mapping
4. **Epic List** with approved epic structure
5. **Epic sections** for each epic (N = 1, 2, 3...)
- Epic title and goal
- All stories for that epic (M = 1, 2, 3...)
- Story title and user story
- Acceptance Criteria using Given/When/Then format
### 7. Present FINAL MENU OPTIONS
After all epics and stories are complete:
Display: "**Select an Option:** [A] Advanced Elicitation [P] Party Mode [C] Continue"
#### Menu Handling Logic:
- IF A: Execute {advancedElicitationTask}
- IF P: Execute {partyModeWorkflow}
- IF C: Save content to {outputFile}, update frontmatter, then only then load, read entire file, then execute {nextStepFile}
- IF Any other comments or queries: help user respond then [Redisplay Menu Options](#7-present-final-menu-options)
#### EXECUTION RULES:
- ALWAYS halt and wait for user input after presenting menu
- ONLY proceed to next step when user selects 'C'
- After other menu items execution, return to this menu
- User can chat or ask questions - always respond and then end with display again of the menu options
## CRITICAL STEP COMPLETION NOTE
ONLY WHEN [C continue option] is selected and [all epics and stories saved to document following the template structure exactly], will you then load and read fully `{nextStepFile}` to execute and begin final validation phase.
---
## 🚨 SYSTEM SUCCESS/FAILURE METRICS
### ✅ SUCCESS:
- All epics processed in sequence
- Stories created for each epic
- Template structure followed exactly
- All FRs covered by stories
- Stories appropriately sized
- Acceptance criteria are specific and testable
- Document is complete and ready for development
### ❌ SYSTEM FAILURE:
- Deviating from template structure
- Missing epics or stories
- Stories too large or unclear
- Missing acceptance criteria
- Not following proper formatting
**Master Rule:** Skipping steps, optimizing sequences, or not following exact instructions is FORBIDDEN and constitutes SYSTEM FAILURE.

144
src/modules/bmm/workflows/3-solutioning/create-epics-and-stories/steps/step-04-final-validation.md Normal file
View File

@ -0,0 +1,144 @@
---
name: 'step-04-final-validation'
description: 'Validate complete coverage of all requirements and ensure implementation readiness'
# Path Definitions
workflow_path: '{project-root}/{bmad_folder}/bmm/workflows/3-solutioning/create-epics-and-stories'
# File References
thisStepFile: '{workflow_path}/steps/step-04-final-validation.md'
workflowFile: '{workflow_path}/workflow.md'
outputFile: '{output_folder}/epics.md'
# Task References
advancedElicitationTask: '{project-root}/.bmad/core/tasks/advanced-elicitation.xml'
partyModeWorkflow: '{project-root}/.bmad/core/workflows/party-mode/workflow.md'
# Template References
epicsTemplate: '{workflow_path}/templates/epics-template.md'
---
# Step 4: Final Validation
## STEP GOAL:
To validate complete coverage of all requirements and ensure stories are ready for development.
## MANDATORY EXECUTION RULES (READ FIRST):
### Universal Rules:
- 🛑 NEVER generate content without user input
- 📖 CRITICAL: Read the complete step file before taking any action
- 🔄 CRITICAL: Process validation sequentially without skipping
- 📋 YOU ARE A FACILITATOR, not a content generator
### Role Reinforcement:
- ✅ You are a product strategist and technical specifications writer
- ✅ If you already have been given communication or persona patterns, continue to use those while playing this new role
- ✅ We engage in collaborative dialogue, not command-response
- ✅ You bring validation expertise and quality assurance
- ✅ User brings their implementation priorities and final review
### Step-Specific Rules:
- 🎯 Focus ONLY on validating complete requirements coverage
- 🚫 FORBIDDEN to skip any validation checks
- 💬 Validate FR coverage, story completeness, and dependencies
- 🚪 ENSURE all stories are ready for development
## EXECUTION PROTOCOLS:
- 🎯 Validate every requirement has story coverage
- 💾 Check story dependencies and flow
- 📖 Verify architecture compliance
- 🚫 FORBIDDEN to approve incomplete coverage
## CONTEXT BOUNDARIES:
- Available context: Complete epic and story breakdown from previous steps
- Focus: Final validation of requirements coverage and story readiness
- Limits: Validation only, no new content creation
- Dependencies: Completed story generation from Step 3
## VALIDATION PROCESS:
### 1. FR Coverage Validation
Review the complete epic and story breakdown to ensure EVERY FR is covered:
**CRITICAL CHECK:**
- Go through each FR from the Requirements Inventory
- Verify it appears in at least one story
- Check that acceptance criteria fully address the FR
- No FRs should be left uncovered
### 2. Architecture Implementation Validation
**Check for Starter Template Setup:**
- Does Architecture document specify a starter template?
- If YES: Epic 1 Story 1 must be "Set up initial project from starter template"
- This includes cloning, installing dependencies, initial configuration
**Database/Entity Creation Validation:**
- Are database tables/entities created ONLY when needed by stories?
- ❌ WRONG: Epic 1 creates all tables upfront
- ✅ RIGHT: Tables created as part of the first story that needs them
- Each story should create/modify ONLY what it needs
### 3. Story Quality Validation
**Each story must:**
- Be completable by a single dev agent
- Have clear acceptance criteria
- Reference specific FRs it implements
- Include necessary technical details
- **Not have forward dependencies** (can only depend on PREVIOUS stories)
- Be implementable without waiting for future stories
### 4. Epic Structure Validation
**Check that:**
- Epics deliver user value, not technical milestones
- Dependencies flow naturally
- Foundation stories only setup what's needed
- No big upfront technical work
### 5. Dependency Validation (CRITICAL)
**Epic Independence Check:**
- Does each epic deliver COMPLETE functionality for its domain?
- Can Epic 2 function without Epic 3 being implemented?
- Can Epic 3 function standalone using Epic 1 & 2 outputs?
- ❌ WRONG: Epic 2 requires Epic 3 features to work
- ✅ RIGHT: Each epic is independently valuable
**Within-Epic Story Dependency Check:**
For each epic, review stories in order:
- Can Story N.1 be completed without Stories N.2, N.3, etc.?
- Can Story N.2 be completed using only Story N.1 output?
- Can Story N.3 be completed using only Stories N.1 & N.2 outputs?
- ❌ WRONG: "This story depends on a future story"
- ❌ WRONG: Story references features not yet implemented
- ✅ RIGHT: Each story builds only on previous stories
### 6. Complete and Save
If all validations pass:
- Update any remaining placeholders in the document
- Ensure proper formatting
- Save the final epics.md
**Present Final Menu:**
**All validations complete!** [C] Complete Workflow
When C is selected, the workflow is complete and the epics.md is ready for development.

57
src/modules/bmm/workflows/3-solutioning/create-epics-and-stories/templates/epics-template.md Normal file
View File

@ -0,0 +1,57 @@
---
stepsCompleted: []
inputDocuments: []
---
# {{project_name}} - Epic Breakdown
## Overview
This document provides the complete epic and story breakdown for {{project_name}}, decomposing the requirements from the PRD, UX Design if it exists, and Architecture requirements into implementable stories.
## Requirements Inventory
### Functional Requirements
{{fr_list}}
### NonFunctional Requirements
{{nfr_list}}
### Additional Requirements
{{additional_requirements}}
### FR Coverage Map
{{requirements_coverage_map}}
## Epic List
{{epics_list}}
<!-- Repeat for each epic in epics_list (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:**
<!-- for each AC on this story -->
**Given** {{precondition}}
**When** {{action}}
**Then** {{expected_outcome}}
**And** {{additional_criteria}}
<!-- End story repeat -->

58
src/modules/bmm/workflows/3-solutioning/create-epics-and-stories/workflow.md Normal file
View File

@ -0,0 +1,58 @@
---
name: 'Create Epics and Stories'
description: 'Transform PRD requirements and Architecture decisions into comprehensive stories organized by user value. This workflow requires completed PRD + Architecture documents (UX recommended if UI exists) and breaks down requirements into implementation-ready epics and user stories that incorporate all available technical and design context. Creates detailed, actionable stories with complete acceptance criteria for development teams.'
web_bundle: true
---
# Create Epics and Stories
**Goal:** Transform PRD requirements and Architecture decisions into comprehensive stories organized by user value, creating detailed, actionable stories with complete acceptance criteria for development teams.
**Your Role:** In addition to your name, communication_style, and persona, you are also a product strategist and technical specifications writer collaborating with a product owner. This is a partnership, not a client-vendor relationship. You bring expertise in requirements decomposition, technical implementation context, and acceptance criteria writing, while the user brings their product vision, user needs, and business requirements. Work together as equals.
---
## WORKFLOW ARCHITECTURE
This uses **step-file architecture** for disciplined execution:
### Core Principles
- **Micro-file Design**: Each step of the overall goal is a self contained instruction file that you will adhere too 1 file as directed at a time
- **Just-In-Time Loading**: Only 1 current step file will be loaded, read, and executed to completion - never load future step files until told to do so
- **Sequential Enforcement**: Sequence within the step files must be completed in order, no skipping or optimization allowed
- **State Tracking**: Document progress in output file frontmatter using `stepsCompleted` array when a workflow produces a document
- **Append-Only Building**: Build documents by appending content as directed to the output file
### Step Processing Rules
1. **READ COMPLETELY**: Always read the entire step file before taking any action
2. **FOLLOW SEQUENCE**: Execute all numbered sections in order, never deviate
3. **WAIT FOR INPUT**: If a menu is presented, halt and wait for user selection
4. **CHECK CONTINUATION**: If the step has a menu with Continue as an option, only proceed to next step when user selects 'C' (Continue)
5. **SAVE STATE**: Update `stepsCompleted` in frontmatter before loading next step
6. **LOAD NEXT**: When directed, load, read entire file, then execute the next step file
### Critical Rules (NO EXCEPTIONS)
- 🛑 **NEVER** load multiple step files simultaneously
- 📖 **ALWAYS** read entire step file before execution
- 🚫 **NEVER** skip steps or optimize the sequence
- 💾 **ALWAYS** update frontmatter of output files when writing the final output for a specific step
- 🎯 **ALWAYS** follow the exact instructions in the step file
- ⏸️ **ALWAYS** halt at menus and wait for user input
- 📋 **NEVER** create mental todo lists from future steps
---
## INITIALIZATION SEQUENCE
### 1. Configuration Loading
Load and read full config from {project-root}/{bmad_folder}/bmm/config.yaml and resolve:
- `project_name`, `output_folder`, `user_name`, `communication_language`, `document_output_language`
### 2. First Step EXECUTION
Load, read the full file and then execute `{project-root}/{bmad_folder}/bmm/workflows/3-solutioning/create-epics-and-stories/steps/step-01-validate-prerequisites.md` to begin the workflow.

53
src/modules/bmm/workflows/3-solutioning/create-epics-and-stories/workflow.yaml
View File

@ -1,53 +0,0 @@
# Epic and Story Decomposition Workflow
name: create-epics-and-stories
description: "Transform PRD requirements and Architecture decisions into comprehensive stories organized by user value. This workflow requires completed PRD + Architecture documents (UX recommended if UI exists) and breaks down requirements into implementation-ready epics and user stories that incorporate all available technical and design context. Creates detailed, actionable stories with complete acceptance criteria for development teams."
author: "BMad"
# Critical variables from config
config_source: "{project-root}/{bmad_folder}/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
# Smart input file references - handles both whole docs and sharded docs
# Priority: Whole document first, then sharded version
input_file_patterns:
prd:
description: "Product Requirements Document with FRs and NFRs (required)"
whole: "{output_folder}/*prd*.md"
sharded: "{output_folder}/*prd*/index.md"
load_strategy: "INDEX_GUIDED"
architecture:
description: "Architecture decisions and technical design (required)"
whole: "{output_folder}/*architecture*.md"
sharded: "{output_folder}/*architecture*/index.md"
load_strategy: "FULL_LOAD"
ux_design:
description: "UX design specification for interaction patterns (recommended if UI exists)"
whole: "{output_folder}/*ux*.md"
sharded: "{output_folder}/*ux*/index.md"
load_strategy: "FULL_LOAD"
# Module path and component files
installed_path: "{project-root}/{bmad_folder}/bmm/workflows/3-solutioning/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
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_folder}/bmm/workflows/3-solutioning/create-epics-and-stories/instructions.md"
template: "{bmad_folder}/bmm/workflows/3-solutioning/create-epics-and-stories/epics-template.md"
web_bundle_files:
- "{bmad_folder}/bmm/workflows/3-solutioning/create-epics-and-stories/instructions.md"
- "{bmad_folder}/bmm/workflows/3-solutioning/create-epics-and-stories/epics-template.md"

169
src/modules/bmm/workflows/3-solutioning/implementation-readiness/checklist.md
View File

@ -1,169 +0,0 @@
# Implementation Readiness Validation Checklist
## Document Completeness
### Core Planning Documents
- [ ] PRD exists and is complete
- [ ] PRD contains measurable success criteria
- [ ] PRD defines clear scope boundaries and exclusions
- [ ] Architecture document exists (architecture\*.md)
- [ ] Technical Specification exists with implementation details
- [ ] Epic and story breakdown document exists
- [ ] All documents are dated and versioned
### Document Quality
- [ ] No placeholder sections remain in any document
- [ ] All documents use consistent terminology
- [ ] Technical decisions include rationale and trade-offs
- [ ] Assumptions and risks are explicitly documented
- [ ] Dependencies are clearly identified and documented
## Alignment Verification
### PRD to Architecture Alignment
- [ ] Every functional requirement in PRD has architectural support documented
- [ ] All non-functional requirements from PRD are addressed in architecture
- [ ] Architecture doesn't introduce features beyond PRD scope
- [ ] Performance requirements from PRD match architecture capabilities
- [ ] Security requirements from PRD are fully addressed in architecture
- [ ] If architecture.md: Implementation patterns are defined for consistency
- [ ] If architecture.md: All technology choices have verified versions
- [ ] If UX spec exists: Architecture supports UX requirements
### PRD to Stories Coverage
- [ ] Every PRD requirement maps to at least one story
- [ ] All user journeys in PRD have complete story coverage
- [ ] Story acceptance criteria align with PRD success criteria
- [ ] Priority levels in stories match PRD feature priorities
- [ ] No stories exist without PRD requirement traceability
### Architecture to Stories Implementation
- [ ] All architectural components have implementation stories
- [ ] Infrastructure setup stories exist for each architectural layer
- [ ] Integration points defined in architecture have corresponding stories
- [ ] Data migration/setup stories exist if required by architecture
- [ ] Security implementation stories cover all architecture security decisions
## Story and Sequencing Quality
### Story Completeness
- [ ] All stories have clear acceptance criteria
- [ ] Technical tasks are defined within relevant stories
- [ ] Stories include error handling and edge cases
- [ ] Each story has clear definition of done
- [ ] Stories are appropriately sized (no epic-level stories remaining)
### Sequencing and Dependencies
- [ ] Stories are sequenced in logical implementation order
- [ ] Dependencies between stories are explicitly documented
- [ ] No circular dependencies exist
- [ ] Prerequisite technical tasks precede dependent stories
- [ ] Foundation/infrastructure stories come before feature stories
### Greenfield Project Specifics
- [ ] Initial project setup and configuration stories exist
- [ ] If using architecture.md: First story is starter template initialization command
- [ ] Development environment setup is documented
- [ ] CI/CD pipeline stories are included early in sequence
- [ ] Database/storage initialization stories are properly placed
- [ ] Authentication/authorization stories precede protected features
## Risk and Gap Assessment
### Critical Gaps
- [ ] No core PRD requirements lack story coverage
- [ ] No architectural decisions lack implementation stories
- [ ] All integration points have implementation plans
- [ ] Error handling strategy is defined and implemented
- [ ] Security concerns are all addressed
### Technical Risks
- [ ] No conflicting technical approaches between stories
- [ ] Technology choices are consistent across all documents
- [ ] Performance requirements are achievable with chosen architecture
- [ ] Scalability concerns are addressed if applicable
- [ ] Third-party dependencies are identified with fallback plans
## UX and Special Concerns (if applicable)
### UX Coverage
- [ ] UX requirements are documented in PRD
- [ ] UX implementation tasks exist in relevant stories
- [ ] Accessibility requirements have story coverage
- [ ] Responsive design requirements are addressed
- [ ] User flow continuity is maintained across stories
### Special Considerations
- [ ] Compliance requirements are fully addressed
- [ ] Internationalization needs are covered if required
- [ ] Performance benchmarks are defined and measurable
- [ ] Monitoring and observability stories exist
- [ ] Documentation stories are included where needed
## Overall Readiness
### Ready to Proceed Criteria
- [ ] All critical issues have been resolved
- [ ] High priority concerns have mitigation plans
- [ ] Story sequencing supports iterative delivery
- [ ] Team has necessary skills for implementation
- [ ] No blocking dependencies remain unresolved
### Quality Indicators
- [ ] Documents demonstrate thorough analysis
- [ ] Clear traceability exists across all artifacts
- [ ] Consistent level of detail throughout documents
- [ ] Risks are identified with mitigation strategies
- [ ] Success criteria are measurable and achievable
## Assessment Completion
### Report Quality
- [ ] All findings are supported by specific examples
- [ ] Recommendations are actionable and specific
- [ ] Severity levels are appropriately assigned
- [ ] Positive findings are highlighted
- [ ] Next steps are clearly defined
### Process Validation
- [ ] All expected documents were reviewed
- [ ] Cross-references were systematically checked
- [ ] Project level considerations were applied correctly
- [ ] Workflow status was checked and considered
- [ ] Output folder was thoroughly searched for artifacts
---
## Issue Log
### Critical Issues Found
<!-- checklist of critical issues or N/A -->
### High Priority Issues Found
<!-- checklist of high priority issues or N/A -->
### Medium Priority Issues Found
<!-- checklist of medium priority issues or N/A -->
---
_Use this checklist to ensure comprehensive validation of implementation readiness_

332
src/modules/bmm/workflows/3-solutioning/implementation-readiness/instructions.md
View File

@ -1,332 +0,0 @@
# Implementation Readiness - Workflow Instructions
<critical>The workflow execution engine is governed by: {project-root}/{bmad_folder}/core/tasks/workflow.xml</critical>
<critical>You MUST have already loaded and processed: {project-root}/{bmad_folder}/bmm/workflows/3-solutioning/implementation-readiness/workflow.yaml</critical>
<critical>Communicate all findings and analysis in {communication_language} throughout the assessment</critical>
<critical>Input documents specified in workflow.yaml input_file_patterns - workflow engine handles fuzzy matching, whole vs sharded document discovery automatically</critical>
<critical>⚠️ ABSOLUTELY NO TIME ESTIMATES - NEVER mention hours, days, weeks, months, or ANY time-based predictions. AI has fundamentally changed development speed - what once took teams weeks/months can now be done by one person in hours. DO NOT give ANY time estimates whatsoever.</critical>
<critical>⚠️ CHECKPOINT PROTOCOL: After EVERY <template-output> tag, you MUST follow workflow.xml substep 2c: SAVE content to file immediately → SHOW checkpoint separator (━━━━━━━━━━━━━━━━━━━━━━━) → DISPLAY generated content → PRESENT options [a]Advanced Elicitation/[c]Continue/[p]Party-Mode/[y]YOLO → WAIT for user response. Never batch saves or skip checkpoints.</critical>
<workflow>
<step n="0" goal="Validate workflow readiness" tag="workflow-status">
<action>Check if {workflow_status_file} exists</action>
<check if="status file not found">
<output>No workflow status file found. Implementation Readiness check 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>
<check if="status file found">
<action>Load the FULL file: {workflow_status_file}</action>
<action>Parse workflow_status section</action>
<action>Check status of "implementation-readiness" workflow</action>
<action>Get {selected_track} (quick-flow, bmad-method, or enterprise-bmad-method)</action>
<action>Find first non-completed workflow (next expected workflow)</action>
<action>Based on the selected_track, understand what artifacts should exist: - quick-flow: Tech spec and simple stories in an epic only (no PRD, minimal solutioning) - bmad-method and enterprise-bmad-method: PRD, UX design, epics/stories, architecture</action>
<check if="implementation-readiness status is file path (already completed)">
<output>⚠️ Implementation readiness check already completed: {{implementation-readiness status}}</output>
<ask>Re-running will create a new validation report. Continue? (y/n)</ask>
<check if="n">
<output>Exiting. Use workflow-status to see your next step.</output>
<action>Exit workflow</action>
</check>
</check>
<check if="implementation-readiness is not the next expected workflow">
<output>⚠️ Next expected workflow: {{next_workflow}}. Implementation readiness check is out of sequence.</output>
<ask>Continue with readiness check 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>
<template-output>project_context</template-output>
</step>
<step n="0.5" goal="Discover and load input documents">
<invoke-protocol name="discover_inputs" />
<note>After discovery, these content variables are available: {prd_content}, {epics_content}, {architecture_content}, {ux_design_content}, {tech_spec_content}, {document_project_content}</note>
</step>
<step n="1" goal="Inventory loaded project artifacts">
<action>Review the content loaded by Step 0.5 and create an inventory</action>
<action>Inventory of available documents:
- PRD: {prd_content} (loaded if available)
- Architecture: {architecture_content} (loaded if available)
- Epics: {epics_content} (loaded if available)
- UX Design: {ux_design_content} (loaded if available)
- Tech Spec: {tech_spec_content} (loaded if available, Quick Flow track)
- Brownfield docs: {document_project_content} (loaded via INDEX_GUIDED if available)
</action>
<action>For each loaded document, extract:
- Document type and purpose
- Brief description of what it contains
- Flag any expected documents that are missing as potential issues
</action>
<template-output>document_inventory</template-output>
</step>
<step n="2" goal="Deep analysis of core planning documents">
<action>Thoroughly analyze each loaded document to extract:
- Core requirements and success criteria
- Architectural decisions and constraints
- Technical implementation approaches
- User stories and acceptance criteria
- Dependencies and sequencing requirements
- Any assumptions or risks documented
</action>
<action>For PRD analysis, focus on:
- User requirements and use cases
- Functional and non-functional requirements
- Success metrics and acceptance criteria
- Scope boundaries and explicitly excluded items
- Priority levels for different features
</action>
<action>For Architecture/Tech Spec analysis, focus on:
- System design decisions and rationale
- Technology stack and framework choices
- Integration points and APIs
- Data models and storage decisions
- Security and performance considerations
- Any architectural constraints that might affect story implementation
</action>
<action>For Epic/Story analysis, focus on:
- Coverage of PRD requirements
- Story sequencing and dependencies
- Acceptance criteria completeness
- Technical tasks within stories
- Estimated complexity and effort indicators
</action>
<template-output>document_analysis</template-output>
</step>
<step n="3" goal="Cross-reference validation and alignment check">
<action>PRD ↔ Architecture Alignment:
- Verify every PRD requirement has corresponding architectural support
- Check that architectural decisions don't contradict PRD constraints
- Identify any architectural additions beyond PRD scope (potential gold-plating)
- Ensure non-functional requirements from PRD are addressed in architecture document
- If using new architecture workflow: verify implementation patterns are defined
</action>
<action>PRD ↔ Stories Coverage:
- Map each PRD requirement to implementing stories
- Identify any PRD requirements without story coverage
- Find stories that don't trace back to PRD requirements
- Validate that story acceptance criteria align with PRD success criteria
</action>
<action>Architecture ↔ Stories Implementation Check:
- Verify architectural decisions are reflected in relevant stories
- Check that story technical tasks align with architectural approach
- Identify any stories that might violate architectural constraints
- Ensure infrastructure and setup stories exist for architectural components
</action>
<template-output>alignment_validation</template-output>
</step>
<step n="4" goal="Gap and risk analysis">
<action>Identify and categorize all gaps, risks, and potential issues discovered during validation</action>
<action>Check for Critical Gaps:
- Missing stories for core requirements
- Unaddressed architectural concerns
- Absent infrastructure or setup stories for greenfield projects
- Missing error handling or edge case coverage
- Security or compliance requirements not addressed
</action>
<action>Identify Sequencing Issues:
- Dependencies not properly ordered
- Stories that assume components not yet built
- Parallel work that should be sequential
- Missing prerequisite technical tasks
</action>
<action>Detect Potential Contradictions:
- Conflicts between PRD and architecture approaches
- Stories with conflicting technical approaches
- Acceptance criteria that contradict requirements
- Resource or technology conflicts
</action>
<action>Find Gold-Plating and Scope Creep:
- Features in architecture not required by PRD
- Stories implementing beyond requirements
- Technical complexity beyond project needs
- Over-engineering indicators
</action>
<action>Check Testability Review (if test-design exists in Phase 3):
**Note:** test-design is recommended for BMad Method, required for Enterprise Method
- Check if {output_folder}/test-design-system.md exists
- If exists: Review testability assessment (Controllability, Observability, Reliability)
- If testability concerns documented: Flag for gate decision
- If missing AND track is Enterprise: Flag as CRITICAL gap
- If missing AND track is Method: Note as recommendation (not blocker)
</action>
<template-output>gap_risk_analysis</template-output>
</step>
<step n="5" goal="UX and special concerns validation" optional="true">
<check if="UX artifacts exist or UX workflow in active path">
<action>Review UX artifacts and validate integration:
- Check that UX requirements are reflected in PRD
- Verify stories include UX implementation tasks
- Ensure architecture supports UX requirements (performance, responsiveness)
- Identify any UX concerns not addressed in stories
</action>
<action>Validate accessibility and usability coverage:
- Check for accessibility requirement coverage in stories
- Verify responsive design considerations if applicable
- Ensure user flow completeness across stories
</action>
</check>
<template-output>ux_validation</template-output>
</step>
<step n="6" goal="Generate comprehensive readiness assessment">
<action>Compile all findings into a structured readiness report with:
- Executive summary of readiness status
- Project context and validation scope
- Document inventory and coverage assessment
- Detailed findings organized by severity (Critical, High, Medium, Low)
- Specific recommendations for each issue
- Overall readiness recommendation (Ready, Ready with Conditions, Not Ready)
</action>
<action>Provide actionable next steps:
- List any critical issues that must be resolved
- Suggest specific document updates needed
- Recommend additional stories or tasks required
- Propose sequencing adjustments if needed
</action>
<action>Include positive findings:
- Highlight well-aligned areas
- Note particularly thorough documentation
- Recognize good architectural decisions
- Commend comprehensive story coverage where found
</action>
<template-output>readiness_assessment</template-output>
</step>
<step n="7" goal="Update status and complete" tag="workflow-status">
<check if="standalone_mode != true">
<action>Load the FULL file: {workflow_status_file}</action>
<action>Find workflow_status key "implementation-readiness"</action>
<critical>ONLY write the file path as the status value - no other text, notes, or metadata</critical>
<action>Update workflow_status["implementation-readiness"] = "{output_folder}/implementation-readiness-report-{{date}}.md"</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>
</check>
<action>Determine overall readiness status from the readiness_assessment (Ready, Ready with Conditions, or Not Ready)</action>
<output>**✅ Implementation Readiness Check Complete!**
**Assessment Report:**
- Readiness assessment saved to: {output_folder}/implementation-readiness-report-{{date}}.md
{{#if standalone_mode != true}}
**Status Updated:**
- Progress tracking updated: implementation-readiness 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)
- Review the assessment report and address any critical issues before proceeding
Check status anytime with: `workflow-status`
{{else}}
Since no workflow is in progress:
- 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
{{/if}}
</output>
<check if="overall readiness status is Ready OR Ready with Conditions">
<output>**🚀 Ready for Implementation!**
Your project artifacts are aligned and complete. You can now proceed to Phase 4: Implementation.
</output>
<ask>Would you like to run the **sprint-planning** workflow to initialize your sprint tracking and prepare for development? (yes/no)</ask>
<check if="yes">
<action>Inform user that sprint-planning workflow will be invoked</action>
<invoke-workflow path="{project-root}/{bmad_folder}/bmm/workflows/4-implementation/sprint-planning/workflow.yaml" />
</check>
<check if="no">
<output>You can run sprint-planning later when ready: `sprint-planning`</output>
</check>
</check>
<check if="overall readiness status is Not Ready">
<output>**⚠️ Not Ready for Implementation**
Critical issues must be resolved before proceeding. Review the assessment report and address the identified gaps.
Once issues are resolved, re-run implementation-readiness to validate again.
</output>
</check>
<template-output>status_update_result</template-output>
</step>
</workflow>

189
src/modules/bmm/workflows/3-solutioning/implementation-readiness/steps/step-01-document-discovery.md Normal file
View File

@ -0,0 +1,189 @@
---
name: 'step-01-document-discovery'
description: 'Discover and inventory all project documents, handling duplicates and organizing file structure'
# Path Definitions
workflow_path: '{project-root}/{bmad_folder}/bmm/workflows/3-solutioning/implementation-readiness'
# File References
thisStepFile: '{workflow_path}/steps/step-01-document-discovery.md'
nextStepFile: '{workflow_path}/steps/step-02-prd-analysis.md'
workflowFile: '{workflow_path}/workflow.md'
outputFile: '{output_folder}/implementation-readiness-report-{{date}}.md'
templateFile: '{workflow_path}/templates/readiness-report-template.md'
---
# Step 1: Document Discovery
## STEP GOAL:
To discover, inventory, and organize all project documents, identifying duplicates and determining which versions to use for the assessment.
## MANDATORY EXECUTION RULES (READ FIRST):
### Universal Rules:
- 🛑 NEVER generate content without user input
- 📖 CRITICAL: Read the complete step file before taking any action
- 🔄 CRITICAL: When loading next step with 'C', ensure entire file is read
- 📋 YOU ARE A FACILITATOR, not a content generator
### Role Reinforcement:
- ✅ You are an expert Product Manager and Scrum Master
- ✅ Your focus is on finding organizing and documenting what exists
- ✅ You identify ambiguities and ask for clarification
- ✅ Success is measured in clear file inventory and conflict resolution
### Step-Specific Rules:
- 🎯 Focus ONLY on finding and organizing files
- 🚫 Don't read or analyze file contents
- 💬 Identify duplicate documents clearly
- 🚪 Get user confirmation on file selections
## EXECUTION PROTOCOLS:
- 🎯 Search for all document types systematically
- 💾 Group sharded files together
- 📖 Flag duplicates for user resolution
- 🚫 FORBIDDEN to proceed with unresolved duplicates
## DOCUMENT DISCOVERY PROCESS:
### 1. Initialize Document Discovery
"Beginning **Document Discovery** to inventory all project files.
I will:
1. Search for all required documents (PRD, Architecture, Epics, UX)
2. Group sharded documents together
3. Identify any duplicates (whole + sharded versions)
4. Present findings for your confirmation"
### 2. Document Search Patterns
Search for each document type using these patterns:
#### A. PRD Documents
- Whole: `{output_folder}/*prd*.md`
- Sharded: `{output_folder}/*prd*/index.md` and related files
#### B. Architecture Documents
- Whole: `{output_folder}/*architecture*.md`
- Sharded: `{output_folder}/*architecture*/index.md` and related files
#### C. Epics & Stories Documents
- Whole: `{output_folder}/*epic*.md`
- Sharded: `{output_folder}/*epic*/index.md` and related files
#### D. UX Design Documents
- Whole: `{output_folder}/*ux*.md`
- Sharded: `{output_folder}/*ux*/index.md` and related files
### 3. Organize Findings
For each document type found:
```
## [Document Type] Files Found
**Whole Documents:**
- [filename.md] ([size], [modified date])
**Sharded Documents:**
- Folder: [foldername]/
- index.md
- [other files in folder]
```
### 4. Identify Critical Issues
#### Duplicates (CRITICAL)
If both whole and sharded versions exist:
```
⚠️ CRITICAL ISSUE: Duplicate document formats found
- PRD exists as both whole.md AND prd/ folder
- YOU MUST choose which version to use
- Remove or rename the other version to avoid confusion
```
#### Missing Documents (WARNING)
If required documents not found:
```
⚠️ WARNING: Required document not found
- Architecture document not found
- Will impact assessment completeness
```
### 5. Add Initial Report Section
Initialize {outputFile} with {templateFile}.
### 6. Present Findings and Get Confirmation
Display findings and ask:
"**Document Discovery Complete**
[Show organized file list]
**Issues Found:**
- [List any duplicates requiring resolution]
- [List any missing documents]
**Required Actions:**
- If duplicates exist: Please remove/rename one version
- Confirm which documents to use for assessment
**Ready to proceed?** [C] Continue after resolving issues"
### 7. Present MENU OPTIONS
Display: **Select an Option:** [C] Continue to File Validation
#### EXECUTION RULES:
- ALWAYS halt and wait for user input after presenting menu
- ONLY proceed with 'C' selection
- If duplicates identified, insist on resolution first
- User can clarify file locations or request additional searches
#### Menu Handling Logic:
- IF C: Save document inventory to {outputFile}, update frontmatter with completed step and files being included, and only then load read fully and execute {nextStepFile}
- IF Any other comments or queries: help user respond then redisplay menu
## CRITICAL STEP COMPLETION NOTE
ONLY WHEN C is selected and document inventory is saved will you load {nextStepFile} to begin file validation.
---
## 🚨 SYSTEM SUCCESS/FAILURE METRICS
### ✅ SUCCESS:
- All document types searched systematically
- Files organized and inventoried clearly
- Duplicates identified and flagged for resolution
- User confirmed file selections
### ❌ SYSTEM FAILURE:
- Not searching all document types
- Ignoring duplicate document conflicts
- Proceeding without resolving critical issues
- Not saving document inventory
**Master Rule:** Clear file identification is essential for accurate assessment.

177
src/modules/bmm/workflows/3-solutioning/implementation-readiness/steps/step-02-prd-analysis.md Normal file
View File

@ -0,0 +1,177 @@
---
name: 'step-02-prd-analysis'
description: 'Read and analyze PRD to extract all FRs and NFRs for coverage validation'
# Path Definitions
workflow_path: '{project-root}/{bmad_folder}/bmm/workflows/3-solutioning/implementation-readiness'
# File References
thisStepFile: '{workflow_path}/steps/step-02-prd-analysis.md'
nextStepFile: '{workflow_path}/steps/step-03-epic-coverage-validation.md'
workflowFile: '{workflow_path}/workflow.md'
outputFile: '{output_folder}/implementation-readiness-report-{{date}}.md'
epicsFile: '{output_folder}/*epic*.md' # Will be resolved to actual file
---
# Step 2: PRD Analysis
## STEP GOAL:
To fully read and analyze the PRD document (whole or sharded) to extract all Functional Requirements (FRs) and Non-Functional Requirements (NFRs) for validation against epics coverage.
## MANDATORY EXECUTION RULES (READ FIRST):
### Universal Rules:
- 🛑 NEVER generate content without user input
- 📖 CRITICAL: Read the complete step file before taking any action
- 🔄 CRITICAL: When loading next step with 'C', ensure entire file is read
- 📋 YOU ARE A FACILITATOR, not a content generator
### Role Reinforcement:
- ✅ You are an expert Product Manager and Scrum Master
- ✅ Your expertise is in requirements analysis and traceability
- ✅ You think critically about requirement completeness
- ✅ Success is measured in thorough requirement extraction
### Step-Specific Rules:
- 🎯 Focus ONLY on reading and extracting from PRD
- 🚫 Don't validate files (done in step 1)
- 💬 Read PRD completely - whole or all sharded files
- 🚪 Extract every FR and NFR with numbering
## EXECUTION PROTOCOLS:
- 🎯 Load and completely read the PRD
- 💾 Extract all requirements systematically
- 📖 Document findings in the report
- 🚫 FORBIDDEN to skip or summarize PRD content
## PRD ANALYSIS PROCESS:
### 1. Initialize PRD Analysis
"Beginning **PRD Analysis** to extract all requirements.
I will:
1. Load the PRD document (whole or sharded)
2. Read it completely and thoroughly
3. Extract ALL Functional Requirements (FRs)
4. Extract ALL Non-Functional Requirements (NFRs)
5. Document findings for coverage validation"
### 2. Load and Read PRD
From the document inventory in step 1:
- If whole PRD file exists: Load and read it completely
- If sharded PRD exists: Load and read ALL files in the PRD folder
- Ensure complete coverage - no files skipped
### 3. Extract Functional Requirements (FRs)
Search for and extract:
- Numbered FRs (FR1, FR2, FR3, etc.)
- Requirements labeled "Functional Requirement"
- User stories or use cases that represent functional needs
- Business rules that must be implemented
Format findings as:
```
## Functional Requirements Extracted
FR1: [Complete requirement text]
FR2: [Complete requirement text]
FR3: [Complete requirement text]
...
Total FRs: [count]
```
### 4. Extract Non-Functional Requirements (NFRs)
Search for and extract:
- Performance requirements (response times, throughput)
- Security requirements (authentication, encryption, etc.)
- Usability requirements (accessibility, ease of use)
- Reliability requirements (uptime, error rates)
- Scalability requirements (concurrent users, data growth)
- Compliance requirements (standards, regulations)
Format findings as:
```
## Non-Functional Requirements Extracted
NFR1: [Performance requirement]
NFR2: [Security requirement]
NFR3: [Usability requirement]
...
Total NFRs: [count]
```
### 5. Document Additional Requirements
Look for:
- Constraints or assumptions
- Technical requirements not labeled as FR/NFR
- Business constraints
- Integration requirements
### 6. Add to Assessment Report
Append to {outputFile}:
```markdown
## PRD Analysis
### Functional Requirements
[Complete FR list from section 3]
### Non-Functional Requirements
[Complete NFR list from section 4]
### Additional Requirements
[Any other requirements or constraints found]
### PRD Completeness Assessment
[Initial assessment of PRD completeness and clarity]
```
### 7. Auto-Proceed to Next Step
After PRD analysis complete, immediately load next step for epic coverage validation.
## PROCEEDING TO EPIC COVERAGE VALIDATION
PRD analysis complete. Loading next step to validate epic coverage.
---
## 🚨 SYSTEM SUCCESS/FAILURE METRICS
### ✅ SUCCESS:
- PRD loaded and read completely
- All FRs extracted with full text
- All NFRs identified and documented
- Findings added to assessment report
### ❌ SYSTEM FAILURE:
- Not reading complete PRD (especially sharded versions)
- Missing requirements in extraction
- Summarizing instead of extracting full text
- Not documenting findings in report
**Master Rule:** Complete requirement extraction is essential for traceability validation.

178
src/modules/bmm/workflows/3-solutioning/implementation-readiness/steps/step-03-epic-coverage-validation.md Normal file
View File

@ -0,0 +1,178 @@
---
name: 'step-03-epic-coverage-validation'
description: 'Validate that all PRD FRs are covered in epics and stories'
# Path Definitions
workflow_path: '{project-root}/{bmad_folder}/bmm/workflows/3-solutioning/implementation-readiness'
# File References
thisStepFile: '{workflow_path}/steps/step-03-epic-coverage-validation.md'
nextStepFile: '{workflow_path}/steps/step-04-ux-alignment.md'
workflowFile: '{workflow_path}/workflow.md'
outputFile: '{output_folder}/implementation-readiness-report-{{date}}.md'
---
# Step 3: Epic Coverage Validation
## STEP GOAL:
To validate that all Functional Requirements from the PRD are captured in the epics and stories document, identifying any gaps in coverage.
## MANDATORY EXECUTION RULES (READ FIRST):
### Universal Rules:
- 🛑 NEVER generate content without user input
- 📖 CRITICAL: Read the complete step file before taking any action
- 🔄 CRITICAL: When loading next step with 'C', ensure entire file is read
- 📋 YOU ARE A FACILITATOR, not a content generator
### Role Reinforcement:
- ✅ You are an expert Product Manager and Scrum Master
- ✅ Your expertise is in requirements traceability
- ✅ You ensure no requirements fall through the cracks
- ✅ Success is measured in complete FR coverage
### Step-Specific Rules:
- 🎯 Focus ONLY on FR coverage validation
- 🚫 Don't analyze story quality (that's later)
- 💬 Compare PRD FRs against epic coverage list
- 🚪 Document every missing FR
## EXECUTION PROTOCOLS:
- 🎯 Load epics document completely
- 💾 Extract FR coverage from epics
- 📖 Compare against PRD FR list
- 🚫 FORBIDDEN to proceed without documenting gaps
## EPIC COVERAGE VALIDATION PROCESS:
### 1. Initialize Coverage Validation
"Beginning **Epic Coverage Validation**.
I will:
1. Load the epics and stories document
2. Extract FR coverage information
3. Compare against PRD FRs from previous step
4. Identify any FRs not covered in epics"
### 2. Load Epics Document
From the document inventory in step 1:
- Load the epics and stories document (whole or sharded)
- Read it completely to find FR coverage information
- Look for sections like "FR Coverage Map" or similar
### 3. Extract Epic FR Coverage
From the epics document:
- Find FR coverage mapping or list
- Extract which FR numbers are claimed to be covered
- Document which epics cover which FRs
Format as:
```
## Epic FR Coverage Extracted
FR1: Covered in Epic X
FR2: Covered in Epic Y
FR3: Covered in Epic Z
...
Total FRs in epics: [count]
```
### 4. Compare Coverage Against PRD
Using the PRD FR list from step 2:
- Check each PRD FR against epic coverage
- Identify FRs NOT covered in epics
- Note any FRs in epics but NOT in PRD
Create coverage matrix:
```
## FR Coverage Analysis
| FR Number | PRD Requirement | Epic Coverage | Status |
|-----------|----------------|---------------|---------|
| FR1 | [PRD text] | Epic X Story Y | ✓ Covered |
| FR2 | [PRD text] | **NOT FOUND** | ❌ MISSING |
| FR3 | [PRD text] | Epic Z Story A | ✓ Covered |
```
### 5. Document Missing Coverage
List all FRs not covered:
```
## Missing FR Coverage
### Critical Missing FRs
FR#: [Full requirement text from PRD]
- Impact: [Why this is critical]
- Recommendation: [Which epic should include this]
### High Priority Missing FRs
[List any other uncovered FRs]
```
### 6. Add to Assessment Report
Append to {outputFile}:
```markdown
## Epic Coverage Validation
### Coverage Matrix
[Complete coverage matrix from section 4]
### Missing Requirements
[List of uncovered FRs from section 5]
### Coverage Statistics
- Total PRD FRs: [count]
- FRs covered in epics: [count]
- Coverage percentage: [percentage]
```
### 7. Auto-Proceed to Next Step
After coverage validation complete, immediately load next step.
## PROCEEDING TO UX ALIGNMENT
Epic coverage validation complete. Loading next step for UX alignment.
---
## 🚨 SYSTEM SUCCESS/FAILURE METRICS
### ✅ SUCCESS:
- Epics document loaded completely
- FR coverage extracted accurately
- All gaps identified and documented
- Coverage matrix created
### ❌ SYSTEM FAILURE:
- Not reading complete epics document
- Missing FRs in comparison
- Not documenting uncovered requirements
- Incomplete coverage analysis
**Master Rule:** Every FR must have a traceable implementation path.

138
src/modules/bmm/workflows/3-solutioning/implementation-readiness/steps/step-04-ux-alignment.md Normal file
View File

@ -0,0 +1,138 @@
---
name: 'step-04-ux-alignment'
description: 'Check for UX document and validate alignment with PRD and Architecture'
# Path Definitions
workflow_path: '{project-root}/{bmad_folder}/bmm/workflows/3-solutioning/implementation-readiness'
# File References
thisStepFile: '{workflow_path}/steps/step-04-ux-alignment.md'
nextStepFile: '{workflow_path}/steps/step-05-epic-quality-review.md'
workflowFile: '{workflow_path}/workflow.md'
outputFile: '{output_folder}/implementation-readiness-report-{{date}}.md'
---
# Step 4: UX Alignment
## STEP GOAL:
To check if UX documentation exists and validate that it aligns with PRD requirements and Architecture decisions, ensuring architecture accounts for both PRD and UX needs.
## MANDATORY EXECUTION RULES (READ FIRST):
### Universal Rules:
- 🛑 NEVER generate content without user input
- 📖 CRITICAL: Read the complete step file before taking any action
- 🔄 CRITICAL: When loading next step with 'C', ensure entire file is read
- 📋 YOU ARE A FACILITATOR, not a content generator
### Role Reinforcement:
- ✅ You are a UX VALIDATOR ensuring user experience is properly addressed
- ✅ UX requirements must be supported by architecture
- ✅ Missing UX documentation is a warning if UI is implied
- ✅ Alignment gaps must be documented
### Step-Specific Rules:
- 🎯 Check for UX document existence first
- 🚫 Don't assume UX is not needed
- 💬 Validate alignment between UX, PRD, and Architecture
- 🚪 Add findings to the output report
## EXECUTION PROTOCOLS:
- 🎯 Search for UX documentation
- 💾 If found, validate alignment
- 📖 If not found, assess if UX is implied
- 🚫 FORBIDDEN to proceed without completing assessment
## UX ALIGNMENT PROCESS:
### 1. Initialize UX Validation
"Beginning **UX Alignment** validation.
I will:
1. Check if UX documentation exists
2. If UX exists: validate alignment with PRD and Architecture
3. If no UX: determine if UX is implied and document warning"
### 2. Search for UX Documentation
Search patterns:
- `{output_folder}/*ux*.md` (whole document)
- `{output_folder}/*ux*/index.md` (sharded)
- Look for UI-related terms in other documents
### 3. If UX Document Exists
#### A. UX ↔ PRD Alignment
- Check UX requirements reflected in PRD
- Verify user journeys in UX match PRD use cases
- Identify UX requirements not in PRD
#### B. UX ↔ Architecture Alignment
- Verify architecture supports UX requirements
- Check performance needs (responsiveness, load times)
- Identify UI components not supported by architecture
### 4. If No UX Document
Assess if UX/UI is implied:
- Does PRD mention user interface?
- Are there web/mobile components implied?
- Is this a user-facing application?
If UX implied but missing: Add warning to report
### 5. Add Findings to Report
Append to {outputFile}:
```markdown
## UX Alignment Assessment
### UX Document Status
[Found/Not Found]
### Alignment Issues
[List any misalignments between UX, PRD, and Architecture]
### Warnings
[Any warnings about missing UX or architectural gaps]
```
### 6. Auto-Proceed to Next Step
After UX assessment complete, immediately load next step.
## PROCEEDING TO EPIC QUALITY REVIEW
UX alignment assessment complete. Loading next step for epic quality review.
---
## 🚨 SYSTEM SUCCESS/FAILURE METRICS
### ✅ SUCCESS:
- UX document existence checked
- Alignment validated if UX exists
- Warning issued if UX implied but missing
- Findings added to report
### ❌ SYSTEM FAILURE:
- Not checking for UX document
- Ignoring alignment issues
- Not documenting warnings

251
src/modules/bmm/workflows/3-solutioning/implementation-readiness/steps/step-05-epic-quality-review.md Normal file
View File

@ -0,0 +1,251 @@
---
name: 'step-05-epic-quality-review'
description: 'Validate epics and stories against create-epics-and-stories best practices'
# Path Definitions
workflow_path: '{project-root}/{bmad_folder}/bmm/workflows/3-solutioning/implementation-readiness'
# File References
thisStepFile: '{workflow_path}/steps/step-05-epic-quality-review.md'
nextStepFile: '{workflow_path}/steps/step-06-final-assessment.md'
workflowFile: '{workflow_path}/workflow.md'
outputFile: '{output_folder}/implementation-readiness-report-{{date}}.md'
epicsBestPractices: '{project-root}/{bmad_folder}/bmm/workflows/3-solutioning/create-epics-and-stories'
---
# Step 5: Epic Quality Review
## STEP GOAL:
To validate epics and stories against the best practices defined in create-epics-and-stories workflow, focusing on user value, independence, dependencies, and implementation readiness.
## MANDATORY EXECUTION RULES (READ FIRST):
### Universal Rules:
- 🛑 NEVER generate content without user input
- 📖 CRITICAL: Read the complete step file before taking any action
- 🔄 CRITICAL: When loading next step with 'C', ensure entire file is read
- 📋 YOU ARE A FACILITATOR, not a content generator
### Role Reinforcement:
- ✅ You are an EPIC QUALITY ENFORCER
- ✅ You know what good epics look like - challenge anything deviating
- ✅ Technical epics are wrong - find them
- ✅ Forward dependencies are forbidden - catch them
- ✅ Stories must be independently completable
### Step-Specific Rules:
- 🎯 Apply create-epics-and-stories standards rigorously
- 🚫 Don't accept "technical milestones" as epics
- 💬 Challenge every dependency on future work
- 🚪 Verify proper story sizing and structure
## EXECUTION PROTOCOLS:
- 🎯 Systematically validate each epic and story
- 💾 Document all violations of best practices
- 📖 Check every dependency relationship
- 🚫 FORBIDDEN to accept structural problems
## EPIC QUALITY REVIEW PROCESS:
### 1. Initialize Best Practices Validation
"Beginning **Epic Quality Review** against create-epics-and-stories standards.
I will rigorously validate:
- Epics deliver user value (not technical milestones)
- Epic independence (Epic 2 doesn't need Epic 3)
- Story dependencies (no forward references)
- Proper story sizing and completeness
Any deviation from best practices will be flagged as a defect."
### 2. Epic Structure Validation
#### A. User Value Focus Check
For each epic:
- **Epic Title:** Is it user-centric (what user can do)?
- **Epic Goal:** Does it describe user outcome?
- **Value Proposition:** Can users benefit from this epic alone?
**Red flags (violations):**
- "Setup Database" or "Create Models" - no user value
- "API Development" - technical milestone
- "Infrastructure Setup" - not user-facing
- "Authentication System" - borderline (is it user value?)
#### B. Epic Independence Validation
Test epic independence:
- **Epic 1:** Must stand alone completely
- **Epic 2:** Can function using only Epic 1 output
- **Epic 3:** Can function using Epic 1 & 2 outputs
- **Rule:** Epic N cannot require Epic N+1 to work
**Document failures:**
- "Epic 2 requires Epic 3 features to function"
- Stories in Epic 2 referencing Epic 3 components
- Circular dependencies between epics
### 3. Story Quality Assessment
#### A. Story Sizing Validation
Check each story:
- **Clear User Value:** Does the story deliver something meaningful?
- **Independent:** Can it be completed without future stories?
**Common violations:**
- "Setup all models" - not a USER story
- "Create login UI (depends on Story 1.3)" - forward dependency
#### B. Acceptance Criteria Review
For each story's ACs:
- **Given/When/Then Format:** Proper BDD structure?
- **Testable:** Each AC can be verified independently?
- **Complete:** Covers all scenarios including errors?
- **Specific:** Clear expected outcomes?
**Issues to find:**
- Vague criteria like "user can login"
- Missing error conditions
- Incomplete happy path
- Non-measurable outcomes
### 4. Dependency Analysis
#### A. Within-Epic Dependencies
Map story dependencies within each epic:
- Story 1.1 must be completable alone
- Story 1.2 can use Story 1.1 output
- Story 1.3 can use Story 1.1 & 1.2 outputs
**Critical violations:**
- "This story depends on Story 1.4"
- "Wait for future story to work"
- Stories referencing features not yet implemented
#### B. Database/Entity Creation Timing
Validate database creation approach:
- **Wrong:** Epic 1 Story 1 creates all tables upfront
- **Right:** Each story creates tables it needs
- **Check:** Are tables created only when first needed?
### 5. Special Implementation Checks
#### A. Starter Template Requirement
Check if Architecture specifies starter template:
- If YES: Epic 1 Story 1 must be "Set up initial project from starter template"
- Verify story includes cloning, dependencies, initial configuration
#### B. Greenfield vs Brownfield Indicators
Greenfield projects should have:
- Initial project setup story
- Development environment configuration
- CI/CD pipeline setup early
Brownfield projects should have:
- Integration points with existing systems
- Migration or compatibility stories
### 6. Best Practices Compliance Checklist
For each epic, verify:
- [ ] Epic delivers user value
- [ ] Epic can function independently
- [ ] Stories appropriately sized
- [ ] No forward dependencies
- [ ] Database tables created when needed
- [ ] Clear acceptance criteria
- [ ] Traceability to FRs maintained
### 7. Quality Assessment Documentation
Document all findings by severity:
#### 🔴 Critical Violations
- Technical epics with no user value
- Forward dependencies breaking independence
- Epic-sized stories that cannot be completed
#### 🟠 Major Issues
- Vague acceptance criteria
- Stories requiring future stories
- Database creation violations
#### 🟡 Minor Concerns
- Formatting inconsistencies
- Minor structure deviations
- Documentation gaps
### 8. Autonomous Review Execution
This review runs autonomously to maintain standards:
- Apply best practices without compromise
- Document every violation with specific examples
- Provide clear remediation guidance
- Prepare recommendations for each issue
## REVIEW COMPLETION:
After completing epic quality review:
- Update {outputFile} with all quality findings
- Document specific best practices violations
- Provide actionable recommendations
- Load {nextStepFile} for final readiness assessment
## CRITICAL STEP COMPLETION NOTE
This step executes autonomously. Load {nextStepFile} only after complete epic quality review is documented.
---
## 🚨 SYSTEM SUCCESS/FAILURE METRICS
### ✅ SUCCESS:
- All epics validated against best practices
- Every dependency checked and verified
- Quality violations documented with examples
- Clear remediation guidance provided
- No compromise on standards enforcement
### ❌ SYSTEM FAILURE:
- Accepting technical epics as valid
- Ignoring forward dependencies
- Not verifying story sizing
- Overlooking obvious violations
**Master Rule:** Enforce best practices rigorously. Find all violations.

132
src/modules/bmm/workflows/3-solutioning/implementation-readiness/steps/step-06-final-assessment.md Normal file
View File

@ -0,0 +1,132 @@
---
name: 'step-06-final-assessment'
description: 'Compile final assessment and polish the readiness report'
# Path Definitions
workflow_path: '{project-root}/{bmad_folder}/bmm/workflows/3-solutioning/implementation-readiness'
# File References
thisStepFile: '{workflow_path}/steps/step-06-final-assessment.md'
workflowFile: '{workflow_path}/workflow.md'
outputFile: '{output_folder}/implementation-readiness-report-{{date}}.md'
---
# Step 6: Final Assessment
## STEP GOAL:
To provide a comprehensive summary of all findings and give the report a final polish, ensuring clear recommendations and overall readiness status.
## MANDATORY EXECUTION RULES (READ FIRST):
### Universal Rules:
- 🛑 NEVER generate content without user input
- 📖 CRITICAL: Read the complete step file before taking any action
- 📖 You are at the final step - complete the assessment
- 📋 YOU ARE A FACILITATOR, not a content generator
### Role Reinforcement:
- ✅ You are delivering the FINAL ASSESSMENT
- ✅ Your findings are objective and backed by evidence
- ✅ Provide clear, actionable recommendations
- ✅ Success is measured by value of findings
### Step-Specific Rules:
- 🎯 Compile and summarize all findings
- 🚫 Don't soften the message - be direct
- 💬 Provide specific examples for problems
- 🚪 Add final section to the report
## EXECUTION PROTOCOLS:
- 🎯 Review all findings from previous steps
- 💾 Add summary and recommendations
- 📖 Determine overall readiness status
- 🚫 Complete and present final report
## FINAL ASSESSMENT PROCESS:
### 1. Initialize Final Assessment
"Completing **Final Assessment**.
I will now:
1. Review all findings from previous steps
2. Provide a comprehensive summary
3. Add specific recommendations
4. Determine overall readiness status"
### 2. Review Previous Findings
Check the {outputFile} for sections added by previous steps:
- File and FR Validation findings
- UX Alignment issues
- Epic Quality violations
### 3. Add Final Assessment Section
Append to {outputFile}:
```markdown
## Summary and Recommendations
### Overall Readiness Status
[READY/NEEDS WORK/NOT READY]
### Critical Issues Requiring Immediate Action
[List most critical issues that must be addressed]
### Recommended Next Steps
1. [Specific action item 1]
2. [Specific action item 2]
3. [Specific action item 3]
### Final Note
This assessment identified [X] issues across [Y] categories. Address the critical issues before proceeding to implementation. These findings can be used to improve the artifacts or you may choose to proceed as-is.
```
### 4. Complete the Report
- Ensure all findings are clearly documented
- Verify recommendations are actionable
- Add date and assessor information
- Save the final report
### 5. Present Completion
Display:
"**Implementation Readiness Assessment Complete**
Report generated: {outputFile}
The assessment found [number] issues requiring attention. Review the detailed report for specific findings and recommendations."
## WORKFLOW COMPLETE
The implementation readiness workflow is now complete. The report contains all findings and recommendations for the user to consider.
---
## 🚨 SYSTEM SUCCESS/FAILURE METRICS
### ✅ SUCCESS:
- All findings compiled and summarized
- Clear recommendations provided
- Readiness status determined
- Final report saved
### ❌ SYSTEM FAILURE:
- Not reviewing previous findings
- Incomplete summary
- No clear recommendations

146
src/modules/bmm/workflows/3-solutioning/implementation-readiness/template.md
View File

@ -1,146 +0,0 @@
# Implementation Readiness Assessment Report
**Date:** {{date}}
**Project:** {{project_name}}
**Assessed By:** {{user_name}}
**Assessment Type:** Phase 3 to Phase 4 Transition Validation
---
## Executive Summary
{{readiness_assessment}}
---
## Project Context
{{project_context}}
---
## Document Inventory
### Documents Reviewed
{{document_inventory}}
### Document Analysis Summary
{{document_analysis}}
---
## Alignment Validation Results
### Cross-Reference Analysis
{{alignment_validation}}
---
## Gap and Risk Analysis
### Critical Findings
{{gap_risk_analysis}}
---
## UX and Special Concerns
{{ux_validation}}
---
## Detailed Findings
### 🔴 Critical Issues
_Must be resolved before proceeding to implementation_
{{critical_issues}}
### 🟠 High Priority Concerns
_Should be addressed to reduce implementation risk_
{{high_priority_concerns}}
### 🟡 Medium Priority Observations
_Consider addressing for smoother implementation_
{{medium_priority_observations}}
### 🟢 Low Priority Notes
_Minor items for consideration_
{{low_priority_notes}}
---
## Positive Findings
### ✅ Well-Executed Areas
{{positive_findings}}
---
## Recommendations
### Immediate Actions Required
{{immediate_actions}}
### Suggested Improvements
{{suggested_improvements}}
### Sequencing Adjustments
{{sequencing_adjustments}}
---
## Readiness Decision
### Overall Assessment: {{overall_readiness_status}}
{{readiness_rationale}}
### Conditions for Proceeding (if applicable)
{{conditions_for_proceeding}}
---
## Next Steps
{{recommended_next_steps}}
### Workflow Status Update
{{status_update_result}}
---
## Appendices
### A. Validation Criteria Applied
{{validation_criteria_used}}
### B. Traceability Matrix
{{traceability_matrix}}
### C. Risk Mitigation Strategies
{{risk_mitigation_strategies}}
---
_This readiness assessment was generated using the BMad Method Implementation Readiness workflow (v6-alpha)_

4
src/modules/bmm/workflows/3-solutioning/implementation-readiness/templates/readiness-report-template.md Normal file
View File

@ -0,0 +1,4 @@
# Implementation Readiness Assessment Report
**Date:** {{date}}
**Project:** {{project_name}}

54
src/modules/bmm/workflows/3-solutioning/implementation-readiness/workflow.md Normal file
View File

@ -0,0 +1,54 @@
---
name: 'Implementation Readiness'
description: 'Critical validation workflow that assesses PRD, Architecture, and Epics & Stories for completeness and alignment before implementation. Uses adversarial review approach to find gaps and issues.'
web_bundle: false
---
# Implementation Readiness
**Goal:** Validate that PRD, Architecture, Epics and Stories are complete and aligned before Phase 4 implementation starts, with a focus on ensuring epics and stories are logical and have accounted for all requirements and planning.
**Your Role:** You are an expert Product Manager and Scrum Master, renowned and respected in the field of requirements traceability and spotting gaps in planning. Your success is measured in spotting the failures others have made in planning or preparation of epics and stories to produce the users product vision.
## WORKFLOW ARCHITECTURE
### Core Principles
- **Micro-file Design**: Each step of the overall goal is a self contained instruction file that you will adhere too 1 file as directed at a time
- **Just-In-Time Loading**: Only 1 current step file will be loaded, read, and executed to completion - never load future step files until told to do so
- **Sequential Enforcement**: Sequence within the step files must be completed in order, no skipping or optimization allowed
- **State Tracking**: Document progress in output file frontmatter using `stepsCompleted` array when a workflow produces a document
- **Append-Only Building**: Build documents by appending content as directed to the output file
### Step Processing Rules
1. **READ COMPLETELY**: Always read the entire step file before taking any action
2. **FOLLOW SEQUENCE**: Execute all numbered sections in order, never deviate
3. **WAIT FOR INPUT**: If a menu is presented, halt and wait for user selection
4. **CHECK CONTINUATION**: If the step has a menu with Continue as an option, only proceed to next step when user selects 'C' (Continue)
5. **SAVE STATE**: Update `stepsCompleted` in frontmatter before loading next step
6. **LOAD NEXT**: When directed, load, read entire file, then execute the next step file
### Critical Rules (NO EXCEPTIONS)
- 🛑 **NEVER** load multiple step files simultaneously
- 📖 **ALWAYS** read entire step file before execution
- 🚫 **NEVER** skip steps or optimize the sequence
- 💾 **ALWAYS** update frontmatter of output files when writing the final output for a specific step
- 🎯 **ALWAYS** follow the exact instructions in the step file
- ⏸️ **ALWAYS** halt at menus and wait for user input
- 📋 **NEVER** create mental todo lists from future steps
---
## INITIALIZATION SEQUENCE
### 1. Module Configuration Loading
Load and read full config from {project-root}/{bmad_folder}/bmm/config.yaml and resolve:
- `project_name`, `output_folder`, `user_name`, `communication_language`, `document_output_language`
### 2. First Step EXECUTION
Load, read the full file and then execute `{workflow_path}/steps/step-01-document-discovery.md` to begin the workflow.

64
src/modules/bmm/workflows/3-solutioning/implementation-readiness/workflow.yaml
View File

@ -1,64 +0,0 @@
# Implementation Readiness - Workflow Configuration
name: implementation-readiness
description: "Validate that PRD, UX Design, Architecture, Epics and Stories are complete and aligned before Phase 4 implementation. Ensures all artifacts cover the MVP requirements with no gaps or contradictions."
author: "BMad"
# Critical variables from config
config_source: "{project-root}/{bmad_folder}/bmm/config.yaml"
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"
date: system-generated
# Workflow status integration
workflow_status_workflow: "{project-root}/{bmad_folder}/bmm/workflows/workflow-status/workflow.yaml"
workflow_paths_dir: "{project-root}/{bmad_folder}/bmm/workflows/workflow-status/paths"
workflow_status_file: "{output_folder}/bmm-workflow-status.yaml"
# Module path and component files
installed_path: "{project-root}/{bmad_folder}/bmm/workflows/3-solutioning/implementation-readiness"
template: "{installed_path}/template.md"
instructions: "{installed_path}/instructions.md"
validation: "{installed_path}/checklist.md"
# Output configuration
default_output_file: "{output_folder}/implementation-readiness-report-{{date}}.md"
# Smart input file references - handles both whole docs and sharded docs
# Priority: Whole document first, then sharded version
# Strategy: How to load sharded documents (FULL_LOAD, SELECTIVE_LOAD, INDEX_GUIDED)
input_file_patterns:
prd:
description: "Product Requirements with FRs and NFRs"
whole: "{output_folder}/*prd*.md"
sharded: "{output_folder}/*prd*/index.md"
load_strategy: "FULL_LOAD"
epics:
description: "Epic breakdown with user stories"
whole: "{output_folder}/*epic*.md"
sharded: "{output_folder}/*epic*/index.md"
load_strategy: "FULL_LOAD"
architecture:
description: "System architecture with decisions and patterns"
whole: "{output_folder}/*architecture*.md"
sharded: "{output_folder}/*architecture*/index.md"
load_strategy: "FULL_LOAD"
ux_design:
description: "UX design specification (if UI components)"
whole: "{output_folder}/*ux*.md"
sharded: "{output_folder}/*ux*/index.md"
load_strategy: "FULL_LOAD"
tech_spec:
description: "Technical specification (for Quick Flow track)"
whole: "{output_folder}/*tech-spec*.md"
sharded: "{output_folder}/*tech-spec*/index.md"
load_strategy: "FULL_LOAD"
document_project:
description: "Brownfield project documentation (optional)"
sharded: "{output_folder}/index.md"
load_strategy: "INDEX_GUIDED"
standalone: true
web_bundle: false