bmad-method 6.0.0-alpha.3 → 6.0.0-alpha.5

package/src/modules/bmm/workflows/4-implementation/retrospective/README.md

@@ -1,77 +0,0 @@
----
-last-redoc-date: 2025-10-01
----
-
-# Retrospective Workflow
-
-The retrospective workflow is v6's learning capture mechanism, run by the Scrum Master (SM) after epic completion to systematically harvest insights, patterns, and improvements discovered during implementation. Unlike traditional retrospectives that focus primarily on process and team dynamics, this workflow performs deep technical and methodological analysis of the entire epic journey—from story creation through implementation to review—identifying what worked well, what could improve, and what patterns emerged. The retrospective produces actionable intelligence that informs future epics, improves workflow templates, and evolves the team's shared knowledge.
-
-This workflow represents a critical feedback loop in the v6 methodology. Each epic is an experiment in adaptive software development, and the retrospective is where we analyze the results of that experiment. The SM examines completed stories, review feedback, course corrections made, story-context effectiveness, technical decisions, and team collaboration patterns to extract transferable learning. This learning manifests as updates to workflow templates, new story-context patterns, refined estimation approaches, and documented best practices.
-
-The retrospective is not just a compliance ritual but a genuine opportunity for continuous improvement. By systematically analyzing what happened during the epic, the team builds institutional knowledge that makes each subsequent epic smoother, faster, and higher quality. The insights captured here directly improve future story creation, context generation, development efficiency, and review effectiveness.
-
-## Usage
-
-```bash
-# Conduct retrospective after epic completion
-bmad run retrospective
-```
-
-The SM should run this workflow:
-
-- After all stories in an epic are completed
-- Before starting the next major epic
-- When significant learning has accumulated
-- As preparation for improving future epic execution
-
-## Inputs
-
-**Required Context:**
-
-- **Epic Document**: Complete epic specification and goals
-- **All Story Documents**: Every story created for the epic
-- **Review Reports**: All review feedback and findings
-- **Course Corrections**: Any correct-course actions taken
-- **Story Contexts**: Generated expert guidance for each story
-- **Implementation Artifacts**: Code commits, test results, deployment records
-
-**Analysis Targets:**
-
-- Story creation accuracy and sizing
-- Story-context effectiveness and relevance
-- Implementation challenges and solutions
-- Review findings and patterns
-- Technical decisions and outcomes
-- Estimation accuracy
-- Team collaboration and communication
-- Workflow effectiveness
-
-## Outputs
-
-**Primary Deliverable:**
-
-- **Retrospective Report** (`[epic-id]-retrospective.xml`): Comprehensive analysis including:
-  - Executive summary of epic outcomes
-  - Story-by-story analysis of what was learned
-  - Technical insights and architecture learnings
-  - Story-context effectiveness assessment
-  - Process improvements identified
-  - Patterns discovered (good and bad)
-  - Recommendations for future epics
-  - Metrics and statistics (velocity, cycle time, etc.)
-
-**Actionable Outputs:**
-
-- **Template Updates**: Improvements to workflow templates based on learning
-- **Pattern Library**: New story-context patterns for common scenarios
-- **Best Practices**: Documented approaches that worked well
-- **Gotchas**: Issues to avoid in future work
-- **Estimation Refinements**: Better story sizing guidance
-- **Process Changes**: Workflow adjustments for next epic
-
-**Artifacts:**
-
-- Epic marked as complete with retrospective attached
-- Knowledge base updated with new patterns
-- Workflow templates updated if needed
-- Team learning captured for onboarding

package/src/modules/bmm/workflows/4-implementation/sprint-planning/README.md

