mirror of
https://github.com/bmadcode/BMAD-METHOD.git
synced 2025-12-29 16:14:59 +00:00
docs: massive documentation overhaul + introduce Paige (Documentation Guide agent)
## 📚 Complete Documentation Restructure **BMM Documentation Hub Created:** - New centralized documentation system at `src/modules/bmm/docs/` - 18 comprehensive guides organized by topic (7000+ lines total) - Clear learning paths for greenfield, brownfield, and quick spec flows - Professional technical writing standards throughout **New Documentation:** - `README.md` - Complete documentation hub with navigation - `quick-start.md` - 15-minute getting started guide - `agents-guide.md` - Comprehensive 12-agent reference (45 min read) - `party-mode.md` - Multi-agent collaboration guide (20 min read) - `scale-adaptive-system.md` - Deep dive on Levels 0-4 (42 min read) - `brownfield-guide.md` - Existing codebase development (53 min read) - `quick-spec-flow.md` - Rapid Level 0-1 development (26 min read) - `workflows-analysis.md` - Phase 1 workflows (12 min read) - `workflows-planning.md` - Phase 2 workflows (19 min read) - `workflows-solutioning.md` - Phase 3 workflows (13 min read) - `workflows-implementation.md` - Phase 4 workflows (33 min read) - `workflows-testing.md` - Testing & QA workflows (29 min read) - `workflow-architecture-reference.md` - Architecture workflow deep-dive - `workflow-document-project-reference.md` - Document-project workflow reference - `enterprise-agentic-development.md` - Team collaboration patterns - `faq.md` - Comprehensive Q&A covering all topics - `glossary.md` - Complete terminology reference - `troubleshooting.md` - Common issues and solutions **Documentation Improvements:** - Removed all version/date footers (git handles versioning) - Agent customization docs now include full rebuild process - Cross-referenced links between all guides - Reading time estimates for all major docs - Consistent professional formatting and structure **Consolidated & Streamlined:** - Module README (`src/modules/bmm/README.md`) streamlined to lean signpost - Root README polished with better hierarchy and clear CTAs - Moved docs from root `docs/` to module-specific locations - Better separation of user docs vs. developer reference ## 🤖 New Agent: Paige (Documentation Guide) **Role:** Technical documentation specialist and information architect **Expertise:** - Professional technical writing standards - Documentation structure and organization - Information architecture and navigation - User-focused content design - Style guide enforcement **Status:** Work in progress - Paige will evolve as documentation needs grow **Integration:** - Listed in agents-guide.md, glossary.md, FAQ - Available for all phases (documentation is continuous) - Can be customized like all BMM agents ## 🔧 Additional Changes - Updated agent manifest with Paige - Updated workflow manifest with new documentation workflows - Fixed workflow-to-agent mappings across all guides - Improved root README with clearer Quick Start section - Better module structure explanations - Enhanced community links with Discord channel names **Total Impact:** - 18 new/restructured documentation files - 7000+ lines of professional technical documentation - Complete navigation system with cross-references - Clear learning paths for all user types - Foundation for knowledge base (coming in beta) Co-Authored-By: Claude <noreply@anthropic.com>
This commit is contained in:
Brian Madison
@@ -1,258 +0,0 @@
|
||||
---
|
||||
last-redoc-date: 2025-10-01
|
||||
---
|
||||
|
||||
# Project Planning Workflow (Phase 2)
|
||||
|
||||
The Phase 2 Planning workflow is **scale-adaptive**, meaning it automatically determines the right level of planning documentation based on project complexity (Levels 0-4). This ensures planning overhead matches project value—from minimal tech specs for bug fixes to comprehensive PRDs for enterprise platforms.
|
||||
|
||||
## Scale-Adaptive Flow (Levels 0-4)
|
||||
|
||||
The workflow routes to different planning approaches based on project level:
|
||||
|
||||
### Level 0 - Single File Change / Bug Fix
|
||||
|
||||
**Planning:** Tech-spec only (lightweight implementation plan)
|
||||
**Output:** `tech-spec.md` with single story
|
||||
**Next Phase:** Direct to implementation (Phase 4)
|
||||
|
||||
### Level 1 - Small Feature (1-3 files, 2-5 stories)
|
||||
|
||||
**Planning:** Tech-spec only (implementation-focused)
|
||||
**Output:** `tech-spec.md` with epic breakdown and stories
|
||||
**Next Phase:** Direct to implementation (Phase 4)
|
||||
|
||||
### Level 2 - Feature Set / Small Project (5-15 stories, 1-2 epics)
|
||||
|
||||
**Planning:** PRD (product-focused) + Tech-spec (technical planning)
|
||||
**Output:** `PRD.md`, `epics.md`, `tech-spec.md`
|
||||
**Next Phase:** Tech-spec workflow (lightweight solutioning), then implementation (Phase 4)
|
||||
**Note:** Level 2 uses tech-spec instead of full architecture to keep planning lightweight
|
||||
|
||||
### Level 3 - Medium Project (15-40 stories, 2-5 epics)
|
||||
|
||||
**Planning:** PRD (strategic product document)
|
||||
**Output:** `PRD.md`, `epics.md`
|
||||
**Next Phase:** create-architecture workflow (Phase 3), then implementation (Phase 4)
|
||||
|
||||
### Level 4 - Large/Enterprise Project (40-100+ stories, 5-10 epics)
|
||||
|
||||
**Planning:** PRD (comprehensive product specification)
|
||||
**Output:** `PRD.md`, `epics.md`
|
||||
**Next Phase:** create-architecture workflow (Phase 3), then implementation (Phase 4)
|
||||
|
||||
**Critical Distinction:**
|
||||
|
||||
- **Levels 0-1:** No PRD, tech-spec only
|
||||
- **Level 2:** PRD + tech-spec (skips full architecture)
|
||||
- **Levels 3-4:** PRD → full create-architecture workflow
|
||||
|
||||
Critical to v6's flow improvement is this workflow's integration with the bmm-workflow-status.md tracking document, which maintains project state across sessions, tracks which agents participate in each phase, and provides continuity for multi-session planning efforts. The workflow can resume from any point, intelligently detecting existing artifacts and determining next steps without redundant work. For UX-heavy projects, it can generate standalone UX specifications or AI frontend prompts from existing specs.
|
||||
|
||||
## Key Features
|
||||
|
||||
- **Scale-adaptive planning** - Automatically determines output based on project complexity
|
||||
- **Intelligent routing** - Uses router system to load appropriate instruction sets
|
||||
- **Continuation support** - Can resume from previous sessions and handle incremental work
|
||||
- **Multi-level outputs** - Supports 5 project levels (0-4) with appropriate artifacts
|
||||
- **Input integration** - Leverages product briefs and market research when available
|
||||
- **Template-driven** - Uses validated templates for consistent output structure
|
||||
|
||||
### Configuration
|
||||
|
||||
The workflow adapts automatically based on project assessment, but key configuration options include:
|
||||
|
||||
- **scale_parameters**: Defines story/epic counts for each project level
|
||||
- **output_folder**: Where all generated documents are stored
|
||||
- **project_name**: Used in document names and templates
|
||||
|
||||
## Workflow Structure
|
||||
|
||||
### Files Included
|
||||
|
||||
```
|
||||
2-plan-workflows/
|
||||
├── README.md # Overview and usage details
|
||||
├── checklist.md # Shared validation criteria
|
||||
├── prd/
|
||||
│ ├── epics-template.md # Epic breakdown template
|
||||
│ ├── instructions.md # Level 2-4 PRD instructions
|
||||
│ ├── prd-template.md # Product Requirements Document template
|
||||
│ └── workflow.yaml
|
||||
├── tech-spec/
|
||||
│ ├── epics-template.md # Epic-to-story handoff template
|
||||
│ ├── instructions-level0-story.md
|
||||
│ ├── instructions-level1-stories.md
|
||||
│ ├── instructions.md # Level 0-1 tech-spec instructions
|
||||
│ ├── tech-spec-template.md # Technical Specification template
|
||||
│ ├── user-story-template.md # Story template for Level 0/1
|
||||
│ └── workflow.yaml
|
||||
├── gdd/
|
||||
│ ├── instructions-gdd.md # Game Design Document instructions
|
||||
│ ├── gdd-template.md # GDD template
|
||||
│ ├── game-types.csv # Genre catalog
|
||||
│ ├── game-types/ # Genre-specific templates
|
||||
│ └── workflow.yaml
|
||||
├── narrative/
|
||||
│ ├── instructions-narrative.md # Narrative design instructions
|
||||
│ ├── narrative-template.md # Narrative planning template
|
||||
│ └── workflow.yaml
|
||||
└── create-ux-design/
|
||||
├── instructions.md # UX design instructions
|
||||
├── ux-design-template.md # UX design template
|
||||
├── checklist.md # UX design validation checklist
|
||||
└── workflow.yaml
|
||||
```
|
||||
|
||||
## Workflow Process
|
||||
|
||||
### Phase 1: Assessment and Routing (Steps 1-5)
|
||||
|
||||
- **Project Analysis**: Determines project type (greenfield/brownfield/legacy)
|
||||
- **Scope Assessment**: Classifies into 5 levels based on complexity
|
||||
- **Document Discovery**: Identifies existing inputs and documentation
|
||||
- **Workflow Routing**: Loads appropriate instruction set based on level
|
||||
- **Continuation Handling**: Resumes from previous work when applicable
|
||||
|
||||
### Phase 2: Level-Specific Planning (Steps vary by level)
|
||||
|
||||
**Level 0 (Single File Change / Bug Fix)**:
|
||||
|
||||
- Tech-spec only workflow
|
||||
- Single story implementation plan
|
||||
- Direct to Phase 4 (implementation)
|
||||
|
||||
**Level 1 (Small Feature)**:
|
||||
|
||||
- Tech-spec only workflow
|
||||
- Epic breakdown with 2-5 stories
|
||||
- Direct to Phase 4 (implementation)
|
||||
|
||||
**Level 2 (Feature Set / Small Project)**:
|
||||
|
||||
- PRD workflow (strategic product document)
|
||||
- Generates `PRD.md` and `epics.md`
|
||||
- Then runs tech-spec workflow (lightweight solutioning)
|
||||
- Then to Phase 4 (implementation)
|
||||
|
||||
**Level 3-4 (Medium to Enterprise Projects)**:
|
||||
|
||||
- PRD workflow (comprehensive product specification)
|
||||
- Generates `PRD.md` and `epics.md`
|
||||
- Hands off to Phase 3 (create-architecture workflow)
|
||||
- Full architecture design before implementation
|
||||
|
||||
### Phase 3: Validation and Handoff (Final steps)
|
||||
|
||||
- **Document Review**: Validates outputs against checklists
|
||||
- **Architect Preparation**: For Level 3-4, prepares handoff materials
|
||||
- **Next Steps**: Provides guidance for development phase
|
||||
|
||||
## Output
|
||||
|
||||
### Generated Files
|
||||
|
||||
- **Primary output**: PRD.md (except Level 0), tech-spec.md, bmm-workflow-status.md
|
||||
- **Supporting files**: epics.md (Level 2-4), PRD-validation-report.md (if validation run)
|
||||
|
||||
### Output Structure by Level
|
||||
|
||||
**Level 0 - Tech Spec Only**:
|
||||
|
||||
- `tech-spec.md` - Single story implementation plan
|
||||
- Direct to implementation
|
||||
|
||||
**Level 1 - Tech Spec with Epic Breakdown**:
|
||||
|
||||
- `tech-spec.md` - Epic breakdown with 2-5 stories
|
||||
- Direct to implementation
|
||||
|
||||
**Level 2 - PRD + Tech Spec**:
|
||||
|
||||
- `PRD.md` - Strategic product document (goals, requirements, user journeys, UX principles, UI goals, epic list, scope)
|
||||
- `epics.md` - Tactical implementation roadmap (detailed story breakdown)
|
||||
- `tech-spec.md` - Lightweight technical planning (generated after PRD)
|
||||
- Then to implementation
|
||||
|
||||
**Level 3-4 - PRD + Full Architecture**:
|
||||
|
||||
- `PRD.md` - Comprehensive product specification
|
||||
- `epics.md` - Complete epic/story breakdown
|
||||
- Hands off to create-architecture workflow (Phase 3)
|
||||
- `architecture.md` - Generated by architect workflow
|
||||
- Then to implementation
|
||||
|
||||
## Requirements
|
||||
|
||||
- **Input Documents**: Product brief and/or market research (recommended but not required)
|
||||
- **Project Configuration**: Valid config.yaml with project_name and output_folder
|
||||
- **Assessment Readiness**: Clear understanding of project scope and objectives
|
||||
|
||||
## Best Practices
|
||||
|
||||
### Before Starting
|
||||
|
||||
1. **Gather Context**: Collect any existing product briefs, market research, or requirements
|
||||
2. **Define Scope**: Have a clear sense of project boundaries and complexity
|
||||
3. **Prepare Stakeholders**: Ensure key stakeholders are available for input if needed
|
||||
|
||||
### During Execution
|
||||
|
||||
1. **Be Honest About Scope**: Accurate assessment ensures appropriate planning depth
|
||||
2. **Leverage Existing Work**: Reference previous documents and avoid duplication
|
||||
3. **Think Incrementally**: Remember that planning can evolve - start with what you know
|
||||
|
||||
### After Completion
|
||||
|
||||
1. **Validate Against Checklist**: Use included validation criteria to ensure completeness
|
||||
2. **Share with Stakeholders**: Distribute appropriate documents to relevant team members
|
||||
3. **Prepare for Architecture**: For Level 3-4 projects, ensure architect has complete context
|
||||
|
||||
## Troubleshooting
|
||||
|
||||
### Common Issues
|
||||
|
||||
**Issue**: Workflow creates wrong level of documentation
|
||||
|
||||
- **Solution**: Review project assessment and restart with correct scope classification
|
||||
- **Check**: Verify the bmm-workflow-status.md reflects actual project complexity
|
||||
|
||||
**Issue**: Missing input documents cause incomplete planning
|
||||
|
||||
- **Solution**: Gather recommended inputs or proceed with manual context gathering
|
||||
- **Check**: Ensure critical business context is captured even without formal documents
|
||||
|
||||
**Issue**: Continuation from previous session fails
|
||||
|
||||
- **Solution**: Check for existing bmm-workflow-status.md and ensure output folder is correct
|
||||
- **Check**: Verify previous session completed at a valid checkpoint
|
||||
|
||||
## Customization
|
||||
|
||||
To customize this workflow:
|
||||
|
||||
1. **Modify Assessment Logic**: Update instructions-router.md to adjust level classification
|
||||
2. **Adjust Templates**: Customize PRD, tech-spec, or epic templates for organizational needs
|
||||
3. **Add Validation**: Extend checklist.md with organization-specific quality criteria
|
||||
4. **Configure Outputs**: Modify workflow.yaml to change file naming or structure
|
||||
|
||||
## Version History
|
||||
|
||||
- **v6.0.0** - Scale-adaptive architecture with intelligent routing
|
||||
- Multi-level project support (0-4)
|
||||
- Continuation and resumption capabilities
|
||||
- Template-driven output generation
|
||||
- Input document integration
|
||||
|
||||
## Support
|
||||
|
||||
For issues or questions:
|
||||
|
||||
- Review the workflow creation guide at `/bmad/bmb/workflows/create-workflow/workflow-creation-guide.md`
|
||||
- Validate output using `checklist.md`
|
||||
- Consult project assessment in `bmm-workflow-status.md`
|
||||
- Check continuation status in existing output documents
|
||||
|
||||
---
|
||||
|
||||
_Part of the BMad Method v6 - BMM (Method) Module_
|
||||
@@ -1,222 +0,0 @@
|
||||
# Game Design Document (GDD) Workflow
|
||||
|
||||
This folder contains the GDD workflow for game projects, replacing the traditional PRD approach with game-specific documentation.
|
||||
|
||||
## Overview
|
||||
|
||||
The GDD workflow creates a comprehensive Game Design Document that captures:
|
||||
|
||||
- Core gameplay mechanics and pillars
|
||||
- Game type-specific elements (RPG systems, platformer movement, puzzle mechanics, etc.)
|
||||
- Level design framework
|
||||
- Art and audio direction
|
||||
- Technical specifications (platform-agnostic)
|
||||
- Development epics
|
||||
|
||||
## Architecture
|
||||
|
||||
### Universal Template
|
||||
|
||||
`gdd-template.md` contains sections common to ALL game types:
|
||||
|
||||
- Executive Summary
|
||||
- Goals and Context
|
||||
- Core Gameplay
|
||||
- Win/Loss Conditions
|
||||
- Progression and Balance
|
||||
- Level Design Framework
|
||||
- Art and Audio Direction
|
||||
- Technical Specs
|
||||
- Development Epics
|
||||
- Success Metrics
|
||||
|
||||
### Game-Type-Specific Injection
|
||||
|
||||
The template includes a `{{GAME_TYPE_SPECIFIC_SECTIONS}}` placeholder that gets replaced with game-type-specific content.
|
||||
|
||||
### Game Types Registry
|
||||
|
||||
`game-types.csv` defines 24+ game types with:
|
||||
|
||||
- **id**: Unique identifier (e.g., `action-platformer`, `rpg`, `roguelike`)
|
||||
- **name**: Human-readable name
|
||||
- **description**: Brief description of the game type
|
||||
- **genre_tags**: Searchable tags
|
||||
- **fragment_file**: Path to type-specific template fragment
|
||||
|
||||
### Game-Type Fragments
|
||||
|
||||
Located in `game-types/` folder, these markdown files contain sections specific to each game type:
|
||||
|
||||
**action-platformer.md**:
|
||||
|
||||
- Movement System (jump mechanics, air control, special moves)
|
||||
- Combat System (attack types, combos, enemy AI)
|
||||
- Level Design Patterns (platforming challenges, combat arenas)
|
||||
- Player Abilities and Unlocks
|
||||
|
||||
**rpg.md**:
|
||||
|
||||
- Character System (stats, classes, leveling)
|
||||
- Inventory and Equipment
|
||||
- Quest System
|
||||
- World and Exploration
|
||||
- NPC and Dialogue
|
||||
- Combat System
|
||||
|
||||
**puzzle.md**:
|
||||
|
||||
- Core Puzzle Mechanics
|
||||
- Puzzle Progression
|
||||
- Level Structure
|
||||
- Player Assistance
|
||||
- Replayability
|
||||
|
||||
**roguelike.md**:
|
||||
|
||||
- Run Structure
|
||||
- Procedural Generation
|
||||
- Permadeath and Progression
|
||||
- Item and Upgrade System
|
||||
- Character Selection
|
||||
- Difficulty Modifiers
|
||||
|
||||
...and 20+ more game types!
|
||||
|
||||
## Workflow Flow
|
||||
|
||||
1. **Router Detection** (instructions-router.md):
|
||||
- Step 3 asks for project type
|
||||
- If "Game" selected → sets `workflow_type = "gdd"`
|
||||
- Skips standard level classification
|
||||
- Jumps to GDD-specific assessment
|
||||
|
||||
2. **Game Type Selection** (instructions-gdd.md Step 1):
|
||||
- Presents 9 common game types + "Other"
|
||||
- Maps selection to `game-types.csv`
|
||||
- Loads corresponding fragment file
|
||||
- Stores `game_type` for injection
|
||||
|
||||
3. **Universal GDD Sections** (Steps 2-5, 7-13):
|
||||
- Platform and target audience
|
||||
- Goals and context
|
||||
- Core gameplay (pillars, loop, win/loss)
|
||||
- Mechanics and controls
|
||||
- Progression and balance
|
||||
- Level design
|
||||
- Art and audio
|
||||
- Technical specs
|
||||
- Epics and metrics
|
||||
|
||||
4. **Game-Type Injection** (Step 6):
|
||||
- Loads fragment from `game-types/{game_type}.md`
|
||||
- For each `{{placeholder}}` in fragment, elicits details
|
||||
- Injects completed sections into `{{GAME_TYPE_SPECIFIC_SECTIONS}}`
|
||||
|
||||
5. **Solutioning Handoff** (Step 14):
|
||||
- Routes to `3-solutioning` workflow
|
||||
- Platform/engine specifics handled by solutioning registry
|
||||
- Game-\* entries in solutioning `registry.csv` provide engine-specific guidance
|
||||
|
||||
## Platform vs. Game Type Separation
|
||||
|
||||
**GDD (this workflow)**: Game-type specifics
|
||||
|
||||
- What makes an RPG an RPG (stats, quests, inventory)
|
||||
- What makes a platformer a platformer (jump mechanics, level design)
|
||||
- Genre-defining mechanics and systems
|
||||
|
||||
**Solutioning (3-solutioning workflow)**: Platform/engine specifics
|
||||
|
||||
- Unity vs. Godot vs. Phaser vs. Unreal
|
||||
- 2D vs. 3D rendering
|
||||
- Physics engines
|
||||
- Input systems
|
||||
- Platform constraints (mobile, web, console)
|
||||
|
||||
This separation allows:
|
||||
|
||||
- Single universal GDD regardless of platform
|
||||
- Platform decisions made during architecture phase
|
||||
- Easy platform pivots without rewriting GDD
|
||||
|
||||
## Output
|
||||
|
||||
**GDD.md**: Complete game design document with:
|
||||
|
||||
- All universal sections filled
|
||||
- Game-type-specific sections injected
|
||||
- Ready for solutioning handoff
|
||||
|
||||
## Example Game Types
|
||||
|
||||
| ID | Name | Key Sections |
|
||||
| ----------------- | ----------------- | ------------------------------------------------- |
|
||||
| action-platformer | Action Platformer | Movement, Combat, Level Patterns, Abilities |
|
||||
| rpg | RPG | Character System, Inventory, Quests, World, NPCs |
|
||||
| puzzle | Puzzle | Puzzle Mechanics, Progression, Level Structure |
|
||||
| roguelike | Roguelike | Run Structure, Procgen, Permadeath, Items |
|
||||
| shooter | Shooter | Weapon Systems, Enemy AI, Arena Design |
|
||||
| strategy | Strategy | Resources, Units, AI, Victory Conditions |
|
||||
| metroidvania | Metroidvania | Interconnected World, Ability Gating, Exploration |
|
||||
| visual-novel | Visual Novel | Branching Story, Dialogue Trees, Choices |
|
||||
| tower-defense | Tower Defense | Waves, Tower Types, Placement, Economy |
|
||||
| card-game | Card Game | Deck Building, Card Mechanics, Turn System |
|
||||
|
||||
...and 14+ more!
|
||||
|
||||
## Adding New Game Types
|
||||
|
||||
1. Add row to `game-types.csv`:
|
||||
|
||||
```csv
|
||||
new-type,New Type Name,"Description",tags,new-type.md
|
||||
```
|
||||
|
||||
2. Create `game-types/new-type.md`:
|
||||
|
||||
```markdown
|
||||
## New Type Specific Elements
|
||||
|
||||
### System Name
|
||||
|
||||
{{system_placeholder}}
|
||||
|
||||
**Details:**
|
||||
|
||||
- Element 1
|
||||
- Element 2
|
||||
```
|
||||
|
||||
3. The workflow automatically uses it!
|
||||
|
||||
## Integration with Solutioning
|
||||
|
||||
When a game project completes the GDD and moves to solutioning:
|
||||
|
||||
1. Solutioning workflow reads `project_type == "game"`
|
||||
2. Loads GDD.md instead of PRD.md
|
||||
3. Matches game platforms to solutioning `registry.csv` game-\* entries
|
||||
4. Provides engine-specific guidance (Unity, Godot, Phaser, etc.)
|
||||
5. Generates architecture.md with platform decisions
|
||||
6. Creates per-epic tech specs
|
||||
|
||||
Example solutioning registry entries:
|
||||
|
||||
- `game-unity-2d`: Unity 2D games
|
||||
- `game-godot-3d`: Godot 3D games
|
||||
- `game-phaser`: Phaser web games
|
||||
- `game-unreal-3d`: Unreal Engine games
|
||||
- `game-custom-3d-rust`: Custom Rust game engines
|
||||
|
||||
## Philosophy
|
||||
|
||||
**Game projects are fundamentally different from software products**:
|
||||
|
||||
- Gameplay feel > feature lists
|
||||
- Playtesting > user testing
|
||||
- Game pillars > product goals
|
||||
- Mechanics > requirements
|
||||
- Fun > utility
|
||||
|
||||
The GDD workflow respects these differences while maintaining BMAD Method rigor.
|
||||
Reference in New Issue
Block a user