2025-11-02 21:18:33 -06:00
# BMM Implementation Workflows (Phase 4)
## Overview
2025-11-04 15:02:19 -06:00
Phase 4 (Implementation) workflows manage the iterative sprint-based development cycle using a **story-centric workflow** where each story moves through a defined lifecycle from creation to completion.
2025-11-02 21:18:33 -06:00
**Key principle:** One story at a time, move it through the entire lifecycle before starting the next.
---
refactor(bmm,cis,core): Align diagram workflows with agile roles and distribute capabilities
## The Tale of the Frame Expert
Once upon a time, BMad Method had a specialized agent called Frame Expert.
This agent was the master of all visual artifacts - flowcharts, diagrams,
wireframes, data flows. Whenever anyone needed a diagram, they called upon
Frame Expert. The agent lived in its own isolated domain with four dedicated
workflows and a library of shared templates.
## The Awakening
But something felt wrong. Teams using BMad Method were meant to mirror real
agile teams - Product Managers, Architects, UX Designers, Tech Writers,
Developers. Each agent represented an authentic role you'd find in any
software team.
Except Frame Expert.
No real agile team has a "Frame Expert" or "Diagram Specialist" who creates
all visual artifacts. In real teams, Architects diagram system architecture.
PMs flowchart processes. UX Designers wireframe interfaces. Tech Writers
create documentation diagrams. The visuals emerge from the domain experts
who need them, not from a centralized diagram factory.
Frame Expert was an abstraction that made technical sense but violated the
very soul of BMad Method - authentic agile role modeling.
## The Transformation
And so Frame Expert was dissolved, its knowledge distributed to those who
truly needed it:
**The Architect** inherited system architecture diagrams and data flows -
the blueprints of technical systems they design.
**The Product Manager** received process flowcharts - the visual maps of
features and workflows they orchestrate.
**The UX Designer** claimed wireframes - the interface sketches that bring
their vision to life.
**The Tech Writer** gained all diagram types - the visual aids that clarify
their documentation.
Each agent now creates diagrams in their domain, using their expertise,
serving their purpose.
## The Shared Knowledge
But the wisdom of diagram creation itself - the Excalidraw templates, the
component libraries, the validation patterns - this knowledge was too
valuable to scatter. It was elevated to core resources, where both BMM
agents AND the new CIS presentation-master agent could draw upon it.
Shared infrastructure for common needs. Distributed execution for domain
expertise.
## The Ripple Effects
With diagrams now properly distributed, other misalignments became visible:
Epic creation was happening in Phase 2 (Planning), before Architecture
existed. But epics need architectural context - API contracts, data models,
technical decisions. So epic creation migrated to Phase 3 (Solutioning),
after Architecture provides that foundation.
Workflow paths were updated. Documentation gained visual flowcharts showing
the complete journey. Agent naming standards were clarified - filenames are
stable roles, persona names are user dreams.
## What Changed
**Removed:**
- frame-expert.agent.yaml (the centralized specialist)
- All frame-expert workflows and shared resources
- Phase 2 epic creation workflow (wrong timing)
- game-design workflow path (consolidated to method track)
- v6-open-items.md (planning doc, now complete)
**Distributed Diagram Capabilities:**
- Architect: create-excalidraw-diagram, create-excalidraw-dataflow
- PM: create-excalidraw-flowchart
- Tech Writer: create-excalidraw-{diagram,dataflow,flowchart}, generate-mermaid
- UX Designer: create-excalidraw-wireframe
**Created:**
- src/core/resources/ (shared diagram context for all modules)
- src/modules/cis/agents/presentation-master.agent.yaml (visual comms specialist)
- src/modules/bmm/workflows/3-solutioning/create-epics-and-stories/ (epic creation's new home)
- src/modules/bmm/workflows/diagrams/ (distributed diagram implementations)
- src/modules/bmm/docs/images/ (workflow visualization assets)
**Enhanced:**
- All agent definitions with domain-appropriate diagram workflows
- Documentation with embedded workflow diagrams and visual guides
- Agent compilation docs with critical naming convention rules
- All 4 workflow paths (enterprise/method × brownfield/greenfield)
**Fixed:**
- Epic creation now in Phase 3 after Architecture
- Story context path variables in BMGD module
- PRD workflow descriptions (epics moved to Phase 3)
## For Users
The Frame Expert commands are gone. In their place:
- Need architecture diagrams? Ask `/architect`
- Need process flows? Ask `/pm`
- Need wireframes? Ask `/ux-designer`
- Need documentation visuals? Ask `/tech-writer`
Each expert creates diagrams in their domain, with their context, using
their judgment.
This is how real teams work.
2025-11-18 21:54:48 -06:00
## Complete Workflow Context
Phase 4 is the final phase of the BMad Method workflow. To see how implementation fits into the complete methodology:
2025-11-26 20:42:20 -06:00
The BMad Method consists of four phases working in sequence:
refactor(bmm,cis,core): Align diagram workflows with agile roles and distribute capabilities
## The Tale of the Frame Expert
Once upon a time, BMad Method had a specialized agent called Frame Expert.
This agent was the master of all visual artifacts - flowcharts, diagrams,
wireframes, data flows. Whenever anyone needed a diagram, they called upon
Frame Expert. The agent lived in its own isolated domain with four dedicated
workflows and a library of shared templates.
## The Awakening
But something felt wrong. Teams using BMad Method were meant to mirror real
agile teams - Product Managers, Architects, UX Designers, Tech Writers,
Developers. Each agent represented an authentic role you'd find in any
software team.
Except Frame Expert.
No real agile team has a "Frame Expert" or "Diagram Specialist" who creates
all visual artifacts. In real teams, Architects diagram system architecture.
PMs flowchart processes. UX Designers wireframe interfaces. Tech Writers
create documentation diagrams. The visuals emerge from the domain experts
who need them, not from a centralized diagram factory.
Frame Expert was an abstraction that made technical sense but violated the
very soul of BMad Method - authentic agile role modeling.
## The Transformation
And so Frame Expert was dissolved, its knowledge distributed to those who
truly needed it:
**The Architect** inherited system architecture diagrams and data flows -
the blueprints of technical systems they design.
**The Product Manager** received process flowcharts - the visual maps of
features and workflows they orchestrate.
**The UX Designer** claimed wireframes - the interface sketches that bring
their vision to life.
**The Tech Writer** gained all diagram types - the visual aids that clarify
their documentation.
Each agent now creates diagrams in their domain, using their expertise,
serving their purpose.
## The Shared Knowledge
But the wisdom of diagram creation itself - the Excalidraw templates, the
component libraries, the validation patterns - this knowledge was too
valuable to scatter. It was elevated to core resources, where both BMM
agents AND the new CIS presentation-master agent could draw upon it.
Shared infrastructure for common needs. Distributed execution for domain
expertise.
## The Ripple Effects
With diagrams now properly distributed, other misalignments became visible:
Epic creation was happening in Phase 2 (Planning), before Architecture
existed. But epics need architectural context - API contracts, data models,
technical decisions. So epic creation migrated to Phase 3 (Solutioning),
after Architecture provides that foundation.
Workflow paths were updated. Documentation gained visual flowcharts showing
the complete journey. Agent naming standards were clarified - filenames are
stable roles, persona names are user dreams.
## What Changed
**Removed:**
- frame-expert.agent.yaml (the centralized specialist)
- All frame-expert workflows and shared resources
- Phase 2 epic creation workflow (wrong timing)
- game-design workflow path (consolidated to method track)
- v6-open-items.md (planning doc, now complete)
**Distributed Diagram Capabilities:**
- Architect: create-excalidraw-diagram, create-excalidraw-dataflow
- PM: create-excalidraw-flowchart
- Tech Writer: create-excalidraw-{diagram,dataflow,flowchart}, generate-mermaid
- UX Designer: create-excalidraw-wireframe
**Created:**
- src/core/resources/ (shared diagram context for all modules)
- src/modules/cis/agents/presentation-master.agent.yaml (visual comms specialist)
- src/modules/bmm/workflows/3-solutioning/create-epics-and-stories/ (epic creation's new home)
- src/modules/bmm/workflows/diagrams/ (distributed diagram implementations)
- src/modules/bmm/docs/images/ (workflow visualization assets)
**Enhanced:**
- All agent definitions with domain-appropriate diagram workflows
- Documentation with embedded workflow diagrams and visual guides
- Agent compilation docs with critical naming convention rules
- All 4 workflow paths (enterprise/method × brownfield/greenfield)
**Fixed:**
- Epic creation now in Phase 3 after Architecture
- Story context path variables in BMGD module
- PRD workflow descriptions (epics moved to Phase 3)
## For Users
The Frame Expert commands are gone. In their place:
- Need architecture diagrams? Ask `/architect`
- Need process flows? Ask `/pm`
- Need wireframes? Ask `/ux-designer`
- Need documentation visuals? Ask `/tech-writer`
Each expert creates diagrams in their domain, with their context, using
their judgment.
This is how real teams work.
2025-11-18 21:54:48 -06:00
2025-11-26 20:42:20 -06:00
1. **Phase 1 (Analysis)** - Optional exploration and discovery workflows
2. **Phase 2 (Planning)** - Required requirements definition using scale-adaptive system
3. **Phase 3 (Solutioning)** - Technical architecture and design decisions
4. **Phase 4 (Implementation)** - Iterative sprint-based development with story-centric workflow
refactor(bmm,cis,core): Align diagram workflows with agile roles and distribute capabilities
## The Tale of the Frame Expert
Once upon a time, BMad Method had a specialized agent called Frame Expert.
This agent was the master of all visual artifacts - flowcharts, diagrams,
wireframes, data flows. Whenever anyone needed a diagram, they called upon
Frame Expert. The agent lived in its own isolated domain with four dedicated
workflows and a library of shared templates.
## The Awakening
But something felt wrong. Teams using BMad Method were meant to mirror real
agile teams - Product Managers, Architects, UX Designers, Tech Writers,
Developers. Each agent represented an authentic role you'd find in any
software team.
Except Frame Expert.
No real agile team has a "Frame Expert" or "Diagram Specialist" who creates
all visual artifacts. In real teams, Architects diagram system architecture.
PMs flowchart processes. UX Designers wireframe interfaces. Tech Writers
create documentation diagrams. The visuals emerge from the domain experts
who need them, not from a centralized diagram factory.
Frame Expert was an abstraction that made technical sense but violated the
very soul of BMad Method - authentic agile role modeling.
## The Transformation
And so Frame Expert was dissolved, its knowledge distributed to those who
truly needed it:
**The Architect** inherited system architecture diagrams and data flows -
the blueprints of technical systems they design.
**The Product Manager** received process flowcharts - the visual maps of
features and workflows they orchestrate.
**The UX Designer** claimed wireframes - the interface sketches that bring
their vision to life.
**The Tech Writer** gained all diagram types - the visual aids that clarify
their documentation.
Each agent now creates diagrams in their domain, using their expertise,
serving their purpose.
## The Shared Knowledge
But the wisdom of diagram creation itself - the Excalidraw templates, the
component libraries, the validation patterns - this knowledge was too
valuable to scatter. It was elevated to core resources, where both BMM
agents AND the new CIS presentation-master agent could draw upon it.
Shared infrastructure for common needs. Distributed execution for domain
expertise.
## The Ripple Effects
With diagrams now properly distributed, other misalignments became visible:
Epic creation was happening in Phase 2 (Planning), before Architecture
existed. But epics need architectural context - API contracts, data models,
technical decisions. So epic creation migrated to Phase 3 (Solutioning),
after Architecture provides that foundation.
Workflow paths were updated. Documentation gained visual flowcharts showing
the complete journey. Agent naming standards were clarified - filenames are
stable roles, persona names are user dreams.
## What Changed
**Removed:**
- frame-expert.agent.yaml (the centralized specialist)
- All frame-expert workflows and shared resources
- Phase 2 epic creation workflow (wrong timing)
- game-design workflow path (consolidated to method track)
- v6-open-items.md (planning doc, now complete)
**Distributed Diagram Capabilities:**
- Architect: create-excalidraw-diagram, create-excalidraw-dataflow
- PM: create-excalidraw-flowchart
- Tech Writer: create-excalidraw-{diagram,dataflow,flowchart}, generate-mermaid
- UX Designer: create-excalidraw-wireframe
**Created:**
- src/core/resources/ (shared diagram context for all modules)
- src/modules/cis/agents/presentation-master.agent.yaml (visual comms specialist)
- src/modules/bmm/workflows/3-solutioning/create-epics-and-stories/ (epic creation's new home)
- src/modules/bmm/workflows/diagrams/ (distributed diagram implementations)
- src/modules/bmm/docs/images/ (workflow visualization assets)
**Enhanced:**
- All agent definitions with domain-appropriate diagram workflows
- Documentation with embedded workflow diagrams and visual guides
- Agent compilation docs with critical naming convention rules
- All 4 workflow paths (enterprise/method × brownfield/greenfield)
**Fixed:**
- Epic creation now in Phase 3 after Architecture
- Story context path variables in BMGD module
- PRD workflow descriptions (epics moved to Phase 3)
## For Users
The Frame Expert commands are gone. In their place:
- Need architecture diagrams? Ask `/architect`
- Need process flows? Ask `/pm`
- Need wireframes? Ask `/ux-designer`
- Need documentation visuals? Ask `/tech-writer`
Each expert creates diagrams in their domain, with their context, using
their judgment.
This is how real teams work.
2025-11-18 21:54:48 -06:00
2025-11-26 20:42:20 -06:00
Phase 4 focuses on the iterative epic and story cycles where stories are implemented, reviewed, and completed one at a time.
refactor(bmm,cis,core): Align diagram workflows with agile roles and distribute capabilities
## The Tale of the Frame Expert
Once upon a time, BMad Method had a specialized agent called Frame Expert.
This agent was the master of all visual artifacts - flowcharts, diagrams,
wireframes, data flows. Whenever anyone needed a diagram, they called upon
Frame Expert. The agent lived in its own isolated domain with four dedicated
workflows and a library of shared templates.
## The Awakening
But something felt wrong. Teams using BMad Method were meant to mirror real
agile teams - Product Managers, Architects, UX Designers, Tech Writers,
Developers. Each agent represented an authentic role you'd find in any
software team.
Except Frame Expert.
No real agile team has a "Frame Expert" or "Diagram Specialist" who creates
all visual artifacts. In real teams, Architects diagram system architecture.
PMs flowchart processes. UX Designers wireframe interfaces. Tech Writers
create documentation diagrams. The visuals emerge from the domain experts
who need them, not from a centralized diagram factory.
Frame Expert was an abstraction that made technical sense but violated the
very soul of BMad Method - authentic agile role modeling.
## The Transformation
And so Frame Expert was dissolved, its knowledge distributed to those who
truly needed it:
**The Architect** inherited system architecture diagrams and data flows -
the blueprints of technical systems they design.
**The Product Manager** received process flowcharts - the visual maps of
features and workflows they orchestrate.
**The UX Designer** claimed wireframes - the interface sketches that bring
their vision to life.
**The Tech Writer** gained all diagram types - the visual aids that clarify
their documentation.
Each agent now creates diagrams in their domain, using their expertise,
serving their purpose.
## The Shared Knowledge
But the wisdom of diagram creation itself - the Excalidraw templates, the
component libraries, the validation patterns - this knowledge was too
valuable to scatter. It was elevated to core resources, where both BMM
agents AND the new CIS presentation-master agent could draw upon it.
Shared infrastructure for common needs. Distributed execution for domain
expertise.
## The Ripple Effects
With diagrams now properly distributed, other misalignments became visible:
Epic creation was happening in Phase 2 (Planning), before Architecture
existed. But epics need architectural context - API contracts, data models,
technical decisions. So epic creation migrated to Phase 3 (Solutioning),
after Architecture provides that foundation.
Workflow paths were updated. Documentation gained visual flowcharts showing
the complete journey. Agent naming standards were clarified - filenames are
stable roles, persona names are user dreams.
## What Changed
**Removed:**
- frame-expert.agent.yaml (the centralized specialist)
- All frame-expert workflows and shared resources
- Phase 2 epic creation workflow (wrong timing)
- game-design workflow path (consolidated to method track)
- v6-open-items.md (planning doc, now complete)
**Distributed Diagram Capabilities:**
- Architect: create-excalidraw-diagram, create-excalidraw-dataflow
- PM: create-excalidraw-flowchart
- Tech Writer: create-excalidraw-{diagram,dataflow,flowchart}, generate-mermaid
- UX Designer: create-excalidraw-wireframe
**Created:**
- src/core/resources/ (shared diagram context for all modules)
- src/modules/cis/agents/presentation-master.agent.yaml (visual comms specialist)
- src/modules/bmm/workflows/3-solutioning/create-epics-and-stories/ (epic creation's new home)
- src/modules/bmm/workflows/diagrams/ (distributed diagram implementations)
- src/modules/bmm/docs/images/ (workflow visualization assets)
**Enhanced:**
- All agent definitions with domain-appropriate diagram workflows
- Documentation with embedded workflow diagrams and visual guides
- Agent compilation docs with critical naming convention rules
- All 4 workflow paths (enterprise/method × brownfield/greenfield)
**Fixed:**
- Epic creation now in Phase 3 after Architecture
- Story context path variables in BMGD module
- PRD workflow descriptions (epics moved to Phase 3)
## For Users
The Frame Expert commands are gone. In their place:
- Need architecture diagrams? Ask `/architect`
- Need process flows? Ask `/pm`
- Need wireframes? Ask `/ux-designer`
- Need documentation visuals? Ask `/tech-writer`
Each expert creates diagrams in their domain, with their context, using
their judgment.
This is how real teams work.
2025-11-18 21:54:48 -06:00
2025-11-26 20:42:20 -06:00
For a visual representation of the complete workflow, see: [workflow-method-greenfield.excalidraw ](./images/workflow-method-greenfield.excalidraw )
2025-11-02 21:18:33 -06:00
---
2025-11-04 15:02:19 -06:00
## Quick Reference
2025-11-02 21:18:33 -06:00
2025-11-26 20:42:20 -06:00
| Workflow | Agent | When | Purpose |
| ------------------- | ----- | --------------------- | ------------------------------------- |
| **sprint-planning** | SM | Once at Phase 4 start | Initialize sprint tracking file |
| **create-story** | SM | Per story | Create next story from epic backlog |
| **dev-story** | DEV | Per story | Implement story with tests |
| **code-review** | DEV | Per story | Senior dev quality review |
| **retrospective** | SM | After epic complete | Review lessons and extract insights |
| **correct-course** | SM | When issues arise | Handle significant mid-sprint changes |
2025-11-02 21:18:33 -06:00
---
2025-11-04 15:02:19 -06:00
## Agent Roles
2025-11-02 21:18:33 -06:00
2025-11-04 15:02:19 -06:00
### SM (Scrum Master) - Primary Implementation Orchestrator
2025-11-02 21:18:33 -06:00
2025-11-26 20:42:20 -06:00
**Workflows:** sprint-planning, create-story, retrospective, correct-course
2025-11-02 21:18:33 -06:00
2025-11-04 15:02:19 -06:00
**Responsibilities:**
2025-11-02 21:18:33 -06:00
2025-11-04 15:02:19 -06:00
- Initialize and maintain sprint tracking
2025-11-26 20:42:20 -06:00
- Create stories from epic backlog
- Handle course corrections when issues arise
- Facilitate retrospectives after epic completion
- Orchestrate overall implementation flow
2025-11-02 21:18:33 -06:00
2025-11-04 15:02:19 -06:00
### DEV (Developer) - Implementation and Quality
2025-11-02 21:18:33 -06:00
2025-11-26 20:42:20 -06:00
**Workflows:** dev-story, code-review
2025-11-02 21:18:33 -06:00
2025-11-04 15:02:19 -06:00
**Responsibilities:**
2025-11-02 21:18:33 -06:00
2025-11-04 15:02:19 -06:00
- Implement stories with tests
- Perform senior developer code reviews
- Ensure quality and adherence to standards
2025-11-26 20:42:20 -06:00
- Complete story implementation lifecycle
2025-11-02 21:18:33 -06:00
---
2025-11-04 15:02:19 -06:00
## Story Lifecycle States
2025-11-02 21:18:33 -06:00
2025-11-04 15:02:19 -06:00
Stories move through these states in the sprint status file:
2025-11-02 21:18:33 -06:00
2025-11-04 15:02:19 -06:00
1. **TODO** - Story identified but not started
2025-12-07 02:35:30 +08:00
2. **IN PROGRESS** - Story being implemented (create-story → dev-story)
2025-11-04 15:02:19 -06:00
3. **READY FOR REVIEW** - Implementation complete, awaiting code review
4. **DONE** - Accepted and complete
2025-11-02 21:18:33 -06:00
---
2025-11-04 15:02:19 -06:00
## Typical Sprint Flow
2025-11-02 21:18:33 -06:00
2025-11-04 15:02:19 -06:00
### Sprint 0 (Planning Phase)
2025-11-02 21:18:33 -06:00
2025-11-04 15:02:19 -06:00
- Complete Phases 1-3 (Analysis, Planning, Solutioning)
refactor: Major v6 epic creation improvements and documentation overhaul
## Key Changes
### 1. Epic Creation Workflow Enhancements
- Added user-value focused epic structure principles (NO technical layer breakdown)
- Implemented multi-mode detection: CONTINUE, REPLACE, or UPDATE existing epics
- Added comprehensive anti-pattern examples showing wrong vs right epic breakdown
- Epics now created AFTER architecture for technically-informed story breakdown
- Added checkpoint protocol for interactive workflow progression
### 2. Removed Deprecated Solutioning Gate Check
- Deleted entire solutioning-gate-check workflow (682 lines)
- Replaced by new implementation-readiness workflow
- Cleaner separation of concerns in solutioning phase
### 3. PRD Template Simplification
- Removed hardcoded "Implementation Planning", "References", and "Next Steps" sections
- PRD now focuses purely on requirements, not workflow orchestration
- Epics/stories created as separate step after architecture
### 4. Documentation Overhaul (15+ docs updated)
- Updated quick-start guide with v6 workflow sequence
- Clarified that epics are created AFTER architecture, not during PRD
- Updated solutioning docs to reflect implementation-readiness pattern
- Improved agents-guide, brownfield-guide, enterprise docs
- Enhanced glossary, FAQ, and workflow reference documentation
### 5. Workflow Path Adjustments
- All 4 paths updated (enterprise/method × brownfield/greenfield)
- Version bumps across BMGD, BMM, and CIS workflow YAMLs
- Minor instruction file updates for consistency
### Files Changed
- 65 files total: 468 insertions, 978 deletions (net reduction of 510 lines)
- 4 files deleted (entire solutioning-gate-check workflow)
- 1 new directory added (implementation-readiness placeholder)
2025-11-16 00:23:47 -06:00
- PRD/GDD + Architecture complete
- **V6: Epics+Stories created via create-epics-and-stories workflow (runs AFTER architecture)**
2025-11-02 21:18:33 -06:00
2025-11-04 15:02:19 -06:00
### Sprint 1+ (Implementation Phase)
2025-11-02 21:18:33 -06:00
2025-11-04 15:02:19 -06:00
**Start of Phase 4:**
2025-11-02 21:18:33 -06:00
2025-11-04 15:02:19 -06:00
1. SM runs `sprint-planning` (once)
2025-11-02 21:18:33 -06:00
2025-11-04 15:02:19 -06:00
**Per Epic:**
2025-11-02 21:18:33 -06:00
2025-11-26 20:42:20 -06:00
- Epic context and stories are already prepared from Phase 3
2025-11-02 21:18:33 -06:00
2025-11-04 15:02:19 -06:00
**Per Story (repeat until epic complete):**
2025-11-02 21:18:33 -06:00
2025-11-04 15:02:19 -06:00
1. SM runs `create-story`
2025-11-26 20:42:20 -06:00
2. DEV runs `dev-story`
3. DEV runs `code-review`
4. If code review fails: DEV fixes issues in `dev-story` , then re-runs `code-review`
2025-11-02 21:18:33 -06:00
2025-11-04 15:02:19 -06:00
**After Epic Complete:**
2025-11-02 21:18:33 -06:00
2025-11-26 20:42:20 -06:00
- SM runs `retrospective`
- Move to next epic
2025-11-02 21:18:33 -06:00
2025-11-04 15:02:19 -06:00
**As Needed:**
2025-11-02 21:18:33 -06:00
2025-12-03 18:00:34 +00:00
- Run `sprint-status` anytime in Phase 4 to inspect sprint-status.yaml and get the next implementation command
- Run `workflow-status` for cross-phase routing and project-level paths
2025-11-04 15:02:19 -06:00
- Run `correct-course` if significant changes needed
2025-11-02 21:18:33 -06:00
---
2025-11-04 15:02:19 -06:00
## Key Principles
2025-11-02 21:18:33 -06:00
2025-11-04 15:02:19 -06:00
### One Story at a Time
2025-11-02 21:18:33 -06:00
2025-11-04 15:02:19 -06:00
Complete each story's full lifecycle before starting the next. This prevents context switching and ensures quality.
2025-11-02 21:18:33 -06:00
2025-11-04 15:02:19 -06:00
### Quality Gates
2025-11-02 21:18:33 -06:00
2025-11-04 15:02:19 -06:00
Every story goes through `code-review` before being marked done. No exceptions.
2025-11-02 21:18:33 -06:00
2025-11-04 15:02:19 -06:00
### Continuous Tracking
2025-11-02 21:18:33 -06:00
2025-11-04 15:02:19 -06:00
The `sprint-status.yaml` file is the single source of truth for all implementation progress.
2025-11-02 21:18:33 -06:00
---
2025-11-26 20:42:20 -06:00
### (BMad Method / Enterprise)
2025-11-02 21:18:33 -06:00
```
refactor: Major v6 epic creation improvements and documentation overhaul
## Key Changes
### 1. Epic Creation Workflow Enhancements
- Added user-value focused epic structure principles (NO technical layer breakdown)
- Implemented multi-mode detection: CONTINUE, REPLACE, or UPDATE existing epics
- Added comprehensive anti-pattern examples showing wrong vs right epic breakdown
- Epics now created AFTER architecture for technically-informed story breakdown
- Added checkpoint protocol for interactive workflow progression
### 2. Removed Deprecated Solutioning Gate Check
- Deleted entire solutioning-gate-check workflow (682 lines)
- Replaced by new implementation-readiness workflow
- Cleaner separation of concerns in solutioning phase
### 3. PRD Template Simplification
- Removed hardcoded "Implementation Planning", "References", and "Next Steps" sections
- PRD now focuses purely on requirements, not workflow orchestration
- Epics/stories created as separate step after architecture
### 4. Documentation Overhaul (15+ docs updated)
- Updated quick-start guide with v6 workflow sequence
- Clarified that epics are created AFTER architecture, not during PRD
- Updated solutioning docs to reflect implementation-readiness pattern
- Improved agents-guide, brownfield-guide, enterprise docs
- Enhanced glossary, FAQ, and workflow reference documentation
### 5. Workflow Path Adjustments
- All 4 paths updated (enterprise/method × brownfield/greenfield)
- Version bumps across BMGD, BMM, and CIS workflow YAMLs
- Minor instruction file updates for consistency
### Files Changed
- 65 files total: 468 insertions, 978 deletions (net reduction of 510 lines)
- 4 files deleted (entire solutioning-gate-check workflow)
- 1 new directory added (implementation-readiness placeholder)
2025-11-16 00:23:47 -06:00
PRD (PM) → Architecture (Architect)
→ create-epics-and-stories (PM) ← V6: After architecture!
→ implementation-readiness (Architect)
2025-11-04 15:02:19 -06:00
→ sprint-planning (SM, once)
→ [Per Epic]:
→ story loop (SM/DEV)
2025-11-26 20:42:20 -06:00
→ retrospective (SM)
2025-11-04 15:02:19 -06:00
→ [Next Epic]
2025-12-05 22:32:59 -06:00
Current Phase: 4 (Implementation)
Current Epic: Epic 1 (Authentication)
Current Sprint: Sprint 1
Next Story: Story 1.3 (Email Verification)
Status: TODO
Dependencies: Story 1.2 (DONE) ✅
**Recommendation:** Run `create-story` to generate Story 1.3
After create-story:
1. Run story-context
2. Run dev-story
3. Run code-review
4. Run story-done
```
See: [workflow-status instructions ](../workflows/workflow-status/instructions.md )
---
### document-project
**Purpose:** Analyze and document brownfield projects by scanning codebase, architecture, and patterns.
**Agent:** Analyst
**Duration:** 1-3 hours
**When to Use:** Brownfield projects without documentation
**How It Works:**
1. Scans codebase structure
2. Identifies architecture patterns
3. Documents technology stack
4. Creates reference documentation
5. Generates PRD-like document from existing code
**Output:** `project-documentation-{date}.md`
**When to Run:**
- Before starting work on legacy project
- When inheriting undocumented codebase
- Creating onboarding documentation
See: [document-project reference ](./workflow-document-project-reference.md )
2025-11-04 15:02:19 -06:00
## Related Documentation
2025-11-02 21:18:33 -06:00
2025-11-26 20:42:20 -06:00
- [Phase 1: Analysis Workflows ](./workflows-analysis.md )
2025-11-04 15:02:19 -06:00
- [Phase 2: Planning Workflows ](./workflows-planning.md )
- [Phase 3: Solutioning Workflows ](./workflows-solutioning.md )
2025-11-02 21:18:33 -06:00
2025-11-04 15:02:19 -06:00
## Troubleshooting
2025-11-02 21:18:33 -06:00
2025-11-04 15:02:19 -06:00
**Q: Which workflow should I run next?**
2025-12-03 18:00:34 +00:00
A: Run `workflow-status` - it reads the sprint status file and tells you exactly what to do. During implementation (Phase 4) run `sprint-status` (fast check against sprint-status.yaml).
2025-11-02 21:18:33 -06:00
2025-11-04 15:02:19 -06:00
**Q: Story needs significant changes mid-implementation?**
A: Run `correct-course` to analyze impact and route appropriately.
2025-11-02 21:18:33 -06:00
2025-11-04 15:02:19 -06:00
**Q: Can I work on multiple stories in parallel?**
A: Not recommended. Complete one story's full lifecycle before starting the next. Prevents context switching and ensures quality.
2025-11-02 21:18:33 -06:00
2025-11-04 15:02:19 -06:00
**Q: What if code review finds issues?**
2025-11-26 20:42:20 -06:00
A: DEV runs `dev-story` to make fixes, re-runs tests, then runs `code-review` again until it passes.
2025-11-02 21:18:33 -06:00
2025-11-04 15:02:19 -06:00
_Phase 4 Implementation - One story at a time, done right._