@@ -1,156 +0,0 @@
-# Sprint Planning Workflow
-
-## Overview
-
-The sprint-planning workflow generates and manages the sprint status tracking file that serves as the single source of truth for Phase 4 implementation. It extracts all epics and stories from epic files and tracks their progress through the development lifecycle.
-
-In Agile terminology, this workflow facilitates **Sprint Planning** or **Sprint 0 Kickoff** - the transition from planning/architecture into actual development execution.
-
-## Purpose
-
-This workflow creates a `sprint-status.yaml` file that:
-
-- Lists all epics, stories, and retrospectives in order
-- Tracks the current status of each item
-- Provides a clear view of what needs to be worked on next
-- Ensures only one story is in progress at a time
-- Maintains the development flow from backlog to done
-
-## When to Use
-
-Run this workflow:
-
-1. **Initially** - After Phase 3 (solutioning) is complete and epics are finalized
-2. **After epic context creation** - To update epic status to 'contexted'
-3. **Periodically** - To auto-detect newly created story files
-4. **For status checks** - To see overall project progress
-
-## Status State Machine
-
-### Epic Flow
-
-```
-backlog → contexted
-```
-
-### Story Flow
-
-```
-backlog → drafted → ready-for-dev → in-progress → review → done
-```
-
-### Retrospective Flow
-
-```
-optional ↔ completed
-```
-
-## Key Guidelines
-
-1. **Epic Context Recommended**: Epics should be `contexted` before their stories can be `drafted`
-2. **Flexible Parallelism**: Multiple stories can be `in-progress` based on team capacity
-3. **Sequential Default**: Stories within an epic are typically worked in order, but parallel work is supported
-4. **Review Flow**: Stories should go through `review` before `done`
-5. **Learning Transfer**: SM typically drafts next story after previous is `done`, incorporating learnings
-
-## File Locations
-
-### Input Files
-
-- **Epic Files**: `{output_folder}/epic*.md` or `{output_folder}/epics.md`
-- **Epic Context**: `{output_folder}/epic-{n}-context.md`
-- **Story Files**: `{story_dir}/{epic}-{story}-{title}.md`
-  - Example: `stories/1-1-user-authentication.md`
-- **Story Context**: `{story_dir}/{epic}-{story}-{title}-context.md`
-  - Example: `stories/1-1-user-authentication-context.md`
-
-### Output File
-
-- **Status File**: `{output_folder}/sprint-status.yaml`
-
-## Usage by Agents
-
-### SM (Scrum Master) Agent
-
-```yaml
-Tasks:
-  - Check sprint-status.yaml for stories in 'done' status
-  - Identify next 'backlog' story to draft
-  - Run create-story workflow
-  - Update status to 'drafted'
-  - Create story context
-  - Update status to 'ready-for-dev'
-```
-
-### Developer Agent
-
-```yaml
-Tasks:
-  - Find stories with 'ready-for-dev' status
-  - Update to 'in-progress' when starting
-  - Implement the story
-  - Update to 'review' when complete
-  - Address review feedback
-  - Update to 'done' after review
-```
-
-### Test Architect
-
-```yaml
-Tasks:
-  - Monitor stories entering 'review'
-  - Track epic progress
-  - Identify when retrospectives are needed
-```
-
-## Example Output
-
-```yaml
-# Sprint Status
-# Generated: 2025-01-20
-# Project: MyPlantFamily
-
-development_status:
-  epic-1: contexted
-  1-1-project-foundation: done
-  1-2-app-shell: done
-  1-3-user-authentication: in-progress
-  1-4-plant-data-model: ready-for-dev
-  1-5-add-plant-manual: drafted
-  1-6-photo-identification: backlog
-  epic-1-retrospective: optional
-
-  epic-2: contexted
-  2-1-personality-system: in-progress
-  2-2-chat-interface: drafted
-  2-3-llm-integration: backlog
-  2-4-reminder-system: backlog
-  epic-2-retrospective: optional
-```
-
-## Integration with BMM Workflow
-
-This workflow is part of Phase 4 (Implementation) and integrates with:
-
-1. **epic-tech-context** - Creates technical context for epics
-2. **create-story** - Drafts individual story files
-3. **story-context** - Adds implementation context to stories
-4. **dev-story** - Developer implements the story
-5. **code-review** - SM reviews implementation
-6. **retrospective** - Optional epic retrospective
-
-## Benefits
-
-- **Clear Visibility**: Everyone knows what's being worked on
-- **Flexible Capacity**: Supports both sequential and parallel work patterns
-- **Learning Transfer**: SM can incorporate learnings when drafting next story
-- **Progress Tracking**: Easy to see overall project status
-- **Automation Friendly**: Simple YAML format for agent updates
-
-## Tips
-
-1. **Initial Generation**: Run immediately after epics are finalized
-2. **Regular Updates**: Agents should update status as they work
-3. **Manual Override**: You can manually edit the file if needed
-4. **Backup First**: The workflow backs up existing status before regenerating
-5. **Validation**: The workflow validates legal status transitions

