planning workflow alignment

This commit is contained in:
Brian Madison
2025-10-15 23:10:33 -05:00
parent b9b219a13b
commit f4b16bfacf
61 changed files with 1117 additions and 992 deletions

View File

@@ -20,7 +20,7 @@ agent:
menu:
- trigger: workflow-status
workflow: "{project-root}/bmad/bmm/workflows/1-analysis/workflow-status/workflow.yaml"
description: Check workflow status and get recommendations
description: Check workflow status and get recommendations (START HERE!)
- trigger: brainstorm-game
workflow: "{project-root}/bmad/bmm/workflows/1-analysis/brainstorm-game/workflow.yaml"
@@ -30,10 +30,14 @@ agent:
workflow: "{project-root}/bmad/bmm/workflows/1-analysis/game-brief/workflow.yaml"
description: Create Game Brief
- trigger: plan-game
workflow: "{project-root}/bmad/bmm/workflows/2-plan/workflow.yaml"
- trigger: gdd
workflow: "{project-root}/bmad/bmm/workflows/2-plan-workflows/gdd/workflow.yaml"
description: Create Game Design Document (GDD)
- trigger: narrative
workflow: "{project-root}/bmad/bmm/workflows/2-plan-workflows/narrative/workflow.yaml"
description: Create Narrative Design Document (story-driven games)
- trigger: research
workflow: "{project-root}/bmad/bmm/workflows/1-analysis/research/workflow.yaml"
description: Conduct Game Market Research

View File

@@ -27,9 +27,13 @@ agent:
workflow: "{project-root}/bmad/bmm/workflows/1-analysis/workflow-status/workflow.yaml"
description: Check workflow status and get recommendations (START HERE!)
- trigger: plan-project
workflow: "{project-root}/bmad/bmm/workflows/2-plan/workflow.yaml"
description: Analyze Project Scope and Create PRD or Smaller Tech Spec
- trigger: prd
workflow: "{project-root}/bmad/bmm/workflows/2-plan-workflows/prd/workflow.yaml"
description: Create Product Requirements Document (PRD) for Level 2-4 projects
- trigger: tech-spec
workflow: "{project-root}/bmad/bmm/workflows/2-plan-workflows/tech-spec/workflow.yaml"
description: Create Tech Spec for Level 0-1 projects
- trigger: correct-course
workflow: "{project-root}/bmad/bmm/workflows/4-implementation/correct-course/workflow.yaml"

View File

@@ -20,8 +20,8 @@ agent:
menu:
- trigger: workflow-status
workflow: "{project-root}/bmad/bmm/workflows/1-analysis/workflow-status/workflow.yaml"
description: Check workflow status and get recommendations
description: Check workflow status and get recommendations (START HERE!)
- trigger: plan-project
workflow: "{project-root}/bmad/bmm/workflows/2-plan/workflow.yaml"
description: UX Workflows, Website Planning, and UI AI Prompt Generation
- trigger: ux-spec
workflow: "{project-root}/bmad/bmm/workflows/2-plan-workflows/ux/workflow.yaml"
description: Create UX/UI Specification and AI Frontend Prompts

View File

