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

package/bmad/bmm/workflows/2-plan-workflows/README.md

@@ -1,258 +0,0 @@
----
-last-redoc-date: 2025-10-01
----
-
-# Project Planning Workflow (Phase 2)
-
-The Phase 2 Planning workflow is **scale-adaptive**, meaning it automatically determines the right level of planning documentation based on project complexity (Levels 0-4). This ensures planning overhead matches project value—from minimal tech specs for bug fixes to comprehensive PRDs for enterprise platforms.
-
-## Scale-Adaptive Flow (Levels 0-4)
-
-The workflow routes to different planning approaches based on project level:
-
-### Level 0 - Single File Change / Bug Fix
-
-**Planning:** Tech-spec only (lightweight implementation plan)
-**Output:** `tech-spec.md` with single story
-**Next Phase:** Direct to implementation (Phase 4)
-
-### Level 1 - Small Feature (1-3 files, 2-5 stories)
-
-**Planning:** Tech-spec only (implementation-focused)
-**Output:** `tech-spec.md` with epic breakdown and stories
-**Next Phase:** Direct to implementation (Phase 4)
-
-### Level 2 - Feature Set / Small Project (5-15 stories, 1-2 epics)
-
-**Planning:** PRD (product-focused) + Tech-spec (technical planning)
-**Output:** `PRD.md`, `epics.md`, `tech-spec.md`
-**Next Phase:** Tech-spec workflow (lightweight solutioning), then implementation (Phase 4)
-**Note:** Level 2 uses tech-spec instead of full architecture to keep planning lightweight
-
-### Level 3 - Medium Project (15-40 stories, 2-5 epics)
-
-**Planning:** PRD (strategic product document)
-**Output:** `PRD.md`, `epics.md`
-**Next Phase:** create-architecture workflow (Phase 3), then implementation (Phase 4)
-
-### Level 4 - Large/Enterprise Project (40-100+ stories, 5-10 epics)
-
-**Planning:** PRD (comprehensive product specification)
-**Output:** `PRD.md`, `epics.md`
-**Next Phase:** create-architecture workflow (Phase 3), then implementation (Phase 4)
-
-**Critical Distinction:**
-
-- **Levels 0-1:** No PRD, tech-spec only
-- **Level 2:** PRD + tech-spec (skips full architecture)
-- **Levels 3-4:** PRD → full create-architecture workflow
-
-Critical to v6's flow improvement is this workflow's integration with the bmm-workflow-status.md tracking document, which maintains project state across sessions, tracks which agents participate in each phase, and provides continuity for multi-session planning efforts. The workflow can resume from any point, intelligently detecting existing artifacts and determining next steps without redundant work. For UX-heavy projects, it can generate standalone UX specifications or AI frontend prompts from existing specs.
-
-## Key Features
-
-- **Scale-adaptive planning** - Automatically determines output based on project complexity
-- **Intelligent routing** - Uses router system to load appropriate instruction sets
-- **Continuation support** - Can resume from previous sessions and handle incremental work
-- **Multi-level outputs** - Supports 5 project levels (0-4) with appropriate artifacts
-- **Input integration** - Leverages product briefs and market research when available
-- **Template-driven** - Uses validated templates for consistent output structure
-
-### Configuration
-
-The workflow adapts automatically based on project assessment, but key configuration options include:
-
-- **scale_parameters**: Defines story/epic counts for each project level
-- **output_folder**: Where all generated documents are stored
-- **project_name**: Used in document names and templates
-
-## Workflow Structure
-
-### Files Included
-
-```
-2-plan-workflows/
-├── README.md                      # Overview and usage details
-├── checklist.md                   # Shared validation criteria
-├── prd/
-│   ├── epics-template.md          # Epic breakdown template
-│   ├── instructions.md            # Level 2-4 PRD instructions
-│   ├── prd-template.md            # Product Requirements Document template
-│   └── workflow.yaml
-├── tech-spec/
-│   ├── epics-template.md          # Epic-to-story handoff template
-│   ├── instructions-level0-story.md
-│   ├── instructions-level1-stories.md
-│   ├── instructions.md            # Level 0-1 tech-spec instructions
-│   ├── tech-spec-template.md      # Technical Specification template
-│   ├── user-story-template.md     # Story template for Level 0/1
-│   └── workflow.yaml
-├── gdd/
-│   ├── instructions-gdd.md        # Game Design Document instructions
-│   ├── gdd-template.md            # GDD template
-│   ├── game-types.csv             # Genre catalog
-│   ├── game-types/                # Genre-specific templates
-│   └── workflow.yaml
-├── narrative/
-│   ├── instructions-narrative.md  # Narrative design instructions
-│   ├── narrative-template.md      # Narrative planning template
-│   └── workflow.yaml
-└── create-ux-design/
-    ├── instructions.md            # UX design instructions
-    ├── ux-design-template.md      # UX design template
-    ├── checklist.md               # UX design validation checklist
-    └── workflow.yaml
-```
-
-## Workflow Process
-
-### Phase 1: Assessment and Routing (Steps 1-5)
-
-- **Project Analysis**: Determines project type (greenfield/brownfield/legacy)
-- **Scope Assessment**: Classifies into 5 levels based on complexity
-- **Document Discovery**: Identifies existing inputs and documentation
-- **Workflow Routing**: Loads appropriate instruction set based on level
-- **Continuation Handling**: Resumes from previous work when applicable
-
-### Phase 2: Level-Specific Planning (Steps vary by level)
-
-**Level 0 (Single File Change / Bug Fix)**:
-
-- Tech-spec only workflow
-- Single story implementation plan
-- Direct to Phase 4 (implementation)
-
-**Level 1 (Small Feature)**:
-
-- Tech-spec only workflow
-- Epic breakdown with 2-5 stories
-- Direct to Phase 4 (implementation)
-
-**Level 2 (Feature Set / Small Project)**:
-
-- PRD workflow (strategic product document)
-- Generates `PRD.md` and `epics.md`
-- Then runs tech-spec workflow (lightweight solutioning)
-- Then to Phase 4 (implementation)
-
-**Level 3-4 (Medium to Enterprise Projects)**:
-
-- PRD workflow (comprehensive product specification)
-- Generates `PRD.md` and `epics.md`
-- Hands off to Phase 3 (create-architecture workflow)
-- Full architecture design before implementation
-
-### Phase 3: Validation and Handoff (Final steps)
-
-- **Document Review**: Validates outputs against checklists
-- **Architect Preparation**: For Level 3-4, prepares handoff materials
-- **Next Steps**: Provides guidance for development phase
-
-## Output
-
-### Generated Files
-
-- **Primary output**: PRD.md (except Level 0), tech-spec.md, bmm-workflow-status.md
-- **Supporting files**: epics.md (Level 2-4), PRD-validation-report.md (if validation run)
-
-### Output Structure by Level
-
-**Level 0 - Tech Spec Only**:
-
-- `tech-spec.md` - Single story implementation plan
-- Direct to implementation
-
-**Level 1 - Tech Spec with Epic Breakdown**:
-
-- `tech-spec.md` - Epic breakdown with 2-5 stories
-- Direct to implementation
-
-**Level 2 - PRD + Tech Spec**:
-
-- `PRD.md` - Strategic product document (goals, requirements, user journeys, UX principles, UI goals, epic list, scope)
-- `epics.md` - Tactical implementation roadmap (detailed story breakdown)
-- `tech-spec.md` - Lightweight technical planning (generated after PRD)
-- Then to implementation
-
-**Level 3-4 - PRD + Full Architecture**:
-
-- `PRD.md` - Comprehensive product specification
-- `epics.md` - Complete epic/story breakdown
-- Hands off to create-architecture workflow (Phase 3)
-- `architecture.md` - Generated by architect workflow
-- Then to implementation
-
-## Requirements
-
-- **Input Documents**: Product brief and/or market research (recommended but not required)
-- **Project Configuration**: Valid config.yaml with project_name and output_folder
-- **Assessment Readiness**: Clear understanding of project scope and objectives
-
-## Best Practices
-
-### Before Starting
-
-1. **Gather Context**: Collect any existing product briefs, market research, or requirements
-2. **Define Scope**: Have a clear sense of project boundaries and complexity
-3. **Prepare Stakeholders**: Ensure key stakeholders are available for input if needed
-
-### During Execution
-
-1. **Be Honest About Scope**: Accurate assessment ensures appropriate planning depth
-2. **Leverage Existing Work**: Reference previous documents and avoid duplication
-3. **Think Incrementally**: Remember that planning can evolve - start with what you know
-
-### After Completion
-
-1. **Validate Against Checklist**: Use included validation criteria to ensure completeness
-2. **Share with Stakeholders**: Distribute appropriate documents to relevant team members
-3. **Prepare for Architecture**: For Level 3-4 projects, ensure architect has complete context
-
-## Troubleshooting
-
-### Common Issues
-
-**Issue**: Workflow creates wrong level of documentation
-
-- **Solution**: Review project assessment and restart with correct scope classification
-- **Check**: Verify the bmm-workflow-status.md reflects actual project complexity
-
-**Issue**: Missing input documents cause incomplete planning
-
-- **Solution**: Gather recommended inputs or proceed with manual context gathering
-- **Check**: Ensure critical business context is captured even without formal documents
-
-**Issue**: Continuation from previous session fails
-
-- **Solution**: Check for existing bmm-workflow-status.md and ensure output folder is correct
-- **Check**: Verify previous session completed at a valid checkpoint
-
-## Customization
-
-To customize this workflow:
-
-1. **Modify Assessment Logic**: Update instructions-router.md to adjust level classification
-2. **Adjust Templates**: Customize PRD, tech-spec, or epic templates for organizational needs
-3. **Add Validation**: Extend checklist.md with organization-specific quality criteria
-4. **Configure Outputs**: Modify workflow.yaml to change file naming or structure
-
-## Version History
-
-- **v6.0.0** - Scale-adaptive architecture with intelligent routing
-  - Multi-level project support (0-4)
-  - Continuation and resumption capabilities
-  - Template-driven output generation
-  - Input document integration
-
-## 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`
-- Consult project assessment in `bmm-workflow-status.md`
-- Check continuation status in existing output documents
-
----
-
-_Part of the BMad Method v6 - BMM (Method) Module_

