start implementing new bm paths into phases 1-4
This commit is contained in:
Brian Madison
parent
00ad756acf
commit
12dd97fe9b
|
|
@ -153,7 +153,7 @@ Each agent brings deep expertise and can be customized to match your team's styl
|
|||
- **Creative Intelligence Suite (CIS)** - Innovation & problem-solving
|
||||
- Brainstorming, design thinking, storytelling
|
||||
- 5 creative facilitation workflows
|
||||
- [→ Creative Workflows](./src/modules/cis/README.md)
|
||||
- [→ Creative Workflows](src/modules/cis/docs/README.md)
|
||||
|
||||
### Key Features
|
||||
|
||||
|
|
|
|||
|
|
@ -60,7 +60,7 @@ Build your own agents, workflows, and modules.
|
|||
|
||||
AI-powered creative thinking and brainstorming.
|
||||
|
||||
- **[CIS Module README](../src/modules/cis/README.md)** - Module overview and workflows
|
||||
- **[CIS Module README](../src/modules/cis/docs/README.md)** - Module overview and workflows
|
||||
|
||||
---
|
||||
|
||||
|
|
|
|||
|
|
@ -1,186 +0,0 @@
|
|||
# IDE Content Injection Standard
|
||||
|
||||
## Overview
|
||||
|
||||
This document defines the standard for IDE-specific content injection in BMAD modules. Each IDE can inject its own specific content into BMAD templates during installation without polluting the source files with IDE-specific code. The installation process is interactive, allowing users to choose what IDE-specific features they want to install.
|
||||
|
||||
## Architecture
|
||||
|
||||
### 1. Injection Points
|
||||
|
||||
Files that support IDE-specific content define injection points using HTML comments:
|
||||
|
||||
```xml
|
||||
<!-- IDE-INJECT-POINT: unique-point-name -->
|
||||
```
|
||||
|
||||
### 2. Module Structure
|
||||
|
||||
Each module that needs IDE-specific content creates a sub-module folder:
|
||||
|
||||
```
|
||||
src/modules/{module-name}/sub-modules/{ide-name}/
|
||||
├── injections.yaml # Injection configuration
|
||||
├── sub-agents/ # IDE-specific subagents (if applicable)
|
||||
└── config.yaml # Other IDE-specific config
|
||||
```
|
||||
|
||||
### 3. Injection Configuration Format
|
||||
|
||||
The `injections.yaml` file defines what content to inject where:
|
||||
|
||||
```yaml
|
||||
# injections.yaml structure
|
||||
injections:
|
||||
- file: 'relative/path/to/file.md' # Path relative to installation root
|
||||
point: 'injection-point-name' # Must match IDE-INJECT-POINT name
|
||||
requires: 'subagent-name' # Which subagent must be selected (or "any")
|
||||
content: | # Content to inject (preserves formatting)
|
||||
<llm>
|
||||
<i>Instructions specific to this IDE</i>
|
||||
</llm>
|
||||
|
||||
# Subagents available for installation
|
||||
subagents:
|
||||
source: 'sub-agents' # Source folder relative to this config
|
||||
target: '.claude/agents' # Claude's expected location (don't change)
|
||||
files:
|
||||
- 'agent1.md'
|
||||
- 'agent2.md'
|
||||
```
|
||||
|
||||
### 4. Interactive Installation Process
|
||||
|
||||
For Claude Code specifically, the installer will:
|
||||
|
||||
1. **Detect available subagents** from the module's `injections.yaml`
|
||||
2. **Ask the user** about subagent installation:
|
||||
- Install all subagents (default)
|
||||
- Select specific subagents
|
||||
- Skip subagent installation
|
||||
3. **Ask installation location** (if subagents selected):
|
||||
- Project level: `.claude/agents/`
|
||||
- User level: `~/.claude/agents/`
|
||||
4. **Copy selected subagents** to the chosen location
|
||||
5. **Inject only relevant content** based on selected subagents
|
||||
|
||||
Other IDEs can implement their own installation logic appropriate to their architecture.
|
||||
|
||||
## Implementation
|
||||
|
||||
### IDE Installer Responsibilities
|
||||
|
||||
Each IDE installer (e.g., `claude-code.js`) must:
|
||||
|
||||
1. **Check for sub-modules**: Look for `sub-modules/{ide-name}/` in each installed module
|
||||
2. **Load injection config**: Parse `injections.yaml` if present
|
||||
3. **Process injections**: Replace injection points with configured content
|
||||
4. **Copy additional files**: Handle subagents or other IDE-specific files
|
||||
|
||||
### Example Implementation (Claude Code)
|
||||
|
||||
```javascript
|
||||
async processModuleInjections(projectDir, bmadDir, options) {
|
||||
for (const moduleName of options.selectedModules) {
|
||||
const configPath = path.join(
|
||||
bmadDir, 'src/modules', moduleName,
|
||||
'sub-modules/claude-code/injections.yaml'
|
||||
);
|
||||
|
||||
if (exists(configPath)) {
|
||||
const config = yaml.load(configPath);
|
||||
|
||||
// Interactive: Ask user about subagent installation
|
||||
const choices = await this.promptSubagentInstallation(config.subagents);
|
||||
|
||||
if (choices.install !== 'none') {
|
||||
// Ask where to install
|
||||
const location = await this.promptInstallLocation();
|
||||
|
||||
// Process injections based on selections
|
||||
for (const injection of config.injections) {
|
||||
if (this.shouldInject(injection, choices)) {
|
||||
await this.injectContent(projectDir, injection, choices);
|
||||
}
|
||||
}
|
||||
|
||||
// Copy selected subagents
|
||||
await this.copySelectedSubagents(projectDir, config.subagents, choices, location);
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## Benefits
|
||||
|
||||
1. **Clean Source Files**: No IDE-specific conditionals in source
|
||||
2. **Modular**: Each IDE manages its own injections
|
||||
3. **Scalable**: Easy to add support for new IDEs
|
||||
4. **Maintainable**: IDE-specific content lives with IDE config
|
||||
5. **Flexible**: Different modules can inject different content
|
||||
|
||||
## Adding Support for a New IDE
|
||||
|
||||
1. Create sub-module folder: `src/modules/{module}/sub-modules/{new-ide}/`
|
||||
2. Add `injections.yaml` with IDE-specific content
|
||||
3. Update IDE installer to process injections using this standard
|
||||
4. Test installation with and without the IDE selected
|
||||
|
||||
## Example: BMM Module with Claude Code
|
||||
|
||||
### File Structure
|
||||
|
||||
```
|
||||
src/modules/bmm/
|
||||
├── agents/pm.md # Has injection point
|
||||
├── templates/prd.md # Has multiple injection points
|
||||
└── sub-modules/
|
||||
└── claude-code/
|
||||
├── injections.yaml # Defines what to inject
|
||||
└── sub-agents/ # Claude Code specific subagents
|
||||
├── market-researcher.md
|
||||
├── requirements-analyst.md
|
||||
└── ...
|
||||
```
|
||||
|
||||
### Injection Point in pm.md
|
||||
|
||||
```xml
|
||||
<agent>
|
||||
<persona>...</persona>
|
||||
<!-- IDE-INJECT-POINT: pm-agent-instructions -->
|
||||
<cmds>...</cmds>
|
||||
</agent>
|
||||
```
|
||||
|
||||
### Injection Configuration
|
||||
|
||||
```yaml
|
||||
injections:
|
||||
- file: '_bmad/bmm/agents/pm.md'
|
||||
point: 'pm-agent-instructions'
|
||||
requires: 'any' # Injected if ANY subagent is selected
|
||||
content: |
|
||||
<llm critical="true">
|
||||
<i>Use 'market-researcher' subagent for analysis</i>
|
||||
</llm>
|
||||
|
||||
- file: '_bmad/bmm/templates/prd.md'
|
||||
point: 'prd-goals-context-delegation'
|
||||
requires: 'market-researcher' # Only if this specific subagent selected
|
||||
content: |
|
||||
<i>DELEGATE: Use 'market-researcher' subagent...</i>
|
||||
```
|
||||
|
||||
### Result After Installation
|
||||
|
||||
```xml
|
||||
<agent>
|
||||
<persona>...</persona>
|
||||
<llm critical="true">
|
||||
<i>Use 'market-researcher' subagent for analysis</i>
|
||||
</llm>
|
||||
<cmds>...</cmds>
|
||||
</agent>
|
||||
```
|
||||
|
|
@ -1,389 +0,0 @@
|
|||
# BMAD Installation & Module System Reference
|
||||
|
||||
## Table of Contents
|
||||
|
||||
1. [Overview](#overview)
|
||||
2. [Quick Start](#quick-start)
|
||||
3. [Architecture](#architecture)
|
||||
4. [Modules](#modules)
|
||||
5. [Configuration System](#configuration-system)
|
||||
6. [Platform Integration](#platform-integration)
|
||||
7. [Development Guide](#development-guide)
|
||||
8. [Troubleshooting](#troubleshooting)
|
||||
|
||||
## Overview
|
||||
|
||||
BMad Core is a modular AI agent framework with intelligent installation, platform-agnostic support, and configuration inheritance.
|
||||
|
||||
### Key Features
|
||||
|
||||
- **Modular Design**: Core + optional modules (BMB, BMM, CIS)
|
||||
- **Smart Installation**: Interactive configuration with dependency resolution
|
||||
- **Clean Architecture**: Centralized `_bmad` directory add to project, no source pollution with multiple folders added
|
||||
|
||||
## Architecture
|
||||
|
||||
### Directory Structure upon installation
|
||||
|
||||
```
|
||||
project-root/
|
||||
├── _bmad/ # Centralized installation
|
||||
│ ├── _config/ # Configuration
|
||||
│ │ ├── agents/ # Agent configs
|
||||
│ │ └── agent-manifest.csv # Agent manifest
|
||||
│ ├── core/ # Core module
|
||||
│ │ ├── agents/
|
||||
│ │ ├── tasks/
|
||||
│ │ └── config.yaml
|
||||
│ ├── bmm/ # BMad Method module
|
||||
│ │ ├── agents/
|
||||
│ │ ├── tasks/
|
||||
│ │ ├── workflows/
|
||||
│ │ └── config.yaml
|
||||
│ └── cis/ # Creative Innovation Studio
|
||||
│ └── ...
|
||||
└── .claude/ # Platform-specific (example)
|
||||
└── agents/
|
||||
```
|
||||
|
||||
### Installation Flow
|
||||
|
||||
1. **Detection**: Check existing installation
|
||||
2. **Selection**: Choose modules interactively or via CLI
|
||||
3. **Configuration**: Collect module-specific settings
|
||||
4. **Installation**: Compile Process and copy files
|
||||
5. **Generation**: Create config files with inheritance
|
||||
6. **Post-Install**: Run module installers
|
||||
7. **Manifest**: Track installed components
|
||||
|
||||
### Key Exclusions
|
||||
|
||||
- `_module-installer/` directories are never copied to destination
|
||||
- module.yaml
|
||||
- `localskip="true"` agents are filtered out
|
||||
- Source `config.yaml` templates are replaced with generated configs
|
||||
|
||||
## Modules
|
||||
|
||||
### Core Module (Required)
|
||||
|
||||
Foundation framework with C.O.R.E. (Collaboration Optimized Reflection Engine)
|
||||
|
||||
- **Components**: Base agents, activation system, advanced elicitation
|
||||
- **Config**: `user_name`, `communication_language`
|
||||
|
||||
### BMM Module
|
||||
|
||||
BMad Method for software development workflows
|
||||
|
||||
- **Components**: PM agent, dev tasks, PRD templates, story generation
|
||||
- **Config**: `project_name`, `tech_docs`, `output_folder`, `story_location`
|
||||
- **Dependencies**: Core
|
||||
|
||||
### CIS Module
|
||||
|
||||
Creative Innovation Studio for design workflows
|
||||
|
||||
- **Components**: Design agents, creative tasks
|
||||
- **Config**: `output_folder`, design preferences
|
||||
- **Dependencies**: Core
|
||||
|
||||
### Module Structure
|
||||
|
||||
```
|
||||
src/modules/{module}/
|
||||
├── _module-installer/ # Not copied to destination
|
||||
│ ├── installer.js # Post-install logic
|
||||
├── module.yaml
|
||||
├── agents/
|
||||
├── tasks/
|
||||
├── templates/
|
||||
└── sub-modules/ # Platform-specific content
|
||||
└── {platform}/
|
||||
├── injections.yaml
|
||||
└── sub-agents/
|
||||
```
|
||||
|
||||
## Configuration System
|
||||
|
||||
### Collection Process
|
||||
|
||||
Modules define prompts in `module.yaml`:
|
||||
|
||||
```yaml
|
||||
project_name:
|
||||
prompt: 'Project title?'
|
||||
default: 'My Project'
|
||||
result: '{value}'
|
||||
|
||||
output_folder:
|
||||
prompt: 'Output location?'
|
||||
default: 'docs'
|
||||
result: '{project-root}/{value}'
|
||||
|
||||
tools:
|
||||
prompt: 'Select tools:'
|
||||
multi-select:
|
||||
- 'Tool A'
|
||||
- 'Tool B'
|
||||
```
|
||||
|
||||
### Configuration Inheritance
|
||||
|
||||
Core values cascade to ALL modules automatically:
|
||||
|
||||
```yaml
|
||||
# core/config.yaml
|
||||
user_name: "Jane"
|
||||
communication_language: "English"
|
||||
|
||||
# bmm/config.yaml (generated)
|
||||
project_name: "My App"
|
||||
tech_docs: "/path/to/docs"
|
||||
# Core Configuration Values (inherited)
|
||||
user_name: "Jane"
|
||||
communication_language: "English"
|
||||
```
|
||||
|
||||
**Reserved Keys**: Core configuration keys cannot be redefined by other modules.
|
||||
|
||||
### Path Placeholders
|
||||
|
||||
- `{project-root}`: Project directory path
|
||||
- `{value}`: User input
|
||||
- `{module}`: Module name
|
||||
- `{core:field}`: Reference core config value
|
||||
|
||||
### Config Generation Rules
|
||||
|
||||
1. ALL installed modules get a `config.yaml` (even without prompts)
|
||||
2. Core values are ALWAYS included in module configs
|
||||
3. Module-specific values come first, core values appended
|
||||
4. Source templates are never copied, only generated configs
|
||||
|
||||
## Platform Integration
|
||||
|
||||
### Supported Platforms
|
||||
|
||||
**Preferred** (Full Integration):
|
||||
|
||||
- Claude Code
|
||||
- Cursor
|
||||
- Windsurf
|
||||
|
||||
**Additional**:
|
||||
Cline, Roo, Rovo Dev,Auggie, GitHub Copilot, Codex, Gemini, Qwen, Trae, Kilo, Crush, iFlow
|
||||
|
||||
### Platform Features
|
||||
|
||||
1. **Setup Handler** (`tools/cli/installers/lib/ide/{platform}.js`)
|
||||
- Directory creation
|
||||
- Configuration generation
|
||||
- Agent processing
|
||||
|
||||
2. **Content Injection** (`sub-modules/{platform}/injections.yaml`)
|
||||
|
||||
```yaml
|
||||
injections:
|
||||
- file: '_bmad/bmm/agents/pm.md'
|
||||
point: 'pm-agent-instructions'
|
||||
content: |
|
||||
<i>Platform-specific instruction</i>
|
||||
|
||||
subagents:
|
||||
source: 'sub-agents'
|
||||
target: '.claude/agents'
|
||||
files: ['agent.md']
|
||||
```
|
||||
|
||||
3. **Interactive Config**
|
||||
- Subagent selection
|
||||
- Installation scope (project/user)
|
||||
- Feature toggles
|
||||
|
||||
### Injection System
|
||||
|
||||
Platform-specific content without source modification:
|
||||
|
||||
- Inject points marked in source: `<!-- IDE-INJECT-POINT:name -->`
|
||||
- Content added during installation only
|
||||
- Source files remain clean
|
||||
|
||||
## Development Guide
|
||||
|
||||
### Creating a Module
|
||||
|
||||
1. **Structure**
|
||||
|
||||
```
|
||||
src/modules/mymod/
|
||||
├── _module-installer/
|
||||
│ ├── installer.js
|
||||
├── module.yaml
|
||||
├── agents/
|
||||
└── tasks/
|
||||
```
|
||||
|
||||
2. **Configuration** (`module.yaml`)
|
||||
|
||||
```yaml
|
||||
code: mymod
|
||||
name: 'My Module'
|
||||
prompt: 'Welcome message'
|
||||
|
||||
setting_name:
|
||||
prompt: 'Configure X?'
|
||||
default: 'value'
|
||||
```
|
||||
|
||||
3. **Installer** (`installer.js`)
|
||||
```javascript
|
||||
async function install(options) {
|
||||
const { projectRoot, config, installedIDEs, logger } = options;
|
||||
// Custom logic
|
||||
return true;
|
||||
}
|
||||
module.exports = { install };
|
||||
```
|
||||
|
||||
### Adding Platform Support
|
||||
|
||||
1. Create handler: `tools/cli/installers/lib/ide/myplatform.js`
|
||||
2. Extend `BaseIdeSetup` class
|
||||
3. Add sub-module: `src/modules/{mod}/sub-modules/myplatform/`
|
||||
4. Define injections and platform agents
|
||||
|
||||
### Agent Configuration
|
||||
|
||||
Extractable config nodes:
|
||||
|
||||
```xml
|
||||
<agent>
|
||||
<setting agentConfig="true">
|
||||
Default value
|
||||
</setting>
|
||||
</agent>
|
||||
```
|
||||
|
||||
Generated in: `bmad/_config/agents/{module}-{agent}.md`
|
||||
|
||||
## Troubleshooting
|
||||
|
||||
### Common Issues
|
||||
|
||||
| Issue | Solution |
|
||||
| ----------------------- | ------------------------------------ |
|
||||
| Existing installation | Use `bmad update` or remove `_bmad/` |
|
||||
| Module not found | Check `src/modules/` exists |
|
||||
| Config not applied | Verify `_bmad/{module}/config.yaml` |
|
||||
| Missing config.yaml | Fixed: All modules now get configs |
|
||||
| Agent unavailable | Check for `localskip="true"` |
|
||||
| module-installer copied | Fixed: Now excluded from copy |
|
||||
|
||||
### Debug Commands
|
||||
|
||||
```bash
|
||||
bmad install -v # Verbose installation
|
||||
bmad status -v # Detailed status
|
||||
```
|
||||
|
||||
### Best Practices
|
||||
|
||||
1. Run from project root
|
||||
2. Backup `_bmad/_config/` before updates
|
||||
3. Use interactive mode for guidance
|
||||
4. Review generated configs post-install
|
||||
|
||||
## Migration from v4
|
||||
|
||||
| v4 | v6 |
|
||||
| ------------------- | -------------------- |
|
||||
| Scattered files | Centralized `_bmad/` |
|
||||
| Monolithic | Modular |
|
||||
| Manual config | Interactive setup |
|
||||
| Limited IDE support | 15+ platforms |
|
||||
| Source modification | Clean injection |
|
||||
|
||||
## Technical Notes
|
||||
|
||||
### Dependency Resolution
|
||||
|
||||
- Direct dependencies (module → module)
|
||||
- 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
|
||||
|
||||
- Filters `localskip="true"` agents
|
||||
- Excludes `_module-installer/` directories
|
||||
- Replaces path placeholders at runtime
|
||||
- Injects activation blocks
|
||||
- Vendors cross-module workflows (see Workflow Vendoring below)
|
||||
|
||||
### Web Bundling
|
||||
|
||||
```bash
|
||||
bmad bundle --web # Filter for web deployment
|
||||
npm run validate:bundles # Validate bundles
|
||||
```
|
||||
|
|
@ -18,8 +18,6 @@ Specialized tools and workflows for creating, customizing, and extending BMad co
|
|||
|
||||
There is a dedicated Agent expert, a Workflow Expert, and a Module Expert agent available!
|
||||
|
||||
### 📋 Workflows
|
||||
|
||||
### 📚 Documentation
|
||||
|
||||
- Comprehensive guides for agents, workflows, and modules
|
||||
|
|
|
|||
|
|
@ -1,209 +0,0 @@
|
|||
# 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.yaml
|
||||
└── _module-installer/
|
||||
└── installer.js (optional)
|
||||
```
|
||||
|
||||
## 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
|
||||
|
|
@ -46,8 +46,8 @@ async function install(options) {
|
|||
}
|
||||
|
||||
// Create implementation artifacts directory (sprint status, stories, reviews)
|
||||
// Check both implementation_artifacts and sprint_artifacts for compatibility
|
||||
const implConfig = config['implementation_artifacts'] || config['sprint_artifacts'];
|
||||
// Check both implementation_artifacts and implementation_artifacts for compatibility
|
||||
const implConfig = config['implementation_artifacts'] || config['implementation_artifacts'];
|
||||
if (implConfig && typeof implConfig === 'string') {
|
||||
// Strip project-root prefix variations
|
||||
const implConfigClean = implConfig.replace(/^\{project-root\}\/?/, '');
|
||||
|
|
|
|||
|
|
@ -11,8 +11,8 @@ communication_language: "{config_source}:communication_language"
|
|||
user_skill_level: "{config_source}:user_skill_level"
|
||||
document_output_language: "{config_source}:document_output_language"
|
||||
date: system-generated
|
||||
sprint_artifacts: "{config_source}:sprint_artifacts"
|
||||
sprint_status: "{sprint_artifacts}/sprint-status.yaml || {output_folder}/sprint-status.yaml"
|
||||
implementation_artifacts: "{config_source}:implementation_artifacts"
|
||||
sprint_status: "{implementation_artifacts}/sprint-status.yaml || {output_folder}/sprint-status.yaml"
|
||||
|
||||
# Workflow components
|
||||
installed_path: "{project-root}/_bmad/bmgd/workflows/4-production/code-review"
|
||||
|
|
@ -23,7 +23,7 @@ template: false
|
|||
variables:
|
||||
# Project context
|
||||
project_context: "**/project-context.md"
|
||||
story_dir: "{sprint_artifacts}"
|
||||
story_dir: "{implementation_artifacts}"
|
||||
|
||||
# Smart input file references - game-specific patterns
|
||||
# Priority: Whole document first, then sharded version
|
||||
|
|
|
|||
|
|
@ -10,8 +10,8 @@ communication_language: "{config_source}:communication_language"
|
|||
user_skill_level: "{config_source}:user_skill_level"
|
||||
document_output_language: "{config_source}:document_output_language"
|
||||
date: system-generated
|
||||
sprint_artifacts: "{config_source}:sprint_artifacts"
|
||||
sprint_status: "{sprint_artifacts}/sprint-status.yaml || {output_folder}/sprint-status.yaml"
|
||||
implementation_artifacts: "{config_source}:implementation_artifacts"
|
||||
sprint_status: "{implementation_artifacts}/sprint-status.yaml || {output_folder}/sprint-status.yaml"
|
||||
|
||||
# Smart input file references - handles both whole docs and sharded docs
|
||||
# Priority: Whole document first, then sharded version
|
||||
|
|
|
|||
|
|
@ -8,8 +8,8 @@ output_folder: "{config_source}:output_folder"
|
|||
user_name: "{config_source}:user_name"
|
||||
communication_language: "{config_source}:communication_language"
|
||||
date: system-generated
|
||||
sprint_artifacts: "{config_source}:sprint_artifacts"
|
||||
story_dir: "{sprint_artifacts}"
|
||||
implementation_artifacts: "{config_source}:implementation_artifacts"
|
||||
story_dir: "{implementation_artifacts}"
|
||||
|
||||
# Workflow components
|
||||
installed_path: "{project-root}/_bmad/bmgd/workflows/4-production/create-story"
|
||||
|
|
@ -19,7 +19,7 @@ validation: "{installed_path}/checklist.md"
|
|||
|
||||
# Variables and inputs
|
||||
variables:
|
||||
sprint_status: "{sprint_artifacts}/sprint-status.yaml || {output_folder}/sprint-status.yaml" # Primary source for story tracking
|
||||
sprint_status: "{implementation_artifacts}/sprint-status.yaml || {output_folder}/sprint-status.yaml" # Primary source for story tracking
|
||||
epics_file: "{output_folder}/epics.md" # Preferred source for epic/story breakdown
|
||||
prd_file: "{output_folder}/PRD.md" # Fallback for requirements
|
||||
architecture_file: "{output_folder}/architecture.md" # Optional architecture context
|
||||
|
|
|
|||
|
|
@ -9,14 +9,14 @@ user_name: "{config_source}:user_name"
|
|||
communication_language: "{config_source}:communication_language"
|
||||
user_skill_level: "{config_source}:user_skill_level"
|
||||
document_output_language: "{config_source}:document_output_language"
|
||||
story_dir: "{config_source}:sprint_artifacts"
|
||||
story_dir: "{config_source}:implementation_artifacts"
|
||||
date: system-generated
|
||||
|
||||
story_file: "" # Explicit story path; auto-discovered if empty
|
||||
# Context file uses same story_key as story file (e.g., "1-2-user-authentication.context.xml")
|
||||
context_file: "{story_dir}/{{story_key}}.context.xml"
|
||||
sprint_artifacts: "{config_source}:sprint_artifacts"
|
||||
sprint_status: "{sprint_artifacts}/sprint-status.yaml || {output_folder}/sprint-status.yaml"
|
||||
implementation_artifacts: "{config_source}:implementation_artifacts"
|
||||
sprint_status: "{implementation_artifacts}/sprint-status.yaml || {output_folder}/sprint-status.yaml"
|
||||
|
||||
# Smart input file references - handles both whole docs and sharded docs
|
||||
# Priority: Whole document first, then sharded version
|
||||
|
|
@ -40,7 +40,7 @@ input_file_patterns:
|
|||
tech_spec:
|
||||
description: "Technical specification"
|
||||
whole: "{output_folder}/tech-spec*.md"
|
||||
sharded: "{sprint_artifacts}/tech-spec-epic-*.md"
|
||||
sharded: "{implementation_artifacts}/tech-spec-epic-*.md"
|
||||
load_strategy: "SELECTIVE_LOAD"
|
||||
ux_design:
|
||||
description: "UX design specification (if UI)"
|
||||
|
|
|
|||
|
|
@ -10,7 +10,7 @@ communication_language: "{config_source}:communication_language"
|
|||
user_skill_level: "{config_source}:user_skill_level"
|
||||
document_output_language: "{config_source}:document_output_language"
|
||||
date: system-generated
|
||||
sprint_artifacts: "{config_source}:sprint_artifacts"
|
||||
implementation_artifacts: "{config_source}:implementation_artifacts"
|
||||
|
||||
installed_path: "{project-root}/_bmad/bmgd/workflows/4-production/retrospective"
|
||||
template: false
|
||||
|
|
@ -41,7 +41,7 @@ input_file_patterns:
|
|||
load_strategy: "SELECTIVE_LOAD"
|
||||
previous_retrospective:
|
||||
description: "Previous retrospective (optional)"
|
||||
pattern: "{sprint_artifacts}/**/epic-{{prev_epic_num}}-retro-*.md"
|
||||
pattern: "{implementation_artifacts}/**/epic-{{prev_epic_num}}-retro-*.md"
|
||||
load_strategy: "SELECTIVE_LOAD"
|
||||
architecture:
|
||||
description: "Game architecture and technical decisions"
|
||||
|
|
@ -54,9 +54,9 @@ input_file_patterns:
|
|||
load_strategy: "INDEX_GUIDED"
|
||||
|
||||
# Required files
|
||||
sprint_status_file: "{sprint_artifacts}/sprint-status.yaml || {output_folder}/sprint-status.yaml"
|
||||
story_directory: "{sprint_artifacts}"
|
||||
retrospectives_folder: "{sprint_artifacts}"
|
||||
sprint_status_file: "{implementation_artifacts}/sprint-status.yaml || {output_folder}/sprint-status.yaml"
|
||||
story_directory: "{implementation_artifacts}"
|
||||
retrospectives_folder: "{implementation_artifacts}"
|
||||
|
||||
standalone: true
|
||||
web_bundle: false
|
||||
|
|
|
|||
|
|
@ -8,7 +8,7 @@ output_folder: "{config_source}:output_folder"
|
|||
user_name: "{config_source}:user_name"
|
||||
communication_language: "{config_source}:communication_language"
|
||||
date: system-generated
|
||||
sprint_artifacts: "{config_source}:sprint_artifacts"
|
||||
implementation_artifacts: "{config_source}:implementation_artifacts"
|
||||
|
||||
# Workflow components
|
||||
installed_path: "{project-root}/_bmad/bmgd/workflows/4-production/sprint-planning"
|
||||
|
|
@ -23,15 +23,15 @@ variables:
|
|||
|
||||
# Tracking system configuration
|
||||
tracking_system: "file-system" # Options: file-system, Future will support other options from config of mcp such as jira, linear, trello
|
||||
story_location: "{config_source}:sprint_artifacts" # Relative path for file-system, Future will support URL for Jira/Linear/Trello
|
||||
story_location_absolute: "{config_source}:sprint_artifacts" # Absolute path for file operations
|
||||
story_location: "{config_source}:implementation_artifacts" # Relative path for file-system, Future will support URL for Jira/Linear/Trello
|
||||
story_location_absolute: "{config_source}:implementation_artifacts" # Absolute path for file operations
|
||||
|
||||
# Source files (file-system only)
|
||||
epics_location: "{output_folder}" # Directory containing epic*.md files
|
||||
epics_pattern: "epic*.md" # Pattern to find epic files
|
||||
|
||||
# Output configuration
|
||||
status_file: "{sprint_artifacts}/sprint-status.yaml"
|
||||
status_file: "{implementation_artifacts}/sprint-status.yaml"
|
||||
|
||||
# Smart input file references - handles both whole docs and sharded docs
|
||||
# Priority: Whole document first, then sharded version
|
||||
|
|
|
|||
|
|
@ -10,7 +10,7 @@ user_name: "{config_source}:user_name"
|
|||
communication_language: "{config_source}:communication_language"
|
||||
document_output_language: "{config_source}:document_output_language"
|
||||
date: system-generated
|
||||
sprint_artifacts: "{config_source}:sprint_artifacts"
|
||||
implementation_artifacts: "{config_source}:implementation_artifacts"
|
||||
|
||||
# Workflow components
|
||||
installed_path: "{project-root}/_bmad/bmgd/workflows/4-production/sprint-status"
|
||||
|
|
@ -18,14 +18,14 @@ instructions: "{installed_path}/instructions.md"
|
|||
|
||||
# Inputs
|
||||
variables:
|
||||
sprint_status_file: "{sprint_artifacts}/sprint-status.yaml || {output_folder}/sprint-status.yaml"
|
||||
sprint_status_file: "{implementation_artifacts}/sprint-status.yaml || {output_folder}/sprint-status.yaml"
|
||||
tracking_system: "file-system"
|
||||
|
||||
# Smart input file references
|
||||
input_file_patterns:
|
||||
sprint_status:
|
||||
description: "Sprint status file generated by sprint-planning"
|
||||
whole: "{sprint_artifacts}/sprint-status.yaml || {output_folder}/sprint-status.yaml"
|
||||
whole: "{implementation_artifacts}/sprint-status.yaml || {output_folder}/sprint-status.yaml"
|
||||
load_strategy: "FULL_LOAD"
|
||||
|
||||
# Standalone so IDE commands get generated
|
||||
|
|
|
|||
|
|
@ -27,7 +27,7 @@
|
|||
- Existing code to integrate with?
|
||||
</action>
|
||||
|
||||
<action>Check for existing context in {output_folder} and {sprint_artifacts}</action>
|
||||
<action>Check for existing context in {output_folder} and {implementation_artifacts}</action>
|
||||
|
||||
<checkpoint title="Problem Understanding">
|
||||
[a] Advanced Elicitation [c] Continue [p] Party Mode
|
||||
|
|
@ -113,7 +113,7 @@
|
|||
|
||||
</action>
|
||||
|
||||
<action>Save to {sprint_artifacts}/tech-spec-{slug}.md</action>
|
||||
<action>Save to {implementation_artifacts}/tech-spec-{slug}.md</action>
|
||||
|
||||
</step>
|
||||
|
||||
|
|
@ -123,7 +123,7 @@
|
|||
|
||||
<output>**Tech-Spec Complete!** 🎮
|
||||
|
||||
Saved to: {sprint_artifacts}/tech-spec-{slug}.md
|
||||
Saved to: {implementation_artifacts}/tech-spec-{slug}.md
|
||||
|
||||
[a] Advanced Elicitation - refine further
|
||||
[b] Begin Development (not recommended - fresh context better)
|
||||
|
|
|
|||
|
|
@ -6,7 +6,7 @@ author: "BMad"
|
|||
# Config
|
||||
config_source: "{project-root}/_bmad/bmgd/config.yaml"
|
||||
output_folder: "{config_source}:output_folder"
|
||||
sprint_artifacts: "{config_source}:sprint_artifacts"
|
||||
implementation_artifacts: "{config_source}:implementation_artifacts"
|
||||
user_name: "{config_source}:user_name"
|
||||
communication_language: "{config_source}:communication_language"
|
||||
document_output_language: "{config_source}:document_output_language"
|
||||
|
|
|
|||
|
|
@ -6,7 +6,7 @@ author: "BMad"
|
|||
# Config
|
||||
config_source: "{project-root}/_bmad/bmgd/config.yaml"
|
||||
output_folder: "{config_source}:output_folder"
|
||||
sprint_artifacts: "{config_source}:sprint_artifacts"
|
||||
implementation_artifacts: "{config_source}:implementation_artifacts"
|
||||
user_name: "{config_source}:user_name"
|
||||
communication_language: "{config_source}:communication_language"
|
||||
user_skill_level: "{config_source}:game_dev_experience"
|
||||
|
|
|
|||
|
|
@ -6,7 +6,7 @@ author: "BMad"
|
|||
# Config
|
||||
config_source: "{project-root}/_bmad/bmgd/config.yaml"
|
||||
output_folder: "{config_source}:output_folder"
|
||||
sprint_artifacts: "{config_source}:sprint_artifacts"
|
||||
implementation_artifacts: "{config_source}:implementation_artifacts"
|
||||
user_name: "{config_source}:user_name"
|
||||
communication_language: "{config_source}:communication_language"
|
||||
user_skill_level: "{config_source}:game_dev_experience"
|
||||
|
|
|
|||
|
|
@ -15,7 +15,7 @@
|
|||
- BMGD artifacts: GDD, game brief, architecture, narrative design
|
||||
- Implementation: stories, sprint-status, workflow-status
|
||||
- Game project: engine files (Unity, Unreal, Godot), source directories
|
||||
- Check both {output_folder} and {sprint_artifacts} locations
|
||||
- Check both {output_folder} and {implementation_artifacts} locations
|
||||
</action>
|
||||
|
||||
<action>Categorize into one of these states:
|
||||
|
|
|
|||
|
|
@ -6,7 +6,7 @@ author: "BMad"
|
|||
# Critical variables from config
|
||||
config_source: "{project-root}/_bmad/bmgd/config.yaml"
|
||||
output_folder: "{config_source}:output_folder"
|
||||
sprint_artifacts: "{config_source}:sprint_artifacts"
|
||||
implementation_artifacts: "{config_source}:implementation_artifacts"
|
||||
user_name: "{config_source}:user_name"
|
||||
project_name: "{config_source}:project_name"
|
||||
communication_language: "{config_source}:communication_language"
|
||||
|
|
|
|||
|
|
@ -44,10 +44,9 @@ bmm/
|
|||
|
||||
**Phase 0:** Documentation (brownfield only)
|
||||
**Phase 1:** Analysis (optional) - 5 workflows
|
||||
**Phase 2:** Planning (required) - 6 workflows
|
||||
**Phase 3:** Solutioning (Level 3-4) - 2 workflows
|
||||
**Phase 4:** Implementation (iterative) - 10 workflows
|
||||
**Testing:** Quality assurance (parallel) - 9 workflows
|
||||
**Phase 2:** Planning (required) - 2 workflows
|
||||
**Phase 3:** Solutioning (required) - 3 workflows
|
||||
**Phase 4:** Implementation (iterative) - 7 workflows
|
||||
|
||||
👉 **[Workflow Guides](./docs/README.md#-workflow-guides)** - Detailed documentation for each phase
|
||||
|
||||
|
|
|
|||
|
|
@ -63,9 +63,9 @@ async function install(options) {
|
|||
}
|
||||
|
||||
// Create dev story location if configured
|
||||
if (config['sprint_artifacts']) {
|
||||
if (config['implementation_artifacts']) {
|
||||
// Strip {project-root}/ prefix if present
|
||||
const storyConfig = config['sprint_artifacts'].replace('{project-root}/', '');
|
||||
const storyConfig = config['implementation_artifacts'].replace('{project-root}/', '');
|
||||
const storyPath = path.join(projectRoot, storyConfig);
|
||||
if (!(await fs.pathExists(storyPath))) {
|
||||
logger.log(chalk.yellow(`Creating story directory: ${storyConfig}`));
|
||||
|
|
|
|||
|
|
@ -43,10 +43,6 @@ agent:
|
|||
workflow: "{project-root}/_bmad/bmm/workflows/4-implementation/code-review/workflow.yaml"
|
||||
description: "[CR] Perform a thorough clean context code review (Highly Recommended, use fresh context and different LLM)"
|
||||
|
||||
- trigger: QD or quick-dev or fuzzy match on quick dev
|
||||
workflow: "{project-root}/_bmad/bmm/workflows/4-implementation/quick-dev/workflow.yaml"
|
||||
description: "[QD] Flexible development - execute tech-specs OR direct instructions (optional)"
|
||||
|
||||
- trigger: PS or party-mode or fuzzy match on party mode
|
||||
exec: "{project-root}/_bmad/core/workflows/party-mode/workflow.md"
|
||||
description: "[PS] Bring the whole team in to chat with other expert agents from the party"
|
||||
|
|
|
|||
|
|
@ -25,3 +25,7 @@ agent:
|
|||
- trigger: QD or quick-dev or fuzzy match on quick dev
|
||||
workflow: "{project-root}/_bmad/bmm/workflows/bmad-quick-flow/quick-dev/workflow.yaml"
|
||||
description: "[QD] Implement the tech spec end-to-end solo (Core of Quick Flow)"
|
||||
|
||||
- trigger: CR or code-review or fuzzy match on code review
|
||||
workflow: "{project-root}/_bmad/bmm/workflows/4-implementation/code-review/workflow.yaml"
|
||||
description: "[CR] Perform a thorough clean context code review (Highly Recommended, use fresh context and different LLM)"
|
||||
|
|
|
|||
|
|
@ -8,7 +8,7 @@ Complete guides for the BMad Method Module (BMM) - AI-powered agile development
|
|||
|
||||
**New to BMM?** Start here:
|
||||
|
||||
- **[Quick Start Guide](./quick-start.md)** - Step-by-step guide to building your first project (15 min read)
|
||||
- **[Quick Start Guide](./quick-start.md)** - Step-by-step guide to building your first project
|
||||
- Installation and setup
|
||||
- Understanding the four phases
|
||||
- Running your first workflows
|
||||
|
|
@ -20,44 +20,40 @@ Complete guides for the BMad Method Module (BMM) - AI-powered agile development
|
|||
|
||||
**[Complete Workflow Diagram](./images/workflow-method-greenfield.svg)** - Visual flowchart showing all phases, agents (color-coded), and decision points for the BMad Method standard greenfield track.
|
||||
|
||||
---
|
||||
|
||||
## 📖 Core Concepts
|
||||
|
||||
Understanding how BMM adapts to your needs:
|
||||
|
||||
- **[Scale Adaptive System](./scale-adaptive-system.md)** - How BMM adapts to project size and complexity (42 min read)
|
||||
- **[Scale Adaptive System](./scale-adaptive-system.md)** - How BMM adapts to project size and complexity
|
||||
- Three planning tracks (Quick Flow, BMad Method, Enterprise Method)
|
||||
- Automatic track recommendation
|
||||
- Documentation requirements per track
|
||||
- Planning workflow routing
|
||||
|
||||
- **[BMAD Quick Flow](./bmad-quick-flow.md)** - Fast-track development workflow (32 min read)
|
||||
- **[BMAD Quick Flow](./bmad-quick-flow.md)** - Fast-track development workflow
|
||||
- 3-step process: spec → dev → optional review
|
||||
- Perfect for bug fixes and small features
|
||||
- Rapid prototyping with production quality
|
||||
- Hours to implementation, not days
|
||||
- Barry (Quick Flow Solo Dev) agent owned
|
||||
|
||||
- **[Quick Flow Solo Dev Agent](./quick-flow-solo-dev.md)** - Elite solo developer for rapid development (18 min read)
|
||||
- **[Quick Flow Solo Dev Agent](./quick-flow-solo-dev.md)** - Elite solo developer for rapid development
|
||||
- Barry is an elite developer who thrives on autonomous execution
|
||||
- Lives and breathes the BMAD Quick Flow workflow
|
||||
- Takes projects from concept to deployment with ruthless efficiency
|
||||
- No handoffs, no delays - just pure focused development
|
||||
|
||||
---
|
||||
|
||||
## 🤖 Agents and Collaboration
|
||||
|
||||
Complete guide to BMM's AI agent team:
|
||||
|
||||
- **[Agents Guide](./agents-guide.md)** - Comprehensive agent reference (45 min read)
|
||||
- **[Agents Guide](./agents-guide.md)** - Comprehensive agent reference
|
||||
- 12 specialized BMM agents + BMad Master
|
||||
- Agent roles, workflows, and when to use them
|
||||
- Agent customization system
|
||||
- Best practices and common patterns
|
||||
|
||||
- **[Party Mode Guide](./party-mode.md)** - Multi-agent collaboration (20 min read)
|
||||
- **[Party Mode Guide](./party-mode.md)** - Multi-agent collaboration
|
||||
- How party mode works (19+ agents collaborate in real-time)
|
||||
- When to use it (strategic, creative, cross-functional, complex)
|
||||
- Example party compositions
|
||||
|
|
@ -65,21 +61,17 @@ Complete guide to BMM's AI agent team:
|
|||
- Agent customization in party mode
|
||||
- Best practices
|
||||
|
||||
---
|
||||
|
||||
## 🔧 Working with Existing Code
|
||||
|
||||
Comprehensive guide for brownfield development:
|
||||
|
||||
- **[Brownfield Development Guide](./brownfield-guide.md)** - Complete guide for existing codebases (53 min read)
|
||||
- **[Brownfield Development Guide](./brownfield-guide.md)** - Complete guide for existing codebases
|
||||
- Documentation phase strategies
|
||||
- Track selection for brownfield
|
||||
- Integration with existing patterns
|
||||
- Phase-by-phase workflow guidance
|
||||
- Common scenarios
|
||||
|
||||
---
|
||||
|
||||
## 📚 Quick References
|
||||
|
||||
Essential reference materials:
|
||||
|
|
@ -88,8 +80,6 @@ Essential reference materials:
|
|||
- **[FAQ](./faq.md)** - Frequently asked questions across all topics
|
||||
- **[Enterprise Agentic Development](./enterprise-agentic-development.md)** - Team collaboration strategies
|
||||
|
||||
---
|
||||
|
||||
## 🎯 Choose Your Path
|
||||
|
||||
### I need to...
|
||||
|
|
@ -109,11 +99,6 @@ Essential reference materials:
|
|||
**Understand planning tracks and methodology**
|
||||
→ See [Scale Adaptive System](./scale-adaptive-system.md)
|
||||
|
||||
**Find specific commands or answers**
|
||||
→ Check [FAQ](./faq.md)
|
||||
|
||||
---
|
||||
|
||||
## 📋 Workflow Guides
|
||||
|
||||
Comprehensive documentation for all BMM workflows organized by phase:
|
||||
|
|
@ -162,18 +147,6 @@ For detailed technical documentation on specific complex workflows:
|
|||
- Implementation patterns for agent consistency
|
||||
- Adaptive facilitation approach
|
||||
|
||||
---
|
||||
|
||||
## 🧪 Testing and Quality
|
||||
|
||||
Quality assurance guidance:
|
||||
|
||||
<!-- Test Architect documentation to be added -->
|
||||
|
||||
- Test design workflows
|
||||
- Quality gates
|
||||
- Risk assessment
|
||||
|
||||
## 🏗️ Module Structure
|
||||
|
||||
Understanding BMM components:
|
||||
|
|
@ -184,8 +157,6 @@ Understanding BMM components:
|
|||
- Teams and collaboration
|
||||
- Best practices
|
||||
|
||||
---
|
||||
|
||||
## 🌐 External Resources
|
||||
|
||||
### Community and Support
|
||||
|
|
@ -194,56 +165,4 @@ Understanding BMM components:
|
|||
- **[GitHub Issues](https://github.com/bmad-code-org/BMAD-METHOD/issues)** - Report bugs or request features
|
||||
- **[YouTube Channel](https://www.youtube.com/@BMadCode)** - Video tutorials and walkthroughs
|
||||
|
||||
### Additional Documentation
|
||||
|
||||
- **[IDE Setup Guides](../../../docs/ide-info/)** - Configure your development environment
|
||||
- Claude Code
|
||||
- Cursor
|
||||
- Windsurf
|
||||
- VS Code
|
||||
- Other IDEs
|
||||
|
||||
---
|
||||
|
||||
## 📊 Documentation Map
|
||||
|
||||
```mermaid
|
||||
flowchart TD
|
||||
START[New to BMM?]
|
||||
START --> QS[Quick Start Guide]
|
||||
|
||||
QS --> DECIDE{What are you building?}
|
||||
|
||||
DECIDE -->|Bug fix or<br/>small feature| QF[BMAD Quick Flow]
|
||||
DECIDE -->|Need rapid<br/>development| PE[Principal Engineer]
|
||||
DECIDE -->|New project| SAS[Scale Adaptive System]
|
||||
DECIDE -->|Existing codebase| BF[Brownfield Guide]
|
||||
|
||||
QF --> IMPL[Implementation]
|
||||
PE --> IMPL
|
||||
SAS --> IMPL
|
||||
BF --> IMPL
|
||||
|
||||
IMPL --> REF[Quick References<br/>Glossary, FAQ]
|
||||
|
||||
style START fill:#bfb,stroke:#333,stroke-width:2px,color:#000
|
||||
style QS fill:#bbf,stroke:#333,stroke-width:2px,color:#000
|
||||
style DECIDE fill:#ffb,stroke:#333,stroke-width:2px,color:#000
|
||||
style QF fill:#e1f5fe,stroke:#333,stroke-width:2px,color:#000
|
||||
style PE fill:#fff3e0,stroke:#333,stroke-width:2px,color:#000
|
||||
style IMPL fill:#f9f,stroke:#333,stroke-width:2px,color:#000
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 💡 Tips for Using This Documentation
|
||||
|
||||
1. **Start with Quick Start** if you're new - it provides the essential foundation
|
||||
2. **Use the FAQ** to find quick answers without reading entire guides
|
||||
3. **Bookmark Glossary** for terminology references while reading other docs
|
||||
4. **Follow the suggested paths** above based on your specific situation
|
||||
5. **Join Discord** for interactive help and community insights
|
||||
|
||||
---
|
||||
|
||||
**Ready to begin?** → [Start with the Quick Start Guide](./quick-start.md)
|
||||
|
|
|
|||
File diff suppressed because it is too large
Load Diff
|
|
@ -8,15 +8,16 @@
|
|||
|
||||
## Overview
|
||||
|
||||
BMAD Quick Flow is the fastest path from idea to production in the BMAD Method ecosystem. It's a streamlined 3-step process designed for rapid development without sacrificing quality. Perfect for experienced teams who need to move fast or for smaller features that don't require extensive planning.
|
||||
BMAD Quick Flow is the fastest path from idea to production in the BMAD Method ecosystem. It's a streamlined 3-step process designed for rapid spec driven development without sacrificing quality. Perfect for experienced teams who need to move fast or for smaller features or 1 off efforts that don't require extensive planning.
|
||||
|
||||
### When to Use Quick Flow
|
||||
|
||||
**Perfect For:**
|
||||
|
||||
- Bug fixes and patches
|
||||
- Small feature additions (1-3 days of work)
|
||||
- Small feature additions
|
||||
- Proof of concepts and prototypes
|
||||
- Mid course corrections or additions of something missed in BMM full planning
|
||||
- Performance optimizations
|
||||
- API endpoint additions
|
||||
- UI component enhancements
|
||||
|
|
@ -31,42 +32,19 @@ BMAD Quick Flow is the fastest path from idea to production in the BMAD Method e
|
|||
- Projects requiring extensive UX design
|
||||
- Enterprise-wide initiatives
|
||||
- Mission-critical systems with compliance requirements
|
||||
- Ideas with many 'moving pieces'
|
||||
|
||||
---
|
||||
|
||||
## The Quick Flow Process
|
||||
|
||||
```mermaid
|
||||
flowchart TD
|
||||
START[Idea/Requirement] --> DECIDE{Planning Needed?}
|
||||
Utilizing the Quick Flow Solo Dev, this one agent can do it all!
|
||||
|
||||
DECIDE -->|Yes| CREATE[create-tech-spec]
|
||||
DECIDE -->|No| DIRECT[Direct Development]
|
||||
1. Create an (option) Technical Specification
|
||||
2. Develop with Tests
|
||||
3. AI Driven Code Review
|
||||
|
||||
CREATE --> SPEC[Technical Specification]
|
||||
SPEC --> DEV[quick-dev]
|
||||
DIRECT --> DEV
|
||||
|
||||
DEV --> COMPLETE{Implementation Complete}
|
||||
|
||||
COMPLETE -->|Success| REVIEW{Code Review?}
|
||||
COMPLETE -->|Issues| DEBUG[Debug & Fix]
|
||||
DEBUG --> DEV
|
||||
|
||||
REVIEW -->|Yes| CODE_REVIEW[code-review]
|
||||
REVIEW -->|No| DONE[Production Ready]
|
||||
|
||||
CODE_REVIEW --> FIXES{Fixes Needed?}
|
||||
FIXES -->|Yes| DEBUG
|
||||
FIXES -->|No| DONE
|
||||
|
||||
style START fill:#e1f5fe
|
||||
style CREATE fill:#f3e5f5
|
||||
style SPEC fill:#e8f5e9
|
||||
style DEV fill:#fff3e0
|
||||
style CODE_REVIEW fill:#f1f8e9
|
||||
style DONE fill:#e0f2f1
|
||||
```
|
||||
That's it! Lets look at each step in more detail though.
|
||||
|
||||
### Step 1: Optional Technical Specification
|
||||
|
||||
|
|
@ -103,7 +81,7 @@ The `create-tech-spec` workflow transforms requirements into implementation-read
|
|||
- Make adjustments as needed
|
||||
- Save to sprint artifacts
|
||||
|
||||
**Output:** `{sprint_artifacts}/tech-spec-{slug}.md`
|
||||
**Output:** `{implementation_artifacts}/tech-spec-{slug}.md`
|
||||
|
||||
### Step 2: Development
|
||||
|
||||
|
|
|
|||
|
|
@ -1,542 +0,0 @@
|
|||
# BMM Frequently Asked Questions
|
||||
|
||||
Quick answers to common questions about the BMad Method Module.
|
||||
|
||||
---
|
||||
|
||||
## Table of Contents
|
||||
|
||||
- [Getting Started](#getting-started)
|
||||
- [Choosing the Right Level](#choosing-the-right-level)
|
||||
- [Workflows and Phases](#workflows-and-phases)
|
||||
- [Planning Documents](#planning-documents)
|
||||
- [Implementation](#implementation)
|
||||
- [Brownfield Development](#brownfield-development)
|
||||
- [Tools and Technical](#tools-and-technical)
|
||||
|
||||
---
|
||||
|
||||
## Getting Started
|
||||
|
||||
### Q: Do I always need to run workflow-init?
|
||||
|
||||
**A:** No, once you learn the flow you can go directly to workflows. However, workflow-init is helpful because it:
|
||||
|
||||
- Determines your project's appropriate level automatically
|
||||
- Creates the tracking status file
|
||||
- Routes you to the correct starting workflow
|
||||
|
||||
For experienced users: use the [Quick Reference](./quick-start.md#quick-reference-agent-document-mapping) to go directly to the right agent/workflow.
|
||||
|
||||
### Q: Why do I need fresh chats for each workflow?
|
||||
|
||||
**A:** Context-intensive workflows (like brainstorming, PRD creation, architecture design) can cause AI hallucinations if run in sequence within the same chat. Starting fresh ensures the agent has maximum context capacity for each workflow. This is particularly important for:
|
||||
|
||||
- Planning workflows (PRD, architecture)
|
||||
- Analysis workflows (brainstorming, research)
|
||||
- Complex story implementation
|
||||
|
||||
Quick workflows like status checks can reuse chats safely.
|
||||
|
||||
### Q: Can I skip workflow-status and just start working?
|
||||
|
||||
**A:** Yes, if you already know your project level and which workflow comes next. workflow-status is mainly useful for:
|
||||
|
||||
- New projects (guides initial setup)
|
||||
- When you're unsure what to do next
|
||||
- After breaks in work (reminds you where you left off)
|
||||
- Checking overall progress
|
||||
|
||||
### Q: What's the minimum I need to get started?
|
||||
|
||||
**A:** For the fastest path:
|
||||
|
||||
1. Install BMad Method: `npx bmad-method@alpha install`
|
||||
2. For small changes: Load PM agent → run tech-spec → implement
|
||||
3. For larger projects: Load PM agent → run prd → architect → implement
|
||||
|
||||
### Q: How do I know if I'm in Phase 1, 2, 3, or 4?
|
||||
|
||||
**A:** Check your `bmm-workflow-status.md` file (created by workflow-init). It shows your current phase and progress. If you don't have this file, you can also tell by what you're working on:
|
||||
|
||||
- **Phase 1** - Brainstorming, research, product brief (optional)
|
||||
- **Phase 2** - Creating either a PRD or tech-spec (always required)
|
||||
- **Phase 3** - Architecture design (Level 2-4 only)
|
||||
- **Phase 4** - Actually writing code, implementing stories
|
||||
|
||||
---
|
||||
|
||||
## Choosing the Right Level
|
||||
|
||||
### Q: How do I know which level my project is?
|
||||
|
||||
**A:** Use workflow-init for automatic detection, or self-assess using these keywords:
|
||||
|
||||
- **Level 0:** "fix", "bug", "typo", "small change", "patch" → 1 story
|
||||
- **Level 1:** "simple", "basic", "small feature", "add" → 2-10 stories
|
||||
- **Level 2:** "dashboard", "several features", "admin panel" → 5-15 stories
|
||||
- **Level 3:** "platform", "integration", "complex", "system" → 12-40 stories
|
||||
- **Level 4:** "enterprise", "multi-tenant", "multiple products" → 40+ stories
|
||||
|
||||
When in doubt, start smaller. You can always run create-prd later if needed.
|
||||
|
||||
### Q: Can I change levels mid-project?
|
||||
|
||||
**A:** Yes! If you started at Level 1 but realize it's Level 2, you can run create-prd to add proper planning docs. The system is flexible - your initial level choice isn't permanent.
|
||||
|
||||
### Q: What if workflow-init suggests the wrong level?
|
||||
|
||||
**A:** You can override it! workflow-init suggests a level but always asks for confirmation. If you disagree, just say so and choose the level you think is appropriate. Trust your judgment.
|
||||
|
||||
### Q: Do I always need architecture for Level 2?
|
||||
|
||||
**A:** No, architecture is **optional** for Level 2. Only create architecture if you need system-level design. Many Level 2 projects work fine with just PRD created during planning.
|
||||
|
||||
### Q: What's the difference between Level 1 and Level 2?
|
||||
|
||||
**A:**
|
||||
|
||||
- **Level 1:** 1-10 stories, uses tech-spec (simpler, faster), no architecture
|
||||
- **Level 2:** 5-15 stories, uses PRD (product-focused), optional architecture
|
||||
|
||||
The overlap (5-10 stories) is intentional. Choose based on:
|
||||
|
||||
- Need product-level planning? → Level 2
|
||||
- Just need technical plan? → Level 1
|
||||
- Multiple epics? → Level 2
|
||||
- Single epic? → Level 1
|
||||
|
||||
---
|
||||
|
||||
## Workflows and Phases
|
||||
|
||||
### Q: What's the difference between workflow-status and workflow-init?
|
||||
|
||||
**A:**
|
||||
|
||||
- **workflow-status:** Checks existing status and tells you what's next (use when continuing work)
|
||||
- **workflow-init:** Creates new status file and sets up project (use when starting new project)
|
||||
|
||||
If status file exists, use workflow-status. If not, use workflow-init.
|
||||
|
||||
### Q: Can I skip Phase 1 (Analysis)?
|
||||
|
||||
**A:** Yes! Phase 1 is optional for all levels, though recommended for complex projects. Skip if:
|
||||
|
||||
- Requirements are clear
|
||||
- No research needed
|
||||
- Time-sensitive work
|
||||
- Small changes (Level 0-1)
|
||||
|
||||
### Q: When is Phase 3 (Architecture) required?
|
||||
|
||||
**A:**
|
||||
|
||||
- **Level 0-1:** Never (skip entirely)
|
||||
- **Level 2:** Optional (only if system design needed)
|
||||
- **Level 3-4:** Required (comprehensive architecture mandatory)
|
||||
|
||||
### Q: What happens if I skip a recommended workflow?
|
||||
|
||||
**A:** Nothing breaks! Workflows are guidance, not enforcement. However, skipping recommended workflows (like architecture for Level 3) may cause:
|
||||
|
||||
- Integration issues during implementation
|
||||
- Rework due to poor planning
|
||||
- Conflicting design decisions
|
||||
- Longer development time overall
|
||||
|
||||
### Q: How do I know when Phase 3 is complete and I can start Phase 4?
|
||||
|
||||
**A:** For Level 3-4, run the implementation-readiness workflow. It validates PRD + Architecture + Epics + UX (optional) are aligned before implementation. Pass the gate check = ready for Phase 4.
|
||||
|
||||
### Q: Can I run workflows in parallel or do they have to be sequential?
|
||||
|
||||
**A:** Most workflows must be sequential within a phase:
|
||||
|
||||
- Phase 1: brainstorm → research → product-brief (optional order)
|
||||
- Phase 2: PRD must complete before moving forward
|
||||
- Phase 3: architecture → epics+stories → implementation-readiness (sequential)
|
||||
- Phase 4: Stories within an epic should generally be sequential, but stories in different epics can be parallel if you have capacity
|
||||
|
||||
---
|
||||
|
||||
## Planning Documents
|
||||
|
||||
### Q: Why no tech-spec at Level 2+?
|
||||
|
||||
**A:** Level 2+ projects need product-level planning (PRD) and system-level design (Architecture), which tech-spec doesn't provide. Tech-spec is too narrow for coordinating multiple features. Instead, Level 2-4 uses:
|
||||
|
||||
- PRD (product vision, functional requirements, non-functional requirements)
|
||||
- Architecture (system design)
|
||||
- Epics+Stories (created AFTER architecture is complete)
|
||||
|
||||
### Q: Do I need a PRD for a bug fix?
|
||||
|
||||
**A:** No! Bug fixes are typically Level 0 (single atomic change). Use Quick Spec Flow:
|
||||
|
||||
- Load PM agent
|
||||
- Run tech-spec workflow
|
||||
- Implement immediately
|
||||
|
||||
PRDs are for Level 2-4 projects with multiple features requiring product-level coordination.
|
||||
|
||||
### Q: Can I skip the product brief?
|
||||
|
||||
**A:** Yes, product brief is always optional. It's most valuable for:
|
||||
|
||||
- Level 3-4 projects needing strategic direction
|
||||
- Projects with stakeholders requiring alignment
|
||||
- Novel products needing market research
|
||||
- When you want to explore solution space before committing
|
||||
|
||||
---
|
||||
|
||||
## Implementation
|
||||
|
||||
### Q: Does create-story include implementation context?
|
||||
|
||||
**A:** Yes! The create-story workflow generates story files that include implementation-specific guidance, references existing patterns from your documentation, and provides technical context. The workflow loads your architecture, PRD, and existing project documentation to create comprehensive stories. For Quick Flow projects using tech-spec, the tech-spec itself is already comprehensive, so stories can be simpler.
|
||||
|
||||
### Q: How do I mark a story as done?
|
||||
|
||||
**A:** After dev-story completes and code-review passes:
|
||||
|
||||
1. Open `sprint-status.yaml` (created by sprint-planning)
|
||||
2. Change the story status from `review` to `done`
|
||||
3. Save the file
|
||||
|
||||
### Q: Can I work on multiple stories at once?
|
||||
|
||||
**A:** Yes, if you have capacity! Stories within different epics can be worked in parallel. However, stories within the same epic are usually sequential because they build on each other.
|
||||
|
||||
### Q: What if my story takes longer than estimated?
|
||||
|
||||
**A:** That's normal! Stories are estimates. If implementation reveals more complexity:
|
||||
|
||||
1. Continue working until DoD is met
|
||||
2. Consider if story should be split
|
||||
3. Document learnings in retrospective
|
||||
4. Adjust future estimates based on this learning
|
||||
|
||||
### Q: When should I run retrospective?
|
||||
|
||||
**A:** After completing all stories in an epic (when epic is done). Retrospectives capture:
|
||||
|
||||
- What went well
|
||||
- What could improve
|
||||
- Technical insights
|
||||
- Learnings for future epics
|
||||
|
||||
Don't wait until project end - run after each epic for continuous improvement.
|
||||
|
||||
---
|
||||
|
||||
## Brownfield Development
|
||||
|
||||
### Q: What is brownfield vs greenfield?
|
||||
|
||||
**A:**
|
||||
|
||||
- **Greenfield:** New project, starting from scratch, clean slate
|
||||
- **Brownfield:** Existing project, working with established codebase and patterns
|
||||
|
||||
### Q: Do I have to run document-project for brownfield?
|
||||
|
||||
**A:** Highly recommended, especially if:
|
||||
|
||||
- No existing documentation
|
||||
- Documentation is outdated
|
||||
- AI agents need context about existing code
|
||||
- Level 2-4 complexity
|
||||
|
||||
You can skip it if you have comprehensive, up-to-date documentation including `docs/index.md`.
|
||||
|
||||
### Q: What if I forget to run document-project on brownfield?
|
||||
|
||||
**A:** Workflows will lack context about existing code. You may get:
|
||||
|
||||
- Suggestions that don't match existing patterns
|
||||
- Integration approaches that miss existing APIs
|
||||
- Architecture that conflicts with current structure
|
||||
|
||||
Run document-project and restart planning with proper context.
|
||||
|
||||
### Q: Can I use Quick Spec Flow for brownfield projects?
|
||||
|
||||
**A:** Yes! Quick Spec Flow works great for brownfield. It will:
|
||||
|
||||
- Auto-detect your existing stack
|
||||
- Analyze brownfield code patterns
|
||||
- Detect conventions and ask for confirmation
|
||||
- Generate context-rich tech-spec that respects existing code
|
||||
|
||||
Perfect for bug fixes and small features in existing codebases.
|
||||
|
||||
### Q: How does workflow-init handle brownfield with old planning docs?
|
||||
|
||||
**A:** workflow-init asks about YOUR current work first, then uses old artifacts as context:
|
||||
|
||||
1. Shows what it found (old PRD, epics, etc.)
|
||||
2. Asks: "Is this work in progress, previous effort, or proposed work?"
|
||||
3. If previous effort: Asks you to describe your NEW work
|
||||
4. Determines level based on YOUR work, not old artifacts
|
||||
|
||||
This prevents old Level 3 PRDs from forcing Level 3 workflow for new Level 0 bug fix.
|
||||
|
||||
### Q: What if my existing code doesn't follow best practices?
|
||||
|
||||
**A:** Quick Spec Flow detects your conventions and asks: "Should I follow these existing conventions?" You decide:
|
||||
|
||||
- **Yes** → Maintain consistency with current codebase
|
||||
- **No** → Establish new standards (document why in tech-spec)
|
||||
|
||||
BMM respects your choice - it won't force modernization, but it will offer it.
|
||||
|
||||
---
|
||||
|
||||
## Tools and Technical
|
||||
|
||||
### Q: Why are my Mermaid diagrams not rendering?
|
||||
|
||||
**A:** Common issues:
|
||||
|
||||
1. Missing language tag: Use ` ```mermaid` not just ` ``` `
|
||||
2. Syntax errors in diagram (validate at mermaid.live)
|
||||
3. Tool doesn't support Mermaid (check your Markdown renderer)
|
||||
|
||||
All BMM docs use valid Mermaid syntax that should render in GitHub, VS Code, and most IDEs.
|
||||
|
||||
### Q: Can I use BMM with GitHub Copilot / Cursor / other AI tools?
|
||||
|
||||
**A:** Yes! BMM is complementary. BMM handles:
|
||||
|
||||
- Project planning and structure
|
||||
- Workflow orchestration
|
||||
- Agent Personas and expertise
|
||||
- Documentation generation
|
||||
- Quality gates
|
||||
|
||||
Your AI coding assistant handles:
|
||||
|
||||
- Line-by-line code completion
|
||||
- Quick refactoring
|
||||
- Test generation
|
||||
|
||||
Use them together for best results.
|
||||
|
||||
### Q: What IDEs/tools support BMM?
|
||||
|
||||
**A:** BMM requires tools with **agent mode** and access to **high-quality LLM models** that can load and follow complex workflows, then properly implement code changes.
|
||||
|
||||
**Recommended Tools:**
|
||||
|
||||
- **Claude Code** ⭐ **Best choice**
|
||||
- Sonnet 4.5 (excellent workflow following, coding, reasoning)
|
||||
- Opus (maximum context, complex planning)
|
||||
- Native agent mode designed for BMM workflows
|
||||
|
||||
- **Cursor**
|
||||
- Supports Anthropic (Claude) and OpenAI models
|
||||
- Agent mode with composer
|
||||
- Good for developers who prefer Cursor's UX
|
||||
|
||||
- **Windsurf**
|
||||
- Multi-model support
|
||||
- Agent capabilities
|
||||
- Suitable for BMM workflows
|
||||
|
||||
**What Matters:**
|
||||
|
||||
1. **Agent mode** - Can load long workflow instructions and maintain context
|
||||
2. **High-quality LLM** - Models ranked high on SWE-bench (coding benchmarks)
|
||||
3. **Model selection** - Access to Claude Sonnet 4.5, Opus, or GPT-4o class models
|
||||
4. **Context capacity** - Can handle large planning documents and codebases
|
||||
|
||||
**Why model quality matters:** BMM workflows require LLMs that can follow multi-step processes, maintain context across phases, and implement code that adheres to specifications. Tools with weaker models will struggle with workflow adherence and code quality.
|
||||
|
||||
See [IDE Setup Guides](https://github.com/bmad-code-org/BMAD-METHOD/tree/main/docs/ide-info) for configuration specifics.
|
||||
|
||||
### Q: Can I customize agents?
|
||||
|
||||
**A:** Yes! Agents are installed as markdown files with XML-style content (optimized for LLMs, readable by any model). Create customization files in `_bmad/_config/agents/[agent-name].customize.yaml` to override default behaviors while keeping core functionality intact. See agent documentation for customization options.
|
||||
|
||||
**Note:** While source agents in this repo are YAML, they install as `.md` files with XML-style tags - a format any LLM can read and follow.
|
||||
|
||||
### Q: What happens to my planning docs after implementation?
|
||||
|
||||
**A:** Keep them! They serve as:
|
||||
|
||||
- Historical record of decisions
|
||||
- Onboarding material for new team members
|
||||
- Reference for future enhancements
|
||||
- Audit trail for compliance
|
||||
|
||||
For enterprise projects (Level 4), consider archiving completed planning artifacts to keep workspace clean.
|
||||
|
||||
### Q: Can I use BMM for non-software projects?
|
||||
|
||||
**A:** BMM is optimized for software development, but the methodology principles (scale-adaptive planning, just-in-time design, context injection) can apply to other complex project types. You'd need to adapt workflows and agents for your domain.
|
||||
|
||||
---
|
||||
|
||||
## Advanced Questions
|
||||
|
||||
### Q: What if my project grows from Level 1 to Level 3?
|
||||
|
||||
**A:** Totally fine! When you realize scope has grown:
|
||||
|
||||
1. Run create-prd to add product-level planning
|
||||
2. Run create-architecture for system design
|
||||
3. Use existing tech-spec as input for PRD
|
||||
4. Continue with updated level
|
||||
|
||||
The system is flexible - growth is expected.
|
||||
|
||||
### Q: Can I mix greenfield and brownfield approaches?
|
||||
|
||||
**A:** Yes! Common scenario: adding new greenfield feature to brownfield codebase. Approach:
|
||||
|
||||
1. Run document-project for brownfield context
|
||||
2. Use greenfield workflows for new feature planning
|
||||
3. Explicitly document integration points between new and existing
|
||||
4. Test integration thoroughly
|
||||
|
||||
### Q: How do I handle urgent hotfixes during a sprint?
|
||||
|
||||
**A:** Use correct-course workflow or just:
|
||||
|
||||
1. Save your current work state
|
||||
2. Load PM agent → quick tech-spec for hotfix
|
||||
3. Implement hotfix (Level 0 flow)
|
||||
4. Deploy hotfix
|
||||
5. Return to original sprint work
|
||||
|
||||
Level 0 Quick Spec Flow is perfect for urgent fixes.
|
||||
|
||||
### Q: What if I disagree with the workflow's recommendations?
|
||||
|
||||
**A:** Workflows are guidance, not enforcement. If a workflow recommends something that doesn't make sense for your context:
|
||||
|
||||
- Explain your reasoning to the agent
|
||||
- Ask for alternative approaches
|
||||
- Skip the recommendation if you're confident
|
||||
- Document why you deviated (for future reference)
|
||||
|
||||
Trust your expertise - BMM supports your decisions.
|
||||
|
||||
### Q: Can multiple developers work on the same BMM project?
|
||||
|
||||
**A:** Yes! But the paradigm is fundamentally different from traditional agile teams.
|
||||
|
||||
**Key Difference:**
|
||||
|
||||
- **Traditional:** Multiple devs work on stories within one epic (months)
|
||||
- **Agentic:** Each dev owns complete epics (days)
|
||||
|
||||
**In traditional agile:** A team of 5 devs might spend 2-3 months on a single epic, with each dev owning different stories.
|
||||
|
||||
**With BMM + AI agents:** A single dev can complete an entire epic in 1-3 days. What used to take months now takes days.
|
||||
|
||||
**Team Work Distribution:**
|
||||
|
||||
- **Recommended:** Split work by **epic** (not story)
|
||||
- Each developer owns complete epics end-to-end
|
||||
- Parallel work happens at epic level
|
||||
- Minimal coordination needed
|
||||
|
||||
**For full-stack apps:**
|
||||
|
||||
- Frontend and backend can be separate epics (unusual in traditional agile)
|
||||
- Frontend dev owns all frontend epics
|
||||
- Backend dev owns all backend epics
|
||||
- Works because delivery is so fast
|
||||
|
||||
**Enterprise Considerations:**
|
||||
|
||||
- Use **git submodules** for BMM installation (not .gitignore)
|
||||
- Allows personal configurations without polluting main repo
|
||||
- Teams may use different AI tools (Claude Code, Cursor, etc.)
|
||||
- Developers may follow different methods or create custom agents/workflows
|
||||
|
||||
**Quick Tips:**
|
||||
|
||||
- Share `sprint-status.yaml` (single source of truth)
|
||||
- Assign entire epics to developers (not individual stories)
|
||||
- Coordinate at epic boundaries, not story level
|
||||
- Use git submodules for BMM in enterprise settings
|
||||
|
||||
**For comprehensive coverage of enterprise team collaboration, work distribution strategies, git submodule setup, and velocity expectations, see:**
|
||||
|
||||
👉 **[Enterprise Agentic Development Guide](./enterprise-agentic-development.md)**
|
||||
|
||||
### Q: What is party mode and when should I use it?
|
||||
|
||||
**A:** Party mode is a unique multi-agent collaboration feature where ALL your installed agents (19+ from BMM, CIS, BMB, custom modules) discuss your challenges together in real-time.
|
||||
|
||||
**How it works:**
|
||||
|
||||
1. Run `/bmad:core:workflows:party-mode` (or `*party-mode` from any agent)
|
||||
2. Introduce your topic
|
||||
3. BMad Master selects 2-3 most relevant agents per message
|
||||
4. Agents cross-talk, debate, and build on each other's ideas
|
||||
|
||||
**Best for:**
|
||||
|
||||
- Strategic decisions with trade-offs (architecture choices, tech stack, scope)
|
||||
- Creative brainstorming (game design, product innovation, UX ideation)
|
||||
- Cross-functional alignment (epic kickoffs, retrospectives, phase transitions)
|
||||
- Complex problem-solving (multi-faceted challenges, risk assessment)
|
||||
|
||||
**Example parties:**
|
||||
|
||||
- **Product Strategy:** PM + Innovation Strategist (CIS) + Analyst
|
||||
- **Technical Design:** Architect + Creative Problem Solver (CIS) + Game Architect
|
||||
- **User Experience:** UX Designer + Design Thinking Coach (CIS) + Storyteller (CIS)
|
||||
|
||||
**Why it's powerful:**
|
||||
|
||||
- Diverse perspectives (technical, creative, strategic)
|
||||
- Healthy debate reveals blind spots
|
||||
- Emergent insights from agent interaction
|
||||
- Natural collaboration across modules
|
||||
|
||||
**For complete documentation:**
|
||||
|
||||
👉 **[Party Mode Guide](./party-mode.md)** - How it works, when to use it, example compositions, best practices
|
||||
|
||||
---
|
||||
|
||||
## Getting Help
|
||||
|
||||
### Q: Where do I get help if my question isn't answered here?
|
||||
|
||||
**A:**
|
||||
|
||||
1. Search [Complete Documentation](./README.md) for related topics
|
||||
2. Ask in [Discord Community](https://discord.gg/gk8jAdXWmj) (#general-dev)
|
||||
3. Open a [GitHub Issue](https://github.com/bmad-code-org/BMAD-METHOD/issues)
|
||||
4. Watch [YouTube Tutorials](https://www.youtube.com/@BMadCode)
|
||||
|
||||
### Q: How do I report a bug or request a feature?
|
||||
|
||||
**A:** Open a GitHub issue at: <https://github.com/bmad-code-org/BMAD-METHOD/issues>
|
||||
|
||||
Please include:
|
||||
|
||||
- BMM version (check your installed version)
|
||||
- Steps to reproduce (for bugs)
|
||||
- Expected vs actual behavior
|
||||
- Relevant workflow or agent involved
|
||||
|
||||
---
|
||||
|
||||
## Related Documentation
|
||||
|
||||
- [Quick Start Guide](./quick-start.md) - Get started with BMM
|
||||
- [Glossary](./glossary.md) - Terminology reference
|
||||
- [Scale Adaptive System](./scale-adaptive-system.md) - Understanding levels
|
||||
- [Brownfield Guide](./brownfield-guide.md) - Existing codebase workflows
|
||||
|
||||
---
|
||||
|
||||
**Have a question not answered here?** Please [open an issue](https://github.com/bmad-code-org/BMAD-METHOD/issues) or ask in [Discord](https://discord.gg/gk8jAdXWmj) so we can add it!
|
||||
|
|
@ -1,306 +0,0 @@
|
|||
# BMM Glossary
|
||||
|
||||
Comprehensive terminology reference for the BMad Method Module.
|
||||
|
||||
---
|
||||
|
||||
## Navigation
|
||||
|
||||
- [Core Concepts](#core-concepts)
|
||||
- [Scale and Complexity](#scale-and-complexity)
|
||||
- [Planning Documents](#planning-documents)
|
||||
- [Workflow and Phases](#workflow-and-phases)
|
||||
- [Agents and Roles](#agents-and-roles)
|
||||
- [Status and Tracking](#status-and-tracking)
|
||||
- [Project Types](#project-types)
|
||||
- [Implementation Terms](#implementation-terms)
|
||||
|
||||
---
|
||||
|
||||
## Core Concepts
|
||||
|
||||
### BMM (BMad Method Module)
|
||||
|
||||
Core orchestration system for AI-driven agile development, providing comprehensive lifecycle management through specialized agents and workflows.
|
||||
|
||||
### BMad Method
|
||||
|
||||
The complete methodology for AI-assisted software development, encompassing planning, architecture, implementation, and quality assurance workflows that adapt to project complexity.
|
||||
|
||||
### Scale-Adaptive System
|
||||
|
||||
BMad Method's intelligent workflow orchestration that automatically adjusts planning depth, documentation requirements, and implementation processes based on project needs through three distinct planning tracks (Quick Flow, BMad Method, Enterprise Method).
|
||||
|
||||
### Agent
|
||||
|
||||
A specialized AI persona with specific expertise (PM, Architect, SM, DEV, TEA) that guides users through workflows and creates deliverables. Agents have defined capabilities, communication styles, and workflow access.
|
||||
|
||||
### Workflow
|
||||
|
||||
A multi-step guided process that orchestrates AI agent activities to produce specific deliverables. Workflows are interactive and adapt to user context.
|
||||
|
||||
---
|
||||
|
||||
## Scale and Complexity
|
||||
|
||||
### Quick Flow Track
|
||||
|
||||
Fast implementation track using tech-spec planning only. Best for bug fixes, small features, and changes with clear scope. Typical range: 1-15 stories. No architecture phase needed. Examples: bug fixes, OAuth login, search features.
|
||||
|
||||
### BMad Method Track
|
||||
|
||||
Full product planning track using PRD + Architecture + UX. Best for products, platforms, and complex features requiring system design. Typical range: 10-50+ stories. Examples: admin dashboards, e-commerce platforms, SaaS products.
|
||||
|
||||
### Enterprise Method Track
|
||||
|
||||
Extended enterprise planning track adding Security Architecture, DevOps Strategy, and Test Strategy to BMad Method. Best for enterprise requirements, compliance needs, and multi-tenant systems. Typical range: 30+ stories. Examples: multi-tenant platforms, compliance-driven systems, mission-critical applications.
|
||||
|
||||
### Planning Track
|
||||
|
||||
The methodology path (Quick Flow, BMad Method, or Enterprise Method) chosen for a project based on planning needs, complexity, and requirements rather than story count alone.
|
||||
|
||||
**Note:** Story counts are guidance, not definitions. Tracks are determined by what planning the project needs, not story math.
|
||||
|
||||
---
|
||||
|
||||
## Planning Documents
|
||||
|
||||
### Tech-Spec (Technical Specification)
|
||||
|
||||
**Quick Flow track only.** Comprehensive technical plan created upfront that serves as the primary planning document for small changes or features. Contains problem statement, solution approach, file-level changes, stack detection (brownfield), testing strategy, and developer resources.
|
||||
|
||||
### PRD (Product Requirements Document)
|
||||
|
||||
**BMad Method/Enterprise tracks.** Product-level planning document containing vision, goals, Functional Requirements (FRs), Non-Functional Requirements (NFRs), success criteria, and UX considerations. Replaces tech-spec for larger projects that need product planning. **V6 Note:** PRD focuses on WHAT to build (requirements). Epic+Stories are created separately AFTER architecture via create-epics-and-stories workflow.
|
||||
|
||||
### Architecture Document
|
||||
|
||||
**BMad Method/Enterprise tracks.** System-wide design document defining structure, components, interactions, data models, integration patterns, security, performance, and deployment.
|
||||
|
||||
**Scale-Adaptive:** Architecture complexity scales with track - BMad Method is lightweight to moderate, Enterprise Method is comprehensive with security/devops/test strategies.
|
||||
|
||||
### Epics
|
||||
|
||||
High-level feature groupings that contain multiple related stories. Typically span 5-15 stories each and represent cohesive functionality (e.g., "User Authentication Epic").
|
||||
|
||||
### Product Brief
|
||||
|
||||
Optional strategic planning document created in Phase 1 (Analysis) that captures product vision, market context, user needs, and high-level requirements before detailed planning.
|
||||
|
||||
### GDD (Game Design Document)
|
||||
|
||||
Game development equivalent of PRD, created by Game Designer agent for game projects.
|
||||
|
||||
---
|
||||
|
||||
## Workflow and Phases
|
||||
|
||||
### Phase 0: Documentation (Prerequisite)
|
||||
|
||||
**Conditional phase for brownfield projects.** Creates comprehensive codebase documentation before planning. Only required if existing documentation is insufficient for AI agents.
|
||||
|
||||
### Phase 1: Analysis (Optional)
|
||||
|
||||
Discovery and research phase including brainstorming, research workflows, and product brief creation. Optional for Quick Flow, recommended for BMad Method, required for Enterprise Method.
|
||||
|
||||
### Phase 2: Planning (Required)
|
||||
|
||||
**Always required.** Creates formal requirements and work breakdown. Routes to tech-spec (Quick Flow) or PRD (BMad Method/Enterprise) based on selected track.
|
||||
|
||||
### Phase 3: Solutioning (Track-Dependent)
|
||||
|
||||
Architecture design phase. Required for BMad Method and Enterprise Method tracks. Includes architecture creation, validation, and gate checks.
|
||||
|
||||
### Phase 4: Implementation (Required)
|
||||
|
||||
Sprint-based development through story-by-story iteration. Uses sprint-planning, create-story, dev-story, code-review, and retrospective workflows.
|
||||
|
||||
### Documentation (Prerequisite for Brownfield)
|
||||
|
||||
**Conditional prerequisite for brownfield projects.** Creates comprehensive codebase documentation before planning. Only required if existing documentation is insufficient for AI agents. Uses the `document-project` workflow.
|
||||
|
||||
### Quick Spec Flow
|
||||
|
||||
Fast-track workflow system for Quick Flow track projects that goes straight from idea to tech-spec to implementation, bypassing heavy planning. Designed for bug fixes, small features, and rapid prototyping.
|
||||
|
||||
---
|
||||
|
||||
## Agents and Roles
|
||||
|
||||
### PM (Product Manager)
|
||||
|
||||
Agent responsible for creating PRDs, tech-specs, and managing product requirements. Primary agent for Phase 2 planning.
|
||||
|
||||
### Analyst (Business Analyst)
|
||||
|
||||
Agent that initializes workflows, conducts research, creates product briefs, and tracks progress. Often the entry point for new projects.
|
||||
|
||||
### Architect
|
||||
|
||||
Agent that designs system architecture, creates architecture documents, performs technical reviews, and validates designs. Primary agent for Phase 3 solutioning.
|
||||
|
||||
### SM (Scrum Master)
|
||||
|
||||
Agent that manages sprints, creates stories, generates contexts, and coordinates implementation. Primary orchestrator for Phase 4 implementation.
|
||||
|
||||
### DEV (Developer)
|
||||
|
||||
Agent that implements stories, writes code, runs tests, and performs code reviews. Primary implementer in Phase 4.
|
||||
|
||||
### TEA (Test Architect)
|
||||
|
||||
Agent responsible for test strategy, quality gates, NFR assessment, and comprehensive quality assurance. Integrates throughout all phases.
|
||||
|
||||
### Technical Writer
|
||||
|
||||
Agent specialized in creating and maintaining high-quality technical documentation. Expert in documentation standards, information architecture, and professional technical writing. The agent's internal name is "paige" but is presented as "Technical Writer" to users.
|
||||
|
||||
### UX Designer
|
||||
|
||||
Agent that creates UX design documents, interaction patterns, and visual specifications for UI-heavy projects.
|
||||
|
||||
### Game Designer
|
||||
|
||||
Specialized agent for game development projects. Creates game design documents (GDD) and game-specific workflows.
|
||||
|
||||
### BMad Master
|
||||
|
||||
Meta-level orchestrator agent from BMad Core. Facilitates party mode, lists available tasks and workflows, and provides high-level guidance across all modules.
|
||||
|
||||
### Party Mode
|
||||
|
||||
Multi-agent collaboration feature where all installed agents (19+ from BMM, CIS, BMB, custom modules) discuss challenges together in real-time. BMad Master orchestrates, selecting 2-3 relevant agents per message for natural cross-talk and debate. Best for strategic decisions, creative brainstorming, cross-functional alignment, and complex problem-solving. See [Party Mode Guide](./party-mode.md).
|
||||
|
||||
---
|
||||
|
||||
## Status and Tracking
|
||||
|
||||
### bmm-workflow-status.yaml
|
||||
|
||||
**Phases 1-3.** Tracking file that shows current phase, completed workflows, progress, and next recommended actions. Created by workflow-init, updated automatically.
|
||||
|
||||
### sprint-status.yaml
|
||||
|
||||
**Phase 4 only.** Single source of truth for implementation tracking. Contains all epics, stories, and retrospectives with current status for each. Created by sprint-planning, updated by agents.
|
||||
|
||||
### Story Status Progression
|
||||
|
||||
```
|
||||
backlog → ready-for-dev → in-progress → review → done
|
||||
```
|
||||
|
||||
- **backlog** - Story exists in epic but not yet created
|
||||
- **ready-for-dev** - Story file created via create-story; validation is optional (run `validate-create-story` for quality check before dev picks it up)
|
||||
- **in-progress** - DEV is implementing via dev-story
|
||||
- **review** - Implementation complete, awaiting code-review
|
||||
- **done** - Completed with DoD met
|
||||
|
||||
### Epic Status Progression
|
||||
|
||||
```
|
||||
backlog → in-progress → done
|
||||
```
|
||||
|
||||
- **backlog** - Epic not yet started
|
||||
- **in-progress** - Epic actively being worked on
|
||||
- **done** - All stories in epic completed
|
||||
|
||||
### Retrospective
|
||||
|
||||
Workflow run after completing each epic to capture learnings, identify improvements, and feed insights into next epic planning. Critical for continuous improvement.
|
||||
|
||||
---
|
||||
|
||||
## Project Types
|
||||
|
||||
### Greenfield
|
||||
|
||||
New project starting from scratch with no existing codebase. Freedom to establish patterns, choose stack, and design from clean slate.
|
||||
|
||||
### Brownfield
|
||||
|
||||
Existing project with established codebase, patterns, and constraints. Requires understanding existing architecture, respecting established conventions, and planning integration with current systems.
|
||||
|
||||
**Critical:** Brownfield projects should run document-project workflow BEFORE planning to ensure AI agents have adequate context about existing code.
|
||||
|
||||
### document-project Workflow
|
||||
|
||||
**Brownfield prerequisite.** Analyzes and documents existing codebase, creating comprehensive documentation including project overview, architecture analysis, source tree, API contracts, and data models. Three scan levels: quick, deep, exhaustive.
|
||||
|
||||
---
|
||||
|
||||
## Implementation Terms
|
||||
|
||||
### Story
|
||||
|
||||
Single unit of implementable work with clear acceptance criteria, typically 2-8 hours of development effort. Stories are grouped into epics and tracked in sprint-status.yaml.
|
||||
|
||||
### Story File
|
||||
|
||||
Markdown file containing story details: description, acceptance criteria, technical notes, dependencies, implementation guidance, and testing requirements.
|
||||
|
||||
### Story Context
|
||||
|
||||
Implementation guidance embedded within story files during the create-story workflow. Provides implementation-specific context, references existing patterns, suggests approaches, and helps maintain consistency with established codebase conventions.
|
||||
|
||||
### Sprint Planning
|
||||
|
||||
Workflow that initializes Phase 4 implementation by creating sprint-status.yaml, extracting all epics/stories from planning docs, and setting up tracking infrastructure.
|
||||
|
||||
### Gate Check
|
||||
|
||||
Validation workflow (implementation-readiness) run before Phase 4 to ensure PRD + Architecture + Epics + UX (optional) are aligned with no gaps or contradictions. Required for BMad Method and Enterprise Method tracks.
|
||||
|
||||
### DoD (Definition of Done)
|
||||
|
||||
Criteria that must be met before marking a story as done. Typically includes: implementation complete, tests written and passing, code reviewed, documentation updated, and acceptance criteria validated.
|
||||
|
||||
### Shard / Sharding
|
||||
|
||||
**For runtime LLM optimization only (NOT human docs).** Splitting large planning documents (PRD, epics, architecture) into smaller section-based files to improve workflow efficiency. Phase 1-3 workflows load entire sharded documents transparently. Phase 4 workflows selectively load only needed sections for massive token savings.
|
||||
|
||||
---
|
||||
|
||||
## Additional Terms
|
||||
|
||||
### Workflow Status
|
||||
|
||||
Universal entry point workflow that checks for existing status file, displays current phase/progress, and recommends next action based on project state.
|
||||
|
||||
### Workflow Init
|
||||
|
||||
Initialization workflow that creates bmm-workflow-status.yaml, detects greenfield vs brownfield, determines planning track, and sets up appropriate workflow path.
|
||||
|
||||
### Track Selection
|
||||
|
||||
Automatic analysis by workflow-init that uses keyword analysis, complexity indicators, and project requirements to suggest appropriate track (Quick Flow, BMad Method, or Enterprise Method). User can override suggested track.
|
||||
|
||||
### Correct Course
|
||||
|
||||
Workflow run during Phase 4 when significant changes or issues arise. Analyzes impact, proposes solutions, and routes to appropriate remediation workflows.
|
||||
|
||||
### Migration Strategy
|
||||
|
||||
Plan for handling changes to existing data, schemas, APIs, or patterns during brownfield development. Critical for ensuring backward compatibility and smooth rollout.
|
||||
|
||||
### Feature Flags
|
||||
|
||||
Implementation technique for brownfield projects that allows gradual rollout of new functionality, easy rollback, and A/B testing. Recommended for BMad Method and Enterprise brownfield changes.
|
||||
|
||||
### Integration Points
|
||||
|
||||
Specific locations where new code connects with existing systems. Must be documented explicitly in brownfield tech-specs and architectures.
|
||||
|
||||
### Convention Detection
|
||||
|
||||
Quick Spec Flow feature that automatically detects existing code style, naming conventions, patterns, and frameworks from brownfield codebases, then asks user to confirm before proceeding.
|
||||
|
||||
---
|
||||
|
||||
## Related Documentation
|
||||
|
||||
- [Quick Start Guide](./quick-start.md) - Learn BMM basics
|
||||
- [Scale Adaptive System](./scale-adaptive-system.md) - Deep dive on tracks and complexity
|
||||
- [Brownfield Guide](./brownfield-guide.md) - Working with existing codebases
|
||||
- [Quick Spec Flow](./quick-spec-flow.md) - Fast-track for Quick Flow track
|
||||
- [FAQ](./faq.md) - Common questions
|
||||
|
|
@ -6,12 +6,12 @@ Get started with BMad Method v6 for your new greenfield project. This guide walk
|
|||
|
||||
1. **Install**: `npx bmad-method@alpha install`
|
||||
2. **Initialize**: Load Analyst agent → Run "workflow-init"
|
||||
3. **Plan**: Load PM agent → Run "prd" (or "tech-spec" for small projects)
|
||||
4. **Architect**: Load Architect agent → Run "create-architecture" (10+ stories only)
|
||||
5. **Build**: Load SM agent → Run workflows for each story → Load DEV agent → Implement
|
||||
6. **Always use fresh chats** for each workflow to avoid hallucinations
|
||||
|
||||
---
|
||||
3. **Plan**: Load PM agent to create a PRD
|
||||
4. **Plan UX**: Load UX Expert to create a UX-Design if your application will have a UX/UI element
|
||||
5. **Architect**: Load Architect agent → Run "create-architecture"
|
||||
6. **Epic Plan**: The PM steps back in to help run the create-epics-and-stories
|
||||
7. **Build**: Load SM agent → Run workflows for each story → Load DEV agent → Implement
|
||||
8. **Always use fresh chats** for each workflow to avoid context issues
|
||||
|
||||
## What is BMad Method?
|
||||
|
||||
|
|
|
|||
|
|
@ -43,13 +43,14 @@ project_knowledge: # Artifacts from research, document-project output, other lon
|
|||
prompt: "Where should non-ephemeral project knowledge be searched for and stored\n(docs, research, references)?"
|
||||
default: "docs"
|
||||
result: "{project-root}/{value}"
|
||||
# tea_use_mcp_enhancements:
|
||||
# prompt: "Test Architect Playwright MCP capabilities (healing, exploratory, verification) are optionally available.\nYou will have to setup your MCPs yourself; refer to test-architecture.md for hints.\nWould you like to enable MCP enhancements in Test Architect?"
|
||||
# default: false
|
||||
# result: "{value}"
|
||||
|
||||
# tea_use_playwright_utils:
|
||||
# prompt:
|
||||
# - "Are you using playwright-utils (@seontechnologies/playwright-utils) in your project?\nYou must install packages yourself, or use test architect's *framework command."
|
||||
# default: false
|
||||
# result: "{value}"
|
||||
tea_use_mcp_enhancements:
|
||||
prompt: "WEB APP ONLY: Test Architect Playwright MCP capabilities (healing, exploratory, verification) are optionally available.\nYou will have to setup your MCPs yourself; refer to test-architecture.md for hints.\nWould you like to enable MCP enhancements in Test Architect?"
|
||||
default: false
|
||||
result: "{value}"
|
||||
|
||||
tea_use_playwright_utils:
|
||||
prompt:
|
||||
- "WEB APP ONLY: Are you using playwright-utils (@seontechnologies/playwright-utils) in your project?\nYou must install packages yourself, or use test architect's *framework command."
|
||||
default: false
|
||||
result: "{value}"
|
||||
|
|
|
|||
|
|
@ -1,8 +1,10 @@
|
|||
# Product Brief: {{project_name}}
|
||||
|
||||
**Date:** {{date}}
|
||||
**Author:** {{user_name}}
|
||||
|
||||
---
|
||||
stepsCompleted: []
|
||||
inputDocuments: []
|
||||
date: { system-date }
|
||||
author: { user }
|
||||
---
|
||||
|
||||
# Product Brief: {{project_name}}
|
||||
|
||||
<!-- Content will be appended sequentially through collaborative workflow steps -->
|
||||
|
|
|
|||
|
|
@ -9,7 +9,7 @@ workflow_path: '{project-root}/_bmad/bmm/workflows/1-analysis/create-product-bri
|
|||
thisStepFile: '{workflow_path}/steps/step-01-init.md'
|
||||
nextStepFile: '{workflow_path}/steps/step-02-vision.md'
|
||||
workflowFile: '{workflow_path}/workflow.md'
|
||||
outputFile: '{output_folder}/analysis/product-brief-{{project_name}}-{{date}}.md'
|
||||
outputFile: '{planning_artifacts}/product-brief-{{project_name}}-{{date}}.md'
|
||||
|
||||
# Template References
|
||||
productBriefTemplate: '{workflow_path}/product-brief.template.md'
|
||||
|
|
|
|||
|
|
@ -8,9 +8,7 @@ workflow_path: '{project-root}/_bmad/bmm/workflows/1-analysis/create-product-bri
|
|||
# File References
|
||||
thisStepFile: '{workflow_path}/steps/step-01b-continue.md'
|
||||
workflowFile: '{workflow_path}/workflow.md'
|
||||
outputFile: '{output_folder}/analysis/product-brief-{{project_name}}-{{date}}.md'
|
||||
# Task References
|
||||
# (No task references used in this continuation step)
|
||||
outputFile: '{planning_artifacts}/product-brief-{{project_name}}-{{date}}.md'
|
||||
---
|
||||
|
||||
# Step 1B: Product Brief Continuation
|
||||
|
|
|
|||
|
|
@ -9,7 +9,7 @@ workflow_path: '{project-root}/_bmad/bmm/workflows/1-analysis/create-product-bri
|
|||
thisStepFile: '{workflow_path}/steps/step-02-vision.md'
|
||||
nextStepFile: '{workflow_path}/steps/step-03-users.md'
|
||||
workflowFile: '{workflow_path}/workflow.md'
|
||||
outputFile: '{output_folder}/analysis/product-brief-{{project_name}}-{{date}}.md'
|
||||
outputFile: '{planning_artifacts}/product-brief-{{project_name}}-{{date}}.md'
|
||||
|
||||
# Task References
|
||||
advancedElicitationTask: '{project-root}/_bmad/core/tasks/advanced-elicitation.xml'
|
||||
|
|
|
|||
|
|
@ -9,7 +9,7 @@ workflow_path: '{project-root}/_bmad/bmm/workflows/1-analysis/create-product-bri
|
|||
thisStepFile: '{workflow_path}/steps/step-03-users.md'
|
||||
nextStepFile: '{workflow_path}/steps/step-04-metrics.md'
|
||||
workflowFile: '{workflow_path}/workflow.md'
|
||||
outputFile: '{output_folder}/analysis/product-brief-{{project_name}}-{{date}}.md'
|
||||
outputFile: '{planning_artifacts}/product-brief-{{project_name}}-{{date}}.md'
|
||||
|
||||
# Task References
|
||||
advancedElicitationTask: '{project-root}/_bmad/core/tasks/advanced-elicitation.xml'
|
||||
|
|
|
|||
|
|
@ -9,7 +9,7 @@ workflow_path: '{project-root}/_bmad/bmm/workflows/1-analysis/create-product-bri
|
|||
thisStepFile: '{workflow_path}/steps/step-04-metrics.md'
|
||||
nextStepFile: '{workflow_path}/steps/step-05-scope.md'
|
||||
workflowFile: '{workflow_path}/workflow.md'
|
||||
outputFile: '{output_folder}/analysis/product-brief-{{project_name}}-{{date}}.md'
|
||||
outputFile: '{planning_artifacts}/product-brief-{{project_name}}-{{date}}.md'
|
||||
|
||||
# Task References
|
||||
advancedElicitationTask: '{project-root}/_bmad/core/tasks/advanced-elicitation.xml'
|
||||
|
|
|
|||
|
|
@ -9,7 +9,7 @@ workflow_path: '{project-root}/_bmad/bmm/workflows/1-analysis/create-product-bri
|
|||
thisStepFile: '{workflow_path}/steps/step-05-scope.md'
|
||||
nextStepFile: '{workflow_path}/steps/step-06-complete.md'
|
||||
workflowFile: '{workflow_path}/workflow.md'
|
||||
outputFile: '{output_folder}/analysis/product-brief-{{project_name}}-{{date}}.md'
|
||||
outputFile: '{planning_artifacts}/product-brief-{{project_name}}-{{date}}.md'
|
||||
|
||||
# Task References
|
||||
advancedElicitationTask: '{project-root}/_bmad/core/tasks/advanced-elicitation.xml'
|
||||
|
|
|
|||
|
|
@ -8,9 +8,7 @@ workflow_path: '{project-root}/_bmad/bmm/workflows/1-analysis/create-product-bri
|
|||
# File References
|
||||
thisStepFile: '{workflow_path}/steps/step-06-complete.md'
|
||||
workflowFile: '{workflow_path}/workflow.md'
|
||||
outputFile: '{output_folder}/analysis/product-brief-{{project_name}}-{{date}}.md'
|
||||
# Task References
|
||||
# (No task references used in this completion step)
|
||||
outputFile: '{planning_artifacts}/product-brief-{{project_name}}-{{date}}.md'
|
||||
---
|
||||
|
||||
# Step 6: Product Brief Completion
|
||||
|
|
@ -84,9 +82,8 @@ This brief serves as the foundation for all subsequent product development activ
|
|||
**Status File Management:**
|
||||
Update the main workflow status file:
|
||||
|
||||
- Check if `{output_folder}/bmm-workflow-status.yaml` exists
|
||||
- If not, create it with basic structure
|
||||
- Update workflow_status["product-brief"] = `{outputFile}`
|
||||
- Check if `{output_folder} or {planning_artifacts}/bmm-workflow-status.yaml` exists
|
||||
- If so, update workflow_status["product-brief"] = `{outputFile}`
|
||||
- Add completion timestamp and metadata
|
||||
- Save file, preserving all comments and structure
|
||||
|
||||
|
|
@ -113,7 +110,7 @@ Perform final validation of the product brief:
|
|||
**Recommended Next Workflow:**
|
||||
Provide guidance on logical next workflows:
|
||||
|
||||
1. `workflow prd` - Create detailed Product Requirements Document
|
||||
1. `create-prd` - Create detailed Product Requirements Document
|
||||
- Brief provides foundation for detailed requirements
|
||||
- User personas inform journey mapping
|
||||
- Success metrics become specific acceptance criteria
|
||||
|
|
@ -121,8 +118,8 @@ Provide guidance on logical next workflows:
|
|||
|
||||
**Other Potential Next Steps:**
|
||||
|
||||
2. `workflow create-ux-design` - UX research and design (can run parallel with PRD)
|
||||
3. `workflow domain-research` - Deep market or domain research (if needed)
|
||||
1. `create-ux-design` - UX research and design (can run parallel with PRD)
|
||||
2. `domain-research` - Deep market or domain research (if needed)
|
||||
|
||||
**Strategic Considerations:**
|
||||
|
||||
|
|
|
|||
|
|
@ -51,7 +51,7 @@ This uses **step-file architecture** for disciplined execution:
|
|||
|
||||
Load and read full config from {project-root}/\_bmad/bmm/config.yaml and resolve:
|
||||
|
||||
- `project_name`, `output_folder`, `user_name`, `communication_language`, `document_output_language`, `user_skill_level`
|
||||
- `project_name`, `output_folder`, `planning_artifacts`, `user_name`, `communication_language`, `document_output_language`, `user_skill_level`
|
||||
|
||||
### 2. First Step EXECUTION
|
||||
|
||||
|
|
|
|||
|
|
@ -1,3 +1,17 @@
|
|||
---
|
||||
stepsCompleted: []
|
||||
inputDocuments: []
|
||||
workflowType: 'research'
|
||||
lastStep: 1
|
||||
research_type: '{{research_type}}'
|
||||
research_topic: '{{research_topic}}'
|
||||
research_goals: '{{research_goals}}'
|
||||
user_name: '{{user_name}}'
|
||||
date: '{{date}}'
|
||||
web_research_enabled: true
|
||||
source_verification: true
|
||||
---
|
||||
|
||||
# Research Report: {{research_type}}
|
||||
|
||||
**Date:** {{date}}
|
||||
|
|
|
|||
|
|
@ -25,8 +25,6 @@ web_bundle: true
|
|||
- Detailed research sections with proper citations
|
||||
- Executive summary and conclusions
|
||||
|
||||
---
|
||||
|
||||
## WORKFLOW ARCHITECTURE
|
||||
|
||||
This uses **micro-file architecture** with **routing-based discovery**:
|
||||
|
|
@ -34,9 +32,7 @@ This uses **micro-file architecture** with **routing-based discovery**:
|
|||
- Each research type has its own step folder
|
||||
- Step 01 discovers research type and routes to appropriate sub-workflow
|
||||
- Sequential progression within each research type
|
||||
- Document state tracked in frontmatter
|
||||
|
||||
---
|
||||
- Document state tracked in output frontmatter
|
||||
|
||||
## INITIALIZATION
|
||||
|
||||
|
|
@ -44,25 +40,20 @@ This uses **micro-file architecture** with **routing-based discovery**:
|
|||
|
||||
Load config from `{project-root}/_bmad/bmm/config.yaml` and resolve:
|
||||
|
||||
- `project_name`, `output_folder`, `user_name`
|
||||
- `project_name`, `output_folder`, , `planning_artifacts`, `user_name`
|
||||
- `communication_language`, `document_output_language`, `user_skill_level`
|
||||
- `date` as a system-generated value
|
||||
- `enable_web_research = true` (web research is default behavior)
|
||||
|
||||
### Paths
|
||||
|
||||
- `installed_path` = `{project-root}/_bmad/bmm/workflows/1-analysis/research`
|
||||
- `template_path` = `{installed_path}/research.template.md`
|
||||
- `default_output_file` = `{output_folder}/analysis/research/{{research_type}}-{{topic}}-research-{{date}}.md` (dynamic based on research type)
|
||||
|
||||
---
|
||||
- `default_output_file` = `{planning_artifacts}/research/{{research_type}}-{{topic}}-research-{{date}}.md` (dynamic based on research type)
|
||||
|
||||
## PREREQUISITE
|
||||
|
||||
**⛔ Web search required.** If unavailable, abort and tell the user.
|
||||
|
||||
---
|
||||
|
||||
## RESEARCH BEHAVIOR
|
||||
|
||||
### Web Research Standards
|
||||
|
|
@ -81,9 +72,7 @@ Load config from `{project-root}/_bmad/bmm/config.yaml` and resolve:
|
|||
- **Critical Claims**: Market size, growth rates, competitive data need verification
|
||||
- **Fact Checking**: Apply fact-checking to critical data points
|
||||
|
||||
---
|
||||
|
||||
## EXECUTION
|
||||
## Implementation Instructions
|
||||
|
||||
Execute research type discovery and routing:
|
||||
|
||||
|
|
@ -156,49 +145,29 @@ After understanding the research topic and goals, identify the most appropriate
|
|||
|
||||
### Research Type Routing
|
||||
|
||||
Based on user selection, route to appropriate sub-workflow with the discovered topic:
|
||||
<critical>Based on user selection, route to appropriate sub-workflow with the discovered topic using the following IF block sets of instructions.</critical>
|
||||
|
||||
#### If Market Research:
|
||||
|
||||
- Set `research_type = "market"`
|
||||
- Set `research_topic = [discovered topic from discussion]`
|
||||
- Set output file: `{output_folder}/analysis/research/market-{{research_topic}}-research-{{date}}.md`
|
||||
- Create the starter output file: `{planning_artifacts}/research/market-{{research_topic}}-research-{{date}}.md` with exact copy of the ./research.template.md contents
|
||||
- Load: `./market-steps/step-01-init.md` with topic context
|
||||
|
||||
#### If Domain Research:
|
||||
|
||||
- Set `research_type = "domain"`
|
||||
- Set `research_topic = [discovered topic from discussion]`
|
||||
- Set output file: `{output_folder}/analysis/research/domain-{{research_topic}}-research-{{date}}.md`
|
||||
- Create the starter output file: `{planning_artifacts}/research/domain-{{research_topic}}-research-{{date}}.md` with exact copy of the ./research.template.md contents
|
||||
- Load: `./domain-steps/step-01-init.md` with topic context
|
||||
|
||||
#### If Technical Research:
|
||||
|
||||
- Set `research_type = "technical"`
|
||||
- Set `research_topic = [discovered topic from discussion]`
|
||||
- Set output file: `{output_folder}/analysis/research/technical-{{research_topic}}-research-{{date}}.md`
|
||||
- Create the starter output file: `{planning_artifacts}/research/technical-{{research_topic}}-research-{{date}}.md` with exact copy of the ./research.template.md contents
|
||||
- Load: `./technical-steps/step-01-init.md` with topic context
|
||||
|
||||
**Important**: The discovered topic from the collaborative discussion should be passed to the research initialization steps, so they don't need to ask "What do you want to research?" again - they can focus on refining the scope for their specific research type.
|
||||
|
||||
### Document Initialization
|
||||
|
||||
Create research document with proper metadata:
|
||||
|
||||
```yaml
|
||||
---
|
||||
stepsCompleted: [1]
|
||||
inputDocuments: []
|
||||
workflowType: 'research'
|
||||
lastStep: 1
|
||||
research_type: '{{research_type}}'
|
||||
research_topic: '{{research_topic}}'
|
||||
research_goals: '{{research_goals}}'
|
||||
user_name: '{{user_name}}'
|
||||
date: '{{date}}'
|
||||
web_research_enabled: true
|
||||
source_verification: true
|
||||
---
|
||||
```
|
||||
|
||||
**Note:** All research workflows require web search for current data and source verification.
|
||||
|
|
|
|||
|
|
@ -35,7 +35,7 @@ Initialize the UX design workflow by detecting continuation state and setting up
|
|||
|
||||
First, check if the output document already exists:
|
||||
|
||||
- Look for file at `{output_folder}/ux-design-specification.md`
|
||||
- Look for file at `{planning_artifacts}/ux-design-specification.md`
|
||||
- If exists, read the complete file including frontmatter
|
||||
- If not exists, this is a fresh workflow
|
||||
|
||||
|
|
@ -57,23 +57,23 @@ Discover and load context documents using smart discovery:
|
|||
|
||||
**PRD (Priority: Analysis → Main → Sharded → Whole):**
|
||||
|
||||
1. Check analysis folder: `{output_folder}/analysis/*prd*.md`
|
||||
2. If no analysis files: Try main folder: `{output_folder}/*prd*.md`
|
||||
3. If no main files: Check for sharded PRD folder: `{output_folder}/*prd*/**/*.md`
|
||||
1. Check analysis folder: `{planning_artifacts}/*prd*.md`
|
||||
2. If no files: Try main folder: `{output_folder}/*prd*.md`
|
||||
3. If no main files: Check for sharded PRD folder: `**/*prd*/**/*.md`
|
||||
4. If sharded folder exists: Load EVERY file in that folder completely for UX context
|
||||
5. Add discovered files to `inputDocuments` frontmatter
|
||||
|
||||
**Product Brief (Priority: Analysis → Main → Sharded → Whole):**
|
||||
|
||||
1. Check analysis folder: `{output_folder}/analysis/*brief*.md`
|
||||
1. Check analysis folder: `{planning_artifacts}/*brief*.md`
|
||||
2. If no analysis files: Try main folder: `{output_folder}/*brief*.md`
|
||||
3. If no main files: Check for sharded brief folder: `{output_folder}/*brief*/**/*.md`
|
||||
3. If no main files: Check for sharded brief folder: `**/*brief*/**/*.md`
|
||||
4. If sharded folder exists: Load EVERY file in that folder completely
|
||||
5. Add discovered files to `inputDocuments` frontmatter
|
||||
|
||||
**Research Documents (Priority: Analysis → Main → Sharded → Whole):**
|
||||
|
||||
1. Check analysis folder: `{output_folder}/analysis/research/*research*.md`
|
||||
1. Check analysis folder: `{planning_artifacts}/research/*research*.md`
|
||||
2. If no analysis files: Try main folder: `{output_folder}/*research*.md`
|
||||
3. If no main files: Check for sharded research folder: `{output_folder}/*research*/**/*.md`
|
||||
4. Load useful research files completely
|
||||
|
|
@ -92,7 +92,7 @@ Discover and load context documents using smart discovery:
|
|||
|
||||
#### B. Create Initial Document
|
||||
|
||||
Copy the template from `{installed_path}/ux-design-template.md` to `{output_folder}/ux-design-specification.md`
|
||||
Copy the template from `{installed_path}/ux-design-template.md` to `{planning_artifacts}/ux-design-specification.md`
|
||||
Initialize frontmatter with:
|
||||
|
||||
```yaml
|
||||
|
|
@ -113,7 +113,7 @@ Complete setup and report to user:
|
|||
|
||||
**Document Setup:**
|
||||
|
||||
- Created: `{output_folder}/ux-design-specification.md` from template
|
||||
- Created: `{planning_artifacts}/ux-design-specification.md` from template
|
||||
- Initialized frontmatter with workflow state
|
||||
|
||||
**Input Documents Discovered:**
|
||||
|
|
@ -132,6 +132,12 @@ Do you have any other documents you'd like me to include, or shall we continue t
|
|||
|
||||
[C] Continue to UX discovery"
|
||||
|
||||
## NEXT STEP:
|
||||
|
||||
After user selects [C] to continue, load `./step-02-discovery.md` to begin the UX discovery phase.
|
||||
|
||||
Remember: Do NOT proceed to step-02 until output file has been updated and user explicitly selects [C] to continue!
|
||||
|
||||
## SUCCESS METRICS:
|
||||
|
||||
✅ Existing workflow detected and handed off to step-01b correctly
|
||||
|
|
@ -151,9 +157,3 @@ Do you have any other documents you'd like me to include, or shall we continue t
|
|||
❌ **CRITICAL**: Reading only partial step file - leads to incomplete understanding and poor decisions
|
||||
❌ **CRITICAL**: Proceeding with 'C' without fully reading and understanding the next step file
|
||||
❌ **CRITICAL**: Making decisions without complete understanding of step requirements and protocols
|
||||
|
||||
## NEXT STEP:
|
||||
|
||||
After user selects [C] to continue, load `./step-02-discovery.md` to begin the UX discovery phase.
|
||||
|
||||
Remember: Do NOT proceed to step-02 until user explicitly selects [C] to continue!
|
||||
|
|
|
|||
|
|
@ -146,37 +146,19 @@ Show the generated project understanding content and present choices:
|
|||
[Show the complete markdown content from step 5]
|
||||
|
||||
**What would you like to do?**
|
||||
[A] Advanced Elicitation - Let's dive deeper into project understanding
|
||||
[P] Party Mode - Bring different perspectives on user needs and challenges
|
||||
[C] Continue - Save this to the document and move to core experience definition"
|
||||
|
||||
### 7. Handle Menu Selection
|
||||
|
||||
#### If 'A' (Advanced Elicitation):
|
||||
|
||||
- Execute {project-root}/\_bmad/core/tasks/advanced-elicitation.xml with the current project understanding content
|
||||
- Process the enhanced project insights that come back
|
||||
- Ask user: "Accept these improvements to the project understanding? (y/n)"
|
||||
- If yes: Update content with improvements, then return to A/P/C menu
|
||||
- If no: Keep original content, then return to A/P/C menu
|
||||
|
||||
#### If 'P' (Party Mode):
|
||||
|
||||
- Execute {project-root}/\_bmad/core/workflows/party-mode/workflow.md with the current project understanding
|
||||
- Process the collaborative insights and different perspectives that come back
|
||||
- Ask user: "Accept these changes to the project understanding? (y/n)"
|
||||
- If yes: Update content with improvements, then return to A/P/C menu
|
||||
- If no: Keep original content, then return to A/P/C menu
|
||||
|
||||
#### If 'C' (Continue):
|
||||
|
||||
- Append the final content to `{output_folder}/ux-design-specification.md`
|
||||
- Append the final content to `{planning_artifacts}/ux-design-specification.md`
|
||||
- Update frontmatter: `stepsCompleted: [1, 2]`
|
||||
- Load `./step-03-core-experience.md`
|
||||
|
||||
## APPEND TO DOCUMENT:
|
||||
|
||||
When user selects 'C', append the content directly to the document using the structure from step 5.
|
||||
When user selects 'C', append the content directly to the document. Only after the content is saved to document, load `./step-03-core-experience.md` and execute the instructions.
|
||||
|
||||
## SUCCESS METRICS:
|
||||
|
||||
|
|
@ -204,6 +186,4 @@ When user selects 'C', append the content directly to the document using the str
|
|||
|
||||
## NEXT STEP:
|
||||
|
||||
After user selects 'C' and content is saved to document, load `./step-03-core-experience.md` to define the core user experience.
|
||||
|
||||
Remember: Do NOT proceed to step-03 until user explicitly selects 'C' from the A/P/C menu and content is saved!
|
||||
Remember: Do NOT proceed to step-03 until user explicitly selects 'C' from the menu and content is saved!
|
||||
|
|
|
|||
|
|
@ -176,7 +176,7 @@ Show the generated core experience content and present choices:
|
|||
|
||||
#### If 'C' (Continue):
|
||||
|
||||
- Append the final content to `{output_folder}/ux-design-specification.md`
|
||||
- Append the final content to `{planning_artifacts}/ux-design-specification.md`
|
||||
- Update frontmatter: `stepsCompleted: [1, 2, 3]`
|
||||
- Load `./step-04-emotional-response.md`
|
||||
|
||||
|
|
|
|||
|
|
@ -179,7 +179,7 @@ Show the generated emotional response content and present choices:
|
|||
|
||||
#### If 'C' (Continue):
|
||||
|
||||
- Append the final content to `{output_folder}/ux-design-specification.md`
|
||||
- Append the final content to `{planning_artifacts}/ux-design-specification.md`
|
||||
- Update frontmatter: `stepsCompleted: [1, 2, 3, 4]`
|
||||
- Load `./step-05-inspiration.md`
|
||||
|
||||
|
|
|
|||
|
|
@ -194,9 +194,9 @@ Show the generated inspiration analysis content and present choices:
|
|||
|
||||
#### If 'C' (Continue):
|
||||
|
||||
- Append the final content to `{output_folder}/ux-design-specification.md`
|
||||
- Append the final content to `{planning_artifacts}/ux-design-specification.md`
|
||||
- Update frontmatter: `stepsCompleted: [1, 2, 3, 4, 5]`
|
||||
- Load `./step-06-design-system.md`
|
||||
- Load and execute`./step-06-design-system.md`
|
||||
|
||||
## APPEND TO DOCUMENT:
|
||||
|
||||
|
|
|
|||
|
|
@ -212,7 +212,7 @@ Show the generated design system content and present choices:
|
|||
|
||||
#### If 'C' (Continue):
|
||||
|
||||
- Append the final content to `{output_folder}/ux-design-specification.md`
|
||||
- Append the final content to `{planning_artifacts}/ux-design-specification.md`
|
||||
- Update frontmatter: `stepsCompleted: [1, 2, 3, 4, 5, 6]`
|
||||
- Load `./step-07-defining-experience.md`
|
||||
|
||||
|
|
|
|||
|
|
@ -214,7 +214,7 @@ Show the generated defining experience content and present choices:
|
|||
|
||||
#### If 'C' (Continue):
|
||||
|
||||
- Append the final content to `{output_folder}/ux-design-specification.md`
|
||||
- Append the final content to `{planning_artifacts}/ux-design-specification.md`
|
||||
- Update frontmatter: `stepsCompleted: [1, 2, 3, 4, 5, 6, 7]`
|
||||
- Load `./step-08-visual-foundation.md`
|
||||
|
||||
|
|
|
|||
|
|
@ -184,7 +184,7 @@ Show the generated visual foundation content and present choices:
|
|||
|
||||
#### If 'C' (Continue):
|
||||
|
||||
- Append the final content to `{output_folder}/ux-design-specification.md`
|
||||
- Append the final content to `{planning_artifacts}/ux-design-specification.md`
|
||||
- Update frontmatter: `stepsCompleted: [1, 2, 3, 4, 5, 6, 7, 8]`
|
||||
- Load `./step-09-design-directions.md`
|
||||
|
||||
|
|
|
|||
|
|
@ -184,7 +184,7 @@ Show the generated design direction content and present choices:
|
|||
|
||||
#### If 'C' (Continue):
|
||||
|
||||
- Append the final content to `{output_folder}/ux-design-specification.md`
|
||||
- Append the final content to `{planning_artifacts}/ux-design-specification.md`
|
||||
- Update frontmatter: `stepsCompleted: [1, 2, 3, 4, 5, 6, 7, 8, 9]`
|
||||
- Load `./step-10-user-journeys.md`
|
||||
|
||||
|
|
|
|||
|
|
@ -202,7 +202,7 @@ Show the generated user journey content and present choices:
|
|||
|
||||
#### If 'C' (Continue):
|
||||
|
||||
- Append the final content to `{output_folder}/ux-design-specification.md`
|
||||
- Append the final content to `{planning_artifacts}/ux-design-specification.md`
|
||||
- Update frontmatter: `stepsCompleted: [1, 2, 3, 4, 5, 6, 7, 8, 9, 10]`
|
||||
- Load `./step-11-component-strategy.md`
|
||||
|
||||
|
|
|
|||
|
|
@ -208,7 +208,7 @@ Show the generated component strategy content and present choices:
|
|||
|
||||
#### If 'C' (Continue):
|
||||
|
||||
- Append the final content to `{output_folder}/ux-design-specification.md`
|
||||
- Append the final content to `{planning_artifacts}/ux-design-specification.md`
|
||||
- Update frontmatter: `stepsCompleted: [1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11]`
|
||||
- Load `./step-12-ux-patterns.md`
|
||||
|
||||
|
|
|
|||
|
|
@ -197,7 +197,7 @@ Show the generated UX patterns content and present choices:
|
|||
|
||||
#### If 'C' (Continue):
|
||||
|
||||
- Append the final content to `{output_folder}/ux-design-specification.md`
|
||||
- Append the final content to `{planning_artifacts}/ux-design-specification.md`
|
||||
- Update frontmatter: `stepsCompleted: [1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12]`
|
||||
- Load `./step-13-responsive-accessibility.md`
|
||||
|
||||
|
|
|
|||
|
|
@ -224,7 +224,7 @@ Show the generated responsive and accessibility content and present choices:
|
|||
|
||||
#### If 'C' (Continue):
|
||||
|
||||
- Append the final content to `{output_folder}/ux-design-specification.md`
|
||||
- Append the final content to `{planning_artifacts}/ux-design-specification.md`
|
||||
- Update frontmatter: `stepsCompleted: [1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13]`
|
||||
- Load `./step-14-complete.md`
|
||||
|
||||
|
|
|
|||
|
|
@ -60,7 +60,7 @@ I've successfully collaborated with you to create a comprehensive UX design spec
|
|||
- ✅ UX consistency patterns for common interactions
|
||||
- ✅ Responsive design and accessibility strategy
|
||||
|
||||
**The complete UX design specification is now available at:** `{output_folder}/ux-design-specification.md`
|
||||
**The complete UX design specification is now available at:** `{planning_artifacts}/ux-design-specification.md`
|
||||
|
||||
**Supporting Visual Assets:**
|
||||
|
||||
|
|
@ -221,6 +221,6 @@ This UX design workflow is now complete. The specification serves as the foundat
|
|||
|
||||
**Core Deliverables:**
|
||||
|
||||
- ✅ UX Design Specification: `{output_folder}/ux-design-specification.md`
|
||||
- ✅ UX Design Specification: `{planning_artifacts}/ux-design-specification.md`
|
||||
- ✅ Color Themes Visualizer: `{output_folder}/ux-color-themes.html`
|
||||
- ✅ Design Directions: `{output_folder}/ux-design-directions.html`
|
||||
|
|
|
|||
|
|
@ -27,7 +27,7 @@ This uses **micro-file architecture** for disciplined execution:
|
|||
|
||||
Load config from `{project-root}/_bmad/bmm/config.yaml` and resolve:
|
||||
|
||||
- `project_name`, `output_folder`, `user_name`
|
||||
- `project_name`, `output_folder`, `planning_artifacts`, `user_name`
|
||||
- `communication_language`, `document_output_language`, `user_skill_level`
|
||||
- `date` as system-generated current datetime
|
||||
|
||||
|
|
@ -35,7 +35,7 @@ Load config from `{project-root}/_bmad/bmm/config.yaml` and resolve:
|
|||
|
||||
- `installed_path` = `{project-root}/_bmad/bmm/workflows/2-plan-workflows/create-ux-design`
|
||||
- `template_path` = `{installed_path}/ux-design-template.md`
|
||||
- `default_output_file` = `{output_folder}/ux-design-specification.md`
|
||||
- `default_output_file` = `{planning_artifacts}/ux-design-specification.md`
|
||||
|
||||
### Output Files
|
||||
|
||||
|
|
@ -46,14 +46,12 @@ Load config from `{project-root}/_bmad/bmm/config.yaml` and resolve:
|
|||
|
||||
Discover context documents for UX context (Priority: Analysis folder first, then main folder, then sharded):
|
||||
|
||||
- PRD: `{output_folder}/analysis/*prd*.md` or `{output_folder}/*prd*.md` or `{output_folder}/*prd*/**/*.md`
|
||||
- PRD: `{planning_artifacts}/*prd*.md` or `{output_folder}/*prd*.md` or `{output_folder}/*prd*/**/*.md`
|
||||
- Product brief: `{output_folder}/analysis/*brief*.md` or `{output_folder}/*brief*.md` or `{output_folder}/*brief*/**/*.md`
|
||||
- Epics: `{output_folder}/analysis/*epic*.md` or `{output_folder}/*epic*.md` or `{output_folder}/*epic*/**/*.md`
|
||||
- Research: `{output_folder}/analysis/research/*research*.md` or `{output_folder}/*research*.md` or `{output_folder}/*research*/**/*.md`
|
||||
- Brainstorming: `{output_folder}/analysis/brainstorming/*brainstorming*.md` or `{output_folder}/*brainstorming*.md`
|
||||
|
||||
---
|
||||
|
||||
## EXECUTION
|
||||
|
||||
Load and execute `steps/step-01-init.md` to begin the UX design workflow.
|
||||
|
|
|
|||
|
|
@ -9,7 +9,7 @@ workflow_path: '{project-root}/_bmad/bmm/workflows/3-solutioning/implementation-
|
|||
thisStepFile: '{workflow_path}/steps/step-01-document-discovery.md'
|
||||
nextStepFile: '{workflow_path}/steps/step-02-prd-analysis.md'
|
||||
workflowFile: '{workflow_path}/workflow.md'
|
||||
outputFile: '{output_folder}/implementation-readiness-report-{{date}}.md'
|
||||
outputFile: '{planning_artifacts}/implementation-readiness-report-{{date}}.md'
|
||||
templateFile: '{workflow_path}/templates/readiness-report-template.md'
|
||||
---
|
||||
|
||||
|
|
|
|||
|
|
@ -9,7 +9,7 @@ workflow_path: '{project-root}/_bmad/bmm/workflows/3-solutioning/implementation-
|
|||
thisStepFile: '{workflow_path}/steps/step-02-prd-analysis.md'
|
||||
nextStepFile: '{workflow_path}/steps/step-03-epic-coverage-validation.md'
|
||||
workflowFile: '{workflow_path}/workflow.md'
|
||||
outputFile: '{output_folder}/implementation-readiness-report-{{date}}.md'
|
||||
outputFile: '{planning_artifacts}/implementation-readiness-report-{{date}}.md'
|
||||
epicsFile: '{output_folder}/*epic*.md' # Will be resolved to actual file
|
||||
---
|
||||
|
||||
|
|
|
|||
|
|
@ -9,7 +9,7 @@ workflow_path: '{project-root}/_bmad/bmm/workflows/3-solutioning/implementation-
|
|||
thisStepFile: '{workflow_path}/steps/step-03-epic-coverage-validation.md'
|
||||
nextStepFile: '{workflow_path}/steps/step-04-ux-alignment.md'
|
||||
workflowFile: '{workflow_path}/workflow.md'
|
||||
outputFile: '{output_folder}/implementation-readiness-report-{{date}}.md'
|
||||
outputFile: '{planning_artifacts}/implementation-readiness-report-{{date}}.md'
|
||||
---
|
||||
|
||||
# Step 3: Epic Coverage Validation
|
||||
|
|
|
|||
|
|
@ -9,7 +9,7 @@ workflow_path: '{project-root}/_bmad/bmm/workflows/3-solutioning/implementation-
|
|||
thisStepFile: '{workflow_path}/steps/step-04-ux-alignment.md'
|
||||
nextStepFile: '{workflow_path}/steps/step-05-epic-quality-review.md'
|
||||
workflowFile: '{workflow_path}/workflow.md'
|
||||
outputFile: '{output_folder}/implementation-readiness-report-{{date}}.md'
|
||||
outputFile: '{planning_artifacts}/implementation-readiness-report-{{date}}.md'
|
||||
---
|
||||
|
||||
# Step 4: UX Alignment
|
||||
|
|
|
|||
|
|
@ -9,7 +9,7 @@ workflow_path: '{project-root}/_bmad/bmm/workflows/3-solutioning/implementation-
|
|||
thisStepFile: '{workflow_path}/steps/step-05-epic-quality-review.md'
|
||||
nextStepFile: '{workflow_path}/steps/step-06-final-assessment.md'
|
||||
workflowFile: '{workflow_path}/workflow.md'
|
||||
outputFile: '{output_folder}/implementation-readiness-report-{{date}}.md'
|
||||
outputFile: '{planning_artifacts}/implementation-readiness-report-{{date}}.md'
|
||||
epicsBestPractices: '{project-root}/_bmad/bmm/workflows/3-solutioning/create-epics-and-stories'
|
||||
---
|
||||
|
||||
|
|
|
|||
|
|
@ -8,7 +8,7 @@ workflow_path: '{project-root}/_bmad/bmm/workflows/3-solutioning/implementation-
|
|||
# File References
|
||||
thisStepFile: '{workflow_path}/steps/step-06-final-assessment.md'
|
||||
workflowFile: '{workflow_path}/workflow.md'
|
||||
outputFile: '{output_folder}/implementation-readiness-report-{{date}}.md'
|
||||
outputFile: '{planning_artifacts}/implementation-readiness-report-{{date}}.md'
|
||||
---
|
||||
|
||||
# Step 6: Final Assessment
|
||||
|
|
|
|||
|
|
@ -47,7 +47,7 @@ web_bundle: false
|
|||
|
||||
Load and read full config from {project-root}/\_bmad/bmm/config.yaml and resolve:
|
||||
|
||||
- `project_name`, `output_folder`, `user_name`, `communication_language`, `document_output_language`
|
||||
- `project_name`, `output_folder`, `planning_artifacts`, `user_name`, `communication_language`, `document_output_language`
|
||||
|
||||
### 2. First Step EXECUTION
|
||||
|
||||
|
|
|
|||
|
|
@ -2,7 +2,6 @@
|
|||
stepsCompleted: []
|
||||
inputDocuments: []
|
||||
workflowType: 'architecture'
|
||||
lastStep: 0
|
||||
project_name: '{{project_name}}'
|
||||
user_name: '{{user_name}}'
|
||||
date: '{{date}}'
|
||||
|
|
|
|||
|
|
@ -36,8 +36,8 @@ Initialize the Architecture workflow by detecting continuation state, discoverin
|
|||
|
||||
First, check if the output document already exists:
|
||||
|
||||
- Look for file at `{output_folder}/architecture.md`
|
||||
- If exists, read the complete file including frontmatter
|
||||
- Look for existing {output_folder}||{planning_artifacts} architecture.md or \*\*/architecture/
|
||||
- If exists, read the complete file(s) including frontmatter
|
||||
- If not exists, this is a fresh workflow
|
||||
|
||||
### 2. Handle Continuation (If Document Exists)
|
||||
|
|
@ -58,14 +58,14 @@ Discover and load context documents using smart discovery:
|
|||
|
||||
**PRD Document (Priority: Analysis → Main → Sharded → Whole):**
|
||||
|
||||
1. Check analysis folder: `{output_folder}/*prd*.md`
|
||||
2. If no main files: Check for sharded PRD folder: `{output_folder}/*prd*/**/*.md`
|
||||
1. Check analysis folders: {output*folder} and {planning_artifacts} for a \_prd*.md
|
||||
2. If no main files: Check for sharded PRD folder: `**/*prd*/**/*.md`
|
||||
3. If sharded folder exists: Load EVERY file in that folder completely
|
||||
4. Add discovered files to `inputDocuments` frontmatter
|
||||
|
||||
**Epics/Stories Document (Priority: Analysis → Main → Sharded → Whole):**
|
||||
|
||||
1. Check analysis folder: `{output_folder}/analysis/*epic*.md`
|
||||
1. Check folders: {output*folder} and {planning_artifacts} for a \_epic*.md
|
||||
2. If no analysis files: Try main folder: `{output_folder}/*epic*.md`
|
||||
3. If no main files: Check for sharded epics folder: `{output_folder}/*epic*/**/*.md`
|
||||
4. If sharded folder exists: Load EVERY file in that folder completely
|
||||
|
|
@ -73,24 +73,25 @@ Discover and load context documents using smart discovery:
|
|||
|
||||
**UX Design Specification (Priority: Analysis → Main → Sharded → Whole):**
|
||||
|
||||
1. Check folder: `{output_folder}/*ux*.md`
|
||||
1. Check folders: {output*folder} and {planning_artifacts} for a \_ux*.md
|
||||
2. If no main files: Check for sharded UX folder: `{output_folder}/*ux*/**/*.md`
|
||||
3. If sharded folder exists: Load EVERY file in that folder completely
|
||||
4. Add discovered files to `inputDocuments` frontmatter
|
||||
|
||||
**Research Documents (Priority: Analysis → Main):**
|
||||
|
||||
1. Check folder: `{output_folder}/research/*research*.md`
|
||||
1. Check folders {output*folder} and {planning_artifacts} for /research/\_research*.md
|
||||
2. If no files: Try folder: `{output_folder}/*research*.md`
|
||||
3. Add discovered files to `inputDocuments` frontmatter
|
||||
|
||||
**Project Documentation (Existing Projects):**
|
||||
|
||||
1. Look for index file: `{output_folder/index.md`
|
||||
1. Look for index file: `{project_knowledge}/index.md`
|
||||
2. CRITICAL: Load index.md to understand what project files are available
|
||||
3. Read available files from index to understand existing project context
|
||||
4. This provides essential context for extending existing project with new architecture
|
||||
5. Add discovered files to `inputDocuments` frontmatter
|
||||
6. IF no index.md, ask user which files from the folder to include
|
||||
|
||||
**Project Context Rules (Critical for AI Agents):**
|
||||
|
||||
|
|
@ -123,19 +124,6 @@ Before proceeding, verify we have the essential inputs:
|
|||
#### C. Create Initial Document
|
||||
|
||||
Copy the template from `{installed_path}/architecture-decision-template.md` to `{output_folder}/architecture.md`
|
||||
Initialize frontmatter with:
|
||||
|
||||
```yaml
|
||||
---
|
||||
stepsCompleted: []
|
||||
inputDocuments: []
|
||||
workflowType: 'architecture'
|
||||
lastStep: 0
|
||||
project_name: '{{project_name}}'
|
||||
user_name: '{{user_name}}'
|
||||
date: '{{date}}'
|
||||
---
|
||||
```
|
||||
|
||||
#### D. Complete Initialization and Report
|
||||
|
||||
|
|
|
|||
|
|
@ -30,7 +30,7 @@ This uses **micro-file architecture** for disciplined execution:
|
|||
|
||||
Load config from `{project-root}/_bmad/bmm/config.yaml` and resolve:
|
||||
|
||||
- `project_name`, `output_folder`, `user_name`
|
||||
- `project_name`, `output_folder`, `planning_artifacts`, `user_name`
|
||||
- `communication_language`, `document_output_language`, `user_skill_level`
|
||||
- `date` as system-generated current datetime
|
||||
|
||||
|
|
|
|||
|
|
@ -9,7 +9,7 @@ workflow_path: '{project-root}/_bmad/bmm/workflows/3-solutioning/create-epics-an
|
|||
thisStepFile: '{workflow_path}/steps/step-01-validate-prerequisites.md'
|
||||
nextStepFile: '{workflow_path}/steps/step-02-design-epics.md'
|
||||
workflowFile: '{workflow_path}/workflow.md'
|
||||
outputFile: '{output_folder}/epics.md'
|
||||
outputFile: '{planning_artifacts}/epics.md'
|
||||
epicsTemplate: '{workflow_path}/templates/epics-template.md'
|
||||
|
||||
# Task References
|
||||
|
|
@ -77,20 +77,20 @@ Search for required documents using these patterns (sharded means a large docume
|
|||
|
||||
**PRD Document Search Priority:**
|
||||
|
||||
1. `{output_folder}/*prd*.md` (whole document)
|
||||
2. `{output_folder}/*prd*/index.md` (sharded version)
|
||||
1. `{planning_artifacts}/*prd*.md` (whole document)
|
||||
2. `{planning_artifacts}/*prd*/index.md` (sharded version)
|
||||
|
||||
**Architecture Document Search Priority:**
|
||||
|
||||
1. `{output_folder}/*architecture*.md` (whole document)
|
||||
2. `{output_folder}/*architecture*/index.md` (sharded version)
|
||||
1. `{planning_artifacts}/*architecture*.md` (whole document)
|
||||
2. `{planning_artifacts}/*architecture*/index.md` (sharded version)
|
||||
|
||||
**UX Design Document Search (Optional):**
|
||||
|
||||
1. `{output_folder}/*ux*.md` (whole document)
|
||||
2. `{output_folder}/*ux*/index.md` (sharded version)
|
||||
1. `{planning_artifacts}/*ux*.md` (whole document)
|
||||
2. `{planning_artifacts}/*ux*/index.md` (sharded version)
|
||||
|
||||
Ask the user if there are any other documents, or if what you have found is all there is [Yes/No]. Wait for user confirmation. Once confirmed, create the {outputFile} from the {epicsTemplate} and in the front matter list the files in the array of `inputDocuments: []`.
|
||||
Before proceeding, Ask the user if there are any other documents, or if what you have found is all there is [Yes/No]. Wait for user confirmation. Once confirmed, create the {outputFile} from the {epicsTemplate} and in the front matter list the files in the array of `inputDocuments: []`.
|
||||
|
||||
### 3. Extract Functional Requirements (FRs)
|
||||
|
||||
|
|
|
|||
|
|
@ -9,7 +9,7 @@ workflow_path: '{project-root}/_bmad/bmm/workflows/3-solutioning/create-epics-an
|
|||
thisStepFile: '{workflow_path}/steps/step-02-design-epics.md'
|
||||
nextStepFile: '{workflow_path}/steps/step-03-create-stories.md'
|
||||
workflowFile: '{workflow_path}/workflow.md'
|
||||
outputFile: '{output_folder}/epics.md'
|
||||
outputFile: '{planning_artifacts}/epics.md'
|
||||
|
||||
# Task References
|
||||
advancedElicitationTask: '{project-root}/_bmad/core/tasks/advanced-elicitation.xml'
|
||||
|
|
|
|||
|
|
@ -9,7 +9,7 @@ workflow_path: '{project-root}/_bmad/bmm/workflows/3-solutioning/create-epics-an
|
|||
thisStepFile: '{workflow_path}/steps/step-03-create-stories.md'
|
||||
nextStepFile: '{workflow_path}/steps/step-04-final-validation.md'
|
||||
workflowFile: '{workflow_path}/workflow.md'
|
||||
outputFile: '{output_folder}/epics.md'
|
||||
outputFile: '{planning_artifacts}/epics.md'
|
||||
|
||||
# Task References
|
||||
advancedElicitationTask: '{project-root}/_bmad/core/tasks/advanced-elicitation.xml'
|
||||
|
|
|
|||
|
|
@ -8,7 +8,7 @@ workflow_path: '{project-root}/_bmad/bmm/workflows/3-solutioning/create-epics-an
|
|||
# File References
|
||||
thisStepFile: '{workflow_path}/steps/step-04-final-validation.md'
|
||||
workflowFile: '{workflow_path}/workflow.md'
|
||||
outputFile: '{output_folder}/epics.md'
|
||||
outputFile: '{planning_artifacts}/epics.md'
|
||||
|
||||
# Task References
|
||||
advancedElicitationTask: '{project-root}/_bmad/core/tasks/advanced-elicitation.xml'
|
||||
|
|
|
|||
|
|
@ -51,7 +51,7 @@ This uses **step-file architecture** for disciplined execution:
|
|||
|
||||
Load and read full config from {project-root}/\_bmad/bmm/config.yaml and resolve:
|
||||
|
||||
- `project_name`, `output_folder`, `user_name`, `communication_language`, `document_output_language`
|
||||
- `project_name`, `output_folder`, `planning_artifacts`, `user_name`, `communication_language`, `document_output_language`
|
||||
|
||||
### 2. First Step EXECUTION
|
||||
|
||||
|
|
|
|||
|
|
@ -5,14 +5,14 @@ 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"
|
||||
user_skill_level: "{config_source}:user_skill_level"
|
||||
document_output_language: "{config_source}:document_output_language"
|
||||
date: system-generated
|
||||
sprint_artifacts: "{config_source}:sprint_artifacts"
|
||||
sprint_status: "{sprint_artifacts}/sprint-status.yaml || {output_folder}/sprint-status.yaml"
|
||||
implementation_artifacts: "{config_source}:implementation_artifacts"
|
||||
output_folder: "{implementation_artifacts}"
|
||||
sprint_status: "{implementation_artifacts}/sprint-status.yaml || {output_folder}/sprint-status.yaml"
|
||||
|
||||
# Workflow components
|
||||
installed_path: "{project-root}/_bmad/bmm/workflows/4-implementation/code-review"
|
||||
|
|
@ -23,7 +23,7 @@ template: false
|
|||
variables:
|
||||
# Project context
|
||||
project_context: "**/project-context.md"
|
||||
story_dir: "{sprint_artifacts}"
|
||||
story_dir: "{implementation_artifacts}"
|
||||
|
||||
# Smart input file references - handles both whole docs and sharded docs
|
||||
# Priority: Whole document first, then sharded version
|
||||
|
|
|
|||
|
|
@ -4,14 +4,16 @@ description: "Navigate significant changes during sprint execution by analyzing
|
|||
author: "BMad Method"
|
||||
|
||||
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"
|
||||
user_skill_level: "{config_source}:user_skill_level"
|
||||
document_output_language: "{config_source}:document_output_language"
|
||||
date: system-generated
|
||||
sprint_artifacts: "{config_source}:sprint_artifacts"
|
||||
sprint_status: "{sprint_artifacts}/sprint-status.yaml || {output_folder}/sprint-status.yaml"
|
||||
implementation_artifacts: "{config_source}:implementation_artifacts"
|
||||
planning_artifacts: "{config_source}:planning_artifacts"
|
||||
project_knowledge: "{config_source}:project_knowledge"
|
||||
output_folder: "{implementation_artifacts}"
|
||||
sprint_status: "{implementation_artifacts}/sprint-status.yaml || {output_folder}/sprint-status.yaml"
|
||||
|
||||
# Smart input file references - handles both whole docs and sharded docs
|
||||
# Priority: Whole document first, then sharded version
|
||||
|
|
@ -19,31 +21,31 @@ sprint_status: "{sprint_artifacts}/sprint-status.yaml || {output_folder}/sprint-
|
|||
input_file_patterns:
|
||||
prd:
|
||||
description: "Product requirements for impact analysis"
|
||||
whole: "{output_folder}/*prd*.md"
|
||||
sharded: "{output_folder}/*prd*/*.md"
|
||||
whole: "{planning_artifacts}/*prd*.md"
|
||||
sharded: "{planning_artifacts}/*prd*/*.md"
|
||||
load_strategy: "FULL_LOAD"
|
||||
epics:
|
||||
description: "All epics to analyze change impact"
|
||||
whole: "{output_folder}/*epic*.md"
|
||||
sharded: "{output_folder}/*epic*/*.md"
|
||||
whole: "{planning_artifacts}/*epic*.md"
|
||||
sharded: "{planning_artifacts}/*epic*/*.md"
|
||||
load_strategy: "FULL_LOAD"
|
||||
architecture:
|
||||
description: "System architecture and decisions"
|
||||
whole: "{output_folder}/*architecture*.md"
|
||||
sharded: "{output_folder}/*architecture*/*.md"
|
||||
whole: "{planning_artifacts}/*architecture*.md"
|
||||
sharded: "{planning_artifacts}/*architecture*/*.md"
|
||||
load_strategy: "FULL_LOAD"
|
||||
ux_design:
|
||||
description: "UX design specification (if UI impacts)"
|
||||
whole: "{output_folder}/*ux*.md"
|
||||
sharded: "{output_folder}/*ux*/*.md"
|
||||
whole: "{planning_artifacts}/*ux*.md"
|
||||
sharded: "{planning_artifacts}/*ux*/*.md"
|
||||
load_strategy: "FULL_LOAD"
|
||||
tech_spec:
|
||||
description: "Technical specification"
|
||||
whole: "{output_folder}/tech-spec*.md"
|
||||
whole: "{planning_artifacts}/*tech-spec*.md"
|
||||
load_strategy: "FULL_LOAD"
|
||||
document_project:
|
||||
description: "Brownfield project documentation (optional)"
|
||||
sharded: "{output_folder}/index.md"
|
||||
sharded: "{project_knowledge}/index.md"
|
||||
load_strategy: "INDEX_GUIDED"
|
||||
|
||||
installed_path: "{project-root}/_bmad/bmm/workflows/4-implementation/correct-course"
|
||||
|
|
@ -51,7 +53,7 @@ template: false
|
|||
instructions: "{installed_path}/instructions.md"
|
||||
validation: "{installed_path}/checklist.md"
|
||||
checklist: "{installed_path}/checklist.md"
|
||||
default_output_file: "{output_folder}/sprint-change-proposal-{date}.md"
|
||||
default_output_file: "{planning_artifacts}/sprint-change-proposal-{date}.md"
|
||||
|
||||
standalone: true
|
||||
|
||||
|
|
|
|||
|
|
@ -4,12 +4,12 @@ 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"
|
||||
date: system-generated
|
||||
sprint_artifacts: "{config_source}:sprint_artifacts"
|
||||
story_dir: "{sprint_artifacts}"
|
||||
implementation_artifacts: "{config_source}:implementation_artifacts"
|
||||
output_folder: "{implementation_artifacts}"
|
||||
story_dir: "{implementation_artifacts}"
|
||||
|
||||
# Workflow components
|
||||
installed_path: "{project-root}/_bmad/bmm/workflows/4-implementation/create-story"
|
||||
|
|
@ -19,7 +19,7 @@ validation: "{installed_path}/checklist.md"
|
|||
|
||||
# Variables and inputs
|
||||
variables:
|
||||
sprint_status: "{sprint_artifacts}/sprint-status.yaml || {output_folder}/sprint-status.yaml" # Primary source for story tracking
|
||||
sprint_status: "{implementation_artifacts}/sprint-status.yaml || {output_folder}/sprint-status.yaml" # Primary source for story tracking
|
||||
epics_file: "{output_folder}/epics.md" # Enhanced epics+stories with BDD and source hints
|
||||
prd_file: "{output_folder}/PRD.md" # Fallback for requirements (if not in epics file)
|
||||
architecture_file: "{output_folder}/architecture.md" # Fallback for constraints (if not in epics file)
|
||||
|
|
|
|||
|
|
@ -9,7 +9,7 @@ user_name: "{config_source}:user_name"
|
|||
communication_language: "{config_source}:communication_language"
|
||||
user_skill_level: "{config_source}:user_skill_level"
|
||||
document_output_language: "{config_source}:document_output_language"
|
||||
story_dir: "{config_source}:sprint_artifacts"
|
||||
story_dir: "{config_source}:implementation_artifacts"
|
||||
date: system-generated
|
||||
|
||||
# Workflow components
|
||||
|
|
@ -18,8 +18,8 @@ instructions: "{installed_path}/instructions.xml"
|
|||
validation: "{installed_path}/checklist.md"
|
||||
|
||||
story_file: "" # Explicit story path; auto-discovered if empty
|
||||
sprint_artifacts: "{config_source}:sprint_artifacts"
|
||||
sprint_status: "{sprint_artifacts}/sprint-status.yaml"
|
||||
implementation_artifacts: "{config_source}:implementation_artifacts"
|
||||
sprint_status: "{implementation_artifacts}/sprint-status.yaml"
|
||||
project_context: "**/project-context.md"
|
||||
|
||||
standalone: true
|
||||
|
|
|
|||
|
|
@ -10,7 +10,7 @@ communication_language: "{config_source}:communication_language"
|
|||
user_skill_level: "{config_source}:user_skill_level"
|
||||
document_output_language: "{config_source}:document_output_language"
|
||||
date: system-generated
|
||||
sprint_artifacts: "{config_source}:sprint_artifacts"
|
||||
implementation_artifacts: "{config_source}:implementation_artifacts"
|
||||
|
||||
installed_path: "{project-root}/_bmad/bmm/workflows/4-implementation/retrospective"
|
||||
template: false
|
||||
|
|
@ -31,7 +31,7 @@ input_file_patterns:
|
|||
load_strategy: "SELECTIVE_LOAD"
|
||||
previous_retrospective:
|
||||
description: "Previous epic's retrospective (optional)"
|
||||
pattern: "{sprint_artifacts}/**/epic-{{prev_epic_num}}-retro-*.md"
|
||||
pattern: "{implementation_artifacts}/**/epic-{{prev_epic_num}}-retro-*.md"
|
||||
load_strategy: "SELECTIVE_LOAD"
|
||||
architecture:
|
||||
description: "System architecture for context"
|
||||
|
|
@ -49,9 +49,9 @@ input_file_patterns:
|
|||
load_strategy: "INDEX_GUIDED"
|
||||
|
||||
# Required files
|
||||
sprint_status_file: "{sprint_artifacts}/sprint-status.yaml || {output_folder}/sprint-status.yaml"
|
||||
story_directory: "{sprint_artifacts}"
|
||||
retrospectives_folder: "{sprint_artifacts}"
|
||||
sprint_status_file: "{implementation_artifacts}/sprint-status.yaml || {output_folder}/sprint-status.yaml"
|
||||
story_directory: "{implementation_artifacts}"
|
||||
retrospectives_folder: "{implementation_artifacts}"
|
||||
|
||||
standalone: true
|
||||
web_bundle: false
|
||||
|
|
|
|||
|
|
@ -4,11 +4,12 @@ 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"
|
||||
date: system-generated
|
||||
sprint_artifacts: "{config_source}:sprint_artifacts"
|
||||
implementation_artifacts: "{config_source}:implementation_artifacts"
|
||||
planning_artifacts: "{config_source}:planning_artifacts"
|
||||
output_folder: "{implementation_artifacts}"
|
||||
|
||||
# Workflow components
|
||||
installed_path: "{project-root}/_bmad/bmm/workflows/4-implementation/sprint-planning"
|
||||
|
|
@ -25,15 +26,15 @@ variables:
|
|||
|
||||
# Tracking system configuration
|
||||
tracking_system: "file-system" # Options: file-system, Future will support other options from config of mcp such as jira, linear, trello
|
||||
story_location: "{config_source}:sprint_artifacts" # Relative path for file-system, Future will support URL for Jira/Linear/Trello
|
||||
story_location_absolute: "{config_source}:sprint_artifacts" # Absolute path for file operations
|
||||
story_location: "{config_source}:implementation_artifacts" # Relative path for file-system, Future will support URL for Jira/Linear/Trello
|
||||
story_location_absolute: "{config_source}:implementation_artifacts" # Absolute path for file operations
|
||||
|
||||
# Source files (file-system only)
|
||||
epics_location: "{output_folder}" # Directory containing epic*.md files
|
||||
epics_location: "{planning_artifacts}" # Directory containing epic*.md files
|
||||
epics_pattern: "epic*.md" # Pattern to find epic files
|
||||
|
||||
# Output configuration
|
||||
status_file: "{sprint_artifacts}/sprint-status.yaml"
|
||||
status_file: "{implementation_artifacts}/sprint-status.yaml"
|
||||
|
||||
# Smart input file references - handles both whole docs and sharded docs
|
||||
# Priority: Whole document first, then sharded version
|
||||
|
|
|
|||
|
|
@ -10,7 +10,8 @@ user_name: "{config_source}:user_name"
|
|||
communication_language: "{config_source}:communication_language"
|
||||
document_output_language: "{config_source}:document_output_language"
|
||||
date: system-generated
|
||||
sprint_artifacts: "{config_source}:sprint_artifacts"
|
||||
implementation_artifacts: "{config_source}:implementation_artifacts"
|
||||
planning_artifacts: "{config_source}:planning_artifacts"
|
||||
|
||||
# Workflow components
|
||||
installed_path: "{project-root}/_bmad/bmm/workflows/4-implementation/sprint-status"
|
||||
|
|
@ -18,14 +19,14 @@ instructions: "{installed_path}/instructions.md"
|
|||
|
||||
# Inputs
|
||||
variables:
|
||||
sprint_status_file: "{sprint_artifacts}/sprint-status.yaml || {output_folder}/sprint-status.yaml"
|
||||
sprint_status_file: "{implementation_artifacts}/sprint-status.yaml || {output_folder}/sprint-status.yaml"
|
||||
tracking_system: "file-system"
|
||||
|
||||
# Smart input file references
|
||||
input_file_patterns:
|
||||
sprint_status:
|
||||
description: "Sprint status file generated by sprint-planning"
|
||||
whole: "{sprint_artifacts}/sprint-status.yaml || {output_folder}/sprint-status.yaml"
|
||||
whole: "{implementation_artifacts}/sprint-status.yaml || {output_folder}/sprint-status.yaml"
|
||||
load_strategy: "FULL_LOAD"
|
||||
|
||||
# Standalone so IDE commands get generated
|
||||
|
|
|
|||
|
|
@ -19,7 +19,7 @@
|
|||
|
||||
<action>Ask clarifying questions: problem, who's affected, scope, constraints, existing code?</action>
|
||||
|
||||
<action>Check for existing context in {output_folder} and {sprint_artifacts}</action>
|
||||
<action>Check for existing context in {output_folder} and {implementation_artifacts}</action>
|
||||
|
||||
<checkpoint title="Problem Understanding">
|
||||
[a] Advanced Elicitation [c] Continue [p] Party Mode
|
||||
|
|
@ -88,7 +88,7 @@
|
|||
|
||||
</action>
|
||||
|
||||
<action>Save to {sprint_artifacts}/tech-spec-{slug}.md</action>
|
||||
<action>Save to {implementation_artifacts}/tech-spec-{slug}.md</action>
|
||||
|
||||
</step>
|
||||
|
||||
|
|
@ -98,14 +98,14 @@
|
|||
|
||||
<output>**Tech-Spec Complete!**
|
||||
|
||||
Saved to: {sprint_artifacts}/tech-spec-{slug}.md
|
||||
Saved to: {implementation_artifacts}/tech-spec-{slug}.md
|
||||
|
||||
[a] Advanced Elicitation - refine further
|
||||
[b] Begin Development (not recommended - fresh context better)
|
||||
[d] Done - exit
|
||||
[p] Party Mode - get feedback
|
||||
|
||||
**Recommended:** Run `dev-spec {sprint_artifacts}/tech-spec-{slug}.md` in fresh context.
|
||||
**Recommended:** Run `dev-spec {implementation_artifacts}/tech-spec-{slug}.md` in fresh context.
|
||||
</output>
|
||||
|
||||
<ask>Choice (a/b/d/p):</ask>
|
||||
|
|
|
|||
|
|
@ -5,8 +5,10 @@ author: "BMad"
|
|||
|
||||
# Config
|
||||
config_source: "{project-root}/_bmad/bmm/config.yaml"
|
||||
output_folder: "{config_source}:output_folder"
|
||||
sprint_artifacts: "{config_source}:sprint_artifacts"
|
||||
implementation_artifacts: "{config_source}:implementation_artifacts"
|
||||
planning_artifacts: "{config_source}:planning_artifacts"
|
||||
project_knowledge: "{config_source}:project_knowledge"
|
||||
output_folder: "{implementation_artifacts}"
|
||||
user_name: "{config_source}:user_name"
|
||||
communication_language: "{config_source}:communication_language"
|
||||
document_output_language: "{config_source}:document_output_language"
|
||||
|
|
|
|||
|
|
@ -5,8 +5,10 @@ author: "BMad"
|
|||
|
||||
# Config
|
||||
config_source: "{project-root}/_bmad/bmm/config.yaml"
|
||||
output_folder: "{config_source}:output_folder"
|
||||
sprint_artifacts: "{config_source}:sprint_artifacts"
|
||||
implementation_artifacts: "{config_source}:implementation_artifacts"
|
||||
planning_artifacts: "{config_source}:planning_artifacts"
|
||||
project_knowledge: "{config_source}:project_knowledge"
|
||||
output_folder: "{implementation_artifacts}"
|
||||
user_name: "{config_source}:user_name"
|
||||
communication_language: "{config_source}:communication_language"
|
||||
user_skill_level: "{config_source}:user_skill_level"
|
||||
|
|
|
|||
|
|
@ -83,40 +83,39 @@ Would you like to:
|
|||
Your choice [1/2/3]:
|
||||
</ask>
|
||||
|
||||
<check if="user selects 1">
|
||||
<action>Set resume_mode = true</action>
|
||||
<action>Set workflow_mode = {{mode}}</action>
|
||||
<action>Load findings summaries from state file</action>
|
||||
<action>Load cached project_type_id(s) from state file</action>
|
||||
<check if="user selects 1">
|
||||
<action>Set resume_mode = true</action>
|
||||
<action>Set workflow_mode = {{mode}}</action>
|
||||
<action>Load findings summaries from state file</action>
|
||||
<action>Load cached project_type_id(s) from state file</action>
|
||||
|
||||
<critical>CONDITIONAL CSV LOADING FOR RESUME:</critical>
|
||||
<action>For each cached project_type_id, load ONLY the corresponding row from: {documentation_requirements_csv}</action>
|
||||
<action>Skip loading project-types.csv and architecture_registry.csv (not needed on resume)</action>
|
||||
<action>Store loaded doc requirements for use in remaining steps</action>
|
||||
<critical>CONDITIONAL CSV LOADING FOR RESUME:</critical>
|
||||
<action>For each cached project_type_id, load ONLY the corresponding row from: {documentation_requirements_csv}</action>
|
||||
<action>Skip loading project-types.csv and architecture_registry.csv (not needed on resume)</action>
|
||||
<action>Store loaded doc requirements for use in remaining steps</action>
|
||||
|
||||
<action>Display: "Resuming {{workflow_mode}} from {{current_step}} with cached project type(s): {{cached_project_types}}"</action>
|
||||
<action>Display: "Resuming {{workflow_mode}} from {{current_step}} with cached project type(s): {{cached_project_types}}"</action>
|
||||
|
||||
<check if="workflow_mode == deep_dive">
|
||||
<action>Load and execute: {installed_path}/workflows/deep-dive-instructions.md with resume context</action>
|
||||
</check>
|
||||
|
||||
<check if="workflow_mode == initial_scan OR workflow_mode == full_rescan">
|
||||
<action>Load and execute: {installed_path}/workflows/full-scan-instructions.md with resume context</action>
|
||||
</check>
|
||||
<check if="workflow_mode == deep_dive">
|
||||
<action>Load and execute: {installed_path}/workflows/deep-dive-instructions.md with resume context</action>
|
||||
</check>
|
||||
|
||||
<check if="user selects 2">
|
||||
<action>Create archive directory: {output_folder}/.archive/</action>
|
||||
<action>Move old state file to: {output_folder}/.archive/project-scan-report-{{timestamp}}.json</action>
|
||||
<action>Set resume_mode = false</action>
|
||||
<action>Continue to Step 0.5</action>
|
||||
<check if="workflow_mode == initial_scan OR workflow_mode == full_rescan">
|
||||
<action>Load and execute: {installed_path}/workflows/full-scan-instructions.md with resume context</action>
|
||||
</check>
|
||||
|
||||
<check if="user selects 3">
|
||||
<action>Display: "Exiting workflow without changes."</action>
|
||||
<action>Exit workflow</action>
|
||||
</check>
|
||||
</check>
|
||||
|
||||
<check if="user selects 2">
|
||||
<action>Create archive directory: {output_folder}/.archive/</action>
|
||||
<action>Move old state file to: {output_folder}/.archive/project-scan-report-{{timestamp}}.json</action>
|
||||
<action>Set resume_mode = false</action>
|
||||
<action>Continue to Step 0.5</action>
|
||||
</check>
|
||||
|
||||
<check if="user selects 3">
|
||||
<action>Display: "Exiting workflow without changes."</action>
|
||||
<action>Exit workflow</action>
|
||||
</check>
|
||||
|
||||
<check if="state file age >= 24 hours">
|
||||
|
|
|
|||
|
|
@ -6,7 +6,7 @@ author: "BMad"
|
|||
|
||||
# Critical variables
|
||||
config_source: "{project-root}/_bmad/bmm/config.yaml"
|
||||
output_folder: "{config_source}:output_folder"
|
||||
output_folder: "{config_source}:project_knowledge"
|
||||
user_name: "{config_source}:user_name"
|
||||
communication_language: "{config_source}:communication_language"
|
||||
document_output_language: "{config_source}:document_output_language"
|
||||
|
|
@ -15,7 +15,6 @@ date: system-generated
|
|||
|
||||
# Module path and component files
|
||||
installed_path: "{project-root}/_bmad/bmm/workflows/document-project"
|
||||
template: false # This is an action workflow with multiple output files
|
||||
instructions: "{installed_path}/instructions.md"
|
||||
validation: "{installed_path}/checklist.md"
|
||||
|
||||
|
|
@ -23,7 +22,7 @@ validation: "{installed_path}/checklist.md"
|
|||
documentation_requirements_csv: "{installed_path}/documentation-requirements.csv"
|
||||
|
||||
# Output configuration - Multiple files generated in output folder
|
||||
# Primary output: {output_folder}/index.md
|
||||
# Primary output: {output_folder}/project-documentation/
|
||||
# Additional files generated by sub-workflows based on project structure
|
||||
|
||||
standalone: true
|
||||
|
|
|
|||
|
|
@ -2,7 +2,8 @@
|
|||
project_name: '{{project_name}}'
|
||||
user_name: '{{user_name}}'
|
||||
date: '{{date}}'
|
||||
sections_completed: []
|
||||
sections_completed: ['technology_stack']
|
||||
existing_patterns_found: { { number_of_patterns_discovered } }
|
||||
---
|
||||
|
||||
# Project Context for AI Agents
|
||||
|
|
|
|||
|
|
@ -33,7 +33,7 @@ Discover the project's technology stack, existing patterns, and critical impleme
|
|||
|
||||
First, check if project context already exists:
|
||||
|
||||
- Look for file at `{output_folder}/project-context.md`
|
||||
- Look for file at `{project_knowledge}/project-context.md or {project-root}/**/project-context.md`
|
||||
- If exists: Read complete file to understand existing rules
|
||||
- Present to user: "Found existing project context with {number_of_sections} sections. Would you like to update this or create a new one?"
|
||||
|
||||
|
|
@ -43,7 +43,7 @@ Load and analyze project files to identify technologies:
|
|||
|
||||
**Architecture Document:**
|
||||
|
||||
- Look for `{output_folder}/architecture.md`
|
||||
- Look for `{planning_artifacts}/architecture.md`
|
||||
- Extract technology choices with specific versions
|
||||
- Note architectural decisions that affect implementation
|
||||
|
||||
|
|
@ -55,7 +55,7 @@ Load and analyze project files to identify technologies:
|
|||
|
||||
**Configuration Files:**
|
||||
|
||||
- Look for TypeScript config (`tsconfig.json`)
|
||||
- Look for project language specific configs ( example: `tsconfig.json`)
|
||||
- Build tool configs (webpack, vite, next.config.js, etc.)
|
||||
- Linting and formatting configs (.eslintrc, .prettierrc, etc.)
|
||||
- Testing configurations (jest.config.js, vitest.config.ts, etc.)
|
||||
|
|
@ -123,17 +123,7 @@ Based on discovery, create or update the context document:
|
|||
#### A. Fresh Document Setup (if no existing context)
|
||||
|
||||
Copy template from `{installed_path}/project-context-template.md` to `{output_folder}/project-context.md`
|
||||
Initialize frontmatter with:
|
||||
|
||||
```yaml
|
||||
---
|
||||
project_name: '{{project_name}}'
|
||||
user_name: '{{user_name}}'
|
||||
date: '{{date}}'
|
||||
sections_completed: ['technology_stack']
|
||||
existing_patterns_found: { { number_of_patterns_discovered } }
|
||||
---
|
||||
```
|
||||
Initialize frontmatter fields.
|
||||
|
||||
#### B. Existing Document Update
|
||||
|
||||
|
|
@ -190,4 +180,4 @@ Ready to create/update your project context. This will help AI agents implement
|
|||
|
||||
After user selects [C] to continue, load `./step-02-generate.md` to collaboratively generate the specific project context rules.
|
||||
|
||||
Remember: Do NOT proceed to step-02 until user explicitly selects [C] from the menu and discovery is confirmed!
|
||||
Remember: Do NOT proceed to step-02 until user explicitly selects [C] from the menu and discovery is confirmed and the initial file has been written as directed in this discovery step!
|
||||
|
|
|
|||
|
|
@ -15,7 +15,7 @@
|
|||
- BMM artifacts: PRD, epics, architecture, UX, brief, research, brainstorm
|
||||
- Implementation: stories, sprint-status, workflow-status
|
||||
- Codebase: source directories, package files, git repo
|
||||
- Check both {output_folder} and {sprint_artifacts} locations
|
||||
- Check both {output_folder} and {implementation_artifacts} locations
|
||||
</action>
|
||||
|
||||
<action>Categorize into one of these states:
|
||||
|
|
|
|||
|
|
@ -6,7 +6,7 @@ author: "BMad"
|
|||
# Critical variables from config
|
||||
config_source: "{project-root}/_bmad/bmm/config.yaml"
|
||||
output_folder: "{config_source}:output_folder"
|
||||
sprint_artifacts: "{config_source}:sprint_artifacts"
|
||||
implementation_artifacts: "{config_source}:implementation_artifacts"
|
||||
user_name: "{config_source}:user_name"
|
||||
project_name: "{config_source}:project_name"
|
||||
communication_language: "{config_source}:communication_language"
|
||||
|
|
|
|||
|
|
@ -6,6 +6,8 @@ author: "BMad"
|
|||
# Critical variables from config
|
||||
config_source: "{project-root}/_bmad/bmm/config.yaml"
|
||||
output_folder: "{config_source}:output_folder"
|
||||
planning_artifacts: "{config_source}:planning_artifacts"
|
||||
implementation_artifacts: "{config_source}:implementation_artifacts"
|
||||
user_name: "{config_source}:user_name"
|
||||
communication_language: "{config_source}:communication_language"
|
||||
document_output_language: "{config_source}:document_output_language"
|
||||
|
|
@ -23,7 +25,7 @@ template: "{installed_path}/workflow-status-template.yaml"
|
|||
path_files: "{installed_path}/paths/"
|
||||
|
||||
# Output configuration - reads existing status
|
||||
default_output_file: "{output_folder}/bmm-workflow-status.yaml"
|
||||
default_output_file: "{planning_artifacts}/bmm-workflow-status.yaml"
|
||||
|
||||
standalone: true
|
||||
|
||||
|
|
|
|||
Loading…
Reference in New Issue