package/src/modules/bmm/workflows/4-implementation/story-context/README.md

@@ -1,234 +0,0 @@
-# Story Context Assembly Workflow
-
-## Overview
-
-Assembles a dynamic Story Context XML by pulling latest documentation and existing code/library artifacts relevant to a drafted story. Creates comprehensive development context for AI agents and developers working on specific stories.
-
-## Key Features
-
-- **Automated Context Discovery** - Scans documentation and codebase for relevant artifacts
-- **XML Output Format** - Structured context optimized for LLM consumption
-- **Dependency Detection** - Identifies frameworks, packages, and technical dependencies
-- **Interface Mapping** - Locates existing APIs and interfaces to reuse
-- **Testing Integration** - Includes testing standards and generates test ideas
-- **Status Tracking** - Updates story status and maintains context references
-
-## Usage
-
-### Basic Invocation
-
-```bash
-workflow story-context
-```
-
-### With Specific Story
-
-```bash
-# Process specific story file
-workflow story-context --input /path/to/story.md
-
-# Using story path variable
-workflow story-context --story_path "docs/stories/1.2.feature-name.md"
-```
-
-### Configuration
-
-- **story_path**: Path to target story markdown file (defaults to latest.md)
-- **auto_update_status**: Whether to automatically update story status (default: false)
-
-## Workflow Structure
-
-### Files Included
-
-```
-story-context/
-├── workflow.yaml           # Configuration and metadata
-├── instructions.md         # Step-by-step execution guide
-├── context-template.xml    # XML structure template
-├── checklist.md           # Validation criteria
-└── README.md              # This file
-```
-
-## Workflow Process
-
-### Phase 1: Story Analysis (Steps 1-2)
-
-- **Story Location**: Finds and loads target story markdown file
-- **Content Parsing**: Extracts epic ID, story ID, title, acceptance criteria, and tasks
-- **Template Initialization**: Creates initial XML context structure
-- **User Story Extraction**: Parses "As a... I want... So that..." components
-
-### Phase 2: Documentation Discovery (Step 3)
-
-- **Keyword Analysis**: Identifies relevant terms from story content
-- **Document Scanning**: Searches docs and module documentation
-- **Authority Prioritization**: Prefers PRDs, architecture docs, and specs
-- **Context Extraction**: Captures relevant sections with snippets
-
-### Phase 3: Code Analysis (Step 4)
-
-- **Symbol Search**: Finds relevant modules, functions, and components
-- **Interface Identification**: Locates existing APIs and interfaces
-- **Constraint Extraction**: Identifies development patterns and requirements
-- **Reuse Opportunities**: Highlights existing code to leverage
-
-### Phase 4: Dependency Analysis (Step 5)
-
-- **Manifest Detection**: Scans for package.json, requirements.txt, go.mod, etc.
-- **Framework Identification**: Identifies Unity, Node.js, Python, Go ecosystems
-- **Version Tracking**: Captures dependency versions where available
-- **Configuration Discovery**: Finds relevant project configurations
-
-### Phase 5: Testing Context (Step 6)
-
-- **Standards Extraction**: Identifies testing frameworks and patterns
-- **Location Mapping**: Documents where tests should be placed
-- **Test Ideas**: Generates initial test concepts for acceptance criteria
-- **Framework Integration**: Links to existing test infrastructure
-
-### Phase 6: Validation and Updates (Steps 7-8)
-
-- **XML Validation**: Ensures proper structure and completeness
-- **Status Updates**: Changes story status from Draft to ContextReadyDraft
-- **Reference Tracking**: Adds context file reference to story document
-- **Quality Assurance**: Validates against workflow checklist
-
-## Output
-
-### Generated Files
-
-- **Primary output**: story-context-{epic_id}.{story_id}-{date}.xml
-- **Story updates**: Modified original story file with context references
-
-### Output Structure
-
-```xml
-<storyContext>
-  <story>
-    <basicInfo>
-      <epicId>...</epicId>
-      <storyId>...</storyId>
-      <title>...</title>
-      <status>...</status>
-    </basicInfo>
-    <userStory>
-      <asA>...</asA>
-      <iWant>...</iWant>
-      <soThat>...</soThat>
-    </userStory>
-    <acceptanceCriteria>
-      <criterion id="1">...</criterion>
-    </acceptanceCriteria>
-    <tasks>
-      <task>...</task>
-    </tasks>
-  </story>
-
-  <artifacts>
-    <docs>
-      <doc path="..." title="..." section="..." snippet="..."/>
-    </docs>
-    <code>
-      <file path="..." kind="..." symbol="..." lines="..." reason="..."/>
-    </code>
-    <dependencies>
-      <node>
-        <package name="..." version="..."/>
-      </node>
-    </dependencies>
-  </artifacts>
-
-  <interfaces>
-    <interface name="..." kind="..." signature="..." path="..."/>
-  </interfaces>
-
-  <constraints>
-    <constraint>...</constraint>
-  </constraints>
-
-  <tests>
-    <standards>...</standards>
-    <locations>
-      <location>...</location>
-    </locations>
-    <ideas>
-      <idea ac="1">...</idea>
-    </ideas>
-  </tests>
-</storyContext>
-```
-
-## Requirements
-
-- **Story File**: Valid story markdown with proper structure (epic.story.title.md format)
-- **Repository Access**: Ability to scan documentation and source code
-- **Documentation**: Project documentation in standard locations (docs/, src/, etc.)
-
-## Best Practices
-
-### Before Starting
-
-1. **Ensure Story Quality**: Verify story has clear acceptance criteria and tasks
-2. **Update Documentation**: Ensure relevant docs are current and discoverable
-3. **Clean Repository**: Remove obsolete code that might confuse context assembly
-
-### During Execution
-
-1. **Review Extracted Context**: Verify that discovered artifacts are actually relevant
-2. **Check Interface Accuracy**: Ensure identified APIs and interfaces are current
-3. **Validate Dependencies**: Confirm dependency information matches project state
-
-### After Completion
-
-1. **Review XML Output**: Validate the generated context makes sense
-2. **Test with Developer**: Have a developer review context usefulness
-3. **Update Story Status**: Verify story status was properly updated
-
-## Troubleshooting
-
-### Common Issues
-
-**Issue**: Context contains irrelevant or outdated information
-
-- **Solution**: Review keyword extraction and document filtering logic
-- **Check**: Ensure story title and acceptance criteria are specific and clear
-
-**Issue**: Missing relevant code or interfaces
-
-- **Solution**: Verify code search patterns and symbol extraction
-- **Check**: Ensure relevant code follows project naming conventions
-
-**Issue**: Dependency information is incomplete or wrong
-
-- **Solution**: Check for multiple package manifests or unusual project structure
-- **Check**: Verify dependency files are in expected locations and formats
-
-## Customization
-
-To customize this workflow:
-
-1. **Modify Search Patterns**: Update instructions.md to adjust code and doc discovery
-2. **Extend XML Schema**: Customize context-template.xml for additional context types
-3. **Add Validation**: Extend checklist.md with project-specific quality criteria
-4. **Configure Dependencies**: Adjust dependency detection for specific tech stacks
-
-## Version History
-
-- **v6.0.0** - XML-based context assembly with comprehensive artifact discovery
-  - Multi-ecosystem dependency detection
-  - Interface and constraint extraction
-  - Testing context integration
-  - Story status management
-
-## Support
-
-For issues or questions:
-
-- Review the workflow creation guide at `/bmad/bmb/workflows/create-workflow/workflow-creation-guide.md`
-- Validate output using `checklist.md`
-- Ensure story files follow expected markdown structure
-- Check that repository structure supports automated discovery
-
----
-
-_Part of the BMad Method v6 - BMM (Method) Module_