@@ -107,9 +107,9 @@ Output is designed to feed directly into:
```
1-analysis/game-brief (You are here)
2-plan/gdd (Game Design Document)
2-plan-workflows/gdd (Game Design Document)
2-plan/narrative (Optional: Story-heavy games)
2-plan-workflows/narrative (Optional: Story-heavy games)
3-solutioning (Technical architecture, engine selection)
@@ -216,6 +216,6 @@ A: Involve your team! Collaborative briefs catch blind spots and build shared vi
## Related Workflows
- **Product Brief** (`1-analysis/product-brief`): For software products, not games
- **GDD** (`2-plan/gdd`): Next step after game brief
- **Narrative Design** (`2-plan/narrative`): For story-heavy games after GDD
- **GDD** (`2-plan-workflows/gdd`): Next step after game brief
- **Narrative Design** (`2-plan-workflows/narrative`): For story-heavy games after GDD
- **Solutioning** (`3-solutioning`): Technical architecture after planning

View File

@@ -424,13 +424,45 @@ Based on your responses, here's your complete workflow journey:
{{/if}}
</check>
<action>Always add Phase 2 (required for all levels)</action>
<action>Always add Phase 2 (required for all levels) - route based on project type and level</action>
- Phase: "2-Plan"
- Step: "plan-project"
- Agent: "PM"
- Description: "Create PRD/GDD/Tech-Spec (determines final level)"
- Status: "Planned"
<check if='project_type == "game"'>
<action>Add game planning workflow</action>
- Phase: "2-Plan"
- Step: "gdd"
- Agent: "PM"
- Description: "Create Game Design Document"
- Status: "Planned"
</check>
<check if='project_type != "game"'>
<check if='level_known == true AND estimated_level <= 1'>
<action>Add tech-spec workflow (Levels 0-1)</action>
- Phase: "2-Plan"
- Step: "tech-spec"
- Agent: "Architect"
- Description: "Create technical specification and stories"
- Status: "Planned"
</check>
<check if='level_known == true AND estimated_level >= 2'>
<action>Add PRD workflow (Levels 2-4)</action>
- Phase: "2-Plan"
- Step: "prd"
- Agent: "PM"
- Description: "Create Product Requirements Document and epics"
- Status: "Planned"
</check>
<check if='level_known == false OR estimated_level == "TBD"'>
<action>Add conditional planning note</action>
- Phase: "2-Plan"
- Step: "TBD - Level 0-1 → tech-spec, Level 2-4 → prd"
- Agent: "PM or Architect"
- Description: "Workflow determined after level assessment"
- Status: "Conditional"
</check>
</check>
<check if='needs_ux_workflow == true'>
<action>Add UX workflow to Phase 2 planning (runs after PRD, before Phase 3)</action>
@@ -549,8 +581,16 @@ After documentation is complete, return to check status: `bmad analyst workflow-
{{/if}}
{{#if planned_workflow[0].step != "document-project" AND planned_workflow[0].step != "user-choice"}}
{{#if planned_workflow[0].step == "gdd"}}
Load PM: `bmad pm gdd`
{{else if planned_workflow[0].step == "tech-spec"}}
Load Architect: `bmad architect tech-spec`
{{else if planned_workflow[0].step == "prd"}}
Load PM: `bmad pm prd`
{{else}}
Load {{planned_workflow[0].agent}}: `bmad {{lowercase planned_workflow[0].agent}} {{planned_workflow[0].step}}`
{{/if}}
{{/if}}
{{#if planned_workflow[0].step == "user-choice"}}
Your status file is ready! Run `workflow-status` anytime to see recommendations.
@@ -596,9 +636,9 @@ Continue? (y/n)</ask>
<check if="confirm == 'y'">
<output>**To start new workflow:**
Load PM agent: `bmad pm plan-project`
Run: `bmad analyst workflow-status`
This will create a new workflow status file and guide you through fresh assessment.
This will guide you through fresh workflow assessment and create a new status file.
</output>
</check>
</check>
@@ -644,7 +684,9 @@ Which phase? (1-4)</ask>
**Phase 2: Planning (Required)**
- `plan-project` - Scale-adaptive planning (PRD, GDD, or Tech-Spec)
- `prd` - Product Requirements Document (Level 2-4 software projects)
- `tech-spec` - Technical specification (Level 0-1 software projects)
- `gdd` - Game Design Document (game projects)
- `ux-spec` - UX/UI specification (for projects with UI components)
**Phase 3: Solutioning (Level 3-4 Only)**
@@ -672,12 +714,14 @@ Which phase? (1-4)</ask>
**🎯 Recommended for Your Current Phase ({{current_phase}}):**
{{#if current_phase == '1-Analysis'}}
Continue analysis or move to `plan-project`
Continue analysis or move to Phase 2 Planning (prd/tech-spec/gdd based on your project)
{{/if}}
{{#if current_phase == '2-Plan'}}
{{#if project_level < 3}}
{{#if project_level < 2}}
Ready for Phase 4! Run `create-story` (SM agent)
{{else if project_level == 2}}
Run `tech-spec` workflow for lightweight technical planning, then Phase 4
{{else}}
Ready for Phase 3! Run `solution-architecture` (Architect agent)
{{/if}}

View File

@@ -4,13 +4,50 @@ last-redoc-date: 2025-10-01
# Project Planning Workflow (Phase 2)
This scale-adaptive workflow represents the cornerstone of BMM v6's intelligent project orchestration, automatically determining project complexity (Level 0-4) and routing to specialized planning pathways based on project type, scope, and context. Unlike traditional one-size-fits-all planning approaches, it dynamically adjusts output artifacts—from minimal tech specs for atomic changes to comprehensive PRD suites for enterprise platforms—ensuring planning overhead matches project value. The workflow serves as the critical bridge between Phase 1 analysis outputs and Phase 3 solutioning, establishing the contractual foundation for all subsequent development activities.
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.
The workflow's routing intelligence analyzes project characteristics through multi-dimensional assessment: project type (game, web, mobile, backend), context (greenfield vs. brownfield), scope indicators, and complexity signals. Based on this analysis, it classifies projects into five levels with distinct artifact requirements. Level 0 produces only tech specs for single atomic changes with a single story.
## Scale-Adaptive Flow (Levels 0-4)
Levels 1-2 generate focused PRDs with embedded tech specs. Levels 3-4 create comprehensive PRDs with separate epics that hand off to the architect-driven solutioning workflow. This classification isn't merely about document generation—it fundamentally changes how requirements are structured, validated, and communicated to downstream consumers.
The workflow routes to different planning approaches based on project level:
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 game projects, it routes to specialized GDD generation with genre-specific templates. For UX-heavy projects, it can generate standalone UX specifications or AI frontend prompts from existing specs.
### 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 solution-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:** Solution-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:** Solution-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 solution-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
@@ -34,21 +71,11 @@ The workflow adapts automatically based on project assessment, but key configura
### Files Included
```
2-plan/
2-plan-workflows/
├── README.md # Overview and usage details
├── checklist.md # Validation criteria
├── instructions-router.md # Initial assessment and routing logic
├── workflow.yaml # Configuration and metadata
├── gdd/
│ ├── gdd-template.md # Game Design Document template
│ ├── instructions-gdd.md # Genre-aware GDD instructions
│ └── workflow.yaml
├── narrative/
│ ├── instructions-narrative.md # Narrative design instructions
│ ├── narrative-template.md # Narrative planning template
│ └── workflow.yaml
├── checklist.md # Shared validation criteria
├── prd/
│ ├── epics.md # Epic breakdown template
│ ├── epics-template.md # Epic breakdown template
│ ├── instructions.md # Level 2-4 PRD instructions
│ ├── prd-template.md # Product Requirements Document template
│ └── workflow.yaml
@@ -60,6 +87,16 @@ The workflow adapts automatically based on project assessment, but key configura
│ ├── 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
└── ux/
├── instructions-ux.md # UX specification instructions
├── ux-spec-template.md # UX specification template
@@ -78,23 +115,31 @@ The workflow adapts automatically based on project assessment, but key configura
### Phase 2: Level-Specific Planning (Steps vary by level)
**Level 0 (Single Atomic Change)**:
**Level 0 (Single File Change / Bug Fix)**:
- Creates technical specification only
- Focuses on implementation details for small changes
- Tech-spec only workflow
- Single story implementation plan
- Direct to Phase 4 (implementation)
**Level 1-2 (Features and Small Systems)**:
**Level 1 (Small Feature)**:
- Generates minimal PRD with core sections
- Creates comprehensive tech-spec
- Includes basic epic breakdown
- Tech-spec only workflow
- Epic breakdown with 2-5 stories
- Direct to Phase 4 (implementation)
**Level 3-4 (Full Products and Platforms)**:
**Level 2 (Feature Set / Small Project)**:
- Produces complete PRD with all sections
- Generates detailed epic breakdown
- Includes architect handoff materials
- Creates traceability mapping
- 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 (solution-architecture workflow)
- Full architecture design before implementation
### Phase 3: Validation and Handoff (Final steps)
@@ -113,27 +158,28 @@ The workflow adapts automatically based on project assessment, but key configura
**Level 0 - Tech Spec Only**:
1. **Technical Overview** - Implementation approach
2. **Detailed Design** - Code-level specifications
3. **Testing Strategy** - Validation approach
- `tech-spec.md` - Single story implementation plan
- Direct to implementation
**Level 1-2 - Minimal PRD + Tech Spec**:
**Level 1 - Tech Spec with Epic Breakdown**:
1. **Problem Statement** - Core issue definition
2. **Solution Overview** - High-level approach
3. **Requirements** - Functional and non-functional
4. **Technical Specification** - Implementation details
5. **Success Criteria** - Acceptance criteria
- `tech-spec.md` - Epic breakdown with 2-5 stories
- Direct to implementation
**Level 3-4 - Full PRD + Epics**:
**Level 2 - PRD + Tech Spec**:
1. **Executive Summary** - Project overview
2. **Problem Definition** - Detailed problem analysis
3. **Solution Architecture** - Comprehensive solution design
4. **User Experience** - Journey mapping and wireframes
5. **Requirements** - Complete functional/non-functional specs
6. **Epic Breakdown** - Development phases and stories
7. **Technical Handoff** - Architecture and implementation guidance
- `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 solution-architecture workflow (Phase 3)
- `solution-architecture.md` - Generated by architect workflow
- Then to implementation
## Requirements

View File

@@ -0,0 +1,148 @@
# GDD Workflow Validation Checklist
**Purpose**: Validate GDD workflow outputs are complete, playable, and ready for solutioning.
**Scope**: All game project levels (0-4)
**Expected Outputs**: GDD.md, epics.md
---
## 1. Output Files Exist
- [ ] GDD.md created in output folder
- [ ] epics.md created in output folder (separate file)
- [ ] bmm-workflow-status.md updated
- [ ] No unfilled {{template_variables}}
---
## 2. Core Gameplay Definition (CRITICAL)
### Game Pillars
- [ ] **2-4 game pillars defined** (fundamental gameplay elements)
- [ ] Each pillar is game-defining (not superficial)
- [ ] Pillars are distinct (don't overlap)
### Core Gameplay Loop
- [ ] **Complete cycle documented** (what player does repeatedly)
- [ ] Loop shows: player action → outcome → reward → motivation to repeat
- [ ] Loop sounds compelling and repeatable
### Win/Loss Conditions
- [ ] Victory conditions clearly defined
- [ ] Failure conditions defined (or N/A for sandbox games)
- [ ] Conditions are testable
---
## 3. Game Mechanics and Systems
### Mechanics
- [ ] Primary mechanics described in detail
- [ ] Mechanics support the game pillars
- [ ] Player interaction with mechanics is clear
### Progression
- [ ] Player progression system defined (skill/power/unlock/narrative)
- [ ] Difficulty curve explained
- [ ] Progression feels rewarding
### Platform and Controls
- [ ] Target platforms specified
- [ ] Control scheme appropriate for platforms
- [ ] Input method clear (keyboard/gamepad/touch/etc.)
---
## 4. Story Quality (If epics.md exists)
### Epic Structure
- [ ] Epics represent deliverable game features
- [ ] Epic sequence makes sense for game development
- [ ] Stories show implementation path
### Story Sequencing (If stories present)
- [ ] **Vertical slices**: Each story delivers playable functionality
- [ ] **Sequential ordering**: Stories build progressively
- [ ] **No forward dependencies**: Each story builds on previous work only
- [ ] Stories result in testable game features
---
## 5. Technical Specifications
### Performance and Platform
- [ ] Performance requirements specified (frame rate, resolution, etc.)
- [ ] Platform-specific considerations noted
- [ ] Asset requirements estimated
### Production Scope
- [ ] Art requirements realistic for project scale
- [ ] Audio requirements documented
- [ ] Scope matches project level and resources
---
## 6. Narrative Integration (If Applicable)
**If narrative-design.md was generated:**
- [ ] Narrative aligns with GDD game design
- [ ] Story supports gameplay (not fighting it)
- [ ] Tone consistent across GDD and narrative docs
---
## 7. Consistency
- [ ] Epic titles match between GDD.md and epics.md
- [ ] Game type identified and appropriate
- [ ] Terminology consistent throughout
- [ ] No contradictions between sections
---
## 8. Readiness for Solutioning
- [ ] Sufficient detail for engine/platform selection
- [ ] Game systems defined enough for technical architecture
- [ ] Clear what needs to be built
- [ ] Playable vision (reader can envision playing the game)
---
## 9. Critical Failures (Auto-Fail)
- [ ]**No core gameplay loop** (can't be a game without this)
- [ ]**No game pillars** (game-defining elements missing)
- [ ]**No mechanics** (what does player actually DO?)
- [ ]**No epics.md file** (implementation roadmap required)
- [ ]**Engine/tech in GDD** (should defer to solutioning workflow)
---
## Validation Notes
**Document any findings:**
- Game concept strength: [Compelling / Interesting / Unclear / Weak]
- Strengths:
- Issues to address:
- Recommended actions:
**Ready for solutioning?** [Yes / No - explain]
---
_Adapt based on game type and narrative complexity. Core gameplay must always be solid._

View File

@@ -10,11 +10,61 @@
<critical>Routes to 3-solutioning for architecture (platform-specific decisions handled there)</critical>
<critical>If users mention technical details, append to technical_preferences with timestamp</critical>
<step n="0" goal="Check for workflow status file - REQUIRED">
<action>Check if bmm-workflow-status.md exists in {output_folder}/</action>
<check if="not exists">
<output>**⚠️ No Workflow Status File Found**
The GDD workflow requires an existing workflow status file to understand your project context.
Please run `workflow-status` first to:
- Map out your complete workflow journey
- Determine project type and level
- Create the status file with your planned workflow
**To proceed:**
Run: `bmad analyst workflow-status`
After completing workflow planning, you'll be directed back to this workflow.
</output>
<action>Exit workflow - cannot proceed without status file</action>
</check>
<check if="exists">
<action>Load status file and proceed to Step 1</action>
</check>
</step>
<step n="1" goal="Load context and determine game type">
<action>Load bmm-workflow-status.md</action>
<action>Confirm project_type == "game"</action>
<check if="project_type != game">
<error>This workflow is for game projects only. Software projects should use PRD or tech-spec workflows.</error>
<output>**Incorrect Workflow for Software Projects**
Your status file indicates project_type: {{project_type}}
**Correct workflows for software projects:**
- Level 0-1: `tech-spec` (run with Architect agent)
- Level 2-4: `prd` (run with PM agent)
{{#if project_level <= 1}}
Run: `bmad architect tech-spec`
{{else}}
Run: `bmad pm prd`
{{/if}}
</output>
<action>Exit and redirect user to appropriate software workflow</action>
</check>
<check if="continuation_mode == true">
<action>Load existing GDD.md and check completion status</action>
<ask>Found existing work. Would you like to:
@@ -413,7 +463,7 @@ Your choice:</ask>
</check>
<check if="user selects option 1 or fuzzy indicates wanting to create the narrative design document">
<invoke-workflow>{project-root}/bmad/bmm/workflows/2-plan/narrative/workflow.yaml</invoke-workflow>
<invoke-workflow>{project-root}/bmad/bmm/workflows/2-plan-workflows/narrative/workflow.yaml</invoke-workflow>
<action>Pass GDD context to narrative workflow</action>
<action>Exit current workflow (narrative will hand off to solutioning when done)</action>
@@ -505,7 +555,7 @@ Which would you like to proceed with?</ask>
</check>
<check if="user selects narrative option">
<invoke-workflow>{project-root}/bmad/bmm/workflows/2-plan/narrative/workflow.yaml</invoke-workflow>
<invoke-workflow>{project-root}/bmad/bmm/workflows/2-plan-workflows/narrative/workflow.yaml</invoke-workflow>
<action>Pass GDD context to narrative workflow</action>
</check>

View File

@@ -10,7 +10,7 @@ user_name: "{config_source}:user_name"
date: system-generated
# Workflow components
installed_path: "{project-root}/bmad/bmm/workflows/2-plan/gdd"
installed_path: "{project-root}/bmad/bmm/workflows/2-plan-workflows/gdd"
instructions: "{installed_path}/instructions-gdd.md"
template: "{installed_path}/gdd-template.md"
game_types_csv: "{installed_path}/game-types.csv"
@@ -54,36 +54,36 @@ web_bundle:
name: "gdd"
description: "Game Design Document workflow for all game project levels - from small prototypes to full AAA games. Generates comprehensive GDD with game mechanics, systems, progression, and implementation guidance."
author: "BMad"
instructions: "bmad/bmm/workflows/2-plan/gdd/instructions-gdd.md"
instructions: "bmad/bmm/workflows/2-plan-workflows/gdd/instructions-gdd.md"
use_advanced_elicitation: true
web_bundle_files:
- "bmad/bmm/workflows/2-plan/gdd/instructions-gdd.md"
- "bmad/bmm/workflows/2-plan/gdd/gdd-template.md"
- "bmad/bmm/workflows/2-plan/gdd/game-types.csv"
- "bmad/bmm/workflows/2-plan/gdd/game-types/action-platformer.md"
- "bmad/bmm/workflows/2-plan/gdd/game-types/adventure.md"
- "bmad/bmm/workflows/2-plan/gdd/game-types/card-game.md"
- "bmad/bmm/workflows/2-plan/gdd/game-types/fighting.md"
- "bmad/bmm/workflows/2-plan/gdd/game-types/horror.md"
- "bmad/bmm/workflows/2-plan/gdd/game-types/idle-incremental.md"
- "bmad/bmm/workflows/2-plan/gdd/game-types/metroidvania.md"
- "bmad/bmm/workflows/2-plan/gdd/game-types/moba.md"
- "bmad/bmm/workflows/2-plan/gdd/game-types/party-game.md"
- "bmad/bmm/workflows/2-plan/gdd/game-types/puzzle.md"
- "bmad/bmm/workflows/2-plan/gdd/game-types/racing.md"
- "bmad/bmm/workflows/2-plan/gdd/game-types/rhythm.md"
- "bmad/bmm/workflows/2-plan/gdd/game-types/roguelike.md"
- "bmad/bmm/workflows/2-plan/gdd/game-types/rpg.md"
- "bmad/bmm/workflows/2-plan/gdd/game-types/sandbox.md"
- "bmad/bmm/workflows/2-plan/gdd/game-types/shooter.md"
- "bmad/bmm/workflows/2-plan/gdd/game-types/simulation.md"
- "bmad/bmm/workflows/2-plan/gdd/game-types/sports.md"
- "bmad/bmm/workflows/2-plan/gdd/game-types/strategy.md"
- "bmad/bmm/workflows/2-plan/gdd/game-types/survival.md"
- "bmad/bmm/workflows/2-plan/gdd/game-types/text-based.md"
- "bmad/bmm/workflows/2-plan/gdd/game-types/tower-defense.md"
- "bmad/bmm/workflows/2-plan/gdd/game-types/turn-based-tactics.md"
- "bmad/bmm/workflows/2-plan/gdd/game-types/visual-novel.md"
- "bmad/bmm/workflows/2-plan-workflows/gdd/instructions-gdd.md"
- "bmad/bmm/workflows/2-plan-workflows/gdd/gdd-template.md"
- "bmad/bmm/workflows/2-plan-workflows/gdd/game-types.csv"
- "bmad/bmm/workflows/2-plan-workflows/gdd/game-types/action-platformer.md"
- "bmad/bmm/workflows/2-plan-workflows/gdd/game-types/adventure.md"
- "bmad/bmm/workflows/2-plan-workflows/gdd/game-types/card-game.md"
- "bmad/bmm/workflows/2-plan-workflows/gdd/game-types/fighting.md"
- "bmad/bmm/workflows/2-plan-workflows/gdd/game-types/horror.md"
- "bmad/bmm/workflows/2-plan-workflows/gdd/game-types/idle-incremental.md"
- "bmad/bmm/workflows/2-plan-workflows/gdd/game-types/metroidvania.md"
- "bmad/bmm/workflows/2-plan-workflows/gdd/game-types/moba.md"
- "bmad/bmm/workflows/2-plan-workflows/gdd/game-types/party-game.md"
- "bmad/bmm/workflows/2-plan-workflows/gdd/game-types/puzzle.md"
- "bmad/bmm/workflows/2-plan-workflows/gdd/game-types/racing.md"
- "bmad/bmm/workflows/2-plan-workflows/gdd/game-types/rhythm.md"
- "bmad/bmm/workflows/2-plan-workflows/gdd/game-types/roguelike.md"
- "bmad/bmm/workflows/2-plan-workflows/gdd/game-types/rpg.md"
- "bmad/bmm/workflows/2-plan-workflows/gdd/game-types/sandbox.md"
- "bmad/bmm/workflows/2-plan-workflows/gdd/game-types/shooter.md"
- "bmad/bmm/workflows/2-plan-workflows/gdd/game-types/simulation.md"
- "bmad/bmm/workflows/2-plan-workflows/gdd/game-types/sports.md"
- "bmad/bmm/workflows/2-plan-workflows/gdd/game-types/strategy.md"
- "bmad/bmm/workflows/2-plan-workflows/gdd/game-types/survival.md"
- "bmad/bmm/workflows/2-plan-workflows/gdd/game-types/text-based.md"
- "bmad/bmm/workflows/2-plan-workflows/gdd/game-types/tower-defense.md"
- "bmad/bmm/workflows/2-plan-workflows/gdd/game-types/turn-based-tactics.md"
- "bmad/bmm/workflows/2-plan-workflows/gdd/game-types/visual-novel.md"
# Game frameworks available
frameworks:
- "MDA Framework (Mechanics, Dynamics, Aesthetics)"

View File

@@ -0,0 +1,139 @@
# Narrative Design Workflow Validation Checklist
**Purpose**: Validate narrative design outputs are complete, cohesive, and ready for implementation.
**Scope**: Story-driven games and applications (follows GDD workflow)
**Expected Output**: narrative-design.md
---
## 1. Output File Exists
- [ ] narrative-design.md created in output folder
- [ ] GDD.md exists (narrative workflow requires GDD first)
- [ ] No unfilled {{template_variables}}
---
## 2. Story Foundation
### Core Elements
- [ ] **Narrative premise** clearly stated (elevator pitch, 2-3 sentences)
- [ ] **Core themes** identified (2-4 meaningful themes)
- [ ] **Tone and atmosphere** established
- [ ] Premise is compelling and fits game type
### Story Structure
- [ ] **Story structure chosen** (3-act, hero's journey, branching, etc.)
- [ ] **Acts/sections broken down** with clear progression
- [ ] **Major story beats** documented (key moments that drive narrative)
- [ ] Structure fits narrative complexity level
---
## 3. Characters
### Protagonist(s)
- [ ] Background and motivation explained
- [ ] Character arc defined (how they change)
- [ ] Internal and external conflicts identified
### Antagonist(s)
- [ ] Motivation clear (why they oppose protagonist)
- [ ] Goals and methods explained
- [ ] Not one-dimensional
### Supporting Cast
- [ ] Major supporting characters documented
- [ ] Each has distinct role in story
- [ ] Character relationships mapped
### Character Arcs
- [ ] Major characters have starting → transformation → ending states
- [ ] Arc progression makes sense
---
## 4. World and Lore
- [ ] **World setting** defined (time, place, world type)
- [ ] **World rules** explained (magic, technology, society)
- [ ] **History and backstory** documented
- [ ] Key locations described with narrative significance
---
## 5. Dialogue and Delivery
### Dialogue Framework
- [ ] Dialogue style established
- [ ] Key conversations identified
- [ ] Branching dialogue system described (if applicable)
### Narrative Delivery
- [ ] Cutscenes/cinematics approach defined
- [ ] In-game storytelling methods explained
- [ ] Optional vs. required content distinguished
- [ ] Multiple endings documented (if applicable)
---
## 6. Gameplay Integration
- [ ] **Narrative-gameplay harmony** addressed (how story and mechanics connect)
- [ ] **Story gates** explained (how narrative controls progression)
- [ ] **Player agency** level defined (can player affect story?)
- [ ] Integration doesn't fight game design
---
## 7. Production Scope
- [ ] **Writing scope** estimated (word count, scene count, dialogue lines)
- [ ] Scope realistic for project level
- [ ] Localization considerations noted (if applicable)
- [ ] Voice acting plans documented (if applicable)
---
## 8. Consistency with GDD
- [ ] Narrative aligns with GDD game design
- [ ] Tone matches GDD art/audio direction
- [ ] Story supports game mechanics (doesn't contradict)
- [ ] No conflicts between narrative and gameplay
---
## 9. Critical Failures (Auto-Fail)
- [ ]**No GDD** (narrative workflow requires GDD first)
- [ ]**No character arcs** (protagonist has no development)
- [ ]**No story beats** (major moments not identified)
- [ ]**Contradicts GDD** (narrative fights game design)
---
## Validation Notes
**Document any findings:**
- Narrative strength: [Compelling / Interesting / Adequate / Weak]
- Strengths:
- Issues to address:
- Recommended actions:
**Ready for solutioning?** [Yes / No - explain]
---
_Adapt based on narrative complexity level (Critical/Heavy/Moderate/Light)._

View File

@@ -27,7 +27,7 @@ Your game type ({{game_type}}) suggests **{{suggested_complexity}}**. Confirm or
<action>Set narrative_complexity</action>
<check if="complexity == "Light"">
<check if="complexity == Light">
<ask>Light narrative games usually don't need a full Narrative Design Document. Are you sure you want to continue?
- GDD story sections may be sufficient

View File

@@ -10,7 +10,7 @@ user_name: "{config_source}:user_name"
date: system-generated
# Workflow components
installed_path: "{project-root}/bmad/bmm/workflows/2-plan/narrative"
installed_path: "{project-root}/bmad/bmm/workflows/2-plan-workflows/narrative"
instructions: "{installed_path}/instructions-narrative.md"
template: "{installed_path}/narrative-template.md"
@@ -42,11 +42,11 @@ web_bundle:
name: "narrative"
description: "Narrative design workflow for story-driven games and applications. Creates comprehensive narrative documentation including story structure, character arcs, dialogue systems, and narrative implementation guidance."
author: "BMad"
instructions: "bmad/bmm/workflows/2-plan/narrative/instructions-narrative.md"
instructions: "bmad/bmm/workflows/2-plan-workflows/narrative/instructions-narrative.md"
use_advanced_elicitation: true
web_bundle_files:
- "bmad/bmm/workflows/2-plan/narrative/instructions-narrative.md"
- "bmad/bmm/workflows/2-plan/narrative/narrative-template.md"
- "bmad/bmm/workflows/2-plan-workflows/narrative/instructions-narrative.md"
- "bmad/bmm/workflows/2-plan-workflows/narrative/narrative-template.md"
recommended_inputs: "PRD, Product Brief, Brain Storming Report, GDD"
# Narrative frameworks available
frameworks:

View File

@@ -0,0 +1,117 @@
# PRD Workflow Validation Checklist
**Purpose**: Validate PRD workflow outputs are complete, consistent, and ready for next phase.
**Scope**: Levels 2-4 software projects
**Expected Outputs**: PRD.md, epics.md, updated bmm-workflow-status.md
---
## 1. Output Files Exist
- [ ] PRD.md created in output folder
- [ ] epics.md created in output folder (separate file)
- [ ] bmm-workflow-status.md updated
- [ ] No unfilled {{template_variables}}
---
## 2. PRD.md Core Quality
### Requirements Coverage
- [ ] Functional requirements describe WHAT capabilities (not HOW to implement)
- [ ] Each FR has unique identifier (FR001, FR002, etc.)
- [ ] Non-functional requirements (if any) have business justification
- [ ] Requirements are testable and verifiable
### User Journeys
- [ ] User journeys reference specific FR numbers
- [ ] Journeys show complete user paths through system
- [ ] Success outcomes are clear
### Strategic Focus
- [ ] PRD focuses on WHAT and WHY (not technical HOW)
- [ ] No specific technology choices in PRD (those belong in technical-decisions.md)
- [ ] Goals are outcome-focused, not implementation-focused
---
## 3. epics.md Story Quality
### Story Format
- [ ] All stories follow user story format: "As a [role], I want [capability], so that [benefit]"
- [ ] Each story has numbered acceptance criteria
- [ ] Prerequisites/dependencies explicitly stated
### Story Sequencing (CRITICAL)
- [ ] **Epic 1 establishes foundation** (infrastructure, initial deployable functionality)
- Exception noted if adding to existing app
- [ ] **Vertical slices**: Each story delivers complete, testable functionality (not horizontal layers)
- [ ] **No forward dependencies**: No story depends on work from a LATER story or epic
- [ ] Stories are sequentially ordered within each epic
- [ ] Each story leaves system in working state
### Coverage
- [ ] All FRs from PRD.md are covered by stories in epics.md
- [ ] Epic list in PRD.md matches epics in epics.md (titles and count)
---
## 4. Cross-Document Consistency
- [ ] Epic titles consistent between PRD.md and epics.md
- [ ] FR references in user journeys exist in requirements section
- [ ] Terminology consistent across documents
- [ ] No contradictions between PRD and epics
---
## 5. Readiness for Next Phase
**Adapt based on project level from bmm-workflow-status.md:**
### If Level 2:
- [ ] PRD provides sufficient context for tech-spec workflow (lightweight solutioning)
- [ ] Epic structure supports 5-15 story implementation scope
### If Level 3-4:
- [ ] PRD provides sufficient context for solution-architecture workflow
- [ ] Epic structure supports phased delivery approach
- [ ] Clear value delivery path through epic sequence
---
## 6. Critical Failures (Auto-Fail)
- [ ]**No epics.md file** (two-file output is required)
- [ ]**Epic 1 doesn't establish foundation** (violates core principle)
- [ ]**Stories have forward dependencies** (would break sequential implementation)
- [ ]**Stories not vertically sliced** (horizontal layers block value delivery)
- [ ]**Technical decisions in PRD** (should be in technical-decisions.md)
- [ ]**Epics don't cover all FRs** (orphaned requirements)
- [ ]**User journeys don't reference FR numbers** (missing traceability)
---
## Validation Notes
**Document any findings:**
- Strengths:
- Issues to address:
- Recommended actions:
**Ready for next phase?** [Yes / No - explain]
---
_Adapt this checklist based on actual outputs. Not all sections may apply to every project._

View File

@@ -8,14 +8,64 @@
<workflow>
<step n="0" goal="Check for workflow status file - REQUIRED">
<action>Check if bmm-workflow-status.md exists in {output_folder}/</action>
<check if="not exists">
<output>**⚠️ No Workflow Status File Found**
The PRD workflow requires an existing workflow status file to understand your project context.
Please run `workflow-status` first to:
- Map out your complete workflow journey
- Determine project type and level
- Create the status file with your planned workflow
**To proceed:**
Run: `bmad analyst workflow-status`
After completing workflow planning, you'll be directed back to this workflow.
</output>
<action>Exit workflow - cannot proceed without status file</action>
</check>
<check if="exists">
<action>Load status file: {status_file}</action>
<action>Proceed to Step 1</action>
</check>
</step>
<step n="1" goal="Initialize and load context">
<action>Load status file: {status_file}</action>
<action>Extract project context from status file</action>
<action>Verify project_level is 2, 3, or 4</action>
<check if="project_level < 2">
<error>This workflow is for Level 2-4 only. Level 0-1 should use tech-spec workflow.</error>
<action>Exit and redirect user to tech-spec workflow</action>
<output>**Incorrect Workflow for Your Level**
Your status file indicates Level {{project_level}}.
**Correct workflow:** `tech-spec` (run with Architect agent)
Run: `bmad architect tech-spec`
</output>
<action>Exit and redirect user to tech-spec workflow</action>
</check>
<check if="project_type == game">
<error>This workflow is for software projects. Game projects should use GDD workflow.</error>
<output>**Incorrect Workflow for Game Projects**
**Correct workflow:** `gdd` (run with PM agent)
Run: `bmad pm gdd`
</output>
<action>Exit and redirect user to gdd workflow</action>
</check>
<action>Check for existing PRD.md in {output_folder}</action>
@@ -356,14 +406,22 @@ For each epic from the epic list, expand with full story details:
**Next Steps:**
- Review both documents with stakeholders
- Run solution-architecture workflow for technical design (Level 3-4)
- Or proceed to implementation using create-story workflow (Level 2)
<check if="level == 2">
- Review PRD and epics with stakeholders
- **Next:** Run tech-spec workflow for lightweight technical planning
- Then proceed to implementation (create-story workflow)
</check>
<check if="level >= 3">
- Review PRD and epics with stakeholders
- **Next:** Run solution-architecture workflow for full technical design
- Then proceed to implementation (create-story workflow)
</check>
<ask>Would you like to:
1. Review/refine any section
2. Proceed to solution-architecture workflow
2. Proceed to next phase (tech-spec for Level 2, solution-architecture for Level 3-4)
3. Exit and review documents
</ask>

View File

@@ -11,7 +11,7 @@ user_name: "{config_source}:user_name"
date: system-generated
# Workflow components
installed_path: "{project-root}/bmad/bmm/workflows/2-plan/prd"
installed_path: "{project-root}/bmad/bmm/workflows/2-plan-workflows/prd"
instructions: "{installed_path}/instructions.md"
# Templates
@@ -35,10 +35,10 @@ web_bundle:
name: "prd"
description: "Unified PRD workflow for project levels 2-4. Produces strategic PRD and tactical epic breakdown. Hands off to solution-architecture workflow for technical design. Note: Level 0-1 use tech-spec workflow."
author: "BMad"
instructions: "bmad/bmm/workflows/2-plan/prd/instructions.md"
instructions: "bmad/bmm/workflows/2-plan-workflows/prd/instructions.md"
use_advanced_elicitation: true
web_bundle_files:
- "bmad/bmm/workflows/2-plan/prd/instructions.md"
- "bmad/bmm/workflows/2-plan/prd/prd-template.md"
- "bmad/bmm/workflows/2-plan/prd/epics-template.md"
- "bmad/bmm/workflows/2-plan-workflows/prd/instructions.md"
- "bmad/bmm/workflows/2-plan-workflows/prd/prd-template.md"
- "bmad/bmm/workflows/2-plan-workflows/prd/epics-template.md"
- "bmad/bmm/workflows/_shared/bmm-workflow-status-template.md"

View File

@@ -0,0 +1,107 @@
# Tech-Spec Workflow Validation Checklist
**Purpose**: Validate tech-spec workflow outputs are definitive, complete, and implementation-ready.
**Scope**: Levels 0-1 software projects
**Expected Outputs**: tech-spec.md + story files (1 for Level 0, 2-3 for Level 1)
---
## 1. Output Files Exist
- [ ] tech-spec.md created in output folder
- [ ] Story file(s) created in dev_story_location
- Level 0: 1 story file (story-{slug}.md)
- Level 1: epics.md + 2-3 story files (story-{epic-slug}-N.md)
- [ ] bmm-workflow-status.md updated to Phase 4
- [ ] No unfilled {{template_variables}}
---
## 2. Tech-Spec Definitiveness (CRITICAL)
### No Ambiguity Allowed
- [ ] **Zero "or" statements**: NO "use X or Y", "either A or B", "options include"
- [ ] **Specific versions**: All frameworks, libraries, tools have EXACT versions
- ✅ GOOD: "Python 3.11", "React 18.2.0", "winston v3.8.2"
- ❌ BAD: "Python 2 or 3", "React 18+", "a logger like pino or winston"
- [ ] **Definitive decisions**: Every technical choice is final, not a proposal
### Implementation Clarity
- [ ] Source tree shows EXACT file paths (not "somewhere in src/")
- [ ] Each file marked as create/modify/delete
- [ ] Technical approach describes SPECIFIC implementation
- [ ] Implementation stack has complete toolchain with versions
---
## 3. Story Quality
### Story Format
- [ ] All stories use "As a [role], I want [capability], so that [benefit]" format
- [ ] Each story has numbered acceptance criteria
- [ ] Tasks reference AC numbers: (AC: #1), (AC: #2)
- [ ] Dev Notes section links back to tech-spec.md
### Story Sequencing (If Level 1)
- [ ] **Vertical slices**: Each story delivers complete, testable functionality
- [ ] **Sequential ordering**: Stories in logical progression
- [ ] **No forward dependencies**: No story depends on later work
- [ ] Each story leaves system in working state
### Coverage
- [ ] Story acceptance criteria derived from tech-spec testing section
- [ ] Story tasks map to tech-spec implementation guide
- [ ] Files in stories match tech-spec source tree
---
## 4. Workflow Status Integration
- [ ] bmm-workflow-status.md shows current_phase = "4-Implementation"
- [ ] Phase 2 ("2-Plan") marked complete
- [ ] First story in TODO section, others in BACKLOG (if Level 1)
- [ ] Next action clear (review story, run story-ready)
---
## 5. Readiness for Implementation
- [ ] Developer can start coding from tech-spec alone
- [ ] All technical questions answered definitively
- [ ] Testing approach clear and verifiable
- [ ] Deployment strategy documented
---
## 6. Critical Failures (Auto-Fail)
- [ ]**Non-definitive technical decisions** (any "option A or B" or vague choices)
- [ ]**Missing versions** (framework/library without specific version)
- [ ]**Stories don't match template** (incompatible with story-context/dev-story workflows)
- [ ]**Missing tech-spec sections** (required section missing from tech-spec.md)
- [ ]**Stories have forward dependencies** (would break sequential implementation)
- [ ]**Vague source tree** (file changes not specific)
---
## Validation Notes
**Document any findings:**
- Definitiveness score: [All definitive / Some ambiguity / Significant ambiguity]
- Strengths:
- Issues to address:
- Recommended actions:
**Ready for implementation?** [Yes / No - explain]
---
_Adapt based on Level 0 vs Level 1. Focus on definitiveness above all else._

View File

@@ -9,9 +9,64 @@
<critical>Project analysis already completed - proceeding directly to technical specification</critical>
<critical>NO PRD generated - uses tech_spec_template + story templates</critical>
<step n="0" goal="Check for workflow status file - REQUIRED">
<action>Check if bmm-workflow-status.md exists in {output_folder}/</action>
<check if="not exists">
<output>**⚠️ No Workflow Status File Found**
The tech-spec workflow requires an existing workflow status file to understand your project context.
Please run `workflow-status` first to:
- Map out your complete workflow journey
- Determine project type and level
- Create the status file with your planned workflow
**To proceed:**
Run: `bmad analyst workflow-status`
After completing workflow planning, you'll be directed back to this workflow.
</output>
<action>Exit workflow - cannot proceed without status file</action>
</check>
<check if="exists">
<action>Load status file and proceed to Step 1</action>
</check>
</step>
<step n="1" goal="Confirm project scope and update tracking">
<action>Load bmm-workflow-status.md from {output_folder}/bmm-workflow-status.md</action>
<action>Verify project_level is 0 or 1</action>
<check if="project_level >= 2">
<error>This workflow is for Level 0-1 only. Level 2-4 should use PRD workflow.</error>
<output>**Incorrect Workflow for Your Level**
Your status file indicates Level {{project_level}}.
**Correct workflow:** `prd` (run with PM agent)
Run: `bmad pm prd`
</output>
<action>Exit and redirect user to prd workflow</action>
</check>
<check if="project_type == game">
<error>This workflow is for software projects. Game projects should use GDD workflow.</error>
<output>**Incorrect Workflow for Game Projects**
**Correct workflow:** `gdd` (run with PM agent)
Run: `bmad pm gdd`
</output>
<action>Exit and redirect user to gdd workflow</action>
</check>
<action>Update Workflow Status Tracker:</action>
<check if="project_level == 0">

View File

@@ -11,7 +11,7 @@ user_name: "{config_source}:user_name"
date: system-generated
# Workflow components
installed_path: "{project-root}/bmad/bmm/workflows/2-plan/tech-spec"
installed_path: "{project-root}/bmad/bmm/workflows/2-plan-workflows/tech-spec"
instructions: "{installed_path}/instructions.md"
template: "{installed_path}/tech-spec-template.md"
@@ -57,15 +57,15 @@ web_bundle:
name: "tech-spec-sm"
description: "Technical specification workflow for Level 0-1 projects. Creates focused tech spec with story generation. Level 0: tech-spec + user story. Level 1: tech-spec + epic/stories."
author: "BMad"
instructions: "bmad/bmm/workflows/2-plan/tech-spec/instructions.md"
instructions: "bmad/bmm/workflows/2-plan-workflows/tech-spec/instructions.md"
use_advanced_elicitation: true
web_bundle_files:
- "bmad/bmm/workflows/2-plan/tech-spec/instructions.md"
- "bmad/bmm/workflows/2-plan/tech-spec/instructions-level0-story.md"
- "bmad/bmm/workflows/2-plan/tech-spec/instructions-level1-stories.md"
- "bmad/bmm/workflows/2-plan/tech-spec/tech-spec-template.md"
- "bmad/bmm/workflows/2-plan/tech-spec/user-story-template.md"
- "bmad/bmm/workflows/2-plan/tech-spec/epics-template.md"
- "bmad/bmm/workflows/2-plan-workflows/tech-spec/instructions.md"
- "bmad/bmm/workflows/2-plan-workflows/tech-spec/instructions-level0-story.md"
- "bmad/bmm/workflows/2-plan-workflows/tech-spec/instructions-level1-stories.md"
- "bmad/bmm/workflows/2-plan-workflows/tech-spec/tech-spec-template.md"
- "bmad/bmm/workflows/2-plan-workflows/tech-spec/user-story-template.md"
- "bmad/bmm/workflows/2-plan-workflows/tech-spec/epics-template.md"
# Technical frameworks available
frameworks:
- "Technical Design Patterns"

View File

@@ -0,0 +1,152 @@
# UX/UI Specification Workflow Validation Checklist
**Purpose**: Validate UX workflow outputs are complete, actionable, and ready for development.
**Scope**: Can run standalone or integrated with PRD/GDD workflows
**Expected Outputs**: ux-specification.md, optional ai-frontend-prompt.md
---
## 1. Output File Exists
- [ ] ux-specification.md created in output folder
- [ ] Requirements source identified (PRD, GDD, or gathered requirements)
- [ ] No unfilled {{template_variables}}
---
## 2. UX Foundation
### User Personas
- [ ] **At least one primary persona** defined with goals and pain points
- [ ] Personas have sufficient detail to inform design decisions
- [ ] If PRD/GDD exists, personas align with target audience
### Design Principles
- [ ] **3-5 core design principles** established
- [ ] Principles are actionable (guide real design decisions)
- [ ] Principles fit project goals and users
---
## 3. Information Architecture
### Site/App Structure
- [ ] **Complete site map** showing all major sections/screens
- [ ] Hierarchical relationships clear
- [ ] Navigation paths evident
- [ ] Structure makes sense for users
### Navigation
- [ ] Primary navigation defined
- [ ] Mobile navigation strategy clear (if multi-platform)
- [ ] Navigation approach logical
---
## 4. User Flows
- [ ] **At least 2-3 critical user flows** documented
- [ ] Flows show complete start-to-finish paths
- [ ] Decision points and error states considered
- [ ] Flows include Mermaid diagrams or clear descriptions
- [ ] If PRD exists, flows align with user journeys
---
## 5. Component Library and Visual Design
### Component Approach
- [ ] **Design system strategy** defined (existing system, custom, or hybrid)
- [ ] If using existing, which one specified
- [ ] Core components identified
- [ ] Component states documented (default, hover, active, disabled, error)
### Visual Foundation
- [ ] **Color palette** defined with semantic meanings
- [ ] **Typography** specified (fonts, type scale, usage)
- [ ] **Spacing system** documented
- [ ] Design choices support usability
---
## 6. Responsive and Accessibility
### Responsive Design
- [ ] **Breakpoints defined** for target devices
- [ ] Adaptation patterns explained (how layouts change)
- [ ] Mobile strategy clear (if multi-platform)
### Accessibility
- [ ] **Compliance target** specified (WCAG level)
- [ ] Key accessibility requirements documented
- [ ] Keyboard navigation, screen readers, contrast considered
---
## 7. Implementation Readiness
- [ ] **Next steps** clearly defined
- [ ] Design handoff requirements clear
- [ ] Developers can implement from this spec
- [ ] Sufficient detail for front-end development
---
## 8. Integration with Requirements
**If PRD/GDD exists:**
- [ ] UX covers all user-facing features from requirements
- [ ] User flows align with documented user journeys
- [ ] Platform matches PRD/GDD platforms
- [ ] No contradictions with requirements
---
## 9. AI Frontend Prompt (If Generated)
**If ai-frontend-prompt.md was created:**
- [ ] File exists in output folder
- [ ] Contains complete UX context (colors, typography, components, flows)
- [ ] Formatted for AI tools (v0, Lovable, etc.)
- [ ] Includes appropriate warnings about reviewing generated code
---
## 10. Critical Failures (Auto-Fail)
- [ ]**No user personas** (target users not defined)
- [ ]**No user flows** (critical paths not documented)
- [ ]**No information architecture** (site structure missing)
- [ ]**No component approach** (design system not defined)
- [ ]**No visual foundation** (colors/typography missing)
- [ ]**No responsive strategy** (adaptation not addressed for multi-platform)
- [ ]**Contradicts requirements** (UX fights PRD/GDD if they exist)
---
## Validation Notes
**Document any findings:**
- UX quality: [Production-ready / Good foundation / Needs refinement / Incomplete]
- Strengths:
- Issues to address:
- Recommended actions:
**Ready for development?** [Yes / Needs design phase / No - explain]
---
_Adapt based on whether this is standalone or integrated, and platform requirements._

View File

@@ -10,7 +10,7 @@ user_name: "{config_source}:user_name"
date: system-generated
# Workflow components
installed_path: "{project-root}/bmad/bmm/workflows/2-plan/ux"
installed_path: "{project-root}/bmad/bmm/workflows/2-plan-workflows/ux"
instructions: "{installed_path}/instructions-ux.md"
template: "{installed_path}/ux-spec-template.md"
@@ -50,11 +50,11 @@ web_bundle:
name: "ux-spec"
description: "UX/UI specification workflow for defining user experience and interface design. Creates comprehensive UX documentation including wireframes, user flows, component specifications, and design system guidelines."
author: "BMad"
instructions: "bmad/bmm/workflows/2-plan/ux/instructions-ux.md"
instructions: "bmad/bmm/workflows/2-plan-workflows/ux/instructions-ux.md"
use_advanced_elicitation: true
web_bundle_files:
- "bmad/bmm/workflows/2-plan/ux/instructions-ux.md"
- "bmad/bmm/workflows/2-plan/ux/ux-spec-template.md"
- "bmad/bmm/workflows/2-plan-workflows/ux/instructions-ux.md"
- "bmad/bmm/workflows/2-plan-workflows/ux/ux-spec-template.md"
recommended_inputs: "PRD, Product Brief, Brain Storming Report, GDD"
# UX frameworks available
frameworks:

View File

@@ -1,369 +0,0 @@
# Project Planning Validation Checklist (Adaptive: All Levels)
**Scope**: This checklist adapts based on project level (0-4) and field type (greenfield/brownfield)
- **Level 0**: Tech-spec only validation + Story
- **Level 1**: Tech-spec + Epics validation
- **Level 2-4**: PRD + Epics validation (no tech-spec)
- **Greenfield**: Focus on setup sequencing and dependencies
- **Brownfield**: Focus on integration risks and backward compatibility
## User Intent Validation (Critical First Check)
### Input Sources and User Need
- [ ] Product brief or initial context was properly gathered (not just project name)
- [ ] User's actual problem/need was identified through conversation (not assumed)
- [ ] Technical preferences mentioned by user were captured separately
- [ ] User confirmed the description accurately reflects their vision
- [ ] The PRD addresses what the user asked for, not what we think they need
### Alignment with User Goals
- [ ] Goals directly address the user's stated problem
- [ ] Context reflects actual user-provided information (not invented)
- [ ] Requirements map to explicit user needs discussed
- [ ] Nothing critical the user mentioned is missing
## Document Structure
- [ ] All required sections are present
- [ ] No placeholder text remains (all {{variables}} replaced)
- [ ] Proper formatting and organization throughout
## Section 1: Description
- [ ] Clear, concise description of what's being built
- [ ] Matches user's actual request (not extrapolated)
- [ ] Sets proper scope and expectations
## Section 2: Goals (Step 2)
- [ ] Level 3: Contains 3-5 primary goals
- [ ] Level 4: Contains 5-7 strategic goals
- [ ] Each goal is specific and measurable where possible
- [ ] Goals focus on user and project outcomes
- [ ] Goals represent what success looks like
- [ ] Strategic objectives align with product scale
## Section 3: Context (Step 3)
- [ ] 1-2 short paragraphs explaining why this matters now
- [ ] Context was gathered from user (not invented)
- [ ] Explains actual problem being solved
- [ ] Describes current situation or pain point
- [ ] Connects to real-world impact
## Section 4: Functional Requirements (Step 4)
- [ ] Level 3: Contains 12-20 FRs
- [ ] Level 4: Contains 20-30 FRs
- [ ] Each has unique FR identifier (FR001, FR002, etc.)
- [ ] Requirements describe capabilities, not implementation
- [ ] Related features grouped logically while maintaining granularity
- [ ] All FRs are testable user actions
- [ ] User provided feedback on proposed FRs
- [ ] Missing capabilities user expected were added
- [ ] Priority order reflects user input
- [ ] Coverage comprehensive for target product scale
## Section 5: Non-Functional Requirements (Step 5 - Optional)
- [ ] Only included if truly needed (not arbitrary targets)
- [ ] Each has unique NFR identifier
- [ ] Business justification provided for each NFR
- [ ] Compliance requirements noted if regulated industry
- [ ] Performance constraints tied to business needs
- [ ] Typically 0-5 for MVP (not invented)
## Section 6: User Journeys (Step 6)
- [ ] Level 3: 2-3 detailed user journeys documented
- [ ] Level 4: 3-5 comprehensive journeys for major segments
- [ ] Each journey has named persona with context
- [ ] Journey shows complete path through system via FRs
- [ ] Specific FR references included (e.g., "signs up (FR001)")
- [ ] Success criteria and pain points identified
- [ ] Edge cases and alternative paths considered
- [ ] Journeys validate comprehensive value delivery
## Section 7: UX Principles (Step 7 - Optional)
- [ ] Target users and sophistication level defined
- [ ] Design values stated (simple vs powerful, playful vs professional)
- [ ] Platform strategy specified (mobile-first, web, native)
- [ ] Accessibility requirements noted if applicable
- [ ] Sets direction without prescribing specific solutions
## Section 8: Epics (Step 8)
- [ ] Level 3: 3-5 epics defined (targeting 12-40 stories)
- [ ] Level 4: 5-8 epics defined (targeting 40+ stories)
- [ ] Each epic represents significant, deployable functionality
- [ ] Epic format includes: Title, Goal, Capabilities, Success Criteria, Dependencies
- [ ] Related FRs grouped into coherent capabilities
- [ ] Each epic references specific FR numbers
- [ ] Post-MVP epics listed separately with their FRs
- [ ] Dependencies between epics clearly noted
- [ ] Phased delivery strategy apparent
## Section 9: Out of Scope (Step 9)
- [ ] Ideas preserved with FR/NFR references
- [ ] Format: description followed by (FR###, NFR###)
- [ ] Prevents scope creep while capturing future possibilities
- [ ] Clear distinction from MVP scope
## Section 10: Assumptions and Dependencies (Step 10)
- [ ] Only ACTUAL assumptions from user discussion (not invented)
- [ ] Technical choices user explicitly mentioned captured
- [ ] Dependencies identified in FRs/NFRs listed
- [ ] User-stated constraints documented
- [ ] If none exist, states "No critical assumptions identified yet"
## Cross-References and Consistency
- [ ] All FRs trace back to at least one goal
- [ ] User journeys reference actual FR numbers
- [ ] Epic capabilities cover all FRs
- [ ] Terminology consistent throughout
- [ ] No contradictions between sections
- [ ] Technical details saved to technical_preferences (not in PRD)
## Quality Checks
- [ ] Requirements are strategic, not implementation-focused
- [ ] Document maintains appropriate abstraction level
- [ ] No premature technical decisions
- [ ] Focus on WHAT, not HOW
## Readiness for Next Phase
- [ ] Sufficient detail for comprehensive architecture design
- [ ] Clear enough for detailed solution design
- [ ] Ready for epic breakdown into 12-40+ stories
- [ ] Value delivery path supports phased releases
- [ ] If UI exists, ready for UX expert collaboration
- [ ] Scale and complexity match Level 3-4 requirements
## Scale Validation
- [ ] Project scope justifies PRD
- [ ] Complexity matches Level 1-4 designation
- [ ] Story estimate aligns with epic structure (12-40+)
- [ ] Not over-engineered for actual needs
## Final Validation
- [ ] Document addresses user's original request completely
- [ ] All user feedback incorporated
- [ ] No critical user requirements missing
- [ ] Ready for user final review and approval
- [ ] File saved in correct location: {{output_folder}}/PRD.md
---
# Cohesion Validation (All Levels)
**Purpose**: Validate alignment between planning artifacts and readiness for implementation
## Project Context Detection
- [ ] Project level confirmed (0, 1, 2, 3, or 4)
- [ ] Field type identified (greenfield or brownfield)
- [ ] Appropriate validation sections applied based on context
## Section A: Tech Spec Validation (Levels 0, 1, 2 only)
### A.1 Tech Spec Completeness
- [ ] All technical decisions are DEFINITIVE (no "Option A or B")
- [ ] Specific versions specified for all frameworks/libraries
- [ ] Source tree structure clearly defined
- [ ] Technical approach precisely described
- [ ] Implementation stack complete with exact tools
- [ ] Testing approach clearly defined
- [ ] Deployment strategy documented
### A.2 Tech Spec - PRD Alignment (Levels 1-2 only)
- [ ] Every functional requirement has technical solution
- [ ] Non-functional requirements addressed in tech spec
- [ ] Tech stack aligns with PRD constraints
- [ ] Performance requirements achievable with chosen stack
- [ ] Technical preferences from user incorporated
## Section B: Greenfield-Specific Validation (if greenfield)
### B.1 Project Setup Sequencing
- [ ] Epic 0 or 1 includes project initialization steps
- [ ] Repository setup precedes feature development
- [ ] Development environment configuration included early
- [ ] Core dependencies installed before use
- [ ] Testing infrastructure set up before tests written
### B.2 Infrastructure Before Features
- [ ] Database setup before data operations
- [ ] API framework before endpoint implementation
- [ ] Authentication setup before protected features
- [ ] CI/CD pipeline before deployment
- [ ] Monitoring setup included
### B.3 External Dependencies
- [ ] Third-party account creation assigned to user
- [ ] API keys acquisition process defined
- [ ] Credential storage approach specified
- [ ] External service setup sequenced properly
- [ ] Fallback strategies for external failures
## Section C: Brownfield-Specific Validation (if brownfield)
### C.1 Existing System Integration
- [ ] Current architecture analyzed and documented
- [ ] Integration points with existing system identified
- [ ] Existing functionality preservation validated
- [ ] Database schema compatibility assessed
- [ ] API contract compatibility verified
### C.2 Risk Management
- [ ] Breaking change risks identified and mitigated
- [ ] Rollback procedures defined for each integration
- [ ] Feature flags or toggles included where appropriate
- [ ] Performance degradation risks assessed
- [ ] User impact analysis completed
### C.3 Backward Compatibility
- [ ] Database migrations maintain backward compatibility
- [ ] API changes don't break existing consumers
- [ ] Authentication/authorization integration safe
- [ ] Configuration changes non-breaking
- [ ] Existing monitoring preserved or enhanced
### C.4 Dependency Conflicts
- [ ] New dependencies compatible with existing versions
- [ ] No version conflicts introduced
- [ ] Security vulnerabilities not introduced
- [ ] License compatibility verified
- [ ] Bundle size impact acceptable
## Section D: Feature Sequencing (All Levels)
### D.1 Functional Dependencies
- [ ] Features depending on others sequenced correctly
- [ ] Shared components built before consumers
- [ ] User flows follow logical progression
- [ ] Authentication precedes protected features
### D.2 Technical Dependencies
- [ ] Lower-level services before higher-level ones
- [ ] Utilities and libraries created before use
- [ ] Data models defined before operations
- [ ] API endpoints before client consumption
### D.3 Epic Dependencies
- [ ] Later epics build on earlier epic functionality
- [ ] No circular dependencies between epics
- [ ] Infrastructure from early epics reused
- [ ] Incremental value delivery maintained
## Section E: UI/UX Cohesion (if UI components exist)
### E.1 Design System (Greenfield)
- [ ] UI framework selected and installed early
- [ ] Design system or component library established
- [ ] Styling approach defined
- [ ] Responsive design strategy clear
- [ ] Accessibility requirements defined
### E.2 Design Consistency (Brownfield)
- [ ] UI consistent with existing system
- [ ] Component library updates non-breaking
- [ ] Styling approach matches existing
- [ ] Accessibility standards maintained
- [ ] Existing user workflows preserved
### E.3 UX Flow Validation
- [ ] User journeys mapped completely
- [ ] Navigation patterns defined
- [ ] Error and loading states planned
- [ ] Form validation patterns established
## Section F: Responsibility Assignment (All Levels)
### F.1 User vs Agent Clarity
- [ ] Human-only tasks assigned to user
- [ ] Account creation on external services → user
- [ ] Payment/purchasing actions → user
- [ ] All code tasks → developer agent
- [ ] Configuration management properly assigned
## Section G: Documentation Readiness (All Levels)
### G.1 Developer Documentation
- [ ] Setup instructions comprehensive
- [ ] Technical decisions documented
- [ ] Patterns and conventions clear
- [ ] API documentation plan exists (if applicable)
### G.2 Deployment Documentation (Brownfield)
- [ ] Runbook updates planned
- [ ] Incident response procedures updated
- [ ] Rollback procedures documented and tested
- [ ] Monitoring dashboard updates planned
## Section H: Future-Proofing (All Levels)
### H.1 Extensibility
- [ ] Current scope vs future features clearly separated
- [ ] Architecture supports planned enhancements
- [ ] Technical debt considerations documented
- [ ] Extensibility points identified
### H.2 Observability
- [ ] Monitoring strategy defined
- [ ] Success metrics from planning captured
- [ ] Analytics or tracking included if needed
- [ ] Performance measurement approach clear
## Cohesion Summary
### Overall Readiness Assessment
- [ ] **Ready for Development** - All critical items pass
- [ ] **Needs Alignment** - Some gaps need addressing
- [ ] **Too Risky** (brownfield only) - Integration risks too high
### Critical Gaps Identified
_List any blocking issues or unacceptable risks:_
### Integration Risk Level (brownfield only)
- [ ] Low - well-understood integration with good rollback
- [ ] Medium - some unknowns but manageable
- [ ] High - significant risks require mitigation
### Recommendations
_Specific actions to improve cohesion before development:_
---

View File

@@ -1,325 +0,0 @@
# PRD Workflow Router Instructions
<workflow>
<critical>This workflow requires a workflow status file to exist</critical>
<critical>ALWAYS check for existing bmm-workflow-status.md first</critical>
<critical>If no status file exists, direct user to run workflow-status first</critical>
<critical>The workflow execution engine is governed by: {project_root}/bmad/core/tasks/workflow.xml</critical>
<step n="1" goal="Check for existing workflow status file - REQUIRED">
<action>Check if any bmm-workflow-status\*.md files exist in {output_folder}/</action>
<check if="not exists">
<output>**⚠️ No Workflow Status File Found**
The `plan-project` workflow requires an existing workflow status file.
Please run `workflow-status` first to:
- Map out your complete workflow journey
- Determine project type and level
- Create the status file with your planned workflow
**To proceed:**
1. Load any agent (Analyst, PM, or use bmad-master)
2. Run: `workflow-status`
3. Complete the workflow planning
4. Return here to continue with `plan-project`
Or tell me: "run workflow-status"
</output>
<action>Exit workflow - cannot proceed without status file</action>
</check>
<check if="exists">
<action>Find the most recent bmm-workflow-status.md file</action>
<action>Load the status file</action>
<action>Extract key information:</action>
**From Status File:**
- project_type: From "Project Type:" field
- project_level: From "Project Level:" field (0, 1, 2, 3, or 4)
- field_type: From "Greenfield/Brownfield:" field
- planned_workflow: From "Planned Workflow Journey" table
- current_step: From "Current Step:" field
- next_step: From "Next Step:" field
<action>Validate this workflow is the correct next step</action>
<check if='next_step != "plan-project"'>
<ask>**⚠️ Workflow Sequence Warning**
According to your status file, your next planned step is: **{{next_step}}**
But you're trying to run: **plan-project**
Options:
1. **Continue anyway** - Run plan-project (status file will be updated)
2. **Follow planned workflow** - Run {{next_step}} instead
3. **Update workflow plan** - Run workflow-status to revise plan
Your choice (1-3):
</ask>
<check if='choice == "2"'>
<output>**Recommended Next Step:**
Load agent: {{next_step_agent}}
Run: {{next_step}}
Or tell me: "run {{next_step}}"
</output>
<action>Exit workflow</action>
</check>
<check if='choice == "3"'>
<output>**Update Workflow Plan:**
Run: `workflow-status`
After updating your plan, return here if needed.
</output>
<action>Exit workflow</action>
</check>
</check>
<action>Set status_file_path = existing file path</action>
<action>Check for existing workflow outputs based on level in status file:</action>
- Level 0: Check for tech-spec.md
- Level 1-2: Check for PRD.md, epics.md, tech-spec.md
- Level 3-4: Check for PRD.md, epics.md
<check if="outputs exist">
<ask>Found existing workflow status file: bmm-workflow-status.md (Level {{project_level}})
**Existing documents detected:**
{{list_existing_docs}}
Options:
1. **Continue** - Update existing documents
2. **Start fresh** - Archive old documents, create new ones
3. **Exit** - I'm not ready to regenerate these
Your choice (1-3):</ask>
<check if='option == "1"'>
<action>Set continuation_mode = true</action>
<action>Will update existing documents</action>
</check>
<check if='option == "2"'>
<action>Archive existing documents to: "{output_folder}/archive/"</action>
<action>Set continuation_mode = false</action>
<action>Will create fresh documents</action>
</check>
<check if='option == "3"'>
<action>Exit workflow</action>
</check>
</check>
<check if="outputs do not exist">
<action>Set continuation_mode = false</action>
<action>Ready to create new documents</action>
</check>
</check>
</step>
<step n="2" goal="Use status file data and determine specific planning path">
<output>**Status File Data Loaded:**
- Project Type: {{project_type}}
- Project Level: {{project_level}}
- Field Type: {{field_type}}
- Current Phase: {{current_phase}}
</output>
<ask>What type of planning do you need?
**Based on your project (Level {{project_level}} {{project_type}}):**
{{#if project_level == 0}}
**Recommended:** Tech spec only (Level 0 path)
{{/if}}
{{#if project_level == 1}}
**Recommended:** Tech spec + epic/stories (Level 1 path)
{{/if}}
{{#if project_level >= 2}}
**Recommended:** Full PRD + epics (Level {{project_level}} path)
{{/if}}
**Other Options:**
1. **Follow recommended path** (recommended)
2. **UX/UI specification only**
3. **Generate AI Frontend Prompt** (from existing specs)
4. **Describe custom needs**
Select an option (1-4):</ask>
<action>Capture user selection as {{planning_type}}</action>
<check if='{{planning_type}} == "2" OR "UX/UI specification only"'>
<invoke-workflow>{installed_path}/ux/workflow.yaml</invoke-workflow>
<action>Pass mode="standalone" to UX workflow</action>
<action>Exit router workflow (skip remaining steps)</action>
</check>
<check if='{{planning_type}} == "3" OR "Generate AI Frontend Prompt"'>
<action>Check for existing UX spec or PRD</action>
<invoke-task>{project-root}/bmad/bmm/tasks/ai-fe-prompt.md</invoke-task>
<action>Exit router workflow after prompt generation</action>
</check>
<action if='{{planning_type}} == "1" OR "Follow recommended path"'>Use project_level and project_type from status file to route to appropriate workflow</action>
</step>
<step n="3" goal="Gather additional context if needed">
<action>Read status file to check if additional context is needed</action>
<check if='field_type == "brownfield" AND needs_documentation == true'>
<ask>**⚠️ Brownfield Documentation Needed**
Your status file indicates this brownfield project needs codebase documentation.
The document-project workflow was flagged in your planned workflow.
**Options:**
1. **Generate docs now** - Run document-project workflow (~10-15 min)
2. **Skip for now** - I'll provide context through questions
3. **Already have docs** - I have documentation to reference
Choose option (1-3):</ask>
<check if='option == "1"'>
<action>Invoke document-project workflow before continuing</action>
<invoke-workflow>{project-root}/bmad/bmm/workflows/1-analysis/document-project/workflow.yaml</invoke-workflow>
<action>Wait for documentation to complete</action>
<action>Update status file: Mark document-project as "Complete" in planned workflow</action>
</check>
<check if='option == "2"'>
<action>Set gather_context_via_questions = true</action>
<action>Will ask detailed questions during spec generation</action>
</check>
<check if='option == "3"'>
<action>Set has_documentation = true</action>
<action>Will reference existing documentation</action>
</check>
</check>
<check if='project_level == "TBD"'>
<ask>**Project Level Not Yet Determined**
Your status file indicates the project level will be determined during planning.
**Based on what you want to build, what level best describes your project?**
0. **Single atomic change** - Bug fix, add endpoint, single file change
1. **Coherent feature** - Add search, implement SSO, new component (2-3 stories)
2. **Small complete system** - Admin tool, team app, prototype (multiple epics)
3. **Full product** - Customer portal, SaaS MVP (subsystems, integrations)
4. **Platform/ecosystem** - Enterprise suite, multi-tenant system
Your level (0-4):</ask>
<action>Capture confirmed_level</action>
<action>Update status file with confirmed project_level</action>
</check>
<check if='project_type == "TBD" OR project_type == "custom"'>
<ask>**Project Type Clarification Needed**
Please describe your project type so we can load the correct planning template.
Examples: web, mobile, desktop, backend, library, cli, game, embedded, data, extension, infra
Your project type:</ask>
<action>Capture and map to project_type_id from project-types.csv</action>
<action>Update status file with confirmed project_type</action>
</check>
</step>
<step n="4" goal="Update status file and route to appropriate workflow">
<action>Update status file before proceeding:</action>
<template-output file="{{status_file_path}}">current_workflow</template-output>
<check if="project_level == 0">Set to: "tech-spec (Level 0 - in progress)"</check>
<check if="project_level == 1">Set to: "tech-spec (Level 1 - in progress)"</check>
<check if="project_level >= 2">Set to: "PRD (Level {{project_level}} - in progress)"</check>
<template-output file="{{status_file_path}}">current_step</template-output>
Set to: "plan-project"
<template-output file="{{status_file_path}}">progress_percentage</template-output>
Increment by 10% (planning started)
<action>Add to decisions log:</action>
```
- **{{date}}**: Started plan-project workflow. Routing to {{workflow_type}} workflow based on Level {{project_level}} {{project_type}} project.
```
<critical>Based on project type and level from status file, load ONLY the needed instructions:</critical>
<check if='project_type == "game"'>
<invoke-workflow>{installed_path}/gdd/workflow.yaml</invoke-workflow>
<action>GDD workflow handles all game project levels internally</action>
<action>Pass status_file_path and continuation_mode to workflow</action>
</check>
<check if='project_level == 0 AND project_type != "game"'>
<invoke-workflow>{installed_path}/tech-spec/workflow.yaml</invoke-workflow>
<action>Pass level=0 to tech-spec workflow</action>
<action>Tech-spec workflow will generate tech-spec + 1 story</action>
<action>Pass status_file_path and continuation_mode to workflow</action>
</check>
<check if='project_level == 1 AND project_type != "game"'>
<invoke-workflow>{installed_path}/tech-spec/workflow.yaml</invoke-workflow>
<action>Pass level=1 to tech-spec workflow</action>
<action>Tech-spec workflow will generate tech-spec + epic + 2-3 stories</action>
<action>Pass status_file_path and continuation_mode to workflow</action>
</check>
<check if='project_level >= 2 AND project_type != "game"'>
<invoke-workflow>{installed_path}/prd/workflow.yaml</invoke-workflow>
<action>Pass project_level context to PRD workflow (loads instructions.md)</action>
<action>Pass status_file_path and continuation_mode to workflow</action>
</check>
<critical>Pass context to invoked workflow:</critical>
- status_file_path: {{status_file_path}}
- continuation_mode: {{continuation_mode}}
- existing_documents: {{document_list}}
- project_level: {{project_level}}
- project_type: {{project_type}}
- field_type: {{field_type}}
- gather_context_via_questions: {{gather_context_via_questions}} (if brownfield without docs)
<critical>The invoked workflow will update the status file when complete</critical>
</step>
</workflow>

View File

@@ -1,137 +0,0 @@
# Project Planning Workflow Configuration
name: "plan-project"
description: "Scale-adaptive project planning workflow for all project levels (0-4). Automatically adjusts outputs based on project scope - from single atomic changes (Level 0: tech-spec only) to enterprise platforms (Level 4: full PRD + epics). Level 2-4 route to 3-solutioning workflow for architecture and tech specs. Generates appropriate planning artifacts for each level."
author: "BMad"
# Critical variables load from config_source
config_source: "{project-root}/bmad/bmm/config.yaml"
project_name: "{config_source}:project_name"
output_folder: "{config_source}:output_folder"
user_name: "{config_source}:user_name"
date: system-generated
recommended_inputs:
- product_brief: "{output_folder}/product-brief.md"
- game_brief: "{output_folder}/game-brief.md"
- market_research: "{output_folder}/market-research.md"
# Module path and component files
installed_path: "{project-root}/bmad/bmm/workflows/2-plan"
# Sub-workflow references - Router invokes these workflows based on project type/level
workflow_gdd: "{installed_path}/gdd/workflow.yaml"
workflow_prd: "{installed_path}/prd/workflow.yaml"
workflow_narrative: "{installed_path}/narrative/workflow.yaml"
workflow_tech_spec: "{installed_path}/tech-spec/workflow.yaml"
workflow_ux: "{installed_path}/ux/workflow.yaml"
# Templates - Load these only when the instructions request loading them
prd_template: "{installed_path}/prd/prd-template.md"
status_template: "{project-root}/bmad/bmm/workflows/_shared/bmm-workflow-status-template.md"
epics_template: "{installed_path}/prd/epics-template.md"
tech_spec_template: "{installed_path}/tech-spec/tech-spec-template.md"
ux_spec_template: "{installed_path}/ux/ux-spec-template.md"
gdd_template: "{installed_path}/gdd/gdd-template.md"
game_types_csv: "{installed_path}/gdd/game-types.csv"
narrative_template: "{installed_path}/narrative/narrative-template.md"
# Routing instructions - loads appropriate instruction set based on project level
instructions: "{installed_path}/instructions-router.md"
# Output configuration
status_file: "{output_folder}/bmm-workflow-status.md"
default_output_file: "{output_folder}/PRD.md"
gdd_output_file: "{output_folder}/GDD.md"
epics_output_file: "{output_folder}/epics.md"
tech_spec_file: "{output_folder}/tech-spec.md"
ux_spec_file: "{output_folder}/ux-specification.md"
narrative_design_file: "{output_folder}/narrative-design.md"
ai_frontend_prompt_file: "{output_folder}/ai-frontend-prompt.md"
validation_output_file: "{output_folder}/PRD-validation-report.md"
# Scale parameters - adaptive by project level
scale_parameters:
level_0: "Single atomic change, tech-spec only with linked single story"
level_1: "1-10 stories, 1 epic, minimal PRD + tech-spec"
level_2: "5-15 stories, 1-2 epics, focused PRD + tech-spec"
level_3: "12-40 stories, 1-5 epics, full PRD + architect handoff"
level_4: "40+ stories, 5+ epics, enterprise PRD + architect handoff"
#Do not load these directly - instructions-router.md will load the proper file based on project type/level when needed
instructions_tech_spec: "{installed_path}/tech-spec/instructions.md"
instructions_prd: "{installed_path}/prd/instructions.md"
instructions_ux: "{installed_path}/ux/instructions-ux.md"
instructions_gdd: "{installed_path}/gdd/instructions-gdd.md"
instructions_narrative: "{installed_path}/narrative/instructions-narrative.md"
validation: "{installed_path}/checklist.md"
web_bundle:
name: "plan-project"
description: "Scale-adaptive project planning workflow for all project levels (0-4). Automatically adjusts outputs based on project scope - from single atomic changes (Level 0: tech-spec only) to enterprise platforms (Level 4: full PRD + epics). Level 2-4 route to 3-solutioning workflow for architecture and tech specs. Generates appropriate planning artifacts for each level."
author: "BMad"
# Routing instructions - loads appropriate instruction set based on project level
instructions: "bmad/bmm/workflows/2-plan/instructions-router.md"
validation: "bmad/bmm/workflows/2-plan/checklist.md"
use_advanced_elicitation: true
# Do not load these directly - instructions-router.md will load the proper file based on project type/level when needed
instructions_tech_spec: "bmad/bmm/workflows/2-plan/tech-spec/instructions.md"
instructions_prd: "bmad/bmm/workflows/2-plan/prd/instructions.md"
instructions_ux: "bmad/bmm/workflows/2-plan/ux/instructions-ux.md"
instructions_gdd: "bmad/bmm/workflows/2-plan/gdd/instructions-gdd.md"
instructions_narrative: "bmad/bmm/workflows/2-plan/narrative/instructions-narrative.md"
# Templates - Load these only when the instructions request loading them
prd_template: "{installed_path}/prd/prd-template.md"
status_template: "bmad/bmm/workflows/_shared/bmm-workflow-status-template.md"
epics_template: "{installed_path}/prd/epics-template.md"
tech_spec_template: "{installed_path}/tech-spec/tech-spec-template.md"
ux_spec_template: "{installed_path}/ux/ux-spec-template.md"
gdd_template: "{installed_path}/gdd/gdd-template.md"
game_types_csv: "{installed_path}/gdd/game-types.csv"
narrative_template: "{installed_path}/narrative/narrative-template.md"
# Scale parameters - adaptive by project level
scale_parameters:
level_0: "Single atomic change, tech-spec only with linked single story"
level_1: "1-10 stories, 1 epic, minimal PRD + tech-spec"
level_2: "5-15 stories, 1-2 epics, focused PRD + tech-spec"
level_3: "12-40 stories, 1-5 epics, full PRD + architect handoff"
level_4: "40+ stories, 5+ epics, enterprise PRD + architect handoff"
web_bundle_files:
- "bmad/bmm/workflows/2-plan/instructions-router.md"
- "bmad/bmm/workflows/2-plan/tech-spec/instructions.md"
- "bmad/bmm/workflows/2-plan/prd/instructions.md"
- "bmad/bmm/workflows/2-plan/prd/prd-template.md"
- "bmad/bmm/workflows/2-plan/prd/epics-template.md"
- "bmad/bmm/workflows/2-plan/tech-spec/tech-spec-template.md"
- "bmad/bmm/workflows/2-plan/ux/ux-spec-template.md"
- "bmad/bmm/workflows/2-plan/ux/instructions-ux.md"
- "bmad/bmm/workflows/2-plan/gdd/gdd-template.md"
- "bmad/bmm/workflows/2-plan/gdd/instructions-gdd.md"
- "bmad/bmm/workflows/2-plan/narrative/instructions-narrative.md"
- "bmad/bmm/workflows/2-plan/gdd/game-types.csv"
- "bmad/bmm/workflows/2-plan/gdd/game-types/action-platformer.md"
- "bmad/bmm/workflows/2-plan/gdd/game-types/adventure.md"
- "bmad/bmm/workflows/2-plan/gdd/game-types/card-game.md"
- "bmad/bmm/workflows/2-plan/gdd/game-types/fighting.md"
- "bmad/bmm/workflows/2-plan/gdd/game-types/horror.md"
- "bmad/bmm/workflows/2-plan/gdd/game-types/idle-incremental.md"
- "bmad/bmm/workflows/2-plan/gdd/game-types/metroidvania.md"
- "bmad/bmm/workflows/2-plan/gdd/game-types/moba.md"
- "bmad/bmm/workflows/2-plan/gdd/game-types/party-game.md"
- "bmad/bmm/workflows/2-plan/gdd/game-types/puzzle.md"
- "bmad/bmm/workflows/2-plan/gdd/game-types/racing.md"
- "bmad/bmm/workflows/2-plan/gdd/game-types/rhythm.md"
- "bmad/bmm/workflows/2-plan/gdd/game-types/roguelike.md"
- "bmad/bmm/workflows/2-plan/gdd/game-types/rpg.md"
- "bmad/bmm/workflows/2-plan/gdd/game-types/sandbox.md"
- "bmad/bmm/workflows/2-plan/gdd/game-types/shooter.md"
- "bmad/bmm/workflows/2-plan/gdd/game-types/simulation.md"
- "bmad/bmm/workflows/2-plan/gdd/game-types/sports.md"
- "bmad/bmm/workflows/2-plan/gdd/game-types/strategy.md"
- "bmad/bmm/workflows/2-plan/gdd/game-types/survival.md"
- "bmad/bmm/workflows/2-plan/gdd/game-types/text-based.md"
- "bmad/bmm/workflows/2-plan/gdd/game-types/tower-defense.md"
- "bmad/bmm/workflows/2-plan/gdd/game-types/turn-based-tactics.md"
- "bmad/bmm/workflows/2-plan/gdd/game-types/visual-novel.md"
- "bmad/bmm/workflows/2-plan/narrative/narrative-template.md"
- "bmad/bmm/workflows/2-plan/narrative/instructions-narrative.md"
- "bmad/bmm/workflows/2-plan/checklist.md"

View File

@@ -25,23 +25,23 @@ The BMM (BMAD Method Module) orchestrates software development through four dist
├──────────────────────────────────────────────────────────────┤
│ brainstorm-game ──┐ │
│ brainstorm-project ├──→ research ──→ product-brief ──┐ │
│ game-brief ────────┘
│ game-brief ────────┘ game-brief ┘
└────────────────────────────────────────────────────────┼─────┘
┌──────────────────────────────────────────────────────────────┐
│ PHASE 2: PLANNING │
(Scale-Adaptive Router)
│ (Scale-Adaptive Router - by type)
├──────────────────────────────────────────────────────────────┤
plan-project
├──→ Level 0: tech-spec only
├──→ Level 1-2: PRD + tech-spec
├──→ Level 3-4: PRD + Epics ──────┐
└──→ Game: GDD │
└──────────────────────────────────────────────────────────┼──┘
SOFTWARE: plan-project GAMES: gdd
│ ├──→ Level 0: tech-spec only ├──→ GDD (all levels)
│ ├──→ Level 1: tech-spec only └──→ Narrative design
├──→ Level 2: PRD + tech-spec
└──→ Level 3-4: PRD + Epics ────────────────────────┐
└──────────────────────────────────────────────────────────┼──┘
┌──────────────────────────────────────────────────────────────┐
│ PHASE 3: SOLUTIONING │
(Levels 3-4 Only)
(Software Levels 3-4 / Complex Games)
├──────────────────────────────────────────────────────────────┤
│ 3-solutioning ──→ solution-architecture.md │
│ ↓ │
@@ -124,13 +124,13 @@ The central orchestrator that determines project scale and generates appropriate
### Scale Levels
| Level | Scope | Outputs | Next Phase |
| ----- | ------------------------ | ------------------------------ | ---------------- |
| **0** | Single atomic change | tech-spec + 1 story | → Implementation |
| **1** | 1-10 stories, 1 epic | tech-spec + epic + 2-3 stories | → Implementation |
| **2** | 5-15 stories, 1-2 epics | Focused PRD + tech-spec | → Implementation |
| **3** | 12-40 stories, 2-5 epics | Full PRD + Epics list | → Solutioning |
| **4** | 40+ stories, 5+ epics | Enterprise PRD + Epics | → Solutioning |
| Level | Scope | Outputs | Next Phase |
| ----- | ------------------------ | ------------------------------ | ------------------------------ |
| **0** | Single atomic change | tech-spec + 1 story | → Implementation |
| **1** | 1-10 stories, 1 epic | tech-spec + epic + 2-3 stories | → Implementation |
| **2** | 5-15 stories, 1-2 epics | PRD + epics | → Tech-spec → Implementation |
| **3** | 12-40 stories, 2-5 epics | PRD + epics | → Solutioning → Implementation |
| **4** | 40+ stories, 5+ epics | PRD + epics | → Solutioning → Implementation |
**Key Changes (v6a):**
@@ -140,20 +140,49 @@ The central orchestrator that determines project scale and generates appropriate
### Routing Logic
**Universal Entry Point** (workflow-status):
```
plan-project
├─→ Detect project type (game/web/mobile/backend/etc)
workflow-status
├─→ Check for existing status file
│ ├─→ If exists: Display status + recommend next action
│ └─→ If not exists: Guide workflow planning
├─→ Determine project context (greenfield/brownfield)
├─→ Determine project type (game/web/mobile/backend/etc)
├─→ Assess complexity → assign Level 0-4
├─→ Check context (greenfield/brownfield)
│ └─→ If brownfield & undocumented:
│ └─→ HALT: "Generate brownfield documentation first"
│ └─→ (TBD workflow for codebase analysis)
├─→ Route to appropriate sub-workflow:
│ ├─→ Game → GDD workflow
│ ├─→ Level 0 → tech-spec workflow
│ ├─→ Level 1-2 → PRD + embedded tech-spec
│ └─→ Level 3-4 → PRD + epics → Solutioning
└─→ Generate bmm-workflow-status.md (tracking doc)
├─→ Map complete workflow journey
└─→ Generate bmm-workflow-status.md + direct to first workflow
```
**Direct Routing** (no intermediate routers):
```
workflow-status determines routing:
SOFTWARE PROJECTS:
├─→ Level 0-1 → bmad architect tech-spec
│ └─→ Validates status file + level
│ └─→ Generates tech-spec.md + stories
│ └─→ Direct to Phase 4 (implementation)
├─→ Level 2 → bmad pm prd
│ └─→ Validates status file + level
│ └─→ Generates PRD.md + epics.md
│ └─→ Then: bmad architect tech-spec (lightweight solutioning)
│ └─→ Then: Phase 4 (implementation)
└─→ Level 3-4 → bmad pm prd
└─→ Validates status file + level
└─→ Generates PRD.md + epics.md
└─→ Then: Phase 3 (solution-architecture)
└─→ Then: Phase 4 (implementation)
GAME PROJECTS:
└─→ All Levels → bmad pm gdd
└─→ Validates status file + project type
└─→ Generates GDD.md + epics.md
└─→ Optional: narrative design
└─→ Then: Phase 3 or 4 (based on complexity)
```
### Key Outputs
@@ -381,7 +410,8 @@ plan-project (Phase 2)
- **Phase 2**:
- Level 0: tech-spec.md + story-{slug}.md
- Level 1: tech-spec.md + epic-stories.md + story-{slug}-N.md files
- Level 2-4: PRD.md, Epics.md, or tech-spec.md based on level
- Level 2: PRD.md + epics.md (then tech-spec.md in Phase 3)
- Level 3-4: PRD.md + epics.md (then solution-architecture.md in Phase 3)
- **Phase 3**: solution-architecture.md, epic-specific tech specs
- **Phase 4**: Story files, context XMLs, implemented code
@@ -440,7 +470,9 @@ bmad analyst research
bmad analyst product-brief
# Phase 2: Planning
bmad pm plan-project
bmad pm prd # Level 2-4 software projects
bmad architect tech-spec # Level 0-1 software projects
bmad pm gdd # Game projects
# Phase 3: Solutioning (L3-4)
bmad architect solution-architecture