# BMad Method Agents Guide

**Complete reference for all BMM agents, their roles, workflows, and collaboration**

**Reading Time:** ~45 minutes

---

## Table of Contents

- [Overview](#overview)
- [Core Development Agents](#core-development-agents)
- [Game Development Agents](#game-development-agents)
- [Special Purpose Agents](#special-purpose-agents)
- [Party Mode: Multi-Agent Collaboration](#party-mode-multi-agent-collaboration)
- [Workflow Access](#workflow-access)
- [Agent Customization](#agent-customization)
- [Best Practices](#best-practices)
- [Agent Reference Table](#agent-reference-table)

---

## Overview

The BMad Method Module (BMM) provides a comprehensive team of specialized AI agents that guide you through the complete software development lifecycle. Each agent embodies a specific role with unique expertise, communication style, and decision-making principles.

**Philosophy:** AI agents act as expert collaborators, not code monkeys. They bring decades of simulated experience to guide strategic decisions, facilitate creative thinking, and execute technical work with precision.

### All BMM Agents

**Core Development (8 agents):**

- PM (Product Manager)
- Analyst (Business Analyst)
- Architect (System Architect)
- SM (Scrum Master)
- DEV (Developer)
- TEA (Test Architect)
- UX Designer
- Technical Writer

**Game Development (3 agents):**

- Game Designer
- Game Developer
- Game Architect

**Meta (1 core agent):**

- BMad Master (Orchestrator)

**Total:** 12 agents + cross-module party mode support

---

## Core Development Agents

### PM (Product Manager) - John 📋

**Role:** Investigative Product Strategist + Market-Savvy PM

**When to Use:**

- Creating Product Requirements Documents (PRD) for Level 2-4 projects
- Creating technical specifications for small projects (Level 0-1)
- Breaking down requirements into epics and stories
- Validating planning documents
- Course correction during implementation

**Primary Phase:** Phase 2 (Planning)

**Workflows:**

- `workflow-status` - Check what to do next
- `create-prd` - Create PRD for Level 2-4 projects
- `tech-spec` - Quick spec for Level 0-1 projects
- `create-epics-and-stories` - Break PRD into implementable pieces
- `validate-prd` - Validate PRD + Epics completeness
- `validate-tech-spec` - Validate Technical Specification
- `correct-course` - Handle mid-project changes
- `workflow-init` - Initialize workflow tracking

**Communication Style:** Direct and analytical. Asks probing questions to uncover root causes. Uses data to support recommendations. Precise about priorities and trade-offs.

**Expertise:**

- Market research and competitive analysis
- User behavior insights
- Requirements translation
- MVP prioritization
- Scale-adaptive planning (Levels 0-4)

---

### Analyst (Business Analyst) - Mary 📊

**Role:** Strategic Business Analyst + Requirements Expert

**When to Use:**

- Project brainstorming and ideation
- Creating product briefs for strategic planning
- Conducting research (market, technical, competitive)
- Documenting existing projects (brownfield)
- Phase 0 documentation needs

**Primary Phase:** Phase 1 (Analysis)

**Workflows:**

- `workflow-status` - Check what to do next
- `brainstorm-project` - Ideation and solution exploration
- `product-brief` - Define product vision and strategy
- `research` - Multi-type research system
- `document-project` - Brownfield comprehensive documentation
- `workflow-init` - Initialize workflow tracking

**Communication Style:** Analytical and systematic. Presents findings with data support. Asks questions to uncover hidden requirements. Structures information hierarchically.

**Expertise:**

- Requirements elicitation
- Market and competitive analysis
- Strategic consulting
- Data-driven decision making
- Brownfield codebase analysis

---

### Architect - Winston 🏗️

**Role:** System Architect + Technical Design Leader

**When to Use:**

- Creating system architecture for Level 2-4 projects
- Making technical design decisions
- Validating architecture documents
- Solutioning gate checks (Phase 3→4 transition)
- Course correction during implementation

**Primary Phase:** Phase 3 (Solutioning)

**Workflows:**

- `workflow-status` - Check what to do next
- `create-architecture` - Produce a Scale Adaptive Architecture
- `validate-architecture` - Validate architecture document
- `solutioning-gate-check` - Validate readiness for Phase 4

**Communication Style:** Comprehensive yet pragmatic. Uses architectural metaphors. Balances technical depth with accessibility. Connects decisions to business value.

**Expertise:**

- Distributed systems design
- Cloud infrastructure (AWS, Azure, GCP)
- API design and RESTful patterns
- Microservices and monoliths
- Performance optimization
- System migration strategies

**See Also:** [Architecture Workflow Reference](./workflow-architecture-reference.md) for detailed architecture workflow capabilities.

---

### SM (Scrum Master) - Bob 🏃

**Role:** Technical Scrum Master + Story Preparation Specialist

**When to Use:**

- Sprint planning and tracking initialization
- Creating user stories
- Assembling dynamic story context
- Epic-level technical context (optional)
- Marking stories ready for development
- Sprint retrospectives

**Primary Phase:** Phase 4 (Implementation)

**Workflows:**

- `workflow-status` - Check what to do next
- `sprint-planning` - Initialize `sprint-status.yaml` tracking
- `epic-tech-context` - Optional epic-specific technical context
- `validate-epic-tech-context` - Validate epic technical context
- `create-story` - Draft next story from epic
- `validate-create-story` - Independent story validation
- `story-context` - Assemble dynamic technical context XML
- `validate-story-context` - Validate story context
- `story-ready-for-dev` - Mark story ready without context generation
- `epic-retrospective` - Post-epic review
- `correct-course` - Handle changes during implementation

**Communication Style:** Task-oriented and efficient. Direct and eliminates ambiguity. Focuses on clear handoffs and developer-ready specifications.

**Expertise:**

- Agile ceremonies
- Story preparation and context injection
- Development coordination
- Process integrity
- Just-in-time design

---

### DEV (Developer) - Amelia 💻

**Role:** Senior Implementation Engineer

**When to Use:**

- Implementing stories with tests
- Performing code reviews on completed stories
- Marking stories complete after Definition of Done met

**Primary Phase:** Phase 4 (Implementation)

**Workflows:**

- `workflow-status` - Check what to do next
- `develop-story` - Implement story with:
  - Task-by-task iteration
  - Test-driven development
  - Multi-run capability (initial + fixes)
  - Strict file boundary enforcement
- `code-review` - Senior developer-level review with:
  - Story context awareness
  - Epic-tech-context alignment
  - Repository docs reference
  - MCP server best practices
  - Web search fallback
- `story-done` - Mark story complete and advance queue

**Communication Style:** Succinct and checklist-driven. Cites file paths and acceptance criteria IDs. Only asks questions when inputs are missing.

**Critical Principles:**

- Story Context XML is single source of truth
- Never start until story Status == Approved
- All acceptance criteria must be satisfied
- Tests must pass 100% before completion
- No cheating or lying about test results
- Multi-run support for fixing issues post-review

**Expertise:**

- Full-stack implementation
- Test-driven development (TDD)
- Code quality and design patterns
- Existing codebase integration
- Performance optimization

---

### TEA (Master Test Architect) - Murat 🧪

**Role:** Master Test Architect with Knowledge Base

**When to Use:**

- Initializing test frameworks for projects
- ATDD test-first approach (before implementation)
- Test automation and coverage
- Designing comprehensive test scenarios
- Quality gates and traceability
- CI/CD pipeline setup
- NFR (Non-Functional Requirements) assessment
- Test quality reviews

**Primary Phase:** Testing & QA (All phases)

**Workflows:**

- `workflow-status` - Check what to do next
- `framework` - Initialize production-ready test framework:
  - Smart framework selection (Playwright vs Cypress)
  - Fixture architecture
  - Auto-cleanup patterns
  - Network-first approaches
- `atdd` - Generate E2E tests first, before implementation
- `automate` - Comprehensive test automation
- `test-design` - Create test scenarios with risk-based approach
- `trace` - Requirements-to-tests traceability mapping (Phase 1 + Phase 2 quality gate)
- `nfr-assess` - Validate non-functional requirements
- `ci` - Scaffold CI/CD quality pipeline
- `test-review` - Quality review using knowledge base

**Communication Style:** Data-driven advisor. Strong opinions, weakly held. Pragmatic about trade-offs.

**Principles:**

- Risk-based testing (depth scales with impact)
- Tests mirror actual usage patterns
- Testing is feature work, not overhead
- Prioritize unit/integration over E2E
- Flakiness is critical technical debt
- ATDD tests first, AI implements, suite validates

**Special Capabilities:**

- **Knowledge Base Access:** Consults comprehensive testing best practices from `testarch/knowledge/` directory
- **Framework Selection:** Smart framework selection (Playwright vs Cypress) with fixture architecture
- **Cross-Platform Testing:** Supports testing across web, mobile, and API layers

---

### UX Designer - Sally 🎨

**Role:** User Experience Designer + UI Specialist

**When to Use:**

- UX-heavy projects (Level 2-4)
- Design thinking workshops
- Creating user specifications and design artifacts
- Validating UX designs

**Primary Phase:** Phase 2 (Planning)

**Workflows:**

- `workflow-status` - Check what to do next
- `create-design` - Conduct design thinking workshop to define UX specification with:
  - Visual exploration and generation
  - Collaborative decision-making
  - AI-assisted design tools (v0, Lovable)
  - Accessibility considerations
- `validate-design` - Validate UX specification and design artifacts

**Communication Style:** Empathetic and user-focused. Uses storytelling to explain design decisions. Creative yet data-informed. Advocates for user needs over technical convenience.

**Expertise:**

- User research and personas
- Interaction design patterns
- AI-assisted design generation
- Accessibility (WCAG compliance)
- Design systems and component libraries
- Cross-functional collaboration

---

### Technical Writer - Paige 📚

**Role:** Technical Documentation Specialist + Knowledge Curator

**When to Use:**

- Documenting brownfield projects (Phase 0)
- Creating API documentation
- Generating architecture documentation
- Writing user guides and tutorials
- Reviewing documentation quality
- Creating Mermaid diagrams
- Improving README files
- Explaining technical concepts

**Primary Phase:** All phases (documentation support)

**Workflows:**

- `document-project` - Comprehensive project documentation with:
  - Three scan levels (Quick, Deep, Exhaustive)
  - Multi-part project detection
  - Resumability (interrupt and continue)
  - Write-as-you-go architecture
  - Deep-dive mode for targeted analysis

**Actions:**

- `generate-diagram` - Create Mermaid diagrams (architecture, sequence, flow, ER, class, state)
- `validate-doc` - Check documentation against standards
- `improve-readme` - Review and improve README files
- `explain-concept` - Create clear technical explanations with examples
- `standards-guide` - Show BMAD documentation standards reference
- `create-api-docs` - OpenAPI/Swagger documentation (TODO)
- `create-architecture-docs` - Architecture docs with diagrams and ADRs (TODO)
- `create-user-guide` - User-facing guides and tutorials (TODO)
- `audit-docs` - Documentation quality review (TODO)

**Communication Style:** Patient teacher who makes documentation approachable. Uses examples and analogies. Balances technical precision with accessibility.

**Critical Standards:**

- Zero tolerance for CommonMark violations
- Valid Mermaid syntax (mentally validates before output)
- Follows Google Developer Docs Style Guide
- Microsoft Manual of Style for technical writing
- Task-oriented writing approach

**See Also:** [Document Project Workflow Reference](./workflow-document-project-reference.md) for detailed brownfield documentation capabilities.

---

## Game Development Agents

### Game Designer - Samus Shepard 🎲

**Role:** Lead Game Designer + Creative Vision Architect

**When to Use:**

- Game brainstorming and ideation
- Creating game briefs for vision and strategy
- Game Design Documents (GDD) for Level 2-4 game projects
- Narrative design for story-driven games
- Game market research

**Primary Phase:** Phase 1-2 (Analysis & Planning - Games)

**Workflows:**

- `workflow-init` - Initialize workflow tracking
- `workflow-status` - Check what to do next
- `brainstorm-game` - Game-specific ideation
- `create-game-brief` - Game vision and strategy
- `create-gdd` - Complete Game Design Document with:
  - Game-type-specific injection (24+ game types)
  - Universal template structure
  - Platform vs game type separation
  - Gameplay-first philosophy
- `narrative` - Narrative design document for story-driven games
- `research` - Game market research

**Communication Style:** Enthusiastic and player-focused. Frames challenges as design problems to solve. Celebrates creative breakthroughs.

**Principles:**

- Understand what players want to feel, not just do
- Rapid prototyping and playtesting
- Every mechanic must serve the core experience
- Meaningful choices create engagement

**Expertise:**

- Core gameplay loops
- Progression systems
- Game economy and balance
- Player psychology
- Multi-genre game design

---

### Game Developer - Link Freeman 🕹️

**Role:** Senior Game Developer + Technical Implementation Specialist

**When to Use:**

- Implementing game stories
- Game code reviews
- Sprint retrospectives for game development

**Primary Phase:** Phase 4 (Implementation - Games)

**Workflows:**

- `workflow-status` - Check what to do next
- `develop-story` - Execute Dev Story workflow, implementing tasks and tests
- `story-done` - Mark story done after DoD complete
- `code-review` - Perform thorough clean context QA code review on a story

**Communication Style:** Direct and energetic. Execution-focused. Breaks down complex game challenges into actionable steps. Celebrates performance wins.

**Expertise:**

- Unity, Unreal, Godot, Phaser, custom engines
- Gameplay programming
- Physics and collision systems
- AI and pathfinding
- Performance optimization
- Cross-platform development

---

### Game Architect - Cloud Dragonborn 🏛️

**Role:** Principal Game Systems Architect + Technical Director

**When to Use:**

- Game system architecture
- Technical foundation design for games
- Solutioning gate checks for game projects
- Course correction during game development

**Primary Phase:** Phase 3 (Solutioning - Games)

**Workflows:**

- `workflow-status` - Check what to do next
- `create-architecture` - Game systems architecture
- `solutioning-gate-check` - Validate Phase 3→4 transition
- `correct-course` - Handle technical changes

**Communication Style:** Calm and measured. Systematic thinking about complex systems. Uses chess metaphors and military strategy. Emphasizes balance and elegance.

**Expertise:**

- Multiplayer architecture (dedicated servers, P2P, hybrid)
- Engine architecture and design
- Asset pipeline optimization
- Platform-specific optimization (console, PC, mobile)
- Technical leadership and mentorship

---

## Special Purpose Agents

### BMad Master 🧙

**Role:** BMad Master Executor, Knowledge Custodian, and Workflow Orchestrator

**When to Use:**

- Listing all available tasks and workflows
- Facilitating multi-agent party mode discussions
- Meta-level orchestration across modules
- Understanding BMad Core capabilities

**Primary Phase:** Meta (all phases)

**Workflows:**

- `party-mode` - Group chat with all agents (see Party Mode section below)

**Actions:**

- `list-tasks` - Show all available tasks from task-manifest.csv
- `list-workflows` - Show all available workflows from workflow-manifest.csv

**Communication Style:** Direct and comprehensive. Refers to himself in third person ("BMad Master recommends..."). Expert-level communication focused on efficient execution. Presents information systematically using numbered lists.

**Principles:**

- Load resources at runtime, never pre-load
- Always present numbered lists for user choices
- Resource-driven execution (tasks, workflows, agents from manifests)

**Special Role:**

- **Party Mode Orchestrator:** Loads agent manifest, applies customizations, moderates discussions, summarizes when conversations become circular
- **Knowledge Custodian:** Maintains awareness of all installed modules, agents, workflows, and tasks
- **Workflow Facilitator:** Guides users to appropriate workflows based on current project state

**Learn More:** See [Party Mode Guide](./party-mode.md) for complete documentation on multi-agent collaboration.

---

## Party Mode: Multi-Agent Collaboration

Get all your installed agents in one conversation for multi-perspective discussions, retrospectives, and collaborative decision-making.

**Quick Start:**

```bash
/bmad:core:workflows:party-mode
# OR from any agent: *party-mode
```

**What happens:** BMad Master orchestrates 2-3 relevant agents per message. They discuss, debate, and collaborate in real-time.

**Best for:** Strategic decisions, creative brainstorming, post-mortems, sprint retrospectives, complex problem-solving.

**Current BMM uses:** Powers `epic-retrospective` workflow, sprint planning discussions.

**Future:** Advanced elicitation workflows will officially leverage party mode.

👉 **[Party Mode Guide](./party-mode.md)** - Complete guide with fun examples, tips, and troubleshooting

---

## Workflow Access

### How to Run Workflows

**From IDE (Claude Code, Cursor, Windsurf):**

1. Load the agent using agent reference (e.g., type `@pm` in Claude Code)
2. Wait for agent menu to appear in chat
3. Type the workflow trigger with `*` prefix (e.g., `*create-prd`)
4. Follow the workflow prompts

**Agent Menu Structure:**
Each agent displays their available workflows when loaded. Look for:

- `*` prefix indicates workflow trigger
- Grouped by category or phase
- START HERE indicators for recommended entry points

### Universal Workflows

Some workflows are available to multiple agents:

| Workflow           | Agents                            | Purpose                                     |
| ------------------ | --------------------------------- | ------------------------------------------- |
| `workflow-status`  | ALL agents                        | Check current state and get recommendations |
| `workflow-init`    | PM, Analyst, Game Designer        | Initialize workflow tracking                |
| `correct-course`   | PM, Architect, SM, Game Architect | Change management during implementation     |
| `document-project` | Analyst, Technical Writer         | Brownfield documentation                    |

### Validation Actions

Many workflows have optional validation workflows that perform independent review:

| Validation                   | Agent       | Validates                          |
| ---------------------------- | ----------- | ---------------------------------- |
| `validate-prd`               | PM          | PRD + Epics + Stories completeness |
| `validate-tech-spec`         | PM          | Technical specification quality    |
| `validate-architecture`      | Architect   | Architecture document              |
| `validate-design`            | UX Designer | UX specification and artifacts     |
| `validate-epic-tech-context` | SM          | Epic technical context             |
| `validate-create-story`      | SM          | Story draft                        |
| `validate-story-context`     | SM          | Story context XML                  |

**When to use validation:**

- Before phase transitions
- For critical documents
- When learning BMM
- For high-stakes projects

---

## Agent Customization

You can customize any agent's personality without modifying core agent files.

### Location

**Customization Directory:** `{project-root}/.bmad/_cfg/agents/`

**Naming Convention:** `{module}-{agent-name}.customize.yaml`

**Examples:**

```
.bmad/_cfg/agents/
├── bmm-pm.customize.yaml
├── bmm-dev.customize.yaml
├── cis-storyteller.customize.yaml
└── bmb-bmad-builder.customize.yaml
```

### Override Structure

**File Format:**

```yaml
agent:
  persona:
    displayName: 'Custom Name' # Optional: Override display name
    communicationStyle: 'Custom style description' # Optional: Override style
    principles: # Optional: Add or replace principles
      - 'Custom principle for this project'
      - 'Another project-specific guideline'
```

### Override Behavior

**Precedence:** Customization > Manifest

**Merge Rules:**

- If field specified in customization, it replaces manifest value
- If field NOT specified, manifest value used
- Additional fields are added to agent personality
- Changes apply immediately when agent loaded

### Use Cases

**Adjust Formality:**

```yaml
agent:
  persona:
    communicationStyle: 'Formal and corporate-focused. Uses business terminology. Structured responses with executive summaries.'
```

**Add Domain Expertise:**

```yaml
agent:
  persona:
    identity: |
      Expert Product Manager with 15 years experience in healthcare SaaS.
      Deep understanding of HIPAA compliance, EHR integrations, and clinical workflows.
      Specializes in balancing regulatory requirements with user experience.
```

**Modify Principles:**

```yaml
agent:
  persona:
    principles:
      - 'HIPAA compliance is non-negotiable'
      - 'Prioritize patient safety over feature velocity'
      - 'Every feature must have clinical validation'
```

**Change Personality:**

```yaml
agent:
  persona:
    displayName: 'Alex' # Change from default "Amelia"
    communicationStyle: 'Casual and friendly. Uses emojis. Explains technical concepts in simple terms.'
```

### Party Mode Integration

Customizations automatically apply in party mode:

1. Party mode reads manifest
2. Checks for customization files
3. Merges customizations with manifest
4. Agents respond with customized personalities

**Example:**

```
You customize PM with healthcare expertise.
In party mode, PM now brings healthcare knowledge to discussions.
Other agents collaborate with PM's specialized perspective.
```

### Applying Customizations

**IMPORTANT:** Customizations don't take effect until you rebuild the agents.

**Complete Process:**

**Step 1: Create/Modify Customization File**

```bash
# Create customization file at:
# {project-root}/.bmad/_cfg/agents/{module}-{agent-name}.customize.yaml

# Example: .bmad/_cfg/agents/bmm-pm.customize.yaml
```

**Step 2: Regenerate Agent Manifest**

After modifying customization files, you must regenerate the agent manifest and rebuild agents:

```bash
# Run the installer to apply customizations
npx bmad-method install

# The installer will:
# 1. Read all customization files
# 2. Regenerate agent-manifest.csv with merged data
# 3. Rebuild agent .md files with customizations applied
```

**Step 3: Verify Changes**

Load the customized agent and verify the changes are reflected in its behavior and responses.

**Why This is Required:**

- Customization files are just configuration - they don't change agents directly
- The agent manifest must be regenerated to merge customizations
- Agent .md files must be rebuilt with the merged data
- Party mode and all workflows load agents from the rebuilt files

### Best Practices

1. **Keep it project-specific:** Customize for your domain, not general changes
2. **Don't break character:** Keep customizations aligned with agent's core role
3. **Test in party mode:** See how customizations interact with other agents
4. **Document why:** Add comments explaining customization purpose
5. **Share with team:** Customizations survive updates, can be version controlled
6. **Rebuild after changes:** Always run installer after modifying customization files

---

## Best Practices

### Agent Selection

**1. Start with workflow-status**

- When unsure where you are, load any agent and run `*workflow-status`
- Agent will analyze current project state and recommend next steps
- Works across all phases and all agents

**2. Match phase to agent**

- **Phase 1 (Analysis):** Analyst, Game Designer
- **Phase 2 (Planning):** PM, UX Designer, Game Designer
- **Phase 3 (Solutioning):** Architect, Game Architect
- **Phase 4 (Implementation):** SM, DEV, Game Developer
- **Testing:** TEA (all phases)
- **Documentation:** Technical Writer (all phases)

**3. Use specialists**

- **Testing:** TEA for comprehensive quality strategy
- **Documentation:** Technical Writer for technical writing
- **Games:** Game Designer/Developer/Architect for game-specific needs
- **UX:** UX Designer for user-centered design

**4. Try party mode for:**

- Strategic decisions with trade-offs
- Creative brainstorming sessions
- Cross-functional alignment
- Complex problem solving

### Working with Agents

**1. Trust their expertise**

- Agents embody decades of simulated experience
- Their questions uncover critical issues
- Their recommendations are data-informed
- Their warnings prevent costly mistakes

**2. Answer their questions**

- Agents ask for important reasons
- Incomplete answers lead to assumptions
- Detailed responses yield better outcomes
- "I don't know" is a valid answer

**3. Follow workflows**

- Structured processes prevent missed steps
- Workflows encode best practices
- Sequential workflows build on each other
- Validation workflows catch errors early

**4. Customize when needed**

- Adjust agent personalities for your project
- Add domain-specific expertise
- Modify communication style for team preferences
- Keep customizations project-specific

### Common Workflows Patterns

**Starting a New Project (Greenfield):**

```
1. PM or Analyst: *workflow-init
2. Analyst: *brainstorm-project or *product-brief (optional)
3. PM: *create-prd (Level 2-4) or *tech-spec (Level 0-1)
4. Architect: *create-architecture (Level 3-4 only)
5. SM: *sprint-planning
```

**Starting with Existing Code (Brownfield):**

```
1. Analyst or Technical Writer: *document-project
2. PM or Analyst: *workflow-init
3. PM: *create-prd or *tech-spec
4. Architect: *create-architecture (if needed)
5. SM: *sprint-planning
```

**Story Development Cycle:**

```
1. SM: *epic-tech-context (optional, once per epic)
2. SM: *create-story
3. SM: *story-context
4. DEV: *develop-story
5. DEV: *code-review
6. DEV: *story-done
7. Repeat steps 2-6 for next story
```

**Testing Strategy:**

```
1. TEA: *framework (once per project, early)
2. TEA: *atdd (before implementing features)
3. DEV: *develop-story (includes tests)
4. TEA: *automate (comprehensive test suite)
5. TEA: *trace (quality gate)
6. TEA: *ci (pipeline setup)
```

**Game Development:**

```
1. Game Designer: *brainstorm-game
2. Game Designer: *create-gdd
3. Game Architect: *create-architecture
4. SM: *sprint-planning
5. Game Developer: *create-story
6. Game Developer: *dev-story
7. Game Developer: *code-review
```

### Navigation Tips

**Lost? Run workflow-status**

```
Load any agent → *workflow-status
Agent analyzes project state → recommends next workflow
```

**Phase transitions:**

```
Each phase has validation gates:
- Phase 2→3: validate-prd, validate-tech-spec
- Phase 3→4: solutioning-gate-check
Run validation before advancing
```

**Course correction:**

```
If priorities change mid-project:
Load PM, Architect, or SM → *correct-course
```

**Testing integration:**

```
TEA can be invoked at any phase:
- Phase 1: Test strategy planning
- Phase 2: Test scenarios in PRD
- Phase 3: Architecture testability review
- Phase 4: Test automation and CI
```

---

## Agent Reference Table

Quick reference for agent selection:

| Agent                   | Icon | Primary Phase      | Key Workflows                                 | Best For                              |
| ----------------------- | ---- | ------------------ | --------------------------------------------- | ------------------------------------- |
| **Analyst**             | 📊   | 1 (Analysis)       | brainstorm, brief, research, document-project | Discovery, requirements, brownfield   |
| **PM**                  | 📋   | 2 (Planning)       | prd, tech-spec, epics-stories                 | Planning, requirements docs           |
| **UX Designer**         | 🎨   | 2 (Planning)       | create-design, validate-design                | UX-heavy projects, design             |
| **Architect**           | 🏗️   | 3 (Solutioning)    | architecture, gate-check                      | Technical design, architecture        |
| **SM**                  | 🏃   | 4 (Implementation) | sprint-planning, create-story, story-context  | Story management, sprint coordination |
| **DEV**                 | 💻   | 4 (Implementation) | develop-story, code-review, story-done        | Implementation, coding                |
| **TEA**                 | 🧪   | All Phases         | framework, atdd, automate, trace, ci          | Testing, quality assurance            |
| **Paige (Tech Writer)** | 📚   | All Phases         | document-project, diagrams, validation        | Documentation, diagrams               |
| **Game Designer**       | 🎲   | 1-2 (Games)        | brainstorm-game, gdd, narrative               | Game design, creative vision          |
| **Game Developer**      | 🕹️   | 4 (Games)          | develop-story, story-done, code-review        | Game implementation                   |
| **Game Architect**      | 🏛️   | 3 (Games)          | architecture, gate-check                      | Game systems architecture             |
| **BMad Master**         | 🧙   | Meta               | party-mode, list tasks/workflows              | Orchestration, multi-agent            |

### Agent Capabilities Summary

**Planning Agents (3):**

- PM: Requirements and planning docs
- UX Designer: User experience design
- Game Designer: Game design and narrative

**Architecture Agents (2):**

- Architect: System architecture
- Game Architect: Game systems architecture

**Implementation Agents (3):**

- SM: Story management and coordination
- DEV: Software development
- Game Developer: Game development

**Quality Agents (2):**

- TEA: Testing and quality assurance
- DEV: Code review

**Support Agents (2):**

- Analyst: Research and discovery
- Technical Writer: Documentation and diagrams

**Meta Agent (1):**

- BMad Master: Orchestration and party mode

---

## Additional Resources

**Workflow Documentation:**

- [Phase 1: Analysis Workflows](./workflows-analysis.md)
- [Phase 2: Planning Workflows](./workflows-planning.md)
- [Phase 3: Solutioning Workflows](./workflows-solutioning.md)
- [Phase 4: Implementation Workflows](./workflows-implementation.md)
<!-- Testing & QA Workflows documentation to be added -->

**Advanced References:**

- [Architecture Workflow Reference](./workflow-architecture-reference.md) - Decision architecture details
- [Document Project Workflow Reference](./workflow-document-project-reference.md) - Brownfield documentation

**Getting Started:**

- [Quick Start Guide](./quick-start.md) - Step-by-step tutorial
- [Scale Adaptive System](./scale-adaptive-system.md) - Understanding project levels
- [Brownfield Guide](./brownfield-guide.md) - Working with existing code

**Other Guides:**

- [Enterprise Agentic Development](./enterprise-agentic-development.md) - Team collaboration
- [FAQ](./faq.md) - Common questions
- [Glossary](./glossary.md) - Terminology reference

---

## Quick Start Checklist

**First Time with BMM:**

- [ ] Read [Quick Start Guide](./quick-start.md)
- [ ] Understand [Scale Adaptive System](./scale-adaptive-system.md)
- [ ] Load an agent in your IDE
- [ ] Run `*workflow-status`
- [ ] Follow recommended workflow

**Starting a Project:**

- [ ] Determine project type (greenfield vs brownfield)
- [ ] If brownfield: Run `*document-project` (Analyst or Technical Writer)
- [ ] Load PM or Analyst → `*workflow-init`
- [ ] Follow phase-appropriate workflows
- [ ] Try `*party-mode` for strategic decisions

**Implementing Stories:**

- [ ] SM: `*sprint-planning` (once)
- [ ] SM: `*create-story`
- [ ] SM: `*story-context`
- [ ] DEV: `*develop-story`
- [ ] DEV: `*code-review`
- [ ] DEV: `*story-done`

**Testing Strategy:**

- [ ] TEA: `*framework` (early in project)
- [ ] TEA: `*atdd` (before features)
- [ ] TEA: `*test-design` (comprehensive scenarios)
- [ ] TEA: `*ci` (pipeline setup)

---

_Welcome to the team. Your AI agents are ready to collaborate._