Archon/bmad/bmm/docs/agents-guide.md

BMad Method Agents Guide

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

Reading Time: ~45 minutes

---

Table of Contents

• Overview
• Core Development Agents
• Game Development Agents
• Special Purpose Agents
• Party Mode: Multi-Agent Collaboration
• Workflow Access
• Agent Customization
• Best Practices
• 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 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 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 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:

/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 - 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:

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:

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

Add Domain Expertise:

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:

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

Change Personality:

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

# 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:

# 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
• Phase 2: Planning Workflows
• Phase 3: Solutioning Workflows
• Phase 4: Implementation Workflows
• Testing & QA Workflows

Advanced References:

• Architecture Workflow Reference - Decision architecture details
• Document Project Workflow Reference - Brownfield documentation

Getting Started:

• Quick Start Guide - Step-by-step tutorial
• Scale Adaptive System - Understanding project levels
• Brownfield Guide - Working with existing code

Other Guides:

• Enterprise Agentic Development - Team collaboration
• FAQ - Common questions
• Troubleshooting - Problem resolution
• Glossary - Terminology reference

---

Quick Start Checklist

First Time with BMM:

• Read Quick Start Guide
• Understand Scale Adaptive System
• 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.