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

package/src/modules/bmm/workflows/2-plan-workflows/gdd/README.md

@@ -1,222 +0,0 @@
-# Game Design Document (GDD) Workflow
-
-This folder contains the GDD workflow for game projects, replacing the traditional PRD approach with game-specific documentation.
-
-## Overview
-
-The GDD workflow creates a comprehensive Game Design Document that captures:
-
-- Core gameplay mechanics and pillars
-- Game type-specific elements (RPG systems, platformer movement, puzzle mechanics, etc.)
-- Level design framework
-- Art and audio direction
-- Technical specifications (platform-agnostic)
-- Development epics
-
-## Architecture
-
-### Universal Template
-
-`gdd-template.md` contains sections common to ALL game types:
-
-- Executive Summary
-- Goals and Context
-- Core Gameplay
-- Win/Loss Conditions
-- Progression and Balance
-- Level Design Framework
-- Art and Audio Direction
-- Technical Specs
-- Development Epics
-- Success Metrics
-
-### Game-Type-Specific Injection
-
-The template includes a `{{GAME_TYPE_SPECIFIC_SECTIONS}}` placeholder that gets replaced with game-type-specific content.
-
-### Game Types Registry
-
-`game-types.csv` defines 24+ game types with:
-
-- **id**: Unique identifier (e.g., `action-platformer`, `rpg`, `roguelike`)
-- **name**: Human-readable name
-- **description**: Brief description of the game type
-- **genre_tags**: Searchable tags
-- **fragment_file**: Path to type-specific template fragment
-
-### Game-Type Fragments
-
-Located in `game-types/` folder, these markdown files contain sections specific to each game type:
-
-**action-platformer.md**:
-
-- Movement System (jump mechanics, air control, special moves)
-- Combat System (attack types, combos, enemy AI)
-- Level Design Patterns (platforming challenges, combat arenas)
-- Player Abilities and Unlocks
-
-**rpg.md**:
-
-- Character System (stats, classes, leveling)
-- Inventory and Equipment
-- Quest System
-- World and Exploration
-- NPC and Dialogue
-- Combat System
-
-**puzzle.md**:
-
-- Core Puzzle Mechanics
-- Puzzle Progression
-- Level Structure
-- Player Assistance
-- Replayability
-
-**roguelike.md**:
-
-- Run Structure
-- Procedural Generation
-- Permadeath and Progression
-- Item and Upgrade System
-- Character Selection
-- Difficulty Modifiers
-
-...and 20+ more game types!
-
-## Workflow Flow
-
-1. **Router Detection** (instructions-router.md):
-   - Step 3 asks for project type
-   - If "Game" selected → sets `workflow_type = "gdd"`
-   - Skips standard level classification
-   - Jumps to GDD-specific assessment
-
-2. **Game Type Selection** (instructions-gdd.md Step 1):
-   - Presents 9 common game types + "Other"
-   - Maps selection to `game-types.csv`
-   - Loads corresponding fragment file
-   - Stores `game_type` for injection
-
-3. **Universal GDD Sections** (Steps 2-5, 7-13):
-   - Platform and target audience
-   - Goals and context
-   - Core gameplay (pillars, loop, win/loss)
-   - Mechanics and controls
-   - Progression and balance
-   - Level design
-   - Art and audio
-   - Technical specs
-   - Epics and metrics
-
-4. **Game-Type Injection** (Step 6):
-   - Loads fragment from `game-types/{game_type}.md`
-   - For each `{{placeholder}}` in fragment, elicits details
-   - Injects completed sections into `{{GAME_TYPE_SPECIFIC_SECTIONS}}`
-
-5. **Solutioning Handoff** (Step 14):
-   - Routes to `3-solutioning` workflow
-   - Platform/engine specifics handled by solutioning registry
-   - Game-\* entries in solutioning `registry.csv` provide engine-specific guidance
-
-## Platform vs. Game Type Separation
-
-**GDD (this workflow)**: Game-type specifics
-
-- What makes an RPG an RPG (stats, quests, inventory)
-- What makes a platformer a platformer (jump mechanics, level design)
-- Genre-defining mechanics and systems
-
-**Solutioning (3-solutioning workflow)**: Platform/engine specifics
-
-- Unity vs. Godot vs. Phaser vs. Unreal
-- 2D vs. 3D rendering
-- Physics engines
-- Input systems
-- Platform constraints (mobile, web, console)
-
-This separation allows:
-
-- Single universal GDD regardless of platform
-- Platform decisions made during architecture phase
-- Easy platform pivots without rewriting GDD
-
-## Output
-
-**GDD.md**: Complete game design document with:
-
-- All universal sections filled
-- Game-type-specific sections injected
-- Ready for solutioning handoff
-
-## Example Game Types
-
-| ID                | Name              | Key Sections                                      |
-| ----------------- | ----------------- | ------------------------------------------------- |
-| action-platformer | Action Platformer | Movement, Combat, Level Patterns, Abilities       |
-| rpg               | RPG               | Character System, Inventory, Quests, World, NPCs  |
-| puzzle            | Puzzle            | Puzzle Mechanics, Progression, Level Structure    |
-| roguelike         | Roguelike         | Run Structure, Procgen, Permadeath, Items         |
-| shooter           | Shooter           | Weapon Systems, Enemy AI, Arena Design            |
-| strategy          | Strategy          | Resources, Units, AI, Victory Conditions          |
-| metroidvania      | Metroidvania      | Interconnected World, Ability Gating, Exploration |
-| visual-novel      | Visual Novel      | Branching Story, Dialogue Trees, Choices          |
-| tower-defense     | Tower Defense     | Waves, Tower Types, Placement, Economy            |
-| card-game         | Card Game         | Deck Building, Card Mechanics, Turn System        |
-
-...and 14+ more!
-
-## Adding New Game Types
-
-1. Add row to `game-types.csv`:
-
-   ```csv
-   new-type,New Type Name,"Description",tags,new-type.md
-   ```
-
-2. Create `game-types/new-type.md`:
-
-   ```markdown
-   ## New Type Specific Elements
-
-   ### System Name
-
-   {{system_placeholder}}
-
-   **Details:**
-
-   - Element 1
-   - Element 2
-   ```
-
-3. The workflow automatically uses it!
-
-## Integration with Solutioning
-
-When a game project completes the GDD and moves to solutioning:
-
-1. Solutioning workflow reads `project_type == "game"`
-2. Loads GDD.md instead of PRD.md
-3. Matches game platforms to solutioning `registry.csv` game-\* entries
-4. Provides engine-specific guidance (Unity, Godot, Phaser, etc.)
-5. Generates architecture.md with platform decisions
-6. Creates per-epic tech specs
-
-Example solutioning registry entries:
-
-- `game-unity-2d`: Unity 2D games
-- `game-godot-3d`: Godot 3D games
-- `game-phaser`: Phaser web games
-- `game-unreal-3d`: Unreal Engine games
-- `game-custom-3d-rust`: Custom Rust game engines
-
-## Philosophy
-
-**Game projects are fundamentally different from software products**:
-
-- Gameplay feel > feature lists
-- Playtesting > user testing
-- Game pillars > product goals
-- Mechanics > requirements
-- Fun > utility
-
-The GDD workflow respects these differences while maintaining BMAD Method rigor.