package/bmad/bmm/workflows/3-solutioning/README.md

@@ -1 +0,0 @@
-New Doc Incoming...

package/bmad/bmm/workflows/3-solutioning/solutioning-gate-check/README.md

@@ -1,177 +0,0 @@
-# Implementation Ready Check Workflow
-
-## Overview
-
-The Implementation Ready Check workflow provides a systematic validation of all planning and solutioning artifacts before transitioning from Phase 3 (Solutioning) to Phase 4 (Implementation) in the BMad Method. This workflow ensures that PRDs, architecture documents, and story breakdowns are properly aligned with no critical gaps or contradictions.
-
-## Purpose
-
-This workflow is designed to:
-
-- **Validate Completeness**: Ensure all required planning documents exist and are complete
-- **Verify Alignment**: Check that PRD, architecture, and stories are cohesive and aligned
-- **Identify Gaps**: Detect missing stories, unaddressed requirements, or sequencing issues
-- **Assess Risks**: Find contradictions, conflicts, or potential implementation blockers
-- **Provide Confidence**: Give teams confidence that planning is solid before starting development
-
-## When to Use
-
-This workflow should be invoked:
-
-- At the end of Phase 3 (Solutioning) for Level 2-4 projects
-- Before beginning Phase 4 (Implementation)
-- After significant planning updates or architectural changes
-- When validating readiness for Level 0-1 projects (simplified validation)
-
-## Project Level Adaptations
-
-The workflow adapts its validation based on project level:
-
-### Level 0-1 Projects
-
-- Validates tech spec and simple stories only
-- Checks internal consistency and basic coverage
-- Lighter validation appropriate for simple projects
-
-### Level 2 Projects
-
-- Validates PRD, tech spec (with embedded architecture), and stories
-- Ensures PRD requirements are fully covered
-- Verifies technical approach aligns with business goals
-
-### Level 3-4 Projects
-
-- Full validation of PRD, architecture document, and comprehensive stories
-- Deep cross-reference checking across all artifacts
-- Validates architectural decisions don't introduce scope creep
-- Checks UX artifacts if applicable
-
-## How to Invoke
-
-### Via Scrum Master Agent
-
-```
-*solutioning-gate-check
-```
-
-### Direct Workflow Invocation
-
-```
-workflow solutioning-gate-check
-```
-
-## Expected Inputs
-
-The workflow will automatically search your project's output folder for:
-
-- Product Requirements Documents (PRD)
-- Architecture documents
-- Technical Specifications
-- Epic and Story breakdowns
-- UX artifacts (if applicable)
-
-No manual input file specification needed - the workflow discovers documents automatically.
-
-## Generated Output
-
-The workflow produces a comprehensive **Implementation Readiness Report** containing:
-
-1. **Executive Summary** - Overall readiness status
-2. **Document Inventory** - What was found and reviewed
-3. **Alignment Validation** - Cross-reference analysis results
-4. **Gap Analysis** - Missing items and risks identified
-5. **Findings by Severity** - Critical, High, Medium, Low issues
-6. **Recommendations** - Specific actions to address issues
-7. **Readiness Decision** - Ready, Ready with Conditions, or Not Ready
-
-Output Location: `{output_folder}/implementation-readiness-report-{date}.md`
-
-## Workflow Steps
-
-1. **Initialize** - Get current workflow status and project level
-2. **Document Discovery** - Find all planning artifacts
-3. **Deep Analysis** - Extract requirements, decisions, and stories
-4. **Cross-Reference Validation** - Check alignment between all documents
-5. **Gap and Risk Analysis** - Identify issues and conflicts
-6. **UX Validation** (optional) - Verify UX concerns are addressed
-7. **Generate Report** - Compile comprehensive readiness assessment
-8. **Status Update** (optional) - Offer to advance workflow to next phase
-
-## Validation Criteria
-
-The workflow uses systematic validation rules adapted to each project level:
-
-- **Document completeness and quality**
-- **Requirement to story traceability**
-- **Architecture to implementation alignment**
-- **Story sequencing and dependencies**
-- **Greenfield project setup coverage**
-- **Risk identification and mitigation**
-
-For projects using the new architecture workflow (decision-architecture.md), additional validations include:
-
-- **Implementation patterns defined for consistency**
-- **Technology versions verified and current**
-- **Starter template initialization as first story**
-- **UX specification alignment (if provided)**
-
-## Special Features
-
-### Intelligent Adaptation
-
-- Automatically adjusts validation based on project level
-- Recognizes when UX workflow is active
-- Handles greenfield vs. brownfield projects differently
-
-### Comprehensive Coverage
-
-- Validates not just presence but quality and alignment
-- Checks for both gaps and gold-plating
-- Ensures logical story sequencing
-
-### Actionable Output
-
-- Provides specific, actionable recommendations
-- Categorizes issues by severity
-- Includes positive findings and commendations
-
-## Integration with BMad Method
-
-This workflow integrates seamlessly with the BMad Method workflow system:
-
-- Uses workflow-status to understand project context
-- Can update workflow status to advance to next phase
-- Follows standard BMad document naming conventions
-- Searches standard output folders automatically
-
-## Troubleshooting
-
-### Documents Not Found
-
-- Ensure documents are in the configured output folder
-- Check that document names follow BMad conventions
-- Verify workflow-status is properly configured
-
-### Validation Too Strict
-
-- The workflow adapts to project level automatically
-- Level 0-1 projects get lighter validation
-- Consider if your project level is set correctly
-
-### Report Too Long
-
-- Focus on Critical and High priority issues first
-- Use the executive summary for quick decisions
-- Review detailed findings only for areas of concern
-
-## Support
-
-For issues or questions about this workflow:
-
-- Consult the BMad Method documentation
-- Check the SM agent for workflow guidance
-- Review validation-criteria.yaml for detailed rules
-
----
-
-_This workflow is part of the BMad Method v6-alpha suite of planning and solutioning tools_

package/bmad/bmm/workflows/4-implementation/README.md

@@ -1,221 +0,0 @@
-# Phase 4: Implementation
-
-## Overview
-
-Phase 4 is where planning transitions into actual development. This phase manages the iterative implementation of stories defined in the epic files, tracking their progress through a well-defined status workflow.
-
-## Status Definitions
-
-### Epic Status
-
-Epics progress through a simple two-state flow:
-
-| Status        | Description                                                                                                                                     | Next Status |
-| ------------- | ----------------------------------------------------------------------------------------------------------------------------------------------- | ----------- |
-| **backlog**   | Epic exists in epic file but technical context has not been created                                                                             | contexted   |
-| **contexted** | Epic technical context has been created via `epic-tech-context` workflow. This is a prerequisite before any stories in the epic can be drafted. | -           |
-
-**File Indicators:**
-
-- `backlog`: No `epic-{n}-context.md` file exists
-- `contexted`: `{output_folder}/epic-{n}-context.md` file exists
-
-### Story Status
-
-Stories progress through a six-state flow representing their journey from idea to implementation:
-
-| Status            | Description                                                                        | Set By        | Next Status   |
-| ----------------- | ---------------------------------------------------------------------------------- | ------------- | ------------- |
-| **backlog**       | Story only exists in the epic file, no work has begun                              | Initial state | drafted       |
-| **drafted**       | Story file has been created via `create-story` workflow                            | SM Agent      | ready-for-dev |
-| **ready-for-dev** | Story has been drafted, approved, and context created via `story-context` workflow | SM Agent      | in-progress   |
-| **in-progress**   | Developer is actively implementing the story                                       | Dev Agent     | review        |
-| **review**        | Implementation complete, under SM review via `code-review` workflow                | Dev Agent     | done          |
-| **done**          | Story has been reviewed and completed                                              | Dev Agent     | -             |
-
-**File Indicators:**
-
-- `backlog`: No story file exists
-- `drafted`: `{story_dir}/{story-key}.md` file exists (e.g., `1-1-user-auth.md`)
-- `ready-for-dev`: Both story file and context exist (e.g., `1-1-user-auth-context.md`)
-- `in-progress`, `review`, `done`: Manual status updates in sprint-status.yaml
-
-### Retrospective Status
-
-Optional retrospectives can be completed after an epic:
-
-| Status        | Description                                        |
-| ------------- | -------------------------------------------------- |
-| **optional**  | Retrospective can be completed but is not required |
-| **completed** | Retrospective has been completed                   |
-
-## Status Transitions
-
-### Epic Flow
-
-```mermaid
-graph LR
-    backlog --> contexted[contexted via epic-tech-context]
-```
-
-### Story Flow
-
-```mermaid
-graph LR
-    backlog --> drafted[drafted via create-story]
-    drafted --> ready[ready-for-dev via story-context]
-    ready --> progress[in-progress - dev starts]
-    progress --> review[review via code-review]
-    review --> done[done - dev completes]
-```
-
-## Sprint Status Management
-
-The `sprint-status.yaml` file is the single source of truth for tracking all work items. It contains:
-
-- All epics with their current status
-- All stories with their current status
-- Retrospective placeholders for each epic
-- Clear documentation of status definitions
-
-### Example Sprint Status File
-
-```yaml
-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
-  1-7-plant-naming: backlog
-  epic-1-retrospective: optional
-
-  epic-2: backlog
-  2-1-personality-system: backlog
-  2-2-chat-interface: backlog
-  2-3-llm-integration: backlog
-  epic-2-retrospective: optional
-```
-
-## Workflows in Phase 4
-
-### Core Workflows
-
-| Workflow              | Purpose                                            | Updates Status                      |
-| --------------------- | -------------------------------------------------- | ----------------------------------- |
-| **sprint-planning**   | Generate/update sprint-status.yaml from epic files | Auto-detects file-based statuses    |
-| **epic-tech-context** | Create technical context for an epic               | epic: backlog → contexted           |
-| **create-story**      | Draft a story from epics/PRD                       | story: backlog → drafted            |
-| **story-context**     | Add implementation context to story                | story: drafted → ready-for-dev      |
-| **dev-story**         | Developer implements the story                     | story: ready-for-dev → in-progress  |
-| **code-review**       | SM reviews implementation                          | story: in-progress → review         |
-| **retrospective**     | Conduct epic retrospective                         | retrospective: optional → completed |
-| **correct-course**    | Course correction when needed                      | Various status updates              |
-
-### Sprint Planning Workflow
-
-The `sprint-planning` workflow is the foundation of Phase 4. It:
-
-1. **Parses all epic files** (`epic*.md` or `epics.md`)
-2. **Extracts all epics and stories** maintaining their order
-3. **Auto-detects current status** based on existing files:
-   - Checks for epic context files
-   - Checks for story files
-   - Checks for story context files
-4. **Generates sprint-status.yaml** with current reality
-5. **Preserves manual status updates** (won't downgrade statuses)
-
-Run this workflow:
-
-- Initially after Phase 3 completion
-- After creating epic contexts
-- Periodically to sync file-based status
-- To verify current project state
-
-### Workflow Guidelines
-
-1. **Epic Context First**: Epics should be contexted before drafting their stories
-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
-4. **Learning Transfer**: SM drafts next story after previous is done, incorporating learnings
-5. **Review Flow**: Dev moves to review, SM reviews, Dev moves to done
-
-## Agent Responsibilities
-
-### SM (Scrum Master) Agent
-
-- Run `sprint-planning` to generate initial status
-- Create epic contexts (`epic-tech-context`)
-- Draft stories (`create-story`)
-- Create story contexts (`story-context`)
-- Review completed work (`code-review`)
-- Update status in sprint-status.yaml
-
-### Developer Agent
-
-- Check sprint-status.yaml for `ready-for-dev` stories
-- Update status to `in-progress` when starting
-- Implement stories (`dev-story`)
-- Move to `review` when complete
-- Address review feedback
-- Update to `done` after approval
-
-### Test Architect
-
-- Monitor stories entering `review` status
-- Track epic progress
-- Identify when retrospectives needed
-- Validate implementation quality
-
-## Best Practices
-
-1. **Always run sprint-planning first** to establish current state
-2. **Update status immediately** as work progresses
-3. **Check sprint-status.yaml** before starting any work
-4. **Preserve learning** by drafting stories sequentially when possible
-5. **Document decisions** in story and context files
-
-## Naming Conventions
-
-### Story File Naming
-
-- Format: `{epic}-{story}-{kebab-title}.md`
-- Example: `1-1-user-authentication.md`
-- Avoids YAML float parsing issues (1.1 vs 1.10)
-- Makes files self-descriptive
-
-### Git Branch Naming
-
-- Format: `feat/{epic}-{story}-{kebab-title}`
-- Example: `feat/1-1-user-authentication`
-- Consistent with story file naming
-- Clean for branch management
-
-## File Structure
-
-```
-{output_folder}/
-├── sprint-status.yaml                      # Sprint status tracking
-├── epic*.md or epics.md                    # Epic definitions
-├── epic-1-context.md                       # Epic technical contexts
-├── epic-2-context.md
-└── stories/
-    ├── 1-1-user-authentication.md          # Story drafts
-    ├── 1-1-user-authentication-context.md  # Story contexts
-    ├── 1-2-account-management.md
-    ├── 1-2-account-management-context.md
-    └── ...
-```
-
-## Next Steps
-
-After Phase 4 implementation, projects typically move to:
-
-- Deployment and release
-- User acceptance testing
-- Production monitoring
-- Maintenance and updates
-
-The sprint-status.yaml file provides a complete audit trail of the development process and can be used for project reporting and retrospectives.