feat: Extract BMGD module and implement workflow vendoring

This commit extracts game development functionality from BMM into a standalone
BMGD (BMad Game Development) module and implements workflow vendoring to enable
module independence.

BMGD Module Creation:
- Moved agents: game-designer, game-dev, game-architect from BMM to BMGD
- Moved team config: team-gamedev
- Created new Game Dev Scrum Master agent using workflow vendoring pattern
- Reorganized workflows into industry-standard game dev phases:
  * Phase 1 (Preproduction): brainstorm-game, game-brief
  * Phase 2 (Design): gdd, narrative
  * Phase 3 (Technical): game-architecture
  * Phase 4 (Production): vendored from BMM workflows
- Updated all module metadata and config_source references

Workflow Vendoring Feature:
- Enables modules to copy workflows from other modules during installation
- Build-time process that updates config_source in vendored workflows
- New agent YAML attribute: workflow-install (build-time metadata)
- Final compiled agents use workflow-install value for workflow attribute
- Implementation in module manager: vendorCrossModuleWorkflows()
- Allows standalone module installation without forced dependencies

Technical Changes:
- tools/cli/lib/yaml-xml-builder.js: Use workflow-install for workflow attribute
- tools/cli/installers/lib/modules/manager.js: Add vendoring functions
- tools/schema/agent.js: Add workflow-install to menu item schema
- Updated 3 documentation files with workflow vendoring details

BMM Workflow Updates:
- workflow-status/init: Added game detection checkpoint
- workflow-status/paths/game-design.yaml: Redirect to BMGD module
- prd/instructions.md: Route game projects to BMGD
- research/instructions-market.md: Reference BMGD for game development

Documentation:
- Created comprehensive BMGD module README
- Added workflow vendoring documentation
- Updated BMB agent creation and module creation guides
This commit is contained in:
Brian Madison 2025-11-05 20:44:22 -06:00
parent bc76d25be6
commit f84e18760f
66 changed files with 2527 additions and 226 deletions

View File

@ -311,6 +311,66 @@ bmad status -v # Detailed status
- Agent references (cross-module)
- Template dependencies
- Partial module installation (only required files)
- Workflow vendoring for standalone module operation
## Workflow Vendoring
**Problem**: Modules that reference workflows from other modules create dependencies, forcing users to install multiple modules even when they only need one.
**Solution**: Workflow vendoring allows modules to copy workflows from other modules during installation, making them fully standalone.
### How It Works
Agents can specify both `workflow` (source location) and `workflow-install` (destination location) in their menu items:
```yaml
menu:
- trigger: create-story
workflow: '{project-root}/bmad/bmm/workflows/4-implementation/create-story/workflow.yaml'
workflow-install: '{project-root}/bmad/bmgd/workflows/4-production/create-story/workflow.yaml'
description: 'Create a game feature story'
```
**During Installation:**
1. **Vendoring Phase**: Before copying module files, the installer:
- Scans source agent YAML files for `workflow-install` attributes
- Copies entire workflow folders from `workflow` path to `workflow-install` path
- Updates vendored `workflow.yaml` files to reference target module's config
2. **Compilation Phase**: When compiling agents:
- If `workflow-install` exists, uses its value for the `workflow` attribute
- `workflow-install` is build-time metadata only, never appears in final XML
- Compiled agent references vendored workflow location
3. **Config Update**: Vendored workflows get their `config_source` updated:
```yaml
# Source workflow (in bmm):
config_source: "{project-root}/bmad/bmm/config.yaml"
# Vendored workflow (in bmgd):
config_source: "{project-root}/bmad/bmgd/config.yaml"
```
**Result**: Modules become completely standalone with their own copies of needed workflows, configured for their specific use case.
### Example Use Case: BMGD Module
The BMad Game Development module vendors implementation workflows from BMM:
- Game Dev Scrum Master agent references BMM workflows
- During installation, workflows are copied to `bmgd/workflows/4-production/`
- Vendored workflows use BMGD's config (with game-specific settings)
- BMGD can be installed without BMM dependency
### Benefits
**Module Independence** - No forced dependencies
**Clean Namespace** - Workflows live in their module
**Config Isolation** - Each module uses its own configuration
**Customization Ready** - Vendored workflows can be modified independently
**No User Confusion** - Avoid partial module installations
### File Processing
@ -318,6 +378,7 @@ bmad status -v # Detailed status
- Excludes `_module-installer/` directories
- Replaces path placeholders at runtime
- Injects activation blocks
- Vendors cross-module workflows (see Workflow Vendoring below)
### Web Bundling

View File