package/src/modules/bmm/workflows/README.md

@@ -1,215 +0,0 @@
-# BMM Workflows - Complete v6 Guide
-
-Master guide for BMM's four-phase methodology that adapts to project scale (Level 0-4) and context (greenfield/brownfield).
-
-## Table of Contents
-
-- [Core Innovations](#core-innovations)
-- [Universal Entry Point](#universal-entry-point)
-- [Four Phases Overview](#four-phases-overview)
-- [Phase Details](#phase-details)
-  - [Documentation Prerequisite](#documentation-prerequisite)
-  - [Phase 1: Analysis](#phase-1-analysis)
-  - [Phase 2: Planning](#phase-2-planning)
-  - [Phase 3: Solutioning](#phase-3-solutioning)
-  - [Phase 4: Implementation](#phase-4-implementation)
-- [Scale Levels](#scale-levels)
-- [Greenfield vs Brownfield](#greenfield-vs-brownfield)
-- [Critical Rules](#critical-rules)
-
-## Core Innovations
-
-- **Scale-Adaptive Planning** - Automatic routing based on complexity (Level 0-4)
-- **Just-In-Time Design** - Tech specs created per epic during implementation
-- **Dynamic Expertise Injection** - Story-specific technical guidance
-- **Continuous Learning Loop** - Retrospectives improve each cycle
-
-## Universal Entry Point
-
-**Always start with `workflow-status` or `workflow-init`**
-
-### workflow-status
-
-- Checks for existing workflow status file
-- Displays current phase and progress
-- Routes to appropriate next workflow
-- Shows Phase 4 implementation state
-
-### workflow-init
-
-- Creates initial bmm-workflow-status.md
-- Detects greenfield vs brownfield
-- Routes undocumented brownfield to document-project
-- Sets up workflow tracking
-
-## Four Phases Overview
-
-```
-PREREQUISITE: document-project (brownfield without docs)
-                    ↓
-PHASE 1: Analysis (optional)
-    brainstorm → research → brief
-                    ↓
-PHASE 2: Planning (required, scale-adaptive)
-    Level 0-1: tech-spec only
-    Level 2-4: PRD + epics
-                    ↓
-PHASE 3: Solutioning (Level 2-4 only)
-    architecture → validation → gate-check
-                    ↓
-PHASE 4: Implementation (iterative)
-    sprint-planning → epic-context → story cycle
-```
-
-## Phase Details
-
-### Documentation Prerequisite
-
-**When:** Brownfield projects without documentation OR post-completion cleanup
-
-| Workflow         | Purpose                       | Output             |
-| ---------------- | ----------------------------- | ------------------ |
-| document-project | Analyze and document codebase | Comprehensive docs |
-
-**Use Cases:**
-
-1. **Pre-Phase 1**: Understand existing brownfield code
-2. **Post-Phase 4**: Create clean documentation replacing scattered artifacts
-
-### Phase 1: Analysis
-
-**Optional workflows for discovery and requirements gathering**
-
-| Workflow           | Agent         | Purpose               | Output                 |
-| ------------------ | ------------- | --------------------- | ---------------------- |
-| brainstorm-project | Analyst       | Software ideation     | Architecture proposals |
-| brainstorm-game    | Game Designer | Game concept ideation | Concept proposals      |
-| research           | Analyst       | Multi-mode research   | Research artifacts     |
-| product-brief      | Analyst       | Strategic planning    | Product brief          |
-| game-brief         | Game Designer | Game foundation       | Game brief             |
-
-### Phase 2: Planning
-
-**Required phase with scale-adaptive routing**
-
-| Workflow         | Agent         | Output         | Levels      |
-| ---------------- | ------------- | -------------- | ----------- |
-| prd              | PM            | PRD.md + epics | 2-4         |
-| tech-spec        | PM            | tech-spec.md   | 0-1         |
-| gdd              | Game Designer | GDD.md         | Games       |
-| create-ux-design | UX            | ux-design.md   | Conditional |
-
-### Phase 3: Solutioning
-
-**Architecture phase for Level 2-4 projects**
-
-| Workflow               | Agent     | Purpose           | Output                 |
-| ---------------------- | --------- | ----------------- | ---------------------- |
-| create-architecture    | Architect | System design     | architecture.md + ADRs |
-| validate-architecture  | Architect | Design validation | Validation report      |
-| solutioning-gate-check | Architect | PRD/UX/arch check | Gate report            |
-
-### Phase 4: Implementation
-
-**Sprint-based development cycle**
-
-#### Sprint Status System
-
-**Epic Flow:** `backlog → contexted`
-
-**Story Flow:** `backlog → drafted → ready-for-dev → in-progress → review → done`
-
-#### Implementation Workflows
-
-| Workflow          | Agent | Purpose                 | Status Updates                              |
-| ----------------- | ----- | ----------------------- | ------------------------------------------- |
-| sprint-planning   | SM    | Initialize tracking     | Creates sprint-status.yaml                  |
-| epic-tech-context | SM    | Epic technical context  | Epic: backlog → contexted                   |
-| create-story      | SM    | Draft story files       | Story: backlog → drafted                    |
-| story-context     | SM    | Implementation guidance | Story: drafted → ready-for-dev              |
-| dev-story         | DEV   | Implement               | Story: ready-for-dev → in-progress → review |
-| code-review       | DEV   | Quality validation      | No auto update                              |
-| retrospective     | SM    | Capture learnings       | Retrospective: optional → completed         |
-| correct-course    | SM    | Handle issues           | Adaptive                                    |
-
-#### Implementation Loop
-
-```
-sprint-planning (creates sprint-status.yaml)
-    ↓
-For each epic:
-    epic-tech-context
-        ↓
-    For each story:
-        create-story → story-context → dev-story → code-review
-            ↓
-        Mark done in sprint-status.yaml
-    ↓
-    retrospective (epic complete)
-```
-
-## Scale Levels
-
-| Level | Scope         | Documentation         | Path            |
-| ----- | ------------- | --------------------- | --------------- |
-| 0     | Single change | tech-spec only        | Phase 2 → 4     |
-| 1     | 1-10 stories  | tech-spec only        | Phase 2 → 4     |
-| 2     | 5-15 stories  | PRD + architecture    | Phase 2 → 3 → 4 |
-| 3     | 12-40 stories | PRD + full arch       | Phase 2 → 3 → 4 |
-| 4     | 40+ stories   | PRD + enterprise arch | Phase 2 → 3 → 4 |
-
-## Greenfield vs Brownfield
-
-### Greenfield (New Projects)
-
-```
-Phase 1 (optional) → Phase 2 → Phase 3 (L2-4) → Phase 4
-```
-
-- Clean slate for design
-- No existing constraints
-- Direct to planning
-
-### Brownfield (Existing Code)
-
-```
-document-project (if needed) → Phase 1 (optional) → Phase 2 → Phase 3 (L2-4) → Phase 4
-```
-
-- Must understand existing patterns
-- Documentation prerequisite if undocumented
-- Consider technical debt in planning
-
-## Critical Rules
-
-### Phase Transitions
-
-1. **Check workflow-status** before any Phase 1-3 workflow
-2. **Document brownfield** before planning if undocumented
-3. **Complete planning** before solutioning
-4. **Complete architecture** (L2-4) before implementation
-
-### Implementation Rules
-
-1. **Epic context first** - Must context epic before drafting stories
-2. **Sequential by default** - Work stories in order within epic
-3. **Learning transfer** - Draft next story after previous done
-4. **Manual status updates** - Update sprint-status.yaml as needed
-
-### Story Management
-
-1. **Single source of truth** - sprint-status.yaml tracks everything
-2. **No story search** - Agents read exact story from status file
-3. **Context injection** - Each story gets specific technical guidance
-4. **Retrospective learning** - Capture improvements per epic
-
-### Best Practices
-
-1. **Trust the process** - Let workflows guide you
-2. **Respect scale** - Don't over-document small projects
-3. **Use status tracking** - Always know where you are
-4. **Iterate and learn** - Each epic improves the next
-
----
-
-For specific workflow details, see individual workflow READMEs in their respective directories.