package/src/modules/bmm/workflows/3-solutioning/README.md

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

package/src/modules/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/src/modules/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.

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

@@ -1,69 +0,0 @@
-# Review Story (Senior Developer Code Review)
-
-Perform an AI-driven Senior Developer Code Review on a story flagged "Ready for Review". The workflow ingests the story, its Story Context, and the epic’s Tech Spec, consults local docs, uses enabled MCP servers for up-to-date best practices (with web search fallback), and appends structured review notes to the story.
-
-## What It Does
-
-- Auto-discovers the target story or accepts an explicit `story_path`
-- Verifies the story is in a reviewable state (e.g., Ready for Review/Review)
-- Loads Story Context (from Dev Agent Record → Context Reference or auto-discovery)
-- Locates the epic Tech Spec and relevant architecture/standards docs
-- Uses MCP servers for best-practices and security references; falls back to web search
-- Reviews implementation vs Acceptance Criteria, Tech Spec, and repo standards
-- Evaluates code quality, security, and test coverage
-- Appends a "Senior Developer Review (AI)" section to the story with findings and action items
-- Optionally updates story Status based on outcome
-
-## How to Invoke
-
-- Tell the Dev Agent to perform a \*code-review after loading the dev agent. This is a context intensive operation so this should not be done in the same context as a just completed dev session - clear the context, reload the dev, then run code-review!
-
-## Inputs and Variables
-
-- `story_path` (optional): Explicit path to a story file
-- `story_dir` (from config): `{project-root}/bmad/bmm/config.yaml` → `dev_story_location`
-- `allow_status_values`: Defaults include `Ready for Review`, `Review`
-- `auto_discover_context` (default: true)
-- `auto_discover_tech_spec` (default: true)
-- `tech_spec_glob_template`: `tech-spec-epic-{{epic_num}}*.md`
-- `arch_docs_search_dirs`: Defaults to `docs/` and `outputs/`
-- `enable_mcp_doc_search` (default: true)
-- `enable_web_fallback` (default: true)
-- `update_status_on_result` (default: false)
-
-## Story Updates
-
-- Appends a section titled: `Senior Developer Review (AI)` at the end
-- Adds a Change Log entry: "Senior Developer Review notes appended"
-- If enabled, updates `Status` based on outcome
-
-## Persistence and Backlog
-
-To ensure review findings become actionable work, the workflow can persist action items to multiple targets (configurable):
-
-- Story tasks: Inserts unchecked items under `Tasks / Subtasks` in a "Review Follow-ups (AI)" subsection so `dev-story` can pick them up next.
-- Story review section: Keeps a full list under "Senior Developer Review (AI) → Action Items".
-- Backlog file: Appends normalized rows to `docs/backlog.md` (created if missing) for cross-cutting or longer-term improvements.
-- Epic follow-ups: If an epic Tech Spec is found, appends to its `Post-Review Follow-ups` section.
-
-Configure via `workflow.yaml` variables:
-
-- `persist_action_items` (default: true)
-- `persist_targets`: `story_tasks`, `story_review_section`, `backlog_file`, `epic_followups`
-- `backlog_file` (default: `{project-root}/docs/backlog.md`)
-- `update_epic_followups` (default: true)
-- `epic_followups_section_title` (default: `Post-Review Follow-ups`)
-
-Routing guidance:
-
-- Put must-fix items to ship the story into the story’s tasks.
-- Put same-epic but non-blocking improvements into the epic Tech Spec follow-ups.
-- Put cross-cutting, future, or refactor work into the backlog file.
-
-## Related Workflows
-
-- `dev-story` — Implements tasks/subtasks and can act on review action items
-- `story-context` — Generates Story Context for a single story
-- `tech-spec` — Generates epic Tech Spec documents
-
-_Part of the BMAD Method v6 — Implementation Phase_