@ -193,9 +193,23 @@ menu:
- trigger: [emerging from conversation]
workflow: [path based on capability]
description: [user's words refined]
```
# For cross-module workflow references (advanced):
- trigger: [another capability]
workflow: "{project-root}/bmad/SOURCE_MODULE/workflows/path/to/workflow.yaml"
workflow-install: "{project-root}/bmad/THIS_MODULE/workflows/vendored/path/workflow.yaml"
description: [description]
`````
</example>
<note>**Workflow Vendoring (Advanced):**
When an agent needs workflows from another module, use both `workflow` (source) and `workflow-install` (destination).
During installation, the workflow will be copied and configured for this module, making it standalone.
This is typically used when creating specialized modules that reuse common workflows with different configurations.
</note>
<template-output>agent_commands</template-output>
</step>
@ -298,14 +312,16 @@ menu: {{The capabilities built}}
**Folder Structure:**
```
`````
{{agent_filename}}-sidecar/
├── memories.md # Persistent memory
├── instructions.md # Private directives
├── knowledge/ # Knowledge base
│ └── README.md
└── sessions/ # Session notes
```
````
**File: memories.md**
@ -323,7 +339,7 @@ menu: {{The capabilities built}}
## Personal Notes
<!-- My observations and insights -->
```
````
**File: instructions.md**

View File

@ -136,6 +136,40 @@ Tasks should be used for:
- Declare dependencies in config.yaml
- Version compatibility notes
### Workflow Vendoring (Advanced)
For modules that need workflows from other modules but want to remain standalone, use **workflow vendoring**:
**In Agent YAML:**
```yaml
menu:
- trigger: command-name
workflow: '{project-root}/bmad/SOURCE_MODULE/workflows/path/workflow.yaml'
workflow-install: '{project-root}/bmad/THIS_MODULE/workflows/vendored/workflow.yaml'
description: 'Command description'
```
**What Happens:**
- During installation, workflows are copied from `workflow` to `workflow-install` location
- Vendored workflows get `config_source` updated to reference this module's config
- Compiled agent only references the `workflow-install` path
- Module becomes fully standalone - no source module dependency required
**Use Cases:**
- Specialized modules that reuse common workflows with different configs
- Domain-specific adaptations (e.g., game dev using standard dev workflows)
- Testing workflows in isolation
**Benefits:**
- Module independence (no forced dependencies)
- Clean namespace (workflows in your module)
- Config isolation (use your module's settings)
- Customization ready (modify vendored workflows freely)
## Installation Infrastructure
### Required: \_module-installer/install-config.yaml

208
src/modules/bmgd/README.md Normal file
View File

@ -0,0 +1,208 @@
# BMad Game Development (BMGD)
A comprehensive game development toolkit providing specialized agents and workflows for creating games from initial concept through production.
## Overview
The BMGD module brings together game-specific development workflows organized around industry-standard development phases:
- **Preproduction** - Concept development, brainstorming, game brief creation
- **Design** - Game Design Document (GDD) and narrative design
- **Technical** - Game architecture and technical specifications
- **Production** - Sprint-based implementation using BMM workflows
## Installation
```bash
bmad install bmgd
```
During installation, you'll be asked to configure:
- Game project name
- Document storage locations
- Development experience level
- Primary target platform
## Components
### Agents (4)
**Game Designer** 🎨
Creative vision and game design documentation specialist. Creates compelling GDDs and defines game mechanics.
**Game Developer** 🕹️
Senior implementation specialist with expertise across Unity, Unreal, and custom engines. Handles gameplay programming, physics, AI, and optimization.
**Game Architect** 🏗️
Technical systems and infrastructure expert. Designs scalable game architecture and engine-level solutions.
**Game Dev Scrum Master** 🎯
Sprint orchestrator specialized in game development workflows. Coordinates multi-disciplinary teams and translates GDDs into actionable development stories.
### Team Bundle
**Team Game Development** 🎮
Pre-configured team including Game Designer, Game Developer, and Game Architect for comprehensive game projects.
### Workflows
#### Phase 1: Preproduction
- **brainstorm-game** - Interactive game concept brainstorming
- **game-brief** - Create focused game brief document
#### Phase 2: Design
- **gdd** - Generate comprehensive Game Design Document
- **narrative** - Design narrative structure and story elements
#### Phase 3: Technical
- **game-architecture** - Define technical architecture (adapted from BMM architecture workflow)
#### Phase 4: Production
Production workflows are provided by the BMM module and accessible through the Game Dev Scrum Master agent:
- Sprint planning
- Story creation and management
- Epic technical specifications
- Code review and retrospectives
## Quick Start
### 1. Start with Concept Development
```
Load agent: game-designer
Run workflow: brainstorm-game
```
### 2. Create Game Brief
```
Run workflow: game-brief
```
### 3. Develop Game Design Document
```
Run workflow: gdd
```
### 4. Define Technical Architecture
```
Load agent: game-architect
Run workflow: game-architecture
```
### 5. Begin Production Sprints
```
Load agent: game-scrum-master
Run: *sprint-planning
```
## Module Structure
```
bmgd/
├── agents/
│ ├── game-designer.agent.yaml
│ ├── game-dev.agent.yaml
│ ├── game-architect.agent.yaml
│ └── game-scrum-master.agent.yaml
├── teams/
│ └── team-gamedev.yaml
├── workflows/
│ ├── 1-preproduction/
│ │ ├── brainstorm-game/
│ │ └── game-brief/
│ ├── 2-design/
│ │ ├── gdd/
│ │ └── narrative/
│ ├── 3-technical/
│ │ └── game-architecture/
│ └── 4-production/
│ (Uses BMM workflows via cross-module references)
├── templates/
├── data/
└── _module-installer/
└── install-config.yaml
```
## Configuration
After installation, configure the module in `bmad/bmgd/config.yaml`
Key settings:
- **game_project_name** - Your game's working title
- **game_design_docs** - Location for GDD and design documents
- **game_tech_docs** - Location for technical documentation
- **game_story_location** - Location for development user stories
- **game_dev_experience** - Your experience level (affects agent communication)
- **primary_platform** - Target platform (PC, mobile, console, web, multi-platform)
## Workflow Integration
BMGD leverages the BMM module for production/implementation workflows. The Game Dev Scrum Master agent provides access to:
- Sprint planning and management
- Story creation from GDD specifications
- Epic technical context generation
- Code review workflows
- Retrospectives and course correction
This separation allows BMGD to focus on game-specific design and architecture while using battle-tested agile implementation workflows.
## Example: Creating a 2D Platformer
1. **Brainstorm** concepts with `brainstorm-game` workflow
2. **Define** the vision with `game-brief` workflow
3. **Design** mechanics and progression with `gdd` workflow
4. **Craft** character arcs and story with `narrative` workflow
5. **Architect** technical systems with `game-architecture` workflow
6. **Implement** via Game Dev Scrum Master sprint workflows
## Development Roadmap
### Phase 1: Core Enhancement
- [ ] Customize game-architecture workflow for game-specific patterns
- [ ] Add game-specific templates (level design, character sheets, etc.)
- [ ] Create asset pipeline workflows
### Phase 2: Expanded Features
- [ ] Add monetization planning workflows
- [ ] Create playtesting and feedback workflows
- [ ] Develop game balancing tools
### Phase 3: Platform Integration
- [ ] Add platform-specific deployment workflows
- [ ] Create build and release automation
- [ ] Develop live ops workflows
## Contributing
To extend this module:
1. Add new agents using `/bmad:bmb:workflows:create-agent`
2. Add new workflows using `/bmad:bmb:workflows:create-workflow`
3. Submit improvements via pull request
## Dependencies
- **BMM Module** - Required for production/implementation workflows
## Author
Extracted and refined from BMM module on 2025-11-05
## License
Part of the BMAD Method ecosystem

View File

@ -0,0 +1,66 @@
# BMad Game Dev Module Configuration
code: bmgd
name: "BMGD: BMad Game Development"
default_selected: false
prompt:
- "Welcome to the BMad Game Development Module!"
- "This module provides specialized agents and workflows for game creation,"
- "from initial concept through production, covering all major game dev phases."
- "All paths are relative to project root, with no leading slash."
# Core config values automatically inherited:
## user_name
## communication_language
## document_output_language
## output_folder
game_project_name:
prompt: "What is the name of your game project?"
default: "{directory_name}"
result: "{value}"
game_design_docs:
prompt: "Where should game design documents (GDD, narrative, etc.) be stored?"
default: "docs/design"
result: "{project-root}/{value}"
game_tech_docs:
prompt: "Where should game technical documentation be stored?"
default: "docs/technical"
result: "{project-root}/{value}"
game_story_location:
prompt: "Where should game development stories be stored?"
default: "docs/stories"
result: "{project-root}/{value}"
game_dev_experience:
prompt: "What is your game development experience level?"
default: "intermediate"
result: "{value}"
single-select:
- value: "beginner"
label: "Beginner - New to game development, provide detailed guidance"
- value: "intermediate"
label: "Intermediate - Familiar with game dev concepts, balanced approach"
- value: "expert"
label: "Expert - Experienced game developer, be direct and technical"
specified_framework:
prompt: "Which game development framework or engine do you want to install support for?"
default: "unity"
result: "{value}"
multi-select:
- value: "unity"
label: "Unity"
- value: "unreal"
label: "Unreal Engine"
- value: "godot"
label: "Godot"
- value: "custom"
label: "Custom / Other"
data_path:
result: "{project-root}/bmad/bmgd/data"

View File

@ -2,11 +2,11 @@
agent:
metadata:
id: bmad/bmm/agents/game-architect.md
id: bmad/bmgd/agents/game-architect.md
name: Cloud Dragonborn
title: Game Architect
icon: 🏛️
module: bmm
module: bmgd
persona:
role: Principal Game Systems Architect + Technical Director
@ -18,18 +18,11 @@ agent:
- Scalability means building for tomorrow without over-engineering today. Simplicity is the ultimate sophistication in system design.
menu:
- trigger: workflow-status
workflow: "{project-root}/bmad/bmm/workflows/workflow-status/workflow.yaml"
description: Check workflow status and get recommendations
- trigger: correct-course
workflow: "{project-root}/bmad/bmm/workflows/4-implementation/correct-course/workflow.yaml"
workflow-install: "{project-root}/bmad/bmgd/workflows/4-production/correct-course/workflow.yaml"
description: Course Correction Analysis
- trigger: create-architecture
workflow: "{project-root}/bmad/bmm/workflows/3-solutioning/architecture/workflow.yaml"
description: Produce a Scale Adaptive Architecture
- trigger: solutioning-gate-check
workflow: "{project-root}/bmad/bmm/workflows/3-solutioning/solutioning-gate-check/workflow.yaml"
description: Validate solutioning complete, ready for Phase 4 (Level 2-4 only)
workflow: "{project-root}/bmad/bmgd/workflows/3-technical/game-architecture/workflow.yaml"
description: Produce a Scale Adaptive Game Architecture

View File

@ -2,11 +2,11 @@
agent:
metadata:
id: bmad/bmm/agents/game-designer.md
id: bmad/bmgd/agents/game-designer.md
name: Samus Shepard
title: Game Designer
icon: 🎲
module: bmm
module: bmgd
persona:
role: Lead Game Designer + Creative Vision Architect
@ -18,30 +18,18 @@ agent:
- Design is about making meaningful choices matter, creating moments of mastery, and respecting player time while delivering compelling challenge.
menu:
- trigger: workflow-init
workflow: "{project-root}/bmad/bmm/workflows/workflow-status/init/workflow.yaml"
description: Start a new sequenced workflow path
- trigger: workflow-status
workflow: "{project-root}/bmad/bmm/workflows/workflow-status/workflow.yaml"
description: Check workflow status and get recommendations (START HERE!)
- trigger: brainstorm-game
workflow: "{project-root}/bmad/bmm/workflows/1-analysis/brainstorm-game/workflow.yaml"
description: Guide me through Game Brainstorming
workflow: "{project-root}/bmad/bmgd/workflows/1-preproduction/brainstorm-game/workflow.yaml"
description: 1. Guide me through Game Brainstorming
- trigger: create-game-brief
workflow: "{project-root}/bmad/bmm/workflows/1-analysis/game-brief/workflow.yaml"
description: Create Game Brief
workflow: "{project-root}/bmad/bmgd/workflows/1-preproduction/game-brief/workflow.yaml"
description: 3. Create Game Brief
- trigger: create-gdd
workflow: "{project-root}/bmad/bmm/workflows/2-plan-workflows/gdd/workflow.yaml"
description: Create Game Design Document (GDD)
workflow: "{project-root}/bmad/bmgd/workflows/2-design/gdd/workflow.yaml"
description: 4. 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
workflow: "{project-root}/bmad/bmgd/workflows/2-design/narrative/workflow.yaml"
description: 5. Create Narrative Design Document (story-driven games)

View File

@ -2,11 +2,11 @@
agent:
metadata:
id: bmad/bmm/agents/game-dev.md
id: bmad/bmgd/agents/game-dev.md
name: Link Freeman
title: Game Developer
icon: 🕹️
module: bmm
module: bmgd
persona:
role: Senior Game Developer + Technical Implementation Specialist
@ -18,18 +18,17 @@ agent:
- Clean architecture enables creativity - messy code kills innovation. Ship early, ship often, iterate based on player feedback.
menu:
- trigger: workflow-status
workflow: "{project-root}/bmad/bmm/workflows/workflow-status/workflow.yaml"
description: "Check workflow status and get recommendations"
- trigger: develop-story
workflow: "{project-root}/bmad/bmm/workflows/4-implementation/dev-story/workflow.yaml"
workflow-install: "{project-root}/bmad/bmgd/workflows/4-production/dev-story/workflow.yaml"
description: "Execute Dev Story workflow, implementing tasks and tests, or performing updates to the story"
- trigger: story-done
workflow: "{project-root}/bmad/bmm/workflows/4-implementation/story-done/workflow.yaml"
description: "Mark story done after DoD complete"
- trigger: code-review
workflow: "{project-root}/bmad/bmm/workflows/4-implementation/code-review/workflow.yaml"
workflow-install: "{project-root}/bmad/bmgd/workflows/4-production/code-review/workflow.yaml"
description: "Perform a thorough clean context QA code review on a story flagged Ready for Review"
- trigger: story-done
workflow: "{project-root}/bmad/bmm/workflows/4-implementation/story-done/workflow.yaml"
workflow-install: "{project-root}/bmad/bmgd/workflows/4-production/story-done/workflow.yaml"
description: "Mark story done after DoD complete"

View File

@ -0,0 +1,70 @@
# Game Dev Scrum Master Agent Definition
agent:
metadata:
id: bmad/bmgd/agents/game-scrum-master.md
name: Max
title: Game Dev Scrum Master
icon: 🎯
module: bmgd
persona:
role: Game Development Scrum Master + Sprint Orchestrator
identity: Certified Scrum Master specializing in game development workflows. Expert in agile game development, story preparation for game features, and coordinating multi-disciplinary game teams (designers, developers, artists). Experienced in managing sprints across all game development phases from preproduction through production. Skilled at translating game design documents into actionable development stories.
communication_style: Energetic and milestone-focused. I speak in game dev terminology and celebrate hitting development milestones like hitting save points in a tough level. Clear handoffs and structured preparation are my special abilities. I keep the team moving forward through each phase of development.
principles:
- I maintain clean separation between design specification and implementation, ensuring GDDs and Tech Specs flow smoothly into developer-ready user stories that capture the essence of gameplay features.
- My commitment to iterative development means every sprint delivers playable increments, enabling rapid playtesting and feedback loops that keep the game fun.
- I coordinate across disciplines - ensuring designers, developers, and architects are aligned on feature implementation and technical approach.
critical_actions:
- "When running *create-story for game features, use GDD, Architecture, and Tech Spec to generate complete draft stories without elicitation, focusing on playable outcomes."
menu:
- trigger: sprint-planning
workflow: "{project-root}/bmad/bmm/workflows/4-implementation/sprint-planning/workflow.yaml"
workflow-install: "{project-root}/bmad/bmgd/workflows/4-production/sprint-planning/workflow.yaml"
description: Generate or update sprint-status.yaml from epic files
- trigger: epic-tech-context
workflow: "{project-root}/bmad/bmm/workflows/4-implementation/epic-tech-context/workflow.yaml"
workflow-install: "{project-root}/bmad/bmgd/workflows/4-production/epic-tech-context/workflow.yaml"
description: (Optional) Use the GDD and Architecture to create an Epic-Tech-Spec for a specific epic
- trigger: validate-epic-tech-context
validate-workflow: "{project-root}/bmad/bmgd/workflows/4-production/epic-tech-context/workflow.yaml"
description: (Optional) Validate latest Tech Spec against checklist
- trigger: create-story-draft
workflow: "{project-root}/bmad/bmm/workflows/4-implementation/create-story/workflow.yaml"
workflow-install: "{project-root}/bmad/bmgd/workflows/4-production/create-story/workflow.yaml"
description: Create a Story Draft for a game feature
- trigger: validate-create-story
validate-workflow: "{project-root}/bmad/bmgd/workflows/4-production/create-story/workflow.yaml"
description: (Optional) Validate Story Draft with Independent Review
- trigger: story-context
workflow: "{project-root}/bmad/bmm/workflows/4-implementation/story-context/workflow.yaml"
workflow-install: "{project-root}/bmad/bmgd/workflows/4-production/story-context/workflow.yaml"
description: (Optional) Assemble dynamic Story Context (XML) from latest docs and code and mark story ready for dev
- trigger: validate-story-context
validate-workflow: "{project-root}/bmad/bmgd/workflows/4-production/story-context/workflow.yaml"
description: (Optional) Validate latest Story Context XML against checklist
- trigger: story-ready-for-dev
workflow: "{project-root}/bmad/bmm/workflows/4-implementation/story-ready/workflow.yaml"
workflow-install: "{project-root}/bmad/bmgd/workflows/4-production/story-ready/workflow.yaml"
description: (Optional) Mark drafted story ready for dev without generating Story Context
- trigger: epic-retrospective
workflow: "{project-root}/bmad/bmm/workflows/4-implementation/retrospective/workflow.yaml"
workflow-install: "{project-root}/bmad/bmgd/workflows/4-production/retrospective/workflow.yaml"
data: "{project-root}/bmad/_cfg/agent-manifest.csv"
description: (Optional) Facilitate team retrospective after a game development epic is completed
- trigger: correct-course
workflow: "{project-root}/bmad/bmm/workflows/4-implementation/correct-course/workflow.yaml"
workflow-install: "{project-root}/bmad/bmgd/workflows/4-production/correct-course/workflow.yaml"
description: (Optional) Navigate significant changes during game dev sprint

View File

@ -2,13 +2,15 @@
bundle:
name: Team Game Development
icon: 🎮
description: Specialized game development team including Game Designer (creative vision and GDD), Game Developer (implementation and code), and Game Architect (technical systems and infrastructure). Perfect for game projects across all scales and platforms.
description: Specialized game development team including Game Designer (creative vision and GDD), Game Developer (implementation and code), Game Architect (technical systems and infrastructure), and Game Dev Scrum Master (sprint coordination). Perfect for game projects across all scales and platforms.
agents:
- game-designer
- game-dev
- game-architect
- game-scrum-master
workflows:
- brainstorm-game
- game-brief
- gdd
- narrative

View File

@ -4,16 +4,16 @@ description: "Facilitate game brainstorming sessions by orchestrating the CIS br
author: "BMad"
# Critical variables from config
config_source: "{project-root}/bmad/bmm/config.yaml"
config_source: "{project-root}/bmad/bmgd/config.yaml"
output_folder: "{config_source}:output_folder"
user_name: "{config_source}:user_name"
communication_language: "{config_source}:communication_language"
document_output_language: "{config_source}:document_output_language"
user_skill_level: "{config_source}:user_skill_level"
game_dev_experience: "{config_source}:game_dev_experience"
date: system-generated
# Module path and component files
installed_path: "{project-root}/bmad/bmm/workflows/1-analysis/brainstorm-game"
installed_path: "{project-root}/bmad/bmgd/workflows/1-preproduction/brainstorm-game"
template: false
instructions: "{installed_path}/instructions.md"
@ -30,12 +30,12 @@ web_bundle:
name: "brainstorm-game"
description: "Facilitate game brainstorming sessions by orchestrating the CIS brainstorming workflow with game-specific context, guidance, and additional game design techniques."
author: "BMad"
instructions: "bmad/bmm/workflows/1-analysis/brainstorm-game/instructions.md"
instructions: "bmad/bmgd/workflows/1-preproduction/brainstorm-game/instructions.md"
template: false
web_bundle_files:
- "bmad/bmm/workflows/1-analysis/brainstorm-game/instructions.md"
- "bmad/bmm/workflows/1-analysis/brainstorm-game/game-context.md"
- "bmad/bmm/workflows/1-analysis/brainstorm-game/game-brain-methods.csv"
- "bmad/bmgd/workflows/1-preproduction/brainstorm-game/instructions.md"
- "bmad/bmgd/workflows/1-preproduction/brainstorm-game/game-context.md"
- "bmad/bmgd/workflows/1-preproduction/brainstorm-game/game-brain-methods.csv"
- "bmad/core/workflows/brainstorming/workflow.yaml"
existing_workflows:
- core_brainstorming: "bmad/core/workflows/brainstorming/workflow.yaml"

View File

@ -4,12 +4,12 @@ description: "Interactive game brief creation workflow that guides users through
author: "BMad"
# Critical variables from config
config_source: "{project-root}/bmad/bmm/config.yaml"
config_source: "{project-root}/bmad/bmgd/config.yaml"
output_folder: "{config_source}:output_folder"
user_name: "{config_source}:user_name"
communication_language: "{config_source}:communication_language"
document_output_language: "{config_source}:document_output_language"
user_skill_level: "{config_source}:user_skill_level"
game_dev_experience: "{config_source}:game_dev_experience"
date: system-generated
# Optional input documents
@ -21,7 +21,7 @@ recommended_inputs:
- reference_games: "List of inspiration games (optional)"
# Module path and component files
installed_path: "{project-root}/bmad/bmm/workflows/1-analysis/game-brief"
installed_path: "{project-root}/bmad/bmgd/workflows/1-preproduction/game-brief"
template: "{installed_path}/template.md"
instructions: "{installed_path}/instructions.md"
validation: "{installed_path}/checklist.md"
@ -35,10 +35,10 @@ web_bundle:
name: "game-brief"
description: "Interactive game brief creation workflow that guides users through defining their game vision with multiple input sources and conversational collaboration"
author: "BMad"
instructions: "bmad/bmm/workflows/1-analysis/game-brief/instructions.md"
validation: "bmad/bmm/workflows/1-analysis/game-brief/checklist.md"
template: "bmad/bmm/workflows/1-analysis/game-brief/template.md"
instructions: "bmad/bmgd/workflows/1-preproduction/game-brief/instructions.md"
validation: "bmad/bmgd/workflows/1-preproduction/game-brief/checklist.md"
template: "bmad/bmgd/workflows/1-preproduction/game-brief/template.md"
web_bundle_files:
- "bmad/bmm/workflows/1-analysis/game-brief/instructions.md"
- "bmad/bmm/workflows/1-analysis/game-brief/checklist.md"
- "bmad/bmm/workflows/1-analysis/game-brief/template.md"
- "bmad/bmgd/workflows/1-preproduction/game-brief/instructions.md"
- "bmad/bmgd/workflows/1-preproduction/game-brief/checklist.md"
- "bmad/bmgd/workflows/1-preproduction/game-brief/template.md"

View File

@ -0,0 +1,81 @@
# Game Design Document (GDD) Workflow
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"
# Critical variables from config
config_source: "{project-root}/bmad/bmgd/config.yaml"
output_folder: "{config_source}:output_folder"
user_name: "{config_source}:user_name"
communication_language: "{config_source}:communication_language"
document_output_language: "{config_source}:document_output_language"
game_dev_experience: "{config_source}:game_dev_experience"
date: system-generated
# Workflow components
installed_path: "{project-root}/bmad/bmgd/workflows/2-design/gdd"
instructions: "{installed_path}/instructions-gdd.md"
template: "{installed_path}/gdd-template.md"
game_types_csv: "{installed_path}/game-types.csv"
# Output configuration
default_output_file: "{output_folder}/GDD.md"
# Game type references (loaded based on game type selection)
game_type_guides: "{installed_path}/game-types/"
# Recommended input documents
recommended_inputs:
- game_brief: "{output_folder}/game-brief.md"
- narrative_design: "{output_folder}/narrative-design.md"
- market_research: "{output_folder}/market-research.md"
# Smart input file references - handles both whole docs and sharded docs
# Priority: Whole document first, then sharded version
input_file_patterns:
game_brief:
whole: "{output_folder}/*game-brief*.md"
sharded: "{output_folder}/*game-brief*/index.md"
research:
whole: "{output_folder}/*research*.md"
sharded: "{output_folder}/*research*/index.md"
document_project:
sharded: "{output_folder}/docs/index.md"
standalone: true
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/bmgd/workflows/2-design/gdd/instructions-gdd.md"
web_bundle_files:
- "bmad/bmgd/workflows/2-design/gdd/instructions-gdd.md"
- "bmad/bmgd/workflows/2-design/gdd/gdd-template.md"
- "bmad/bmgd/workflows/2-design/gdd/game-types.csv"
- "bmad/bmgd/workflows/2-design/gdd/game-types/action-platformer.md"
- "bmad/bmgd/workflows/2-design/gdd/game-types/adventure.md"
- "bmad/bmgd/workflows/2-design/gdd/game-types/card-game.md"
- "bmad/bmgd/workflows/2-design/gdd/game-types/fighting.md"
- "bmad/bmgd/workflows/2-design/gdd/game-types/horror.md"
- "bmad/bmgd/workflows/2-design/gdd/game-types/idle-incremental.md"
- "bmad/bmgd/workflows/2-design/gdd/game-types/metroidvania.md"
- "bmad/bmgd/workflows/2-design/gdd/game-types/moba.md"
- "bmad/bmgd/workflows/2-design/gdd/game-types/party-game.md"
- "bmad/bmgd/workflows/2-design/gdd/game-types/puzzle.md"
- "bmad/bmgd/workflows/2-design/gdd/game-types/racing.md"
- "bmad/bmgd/workflows/2-design/gdd/game-types/rhythm.md"
- "bmad/bmgd/workflows/2-design/gdd/game-types/roguelike.md"
- "bmad/bmgd/workflows/2-design/gdd/game-types/rpg.md"
- "bmad/bmgd/workflows/2-design/gdd/game-types/sandbox.md"
- "bmad/bmgd/workflows/2-design/gdd/game-types/shooter.md"
- "bmad/bmgd/workflows/2-design/gdd/game-types/simulation.md"
- "bmad/bmgd/workflows/2-design/gdd/game-types/sports.md"
- "bmad/bmgd/workflows/2-design/gdd/game-types/strategy.md"
- "bmad/bmgd/workflows/2-design/gdd/game-types/survival.md"
- "bmad/bmgd/workflows/2-design/gdd/game-types/text-based.md"
- "bmad/bmgd/workflows/2-design/gdd/game-types/tower-defense.md"
- "bmad/bmgd/workflows/2-design/gdd/game-types/turn-based-tactics.md"
- "bmad/bmgd/workflows/2-design/gdd/game-types/visual-novel.md"

View File

@ -4,16 +4,16 @@ description: "Narrative design workflow for story-driven games and applications.
author: "BMad"
# Critical variables from config
config_source: "{project-root}/bmad/bmm/config.yaml"
config_source: "{project-root}/bmad/bmgd/config.yaml"
output_folder: "{config_source}:output_folder"
user_name: "{config_source}:user_name"
communication_language: "{config_source}:communication_language"
document_output_language: "{config_source}:document_output_language"
user_skill_level: "{config_source}:user_skill_level"
game_dev_experience: "{config_source}:game_dev_experience"
date: system-generated
# Workflow components
installed_path: "{project-root}/bmad/bmm/workflows/2-plan-workflows/narrative"
installed_path: "{project-root}/bmad/bmgd/workflows/2-design/narrative"
instructions: "{installed_path}/instructions-narrative.md"
template: "{installed_path}/narrative-template.md"
@ -32,7 +32,7 @@ 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-workflows/narrative/instructions-narrative.md"
instructions: "bmad/bmgd/workflows/2-design/narrative/instructions-narrative.md"
web_bundle_files:
- "bmad/bmm/workflows/2-plan-workflows/narrative/instructions-narrative.md"
- "bmad/bmm/workflows/2-plan-workflows/narrative/narrative-template.md"
- "bmad/bmgd/workflows/2-design/narrative/instructions-narrative.md"
- "bmad/bmgd/workflows/2-design/narrative/narrative-template.md"

View File

@ -0,0 +1,347 @@
# Architecture Patterns - Common patterns identified from requirements
requirement_patterns:
realtime_collaboration:
triggers:
- "real-time"
- "collaborative"
- "live updates"
- "multi-user"
- "simultaneous editing"
decisions_needed:
- websocket_solution
- conflict_resolution
- state_synchronization
- presence_tracking
- optimistic_updates
suggested_stack:
- "Socket.io or WebSocket native"
- "Redis for pub/sub"
- "Operational Transforms or CRDTs for conflict resolution"
- "PostgreSQL for persistence"
ecommerce:
triggers:
- "shopping cart"
- "checkout"
- "payments"
- "inventory"
- "product catalog"
decisions_needed:
- payment_processor
- cart_persistence
- inventory_management
- order_workflow
- tax_calculation
suggested_stack:
- "Stripe or PayPal for payments"
- "PostgreSQL for products and orders"
- "Redis for cart sessions"
- "BullMQ for order processing"
saas_platform:
triggers:
- "multi-tenant"
- "subscription"
- "billing"
- "team management"
- "roles and permissions"
decisions_needed:
- tenancy_model
- subscription_billing
- permission_system
- team_collaboration
- usage_tracking
suggested_stack:
- "PostgreSQL with Row Level Security"
- "Stripe Billing for subscriptions"
- "RBAC or ABAC for permissions"
- "NextAuth or Clerk for auth"
content_platform:
triggers:
- "CMS"
- "blog"
- "publishing"
- "content management"
- "editorial workflow"
decisions_needed:
- content_storage
- rich_text_editor
- media_handling
- version_control
- publishing_workflow
suggested_stack:
- "PostgreSQL for structured content"
- "S3 or Cloudinary for media"
- "Tiptap or Slate for rich text"
- "Algolia for search"
data_analytics:
triggers:
- "dashboards"
- "reporting"
- "metrics"
- "analytics"
- "data visualization"
decisions_needed:
- data_warehouse
- etl_pipeline
- visualization_library
- query_optimization
- caching_strategy
suggested_stack:
- "PostgreSQL or ClickHouse"
- "Apache Airflow or Temporal for ETL"
- "Chart.js or D3 for visualization"
- "Redis for query caching"
social_platform:
triggers:
- "social network"
- "feed"
- "following"
- "likes"
- "comments"
decisions_needed:
- graph_relationships
- feed_algorithm
- notification_system
- content_moderation
- privacy_controls
suggested_stack:
- "PostgreSQL with graph extensions or Neo4j"
- "Redis for feed caching"
- "Elasticsearch for user search"
- "WebSockets for notifications"
marketplace:
triggers:
- "marketplace"
- "vendors"
- "buyers and sellers"
- "transactions"
- "escrow"
decisions_needed:
- payment_splitting
- escrow_handling
- vendor_management
- dispute_resolution
- commission_model
suggested_stack:
- "Stripe Connect for payments"
- "PostgreSQL for transactions"
- "BullMQ for async processing"
- "S3 for vendor assets"
streaming_platform:
triggers:
- "video streaming"
- "live streaming"
- "media delivery"
- "broadcast"
decisions_needed:
- video_encoding
- cdn_strategy
- streaming_protocol
- bandwidth_optimization
- drm_protection
suggested_stack:
- "AWS MediaConvert or Mux"
- "CloudFront or Fastly CDN"
- "HLS or DASH protocol"
- "S3 for video storage"
iot_platform:
triggers:
- "IoT"
- "sensors"
- "device management"
- "telemetry"
- "edge computing"
decisions_needed:
- message_protocol
- time_series_database
- device_authentication
- data_ingestion
- edge_processing
suggested_stack:
- "MQTT or CoAP protocol"
- "TimescaleDB or InfluxDB"
- "Apache Kafka for ingestion"
- "Grafana for monitoring"
ai_application:
triggers:
- "machine learning"
- "AI features"
- "LLM integration"
- "computer vision"
- "NLP"
decisions_needed:
- model_serving
- vector_database
- prompt_management
- token_optimization
- fallback_strategy
suggested_stack:
- "OpenAI or Anthropic API"
- "Pinecone or pgvector for embeddings"
- "Redis for prompt caching"
- "Langchain or LlamaIndex"
# Quality attribute patterns
quality_attributes:
high_availability:
triggers:
- "99.9% uptime"
- "high availability"
- "fault tolerance"
- "disaster recovery"
architectural_needs:
- load_balancing
- database_replication
- health_checks
- circuit_breakers
- graceful_degradation
high_performance:
triggers:
- "millisecond response"
- "high throughput"
- "low latency"
- "performance critical"
architectural_needs:
- caching_layers
- database_optimization
- cdn_strategy
- code_splitting
- lazy_loading
high_security:
triggers:
- "compliance"
- "HIPAA"
- "GDPR"
- "financial data"
- "PCI DSS"
architectural_needs:
- encryption_at_rest
- encryption_in_transit
- audit_logging
- access_controls
- data_isolation
scalability:
triggers:
- "millions of users"
- "elastic scale"
- "global reach"
- "viral growth"
architectural_needs:
- horizontal_scaling
- database_sharding
- microservices
- queue_systems
- auto_scaling
# Integration patterns
integration_requirements:
payment_processing:
common_choices:
- "Stripe - most developer friendly"
- "PayPal - widest consumer adoption"
- "Square - best for in-person + online"
considerations:
- transaction_fees
- international_support
- subscription_handling
- marketplace_capabilities
email_service:
common_choices:
- "Resend - modern, developer friendly"
- "SendGrid - mature, scalable"
- "Amazon SES - cost effective at scale"
- "Postmark - transactional focus"
considerations:
- deliverability
- template_management
- analytics_needs
- cost_per_email
sms_notifications:
common_choices:
- "Twilio - most comprehensive"
- "Amazon SNS - AWS integrated"
- "Vonage - competitive pricing"
considerations:
- international_coverage
- delivery_rates
- two_way_messaging
- cost_per_message
authentication_providers:
social_providers:
- "Google - highest adoption"
- "GitHub - developer focused"
- "Microsoft - enterprise"
- "Apple - iOS users"
enterprise_providers:
- "SAML 2.0"
- "OAuth 2.0"
- "OpenID Connect"
- "Active Directory"
# Decision heuristics
decision_rules:
database_selection:
if_requirements_include:
- complex_relationships: "PostgreSQL"
- flexible_schema: "MongoDB"
- time_series: "TimescaleDB"
- graph_data: "Neo4j or PostgreSQL with extensions"
- key_value: "Redis"
- wide_column: "Cassandra"
api_pattern_selection:
if_requirements_include:
- simple_crud: "REST"
- complex_queries: "GraphQL"
- type_safety_critical: "tRPC"
- microservices: "gRPC"
- public_api: "REST with OpenAPI"
deployment_selection:
if_requirements_include:
- nextjs_only: "Vercel"
- complex_infrastructure: "AWS"
- quick_prototype: "Railway"
- global_edge: "Fly.io"
- kubernetes_needed: "GCP or AWS EKS"
# Anti-patterns to avoid
anti_patterns:
overengineering:
signs:
- "Microservices for < 10k users"
- "Kubernetes for single app"
- "GraphQL for 5 endpoints"
- "Event sourcing for CRUD app"
recommendation: "Start simple, evolve as needed"
underengineering:
signs:
- "No authentication strategy"
- "No error handling plan"
- "No monitoring approach"
- "No backup strategy"
recommendation: "Cover the fundamentals"
technology_soup:
signs:
- "5+ different databases"
- "Multiple frontend frameworks"
- "Inconsistent patterns"
- "Too many languages"
recommendation: "Maintain consistency"

View File

@ -0,0 +1,103 @@
# Architecture
## Executive Summary
{{executive_summary}}
{{project_initialization_section}}
## Decision Summary
| Category | Decision | Version | Affects Epics | Rationale |
| -------- | -------- | ------- | ------------- | --------- |
{{decision_table_rows}}
## Project Structure
```
{{project_root}}/
{{source_tree}}
```
## Epic to Architecture Mapping
{{epic_mapping_table}}
## Technology Stack Details
### Core Technologies
{{core_stack_details}}
### Integration Points
{{integration_details}}
{{novel_pattern_designs_section}}
## Implementation Patterns
These patterns ensure consistent implementation across all AI agents:
{{implementation_patterns}}
## Consistency Rules
### Naming Conventions
{{naming_conventions}}
### Code Organization
{{code_organization_patterns}}
### Error Handling
{{error_handling_approach}}
### Logging Strategy
{{logging_approach}}
## Data Architecture
{{data_models_and_relationships}}
## API Contracts
{{api_specifications}}
## Security Architecture
{{security_approach}}
## Performance Considerations
{{performance_strategies}}
## Deployment Architecture
{{deployment_approach}}
## Development Environment
### Prerequisites
{{development_prerequisites}}
### Setup Commands
```bash
{{setup_commands}}
```
## Architecture Decision Records (ADRs)
{{key_architecture_decisions}}
---
_Generated by BMAD Decision Architecture Workflow v1.0_
_Date: {{date}}_
_For: {{user_name}}_

View File

@ -0,0 +1,244 @@
# Architecture Document Validation Checklist
**Purpose**: Validate the architecture document itself is complete, implementable, and provides clear guidance for AI agents.
**Note**: This checklist validates the ARCHITECTURE DOCUMENT only. For cross-workflow validation (PRD → Architecture → Stories alignment), use the solutioning-gate-check workflow.
---
## 1. Decision Completeness
### All Decisions Made
- [ ] Every critical decision category has been resolved
- [ ] All important decision categories addressed
- [ ] No placeholder text like "TBD", "[choose]", or "{TODO}" remains
- [ ] Optional decisions either resolved or explicitly deferred with rationale
### Decision Coverage
- [ ] Data persistence approach decided
- [ ] API pattern chosen
- [ ] Authentication/authorization strategy defined
- [ ] Deployment target selected
- [ ] All functional requirements have architectural support
---
## 2. Version Specificity
### Technology Versions
- [ ] Every technology choice includes a specific version number
- [ ] Version numbers are current (verified via WebSearch, not hardcoded)
- [ ] Compatible versions selected (e.g., Node.js version supports chosen packages)
- [ ] Verification dates noted for version checks
### Version Verification Process
- [ ] WebSearch used during workflow to verify current versions
- [ ] No hardcoded versions from decision catalog trusted without verification
- [ ] LTS vs. latest versions considered and documented
- [ ] Breaking changes between versions noted if relevant
---
## 3. Starter Template Integration (if applicable)
### Template Selection
- [ ] Starter template chosen (or "from scratch" decision documented)
- [ ] Project initialization command documented with exact flags
- [ ] Starter template version is current and specified
- [ ] Command search term provided for verification
### Starter-Provided Decisions
- [ ] Decisions provided by starter marked as "PROVIDED BY STARTER"
- [ ] List of what starter provides is complete
- [ ] Remaining decisions (not covered by starter) clearly identified
- [ ] No duplicate decisions that starter already makes
---
## 4. Novel Pattern Design (if applicable)
### Pattern Detection
- [ ] All unique/novel concepts from PRD identified
- [ ] Patterns that don't have standard solutions documented
- [ ] Multi-epic workflows requiring custom design captured
### Pattern Documentation Quality
- [ ] Pattern name and purpose clearly defined
- [ ] Component interactions specified
- [ ] Data flow documented (with sequence diagrams if complex)
- [ ] Implementation guide provided for agents
- [ ] Edge cases and failure modes considered
- [ ] States and transitions clearly defined
### Pattern Implementability
- [ ] Pattern is implementable by AI agents with provided guidance
- [ ] No ambiguous decisions that could be interpreted differently
- [ ] Clear boundaries between components
- [ ] Explicit integration points with standard patterns
---
## 5. Implementation Patterns
### Pattern Categories Coverage
- [ ] **Naming Patterns**: API routes, database tables, components, files
- [ ] **Structure Patterns**: Test organization, component organization, shared utilities
- [ ] **Format Patterns**: API responses, error formats, date handling
- [ ] **Communication Patterns**: Events, state updates, inter-component messaging
- [ ] **Lifecycle Patterns**: Loading states, error recovery, retry logic
- [ ] **Location Patterns**: URL structure, asset organization, config placement
- [ ] **Consistency Patterns**: UI date formats, logging, user-facing errors
### Pattern Quality
- [ ] Each pattern has concrete examples
- [ ] Conventions are unambiguous (agents can't interpret differently)
- [ ] Patterns cover all technologies in the stack
- [ ] No gaps where agents would have to guess
- [ ] Implementation patterns don't conflict with each other
---
## 6. Technology Compatibility
### Stack Coherence
- [ ] Database choice compatible with ORM choice
- [ ] Frontend framework compatible with deployment target
- [ ] Authentication solution works with chosen frontend/backend
- [ ] All API patterns consistent (not mixing REST and GraphQL for same data)
- [ ] Starter template compatible with additional choices
### Integration Compatibility
- [ ] Third-party services compatible with chosen stack
- [ ] Real-time solutions (if any) work with deployment target
- [ ] File storage solution integrates with framework
- [ ] Background job system compatible with infrastructure
---
## 7. Document Structure
### Required Sections Present
- [ ] Executive summary exists (2-3 sentences maximum)
- [ ] Project initialization section (if using starter template)
- [ ] Decision summary table with ALL required columns:
- Category
- Decision
- Version
- Rationale
- [ ] Project structure section shows complete source tree
- [ ] Implementation patterns section comprehensive
- [ ] Novel patterns section (if applicable)
### Document Quality
- [ ] Source tree reflects actual technology decisions (not generic)
- [ ] Technical language used consistently
- [ ] Tables used instead of prose where appropriate
- [ ] No unnecessary explanations or justifications
- [ ] Focused on WHAT and HOW, not WHY (rationale is brief)
---
## 8. AI Agent Clarity
### Clear Guidance for Agents
- [ ] No ambiguous decisions that agents could interpret differently
- [ ] Clear boundaries between components/modules
- [ ] Explicit file organization patterns
- [ ] Defined patterns for common operations (CRUD, auth checks, etc.)
- [ ] Novel patterns have clear implementation guidance
- [ ] Document provides clear constraints for agents
- [ ] No conflicting guidance present
### Implementation Readiness
- [ ] Sufficient detail for agents to implement without guessing
- [ ] File paths and naming conventions explicit
- [ ] Integration points clearly defined
- [ ] Error handling patterns specified
- [ ] Testing patterns documented
---
## 9. Practical Considerations
### Technology Viability
- [ ] Chosen stack has good documentation and community support
- [ ] Development environment can be set up with specified versions
- [ ] No experimental or alpha technologies for critical path
- [ ] Deployment target supports all chosen technologies
- [ ] Starter template (if used) is stable and well-maintained
### Scalability
- [ ] Architecture can handle expected user load
- [ ] Data model supports expected growth
- [ ] Caching strategy defined if performance is critical
- [ ] Background job processing defined if async work needed
- [ ] Novel patterns scalable for production use
---
## 10. Common Issues to Check
### Beginner Protection
- [ ] Not overengineered for actual requirements
- [ ] Standard patterns used where possible (starter templates leveraged)
- [ ] Complex technologies justified by specific needs
- [ ] Maintenance complexity appropriate for team size
### Expert Validation
- [ ] No obvious anti-patterns present
- [ ] Performance bottlenecks addressed
- [ ] Security best practices followed
- [ ] Future migration paths not blocked
- [ ] Novel patterns follow architectural principles
---
## Validation Summary
### Document Quality Score
- Architecture Completeness: [Complete / Mostly Complete / Partial / Incomplete]
- Version Specificity: [All Verified / Most Verified / Some Missing / Many Missing]
- Pattern Clarity: [Crystal Clear / Clear / Somewhat Ambiguous / Ambiguous]
- AI Agent Readiness: [Ready / Mostly Ready / Needs Work / Not Ready]
### Critical Issues Found
- [ ] Issue 1: **\*\***\_\_\_**\*\***
- [ ] Issue 2: **\*\***\_\_\_**\*\***
- [ ] Issue 3: **\*\***\_\_\_**\*\***
### Recommended Actions Before Implementation
1. ***
2. ***
3. ***
---
**Next Step**: Run the **solutioning-gate-check** workflow to validate alignment between PRD, Architecture, and Stories before beginning implementation.
---
_This checklist validates architecture document quality only. Use solutioning-gate-check for comprehensive readiness validation._

View File

@ -0,0 +1,222 @@
# Decision Catalog - Composability knowledge for architectural decisions
# This provides RELATIONSHIPS and WORKFLOW LOGIC, not generic tech knowledge
#
# ⚠️ CRITICAL: All version/feature info MUST be verified via WebSearch during workflow
# This file only provides: triggers, relationships (pairs_with), and opinionated stacks
decision_categories:
data_persistence:
triggers: ["database", "storage", "data model", "persistence", "state management"]
importance: "critical"
affects: "most epics"
options:
postgresql:
pairs_with: ["Prisma ORM", "TypeORM", "Drizzle", "node-postgres"]
mongodb:
pairs_with: ["Mongoose", "Prisma", "MongoDB driver"]
redis:
pairs_with: ["ioredis", "node-redis"]
supabase:
pairs_with: ["@supabase/supabase-js"]
firebase:
pairs_with: ["firebase-admin"]
api_pattern:
triggers: ["API", "client communication", "frontend backend", "service communication"]
importance: "critical"
affects: "all client-facing epics"
options:
rest:
pairs_with: ["Express", "Fastify", "NestJS", "Hono"]
graphql:
pairs_with: ["Apollo Server", "GraphQL Yoga", "Mercurius"]
trpc:
pairs_with: ["Next.js", "React Query"]
grpc:
pairs_with: ["@grpc/grpc-js", "protobufjs"]
authentication:
triggers: ["auth", "login", "user management", "security", "identity"]
importance: "critical"
affects: "security and user epics"
options:
nextauth:
pairs_with: ["Next.js", "Prisma"]
auth0:
pairs_with: ["@auth0/nextjs-auth0"]
clerk:
pairs_with: ["@clerk/nextjs"]
supabase_auth:
pairs_with: ["@supabase/supabase-js"]
firebase_auth:
pairs_with: ["firebase-admin"]
real_time:
triggers: ["real-time", "websocket", "live updates", "chat", "collaboration"]
importance: "medium"
affects: "real-time features"
options:
socket_io:
pairs_with: ["Express", "socket.io-client"]
pusher:
pairs_with: ["pusher-js"]
ably:
pairs_with: ["ably"]
supabase_realtime:
pairs_with: ["@supabase/supabase-js"]
firebase_realtime:
pairs_with: ["firebase"]
email:
triggers: ["email", "notifications", "transactional email"]
importance: "medium"
affects: "notification epics"
options:
resend:
pairs_with: ["resend", "react-email"]
sendgrid:
pairs_with: ["@sendgrid/mail"]
postmark:
pairs_with: ["postmark"]
ses:
pairs_with: ["@aws-sdk/client-ses"]
file_storage:
triggers: ["upload", "file storage", "images", "media", "CDN"]
importance: "medium"
affects: "media handling epics"
options:
s3:
pairs_with: ["@aws-sdk/client-s3", "multer"]
cloudinary:
pairs_with: ["cloudinary"]
uploadthing:
pairs_with: ["uploadthing"]
supabase_storage:
pairs_with: ["@supabase/supabase-js"]
search:
triggers: ["search", "full text", "elasticsearch", "algolia", "fuzzy"]
importance: "medium"
affects: "search and discovery epics"
options:
postgres_fts:
pairs_with: ["PostgreSQL"]
elasticsearch:
pairs_with: ["@elastic/elasticsearch"]
algolia:
pairs_with: ["algoliasearch"]
typesense:
pairs_with: ["typesense"]
background_jobs:
triggers: ["queue", "jobs", "workers", "async", "background processing", "scheduled"]
importance: "medium"
affects: "async processing epics"
options:
bullmq:
pairs_with: ["Redis"]
sqs:
pairs_with: ["@aws-sdk/client-sqs"]
temporal:
pairs_with: ["@temporalio/client"]
inngest:
pairs_with: ["inngest"]
deployment_target:
triggers: ["deployment", "hosting", "infrastructure", "cloud", "server"]
importance: "high"
affects: "all epics"
options:
vercel:
pairs_with: ["Next.js", "serverless functions"]
aws:
pairs_with: ["any stack"]
railway:
pairs_with: ["any stack", "managed databases"]
fly_io:
pairs_with: ["Docker containers"]
# Opinionated stack combinations (BMM methodology)
common_stacks:
modern_fullstack:
name: "Modern Full-Stack"
components: ["Next.js", "PostgreSQL or Supabase", "Prisma ORM", "NextAuth.js", "Tailwind CSS", "TypeScript", "Vercel"]
good_for: "Most web applications"
enterprise_stack:
name: "Enterprise Stack"
components: ["NestJS", "PostgreSQL", "TypeORM", "Auth0", "Redis", "Docker", "AWS"]
good_for: "Large-scale enterprise applications"
rapid_prototype:
name: "Rapid Prototype"
components: ["Next.js", "Supabase", "shadcn/ui", "Vercel"]
good_for: "MVP and rapid development"
real_time_app:
name: "Real-Time Application"
components: ["Next.js", "Supabase Realtime", "PostgreSQL", "Prisma", "Socket.io fallback"]
good_for: "Chat, collaboration, live updates"
mobile_app:
name: "Mobile Application"
components: ["Expo", "React Native", "Supabase or Firebase", "React Query"]
good_for: "Cross-platform mobile apps"
# Starter templates and what decisions they make
starter_templates:
create_next_app:
name: "Create Next App"
command_search: "npx create-next-app@latest"
decisions_provided: ["Next.js framework", "TypeScript option", "App Router vs Pages", "Tailwind CSS option", "ESLint"]
good_for: ["React web applications", "Full-stack apps", "SSR/SSG"]
create_t3_app:
name: "Create T3 App"
command_search: "npm create t3-app@latest"
decisions_provided: ["Next.js", "TypeScript", "tRPC", "Prisma", "NextAuth", "Tailwind CSS"]
good_for: ["Type-safe full-stack apps"]
create_vite:
name: "Create Vite"
command_search: "npm create vite@latest"
decisions_provided: ["Framework choice (React/Vue/Svelte)", "TypeScript option", "Vite bundler"]
good_for: ["Fast dev SPAs", "Library development"]
create_remix:
name: "Create Remix"
command_search: "npx create-remix@latest"
decisions_provided: ["Remix framework", "TypeScript option", "Deployment target", "CSS solution"]
good_for: ["Web standards", "Nested routing", "Progressive enhancement"]
nest_new:
name: "NestJS CLI"
command_search: "nest new project"
decisions_provided: ["TypeScript (always)", "Package manager", "Testing framework (Jest)", "Project structure"]
good_for: ["Enterprise APIs", "Microservices", "GraphQL APIs"]
create_expo_app:
name: "Create Expo App"
command_search: "npx create-expo-app"
decisions_provided: ["React Native", "Expo SDK", "TypeScript option", "Navigation option"]
good_for: ["Cross-platform mobile", "React Native apps"]
# Starter selection heuristics (workflow logic)
starter_selection_rules:
by_project_type:
web_application:
recommended: ["create_next_app", "create_t3_app", "create_vite"]
considerations: "SSR needs? → Next.js. Type safety critical? → T3. SPA only? → Vite"
mobile_app:
recommended: ["create_expo_app"]
considerations: "Cross-platform → Expo. Native-heavy → React Native CLI"
api_backend:
recommended: ["nest_new"]
considerations: "Enterprise → NestJS. Simple → Express starter. Performance → Fastify"
full_stack:
recommended: ["create_t3_app", "create_remix"]
considerations: "Type safety → T3. Web standards → Remix. Monolith → RedwoodJS"

View File

@ -0,0 +1,704 @@
# Decision Architecture Workflow Instructions
<workflow name="architecture">
<critical>The workflow execution engine is governed by: {project-root}/bmad/core/tasks/workflow.xml</critical>
<critical>You MUST have already loaded and processed: {installed_path}/workflow.yaml</critical>
<critical>This workflow uses ADAPTIVE FACILITATION - adjust your communication style based on {user_skill_level}</critical>
<critical>The goal is ARCHITECTURAL DECISIONS that prevent AI agent conflicts, not detailed implementation specs</critical>
<critical>Communicate all responses in {communication_language} and tailor to {user_skill_level}</critical>
<critical>Generate all documents in {document_output_language}</critical>
<critical>This workflow replaces architecture with a conversation-driven approach</critical>
<critical>Input documents specified in workflow.yaml input_file_patterns - workflow engine handles fuzzy matching, whole vs sharded document discovery automatically</critical>
<critical>ELICITATION POINTS: After completing each major architectural decision area (identified by template-output tags for decision_record, project_structure, novel_pattern_designs, implementation_patterns, and architecture_document), invoke advanced elicitation to refine decisions before proceeding</critical>
<step n="0" goal="Validate workflow readiness" tag="workflow-status">
<action>Check if {output_folder}/bmm-workflow-status.yaml exists</action>
<check if="status file not found">
<output>No workflow status file found. Decision Architecture can run standalone or as part of BMM workflow path.</output>
<output>**Recommended:** Run `workflow-init` first for project context tracking and workflow sequencing.</output>
<ask>Continue in standalone mode or exit to run workflow-init? (continue/exit)</ask>
<check if="continue">
<action>Set standalone_mode = true</action>
</check>
<check if="exit">
<action>Exit workflow</action>
</check>
</check>
<check if="status file found">
<action>Load the FULL file: {output_folder}/bmm-workflow-status.yaml</action>
<action>Parse workflow_status section</action>
<action>Check status of "create-architecture" workflow</action>
<action>Get project_level from YAML metadata</action>
<action>Find first non-completed workflow (next expected workflow)</action>
<check if="project_level < 3">
<output>**Note: Level {{project_level}} Project**
The Detailed Architecture is typically for Level 3-4 projects, but can be used for any project that needs architectural planning.
For Level {{project_level}}, we'll keep the architecture appropriately scoped.
</output>
</check>
<check if="create-architecture status is file path (already completed)">
<output>⚠️ Architecture already completed: {{create-architecture status}}</output>
<ask>Re-running will overwrite the existing architecture. Continue? (y/n)</ask>
<check if="n">
<output>Exiting. Use workflow-status to see your next step.</output>
<action>Exit workflow</action>
</check>
</check>
<check if="create-architecture is not the next expected workflow">
<output>⚠️ Next expected workflow: {{next_workflow}}. Architecture is out of sequence.</output>
<ask>Continue with Architecture anyway? (y/n)</ask>
<check if="n">
<output>Exiting. Run {{next_workflow}} instead.</output>
<action>Exit workflow</action>
</check>
</check>
<action>Set standalone_mode = false</action>
</check>
<action>Check for existing PRD and epics files using fuzzy matching</action>
<action>Fuzzy match PRD file: {prd_file}</action>
<check if="PRD_not_found">
<output>**PRD Not Found**
Decision Architecture works from your Product Requirements Document (PRD).
Looking for: _PRD_, PRD.md, or prd/index.md + files in {output_folder}
Please run the PRD workflow first to define your requirements.
Architect: `create-prd`
</output>
<action>Exit workflow - PRD required</action>
</check>
</step>
<step n="1" goal="Load and understand project context">
<action>Load the PRD using fuzzy matching: {prd_file}, if the PRD is mulitple files in a folder, load the index file and all files associated with the PRD</action>
<action>Load epics file using fuzzy matching: {epics_file}</action>
<action>Check for UX specification using fuzzy matching:
<action>Attempt to locate: {ux_spec_file}</action>
<check if="ux_spec_found">
<action>Load UX spec and extract architectural implications: - Component complexity (simple forms vs rich interactions) - Animation/transition requirements - Real-time update needs (live data, collaborative features) - Platform-specific UI requirements - Accessibility standards (WCAG compliance level) - Responsive design breakpoints - Offline capability requirements - Performance expectations (load times, interaction responsiveness)
</action>
</check>
</action>
<action>Extract and understand from PRD: - Functional Requirements (what it must do) - Non-Functional Requirements (performance, security, compliance, etc.) - Epic structure and user stories - Acceptance criteria - Any technical constraints mentioned
</action>
<action>Count and assess project scale: - Number of epics: {{epic_count}} - Number of stories: {{story_count}} - Complexity indicators (real-time, multi-tenant, regulated, etc.) - UX complexity level (if UX spec exists) - Novel features
</action>
<action>Reflect understanding back to {user_name}:
"I'm reviewing your project documentation for {{project_name}}.
I see {{epic_count}} epics with {{story_count}} total stories.
{{if_ux_spec}}I also found your UX specification which defines the user experience requirements.{{/if_ux_spec}}
Key aspects I notice:
- [Summarize core functionality]
- [Note critical NFRs]
{{if_ux_spec}}- [Note UX complexity and requirements]{{/if_ux_spec}}
- [Identify unique challenges]
This will help me guide you through the architectural decisions needed
to ensure AI agents implement this consistently."
</action>
<ask>Does this match your understanding of the project?</ask>
<template-output>project_context_understanding</template-output>
</step>
<step n="2" goal="Discover and evaluate starter templates">
<critical>Modern starter templates make many good architectural decisions by default</critical>
<action>Based on PRD analysis, identify the primary technology domain: - Web application → Look for Next.js, Vite, Remix starters - Mobile app → Look for React Native, Expo, Flutter starters - API/Backend → Look for NestJS, Express, Fastify starters - CLI tool → Look for CLI framework starters - Full-stack → Look for T3, RedwoodJS, Blitz starters
</action>
<check if="ux_spec_loaded">
<action>Consider UX requirements when selecting starter:
- Rich animations → Framer Motion compatible starter
- Complex forms → React Hook Form included starter
- Real-time features → Socket.io or WebSocket ready starter
- Accessibility focus → WCAG-compliant component library starter
- Design system → Storybook-enabled starter
</action>
</check>
<action>Search for relevant starter templates with websearch, examples:
<WebSearch>{{primary_technology}} starter template CLI create command latest {date}</WebSearch>
<WebSearch>{{primary_technology}} boilerplate generator latest options</WebSearch>
</action>
<check if="starter_templates_found">
<action>Investigate what each starter provides:
<WebSearch>{{starter_name}} default setup technologies included latest</WebSearch>
<WebSearch>{{starter_name}} project structure file organization</WebSearch>
</action>
<check if="{user_skill_level} == 'expert'">
<action>Present starter options concisely:
"Found {{starter_name}} which provides:
{{quick_decision_list}}
This would establish our base architecture. Use it?"
</action>
</check>
<check if="{user_skill_level} == 'beginner'">
<action>Explain starter benefits:
"I found {{starter_name}}, which is like a pre-built foundation for your project.
Think of it like buying a prefab house frame instead of cutting each board yourself.
It makes these decisions for you:
{{friendly_decision_list}}
This is a great starting point that follows best practices. Should we use it?"
</action>
</check>
<ask>Use {{starter_name}} as the foundation? (recommended) [y/n]</ask>
<check if="user_accepts_starter">
<action>Get current starter command and options:
<WebSearch>{{starter_name}} CLI command options flags latest 2024</WebSearch>
</action>
<action>Document the initialization command:
Store command: {{full_starter_command_with_options}}
Example: "npx create-next-app@latest my-app --typescript --tailwind --app"
</action>
<action>Extract and document starter-provided decisions:
Starter provides these architectural decisions:
- Language/TypeScript: {{provided_or_not}}
- Styling solution: {{provided_or_not}}
- Testing framework: {{provided_or_not}}
- Linting/Formatting: {{provided_or_not}}
- Build tooling: {{provided_or_not}}
- Project structure: {{provided_pattern}}
</action>
<action>Mark these decisions as "PROVIDED BY STARTER" in our decision tracking</action>
<action>Note for first implementation story:
"Project initialization using {{starter_command}} should be the first implementation story"
</action>
</check>
<check if="user_rejects_starter">
<ask>Any specific reason to avoid the starter? (helps me understand constraints)</ask>
<action>Note: Manual setup required, all decisions need to be made explicitly</action>
</check>
</check>
<check if="no_starter_found_or_applicable">
<action>Note: No standard starter template found for this project type.
We will make all architectural decisions explicitly.</action>
</check>
<template-output>starter_template_decision</template-output>
</step>
<step n="3" goal="Adapt facilitation style and identify remaining decisions">
<action>Based on {user_skill_level} from config, set facilitation approach:
<check if="{user_skill_level} == 'expert'">
Set mode: EXPERT
- Use technical terminology freely
- Move quickly through decisions
- Assume familiarity with patterns and tools
- Focus on edge cases and advanced concerns
</check>
<check if="{user_skill_level} == 'intermediate'">
Set mode: INTERMEDIATE
- Balance technical accuracy with clarity
- Explain complex patterns briefly
- Confirm understanding at key points
- Provide context for non-obvious choices
</check>
<check if="{user_skill_level} == 'beginner'">
Set mode: BEGINNER
- Use analogies and real-world examples
- Explain technical concepts in simple terms
- Provide education about why decisions matter
- Protect from complexity overload
</check>
</action>
<action>Load decision catalog: {decision_catalog}</action>
<action>Load architecture patterns: {architecture_patterns}</action>
<action>Analyze PRD against patterns to identify needed decisions: - Match functional requirements to known patterns - Identify which categories of decisions are needed - Flag any novel/unique aspects requiring special attention - Consider which decisions the starter template already made (if applicable)
</action>
<action>Create decision priority list:
CRITICAL (blocks everything): - {{list_of_critical_decisions}}
IMPORTANT (shapes architecture):
- {{list_of_important_decisions}}
NICE-TO-HAVE (can defer):
- {{list_of_optional_decisions}}
</action>
<action>Announce plan to {user_name} based on mode:
<check if="mode == 'EXPERT'">
"Based on your PRD, we need to make {{total_decision_count}} architectural decisions.
{{starter_covered_count}} are covered by the starter template.
Let's work through the remaining {{remaining_count}} decisions."
</check>
<check if="mode == 'BEGINNER'">
"Great! I've analyzed your requirements and found {{total_decision_count}} technical
choices we need to make. Don't worry - I'll guide you through each one and explain
why it matters. {{if_starter}}The starter template handles {{starter_covered_count}}
of these automatically.{{/if_starter}}"
</check>
</action>
<template-output>decision_identification</template-output>
</step>
<step n="4" goal="Facilitate collaborative decision making" repeat="for-each-decision">
<critical>Each decision must be made WITH the user, not FOR them</critical>
<critical>ALWAYS verify current versions using WebSearch - NEVER trust hardcoded versions</critical>
<action>For each decision in priority order:</action>
<action>Present the decision based on mode:
<check if="mode == 'EXPERT'">
"{{Decision_Category}}: {{Specific_Decision}}
Options: {{concise_option_list_with_tradeoffs}}
Recommendation: {{recommendation}} for {{reason}}"
</check>
<check if="mode == 'INTERMEDIATE'">
"Next decision: {{Human_Friendly_Category}}
We need to choose {{Specific_Decision}}.
Common options:
{{option_list_with_brief_explanations}}
For your project, {{recommendation}} would work well because {{reason}}."
</check>
<check if="mode == 'BEGINNER'">
"Let's talk about {{Human_Friendly_Category}}.
{{Educational_Context_About_Why_This_Matters}}
Think of it like {{real_world_analogy}}.
Your main options:
{{friendly_options_with_pros_cons}}
My suggestion: {{recommendation}}
This is good for you because {{beginner_friendly_reason}}."
</check>
</action>
<check if="decision_involves_specific_technology">
<action>Verify current stable version:
<WebSearch>{{technology}} latest stable version 2024</WebSearch>
<WebSearch>{{technology}} current LTS version</WebSearch>
</action>
<action>Update decision record with verified version:
Technology: {{technology}}
Verified Version: {{version_from_search}}
Verification Date: {{today}}
</action>
</check>
<ask>What's your preference? (or 'explain more' for details)</ask>
<check if="user_wants_more_info">
<action>Provide deeper explanation appropriate to skill level</action>
<check if="complex_tradeoffs">
<action>Consider using advanced elicitation:
"Would you like to explore innovative approaches to this decision?
I can help brainstorm unconventional solutions if you have specific goals."
</action>
</check>
</check>
<action>Record decision:
Category: {{category}}
Decision: {{user_choice}}
Version: {{verified_version_if_applicable}}
Affects Epics: {{list_of_affected_epics}}
Rationale: {{user_reasoning_or_default}}
Provided by Starter: {{yes_if_from_starter}}
</action>
<action>Check for cascading implications:
"This choice means we'll also need to {{related_decisions}}"
</action>
<template-output>decision_record</template-output>
<invoke-task halt="true">{project-root}/bmad/core/tasks/adv-elicit.xml</invoke-task>
</step>
<step n="5" goal="Address cross-cutting concerns">
<critical>These decisions affect EVERY epic and story</critical>
<action>Facilitate decisions for consistency patterns: - Error handling strategy (How will all agents handle errors?) - Logging approach (Structured? Format? Levels?) - Date/time handling (Timezone? Format? Library?) - Authentication pattern (Where? How? Token format?) - API response format (Structure? Status codes? Errors?) - Testing strategy (Unit? Integration? E2E?)
</action>
<check if="{user_skill_level} == 'beginner'">
<action>Explain why these matter why its critical to go through and decide these things now.</action>
</check>
<template-output>cross_cutting_decisions</template-output>
</step>
<step n="6" goal="Define project structure and boundaries">
<action>Based on all decisions made, define the project structure</action>
<action>Create comprehensive source tree: - Root configuration files - Source code organization - Test file locations - Build/dist directories - Documentation structure
</action>
<action>Map epics to architectural boundaries:
"Epic: {{epic_name}} → Lives in {{module/directory/service}}"
</action>
<action>Define integration points: - Where do components communicate? - What are the API boundaries? - How do services interact?
</action>
<template-output>project_structure</template-output>
<invoke-task halt="true">{project-root}/bmad/core/tasks/adv-elicit.xml</invoke-task>
</step>
<step n="7" goal="Design novel architectural patterns" optional="true">
<critical>Some projects require INVENTING new patterns, not just choosing existing ones</critical>
<action>Scan PRD for concepts that don't have standard solutions: - Novel interaction patterns (e.g., "swipe to match" before Tinder existed) - Unique multi-component workflows (e.g., "viral invitation system") - New data relationships (e.g., "social graph" before Facebook) - Unprecedented user experiences (e.g., "ephemeral messages" before Snapchat) - Complex state machines crossing multiple epics
</action>
<check if="novel_patterns_detected">
<action>For each novel pattern identified:</action>
<action>Engage user in design collaboration:
<check if="{user_skill_level} == 'expert'">
"The {{pattern_name}} concept requires architectural innovation.
Core challenge: {{challenge_description}}
Let's design the component interaction model:"
</check>
<check if="{user_skill_level} == 'beginner'">
"Your idea about {{pattern_name}} is unique - there isn't a standard way to build this yet!
This is exciting - we get to invent the architecture together.
Let me help you think through how this should work:"
</check>
</action>
<action>Facilitate pattern design:
1. Identify core components involved
2. Map data flow between components
3. Design state management approach
4. Create sequence diagrams for complex flows
5. Define API contracts for the pattern
6. Consider edge cases and failure modes
</action>
<action>Use advanced elicitation for innovation:
"What if we approached this differently?
- What would the ideal user experience look like?
- Are there analogies from other domains we could apply?
- What constraints can we challenge?"
</action>
<action>Document the novel pattern:
Pattern Name: {{pattern_name}}
Purpose: {{what_problem_it_solves}}
Components:
{{component_list_with_responsibilities}}
Data Flow:
{{sequence_description_or_diagram}}
Implementation Guide:
{{how_agents_should_build_this}}
Affects Epics:
{{epics_that_use_this_pattern}}
</action>
<action>Validate pattern completeness:
"Does this {{pattern_name}} design cover all the use cases in your epics?
- {{use_case_1}}: ✓ Handled by {{component}}
- {{use_case_2}}: ✓ Handled by {{component}}
..."
</action>
</check>
<check if="no_novel_patterns">
<action>Note: All patterns in this project have established solutions.
Proceeding with standard architectural patterns.</action>
</check>
<template-output>novel_pattern_designs</template-output>
<invoke-task halt="true">{project-root}/bmad/core/tasks/adv-elicit.xml</invoke-task>
</step>
<step n="8" goal="Define implementation patterns to prevent agent conflicts">
<critical>These patterns ensure multiple AI agents write compatible code</critical>
<critical>Focus on what agents could decide DIFFERENTLY if not specified</critical>
<action>Load pattern categories: {pattern_categories}</action>
<action>Based on chosen technologies, identify potential conflict points:
"Given that we're using {{tech_stack}}, agents need consistency rules for:"
</action>
<action>For each relevant pattern category, facilitate decisions:
NAMING PATTERNS (How things are named):
<check if="has_api">
- REST endpoint naming: /users or /user? Plural or singular?
- Route parameter format: :id or {id}?
</check>
<check if="has_database">
- Table naming: users or Users or user?
- Column naming: user_id or userId?
- Foreign key format: user_id or fk_user?
</check>
<check if="has_frontend">
- Component naming: UserCard or user-card?
- File naming: UserCard.tsx or user-card.tsx?
</check>
STRUCTURE PATTERNS (How things are organized):
- Where do tests live? __tests__/ or *.test.ts co-located?
- How are components organized? By feature or by type?
- Where do shared utilities go?
FORMAT PATTERNS (Data exchange formats):
<check if="has_api">
- API response wrapper? {data: ..., error: ...} or direct response?
- Error format? {message, code} or {error: {type, detail}}?
- Date format in JSON? ISO strings or timestamps?
</check>
COMMUNICATION PATTERNS (How components interact):
<check if="has_events">
- Event naming convention?
- Event payload structure?
</check>
<check if="has_state_management">
- State update pattern?
- Action naming convention?
</check>
LIFECYCLE PATTERNS (State and flow):
- How are loading states handled?
- What's the error recovery pattern?
- How are retries implemented?
LOCATION PATTERNS (Where things go):
- API route structure?
- Static asset organization?
- Config file locations?
CONSISTENCY PATTERNS (Cross-cutting):
- How are dates formatted in the UI?
- What's the logging format?
- How are user-facing errors written?
</action>
<check if="{user_skill_level} == 'expert'">
<action>Rapid-fire through patterns:
"Quick decisions on implementation patterns:
- {{pattern}}: {{suggested_convention}} OK? [y/n/specify]"
</action>
</check>
<check if="{user_skill_level} == 'beginner'">
<action>Explain each pattern's importance:
"Let me explain why this matters:
If one AI agent names database tables 'users' and another names them 'Users',
your app will crash. We need to pick one style and make sure everyone follows it."
</action>
</check>
<action>Document implementation patterns:
Category: {{pattern_category}}
Pattern: {{specific_pattern}}
Convention: {{decided_convention}}
Example: {{concrete_example}}
Enforcement: "All agents MUST follow this pattern"
</action>
<template-output>implementation_patterns</template-output>
<invoke-task halt="true">{project-root}/bmad/core/tasks/adv-elicit.xml</invoke-task>
</step>
<step n="9" goal="Validate architectural coherence">
<action>Run coherence checks:</action>
<action>Check decision compatibility: - Do all decisions work together? - Are there any conflicting choices? - Do the versions align properly?
</action>
<action>Verify epic coverage: - Does every epic have architectural support? - Are all user stories implementable with these decisions? - Are there any gaps?
</action>
<action>Validate pattern completeness: - Are there any patterns we missed that agents would need? - Do novel patterns integrate with standard architecture? - Are implementation patterns comprehensive enough?
</action>
<check if="issues_found">
<action>Address issues with {user_name}:
"I notice {{issue_description}}.
We should {{suggested_resolution}}."
</action>
<ask>How would you like to resolve this?</ask>
<action>Update decisions based on resolution</action>
</check>
<template-output>coherence_validation</template-output>
</step>
<step n="10" goal="Generate decision architecture document">
<critical>The document must be complete, specific, and validation-ready</critical>
<critical>This is the consistency contract for all AI agents</critical>
<action>Load template: {architecture_template}</action>
<action>Generate sections: 1. Executive Summary (2-3 sentences about the architecture approach) 2. Project Initialization (starter command if applicable) 3. Decision Summary Table (with verified versions and epic mapping) 4. Complete Project Structure (full tree, no placeholders) 5. Epic to Architecture Mapping (every epic placed) 6. Technology Stack Details (versions, configurations) 7. Integration Points (how components connect) 8. Novel Pattern Designs (if any were created) 9. Implementation Patterns (all consistency rules) 10. Consistency Rules (naming, organization, formats) 11. Data Architecture (models and relationships) 12. API Contracts (request/response formats) 13. Security Architecture (auth, authorization, data protection) 14. Performance Considerations (from NFRs) 15. Deployment Architecture (where and how) 16. Development Environment (setup and prerequisites) 17. Architecture Decision Records (key decisions with rationale)
</action>
<action>Fill template with all collected decisions and patterns</action>
<action>Ensure starter command is first implementation story:
<check if="using_starter_template">
"## Project Initialization
First implementation story should execute:
```bash
{{starter_command_with_options}}
```
This establishes the base architecture with these decisions:
{{starter_provided_decisions}}"
</check>
</action>
<template-output>architecture_document</template-output>
<invoke-task halt="true">{project-root}/bmad/core/tasks/adv-elicit.xml</invoke-task>
</step>
<step n="11" goal="Validate document completeness">
<action>Load validation checklist: {installed_path}/checklist.md</action>
<action>Run validation checklist from {installed_path}/checklist.md</action>
<action>Verify MANDATORY items:
□ Decision table has Version column with specific versions
□ Every epic is mapped to architecture components
□ Source tree is complete, not generic
□ No placeholder text remains
□ All FRs from PRD have architectural support
□ All NFRs from PRD are addressed
□ Implementation patterns cover all potential conflicts
□ Novel patterns are fully documented (if applicable)
</action>
<check if="validation_failed">
<action>Fix missing items automatically</action>
<goto step="10">Regenerate document section</goto>
</check>
<template-output>validation_results</template-output>
</step>
<step n="12" goal="Final review and update workflow status">
<action>Present completion summary:</action>
<check if="{user_skill_level} == 'expert'">
"Architecture complete. {{decision_count}} decisions documented.
Ready for implementation phase."
</check>
<check if="{user_skill_level} == 'beginner'">
"Excellent! Your architecture is complete. You made {{decision_count}} important
decisions that will keep AI agents consistent as they build your app.
What happens next:
1. AI agents will read this architecture before implementing each story
2. They'll follow your technical choices exactly
3. Your app will be built with consistent patterns throughout
You're ready to move to the implementation phase!"
</check>
<action>Save document to {output_folder}/architecture.md</action>
<check if="standalone_mode != true">
<action>Load the FULL file: {output_folder}/bmm-workflow-status.yaml</action>
<action>Find workflow_status key "create-architecture"</action>
<critical>ONLY write the file path as the status value - no other text, notes, or metadata</critical>
<action>Update workflow_status["create-architecture"] = "{output_folder}/bmm-architecture-{{date}}.md"</action>
<action>Save file, preserving ALL comments and structure including STATUS DEFINITIONS</action>
<action>Find first non-completed workflow in workflow_status (next workflow to do)</action>
<action>Determine next agent from path file based on next workflow</action>
</check>
<output>✅ Decision Architecture workflow complete!</output>
<output>**Deliverables Created:**
- ✅ architecture.md - Complete architectural decisions document
{{if_novel_patterns}}
- ✅ Novel pattern designs for unique concepts
{{/if_novel_patterns}}
{{if_starter_template}}
- ✅ Project initialization command documented
{{/if_starter_template}}
The architecture is ready to guide AI agents through consistent implementation.
**Next Steps:**
- **Next required:** {{next_workflow}} ({{next_agent}} agent)
- Review the architecture.md document before proceeding
Check status anytime with: `workflow-status`
</output>
<template-output>completion_summary</template-output>
</step>
</workflow>

View File

@ -0,0 +1,13 @@
category,when_needed,what_to_define,why_critical
naming_patterns,Any technology with named entities,How things are named (format/case/structure),Agents will create different names for same concept
structure_patterns,Any technology with organization,How things are organized (folders/modules/layers),Agents will put things in different places
format_patterns,Any technology with data exchange,How data is formatted (JSON/XML/responses),Agents will use incompatible formats
communication_patterns,Any technology with inter-component communication,How components talk (protocols/events/messages),Agents will use different communication methods
lifecycle_patterns,Any technology with state or flow,How state changes and flows work,Agents will handle state transitions differently
location_patterns,Any technology with storage or routing,Where things go (URLs/paths/storage),Agents will put things in different locations
consistency_patterns,Always,Cross-cutting concerns (dates/errors/logs),Every agent will do these differently
# PRINCIPLE FOR LLM:
# Any time multiple agents might make the SAME decision DIFFERENTLY, that's a pattern to capture.
# Think about: What could an agent encounter where they'd have to guess?
# If they'd guess, define the pattern. If it's obvious from the tech choice, skip it.
1 category,when_needed,what_to_define,why_critical
2 naming_patterns,Any technology with named entities,How things are named (format/case/structure),Agents will create different names for same concept
3 structure_patterns,Any technology with organization,How things are organized (folders/modules/layers),Agents will put things in different places
4 format_patterns,Any technology with data exchange,How data is formatted (JSON/XML/responses),Agents will use incompatible formats
5 communication_patterns,Any technology with inter-component communication,How components talk (protocols/events/messages),Agents will use different communication methods
6 lifecycle_patterns,Any technology with state or flow,How state changes and flows work,Agents will handle state transitions differently
7 location_patterns,Any technology with storage or routing,Where things go (URLs/paths/storage),Agents will put things in different locations
8 consistency_patterns,Always,Cross-cutting concerns (dates/errors/logs),Every agent will do these differently
9 # PRINCIPLE FOR LLM:
10 # Any time multiple agents might make the SAME decision DIFFERENTLY, that's a pattern to capture.
11 # Think about: What could an agent encounter where they'd have to guess?
12 # If they'd guess, define the pattern. If it's obvious from the tech choice, skip it.

View File

@ -0,0 +1,67 @@
# Game Architecture Workflow Configuration
name: game-architecture
description: "Collaborative game architecture workflow for AI-agent consistency. Intelligent, adaptive conversation that produces a decision-focused game architecture document covering engine, systems, networking, and technical design optimized for game development."
author: "BMad"
# Critical variables
config_source: "{project-root}/bmad/bmgd/config.yaml"
output_folder: "{config_source}:output_folder"
user_name: "{config_source}:user_name"
communication_language: "{config_source}:communication_language"
document_output_language: "{config_source}:document_output_language"
game_dev_experience: "{config_source}:game_dev_experience"
date: system-generated
# Input requirements - We work from GDD, Epics, and optionally Narrative Design
recommended_inputs:
- gdd: "Game Design Document with mechanics, systems, and features"
- epics: "Epic definitions with user stories and acceptance criteria"
- narrative: "Narrative design document with story and character systems (optional)"
# Smart input file references - handles both whole docs and sharded docs
# Priority: Whole document first, then sharded version
input_file_patterns:
gdd:
whole: "{output_folder}/*gdd*.md"
sharded: "{output_folder}/*gdd*/index.md"
epics:
whole: "{output_folder}/*epic*.md"
sharded: "{output_folder}/*epic*/index.md"
narrative:
whole: "{output_folder}/*narrative*.md"
sharded: "{output_folder}/*narrative*/index.md"
document_project:
sharded: "{output_folder}/docs/index.md"
# Module path and component files
installed_path: "{project-root}/bmad/bmgd/workflows/3-technical/game-architecture"
instructions: "{installed_path}/instructions.md"
validation: "{installed_path}/checklist.md"
template: "{installed_path}/architecture-template.md"
# Knowledge bases for intelligent decision making
decision_catalog: "{installed_path}/decision-catalog.yaml"
architecture_patterns: "{installed_path}/architecture-patterns.yaml"
pattern_categories: "{installed_path}/pattern-categories.csv"
# Output configuration
default_output_file: "{output_folder}/game-architecture.md"
# Workflow metadata
version: "1.3.2"
replaces: "architecture"
paradigm: "facilitation-driven"
execution_time: "30-90 minutes depending on user skill level"
features:
- "Starter template discovery and integration"
- "Dynamic version verification via web search"
- "Adaptive facilitation by skill level"
- "Decision-focused architecture"
- "Novel pattern design for unique concepts"
- "Intelligent pattern identification - LLM figures out what patterns matter"
- "Implementation patterns for agent consistency"
standalone: true

View File

@ -663,7 +663,7 @@ Would you like me to strengthen any areas with additional research?"
{{#if standalone_mode != true}}
- **Next workflow:** {{next_workflow}} ({{next_agent}} agent)
- **Optional:** Review findings with stakeholders, or run additional analysis workflows (product-brief, game-brief, etc.)
- **Optional:** Review findings with stakeholders, or run additional analysis workflows (product-brief for software, or install BMGD module for game-brief)
Check status anytime with: `workflow-status`
{{else}}

View File

@ -1,81 +0,0 @@
# Game Design Document (GDD) Workflow
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"
# Critical variables from config
config_source: "{project-root}/bmad/bmm/config.yaml"
output_folder: "{config_source}:output_folder"
user_name: "{config_source}:user_name"
communication_language: "{config_source}:communication_language"
document_output_language: "{config_source}:document_output_language"
user_skill_level: "{config_source}:user_skill_level"
date: system-generated
# Workflow components
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"
# Output configuration
default_output_file: "{output_folder}/GDD.md"
# Game type references (loaded based on game type selection)
game_type_guides: "{installed_path}/game-types/"
# Recommended input documents
recommended_inputs:
- game_brief: "{output_folder}/game-brief.md"
- narrative_design: "{output_folder}/narrative-design.md"
- market_research: "{output_folder}/market-research.md"
# Smart input file references - handles both whole docs and sharded docs
# Priority: Whole document first, then sharded version
input_file_patterns:
game_brief:
whole: "{output_folder}/*game-brief*.md"
sharded: "{output_folder}/*game-brief*/index.md"
research:
whole: "{output_folder}/*research*.md"
sharded: "{output_folder}/*research*/index.md"
document_project:
sharded: "{output_folder}/docs/index.md"
standalone: true
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-workflows/gdd/instructions-gdd.md"
web_bundle_files:
- "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"

View File

@ -62,7 +62,7 @@ Project type signals: API, mobile, web, CLI, SDK, SaaS
Domain complexity signals: medical, finance, government, education, aerospace
SPECIAL ROUTING:
If game detected → Suggest game-brief and GDD workflows
If game detected → Inform user that game development requires the BMGD module (BMad Game Development)
If complex domain detected → Offer domain research options:
A) Run domain-research workflow (thorough)
B) Quick web search (basic)

View File

@ -317,6 +317,56 @@ Your choice [1/2/3]:</ask>
- Default to "software" if not clearly a game
</action>
<check if="project_type == game">
<output>
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
🎮 **GAME DEVELOPMENT DETECTED**
Game development workflows are now part of the **BMad Game Development (BMGD)** module.
The BMM module is designed for software development. For game development, you'll need
the BMGD module which provides specialized game development workflows and agents.
**Would you like to:**
a) Install BMGD module now (recommended for game projects)
b) Continue with BMM workflows (for software projects only)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
</output>
<ask>Your choice [a/b]:</ask>
<check if="choice == a">
<output>
Please run the following command to install the BMGD module:
```bash
bmad install bmgd
```
After installation, you can start your game development workflow with the Game Designer agent.
This workflow-init will now exit. Re-run it after installing BMGD.
</output>
<action>Exit workflow with success status</action>
</check>
<check if="choice == b">
<output>
⚠️ **Warning:** BMM workflows are optimized for software development, not game development.
You may encounter mismatched terminology and workflows. Consider installing BMGD for
a better game development experience.
Continuing with software development workflows...
</output>
<action>Set project_type = "software" (override game detection)</action>
</check>
</check>
<template-output>user_description</template-output>
<template-output>field_type</template-output>
<template-output>project_type</template-output>

View File

@ -1,75 +1,52 @@
# Game Design - All Levels
# Game development follows a different path than software
# Game Development - Use BMGD Module
# Game development workflows have been moved to the BMad Game Development module
project_type: "game"
level: "all"
field_type: "any"
description: "Game development workflow - applies to all complexity levels"
description: "⚠️ Game development requires the BMGD module"
error_message: |
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
🎮 **GAME DEVELOPMENT DETECTED**
Game development workflows are now part of the **BMad Game Development (BMGD)** module,
which provides specialized workflows and agents for game creation.
**To proceed with game development:**
1. Install the BMGD module:
```bash
bmad install bmgd
```
2. The BMGD module includes:
- Game Designer, Game Developer, Game Architect agents
- Game Dev Scrum Master for sprint coordination
- Industry-standard game dev workflows:
• Phase 1 (Preproduction): brainstorm-game, game-brief
• Phase 2 (Design): GDD, narrative design
• Phase 3 (Technical): game architecture
• Phase 4 (Production): sprint planning, story management
3. After installation, load the Game Designer or Game Dev Scrum Master agent
to begin your game development workflow
**Why a separate module?**
- Game development follows different phases than software development
- Specialized agents understand game-specific terminology and patterns
- Workflows configured for game development needs (playtesting, balancing, etc.)
- Can be used standalone or alongside BMM for complete coverage
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
# Placeholder phases - this file should not be used for actual workflow tracking
# Users should install BMGD module instead
phases:
- phase: 1
name: "Analysis"
optional: true
name: "ERROR - Install BMGD Module"
workflows:
- id: "brainstorm-game"
optional: true
agent: "game-designer"
command: "brainstorm-game"
- id: "research"
optional: true
agent: "analyst"
command: "research"
note: "Market research, competitive analysis"
- id: "game-brief"
recommended: true
agent: "game-designer"
command: "game-brief"
output: "Game concept and vision document"
- phase: 2
name: "Planning"
- id: "install-bmgd"
required: true
workflows:
- id: "gdd"
required: true
agent: "pm"
command: "gdd"
output: "Game Design Document with features and mechanics"
- id: "tech-spec"
conditional: "if_level_0_1"
agent: "architect"
command: "tech-spec"
note: "For simpler games, jump to implementation"
- phase: 3
name: "Solutioning"
conditional: "if_level_3_4"
workflows:
- id: "create-architecture"
required: true
agent: "architect"
command: "create-architecture"
note: "Engine architecture, networking, systems"
- id: "validate-architecture"
optional: true
agent: "architect"
command: "validate-architecture"
- id: "solutioning-gate-check"
required: true
agent: "architect"
command: "solutioning-gate-check"
- phase: 4
name: "Implementation"
required: true
workflows:
- id: "sprint-planning"
required: true
agent: "sm"
command: "sprint-planning"
note: "Creates sprint plan with all stories - subsequent work tracked in sprint plan output, not workflow-status"
special_considerations:
- "Iterative playtesting throughout development"
- "Art and audio pipelines run parallel to code"
- "Balance and tuning as ongoing process"
note: "Run: bmad install bmgd"

View File

@ -112,6 +112,10 @@ class ModuleManager {
await fs.remove(targetPath);
}
// Vendor cross-module workflows BEFORE copying
// This reads source agent.yaml files and copies referenced workflows
await this.vendorCrossModuleWorkflows(sourcePath, targetPath, moduleName);
// Copy module files with filtering
await this.copyModuleWithFiltering(sourcePath, targetPath, fileTrackingCallback, options.moduleConfig);
@ -435,6 +439,130 @@ class ModuleManager {
}
}
/**
* Vendor cross-module workflows referenced in agent files
* Scans SOURCE agent.yaml files for workflow-install and copies workflows to destination
* @param {string} sourcePath - Source module path
* @param {string} targetPath - Target module path (destination)
* @param {string} moduleName - Module name being installed
*/
async vendorCrossModuleWorkflows(sourcePath, targetPath, moduleName) {
const sourceAgentsPath = path.join(sourcePath, 'agents');
// Check if source agents directory exists
if (!(await fs.pathExists(sourceAgentsPath))) {
return; // No agents to process
}
// Get all agent YAML files from source
const agentFiles = await fs.readdir(sourceAgentsPath);
const yamlFiles = agentFiles.filter((f) => f.endsWith('.agent.yaml') || f.endsWith('.yaml'));
if (yamlFiles.length === 0) {
return; // No YAML agent files
}
let workflowsVendored = false;
for (const agentFile of yamlFiles) {
const agentPath = path.join(sourceAgentsPath, agentFile);
const agentYaml = yaml.load(await fs.readFile(agentPath, 'utf8'));
// Check if agent has menu items with workflow-install
const menuItems = agentYaml?.agent?.menu || [];
const workflowInstallItems = menuItems.filter((item) => item['workflow-install']);
if (workflowInstallItems.length === 0) {
continue; // No workflow-install in this agent
}
if (!workflowsVendored) {
console.log(chalk.cyan(`\n Vendoring cross-module workflows for ${moduleName}...`));
workflowsVendored = true;
}
console.log(chalk.dim(` Processing: ${agentFile}`));
for (const item of workflowInstallItems) {
const sourceWorkflowPath = item.workflow; // Where to copy FROM
const installWorkflowPath = item['workflow-install']; // Where to copy TO
// Parse SOURCE workflow path
// Example: {project-root}/bmad/bmm/workflows/4-implementation/create-story/workflow.yaml
const sourceMatch = sourceWorkflowPath.match(/\{project-root\}\/bmad\/([^/]+)\/workflows\/(.+)/);
if (!sourceMatch) {
console.warn(chalk.yellow(` Could not parse workflow path: ${sourceWorkflowPath}`));
continue;
}
const [, sourceModule, sourceWorkflowSubPath] = sourceMatch;
// Parse INSTALL workflow path
// Example: {project-root}/bmad/bmgd/workflows/4-production/create-story/workflow.yaml
const installMatch = installWorkflowPath.match(/\{project-root\}\/bmad\/([^/]+)\/workflows\/(.+)/);
if (!installMatch) {
console.warn(chalk.yellow(` Could not parse workflow-install path: ${installWorkflowPath}`));
continue;
}
const installWorkflowSubPath = installMatch[2];
// Determine actual filesystem paths
const sourceModulePath = path.join(this.modulesSourcePath, sourceModule);
const actualSourceWorkflowPath = path.join(sourceModulePath, 'workflows', sourceWorkflowSubPath.replace(/\/workflow\.yaml$/, ''));
const actualDestWorkflowPath = path.join(targetPath, 'workflows', installWorkflowSubPath.replace(/\/workflow\.yaml$/, ''));
// Check if source workflow exists
if (!(await fs.pathExists(actualSourceWorkflowPath))) {
console.warn(chalk.yellow(` Source workflow not found: ${actualSourceWorkflowPath}`));
continue;
}
// Copy the entire workflow folder
console.log(
chalk.dim(
` Vendoring: ${sourceModule}/workflows/${sourceWorkflowSubPath.replace(/\/workflow\.yaml$/, '')}${moduleName}/workflows/${installWorkflowSubPath.replace(/\/workflow\.yaml$/, '')}`,
),
);
await fs.ensureDir(path.dirname(actualDestWorkflowPath));
await fs.copy(actualSourceWorkflowPath, actualDestWorkflowPath, { overwrite: true });
// Update the workflow.yaml config_source reference
const workflowYamlPath = path.join(actualDestWorkflowPath, 'workflow.yaml');
if (await fs.pathExists(workflowYamlPath)) {
await this.updateWorkflowConfigSource(workflowYamlPath, moduleName);
}
}
}
if (workflowsVendored) {
console.log(chalk.green(` ✓ Workflow vendoring complete\n`));
}
}
/**
* Update workflow.yaml config_source to point to new module
* @param {string} workflowYamlPath - Path to workflow.yaml file
* @param {string} newModuleName - New module name to reference
*/
async updateWorkflowConfigSource(workflowYamlPath, newModuleName) {
let yamlContent = await fs.readFile(workflowYamlPath, 'utf8');
// Replace config_source: "{project-root}/bmad/OLD_MODULE/config.yaml"
// with config_source: "{project-root}/bmad/NEW_MODULE/config.yaml"
const configSourcePattern = /config_source:\s*["']?\{project-root\}\/bmad\/[^/]+\/config\.yaml["']?/g;
const newConfigSource = `config_source: "{project-root}/bmad/${newModuleName}/config.yaml"`;
const updatedYaml = yamlContent.replaceAll(configSourcePattern, newConfigSource);
if (updatedYaml !== yamlContent) {
await fs.writeFile(workflowYamlPath, updatedYaml, 'utf8');
console.log(chalk.dim(` Updated config_source to: bmad/${newModuleName}/config.yaml`));
}
}
/**
* Run module-specific installer if it exists
* @param {string} moduleName - Name of the module

View File

@ -311,7 +311,15 @@ class YamlXmlBuilder {
const attrs = [`cmd="${trigger}"`];
// Add handler attributes
if (item.workflow) attrs.push(`workflow="${item.workflow}"`);
// If workflow-install exists, use its value for workflow attribute (vendoring)
// workflow-install is build-time metadata - tells installer where to copy workflows
// The final XML should only have workflow pointing to the install location
if (item['workflow-install']) {
attrs.push(`workflow="${item['workflow-install']}"`);
} else if (item.workflow) {
attrs.push(`workflow="${item.workflow}"`);
}
if (item['validate-workflow']) attrs.push(`validate-workflow="${item['validate-workflow']}"`);
if (item.exec) attrs.push(`exec="${item.exec}"`);
if (item.tmpl) attrs.push(`tmpl="${item.tmpl}"`);

View File

@ -170,6 +170,7 @@ function buildMenuItemSchema() {
trigger: createNonEmptyString('agent.menu[].trigger'),
description: createNonEmptyString('agent.menu[].description'),
workflow: createNonEmptyString('agent.menu[].workflow').optional(),
'workflow-install': createNonEmptyString('agent.menu[].workflow-install').optional(),
'validate-workflow': createNonEmptyString('agent.menu[].validate-workflow').optional(),
exec: createNonEmptyString('agent.menu[].exec').optional(),
action: createNonEmptyString('agent.menu[].action').optional(),