Source: GitHub · Docs · Open source
npx bmad-method install
# Creates:
# _bmad/ ? agents, workflows, config (framework)
# _bmad-output/ ? PRD, architecture, stories (your artifacts)
BMAD installs markdown and YAML files that define AI personas, workflows, and templates. Not a runtime or SaaS. Structured files that shape how LLMs behave during development. Works with Claude Code, Cursor, and Codex CLI.
How It Flows
Each phase produces documents that become context for the next agent. Every handoff is a fresh chat session. Continuity lives in files, not conversation history.
Analyst ? product-brief.md
PM ? PRD.md (reads product-brief)
Architect ? architecture.md (reads PRD)
PM ? epics/*.md (reads PRD + architecture)
SM ? story files (reads epics)
Developer ? working code (reads story + architecture)
Concrete Example
# _bmad-output/product-brief.md (Analyst agent)
We need a task tracking app for small teams.
Users create tasks, assign to team members, track status.
# _bmad-output/PRD.md (PM agent reads brief)
## User Stories
- As a user, I can create a task with title, description, assignee
- As a user, I can mark tasks as pending/in-progress/done
- As a user, I can filter tasks by status and assignee
## Acceptance Criteria
- Task list updates in real-time
- Mobile-responsive UI
- Works offline with sync when reconnected
# _bmad-output/architecture.md (Architect agent reads PRD)
## Stack
- Frontend: React + TypeScript
- Backend: Node.js + PostgreSQL
- Real-time: WebSocket (Socket.io)
- Offline: IndexedDB + sync queue
## Data Model
tasks: id, title, description, status, assignee_id, created_at
# _bmad-output/stories/create-task.md (Developer agent reads story + arch)
## Story: Create Task
User can create a new task via form.
## Implementation
POST /api/tasks - accepts { title, description, assignee_id }
Returns 201 + task object.
Client: React form with validation, optimistic update.
Each agent starts a fresh chat session, reads only its inputs, produces one artifact. No conversation history carries over.
Agents
Seven specialized personas: Analyst (requirements), PM (PRD + epics), Architect (system design), Developer (implementation), Scrum Master (sprint planning), QA (test strategy), Orchestrator (coordinates all).
Each agent loads only its inputs. Analyst reads existing briefs. PM reads product brief. Architect reads PRD. Developer reads story + architecture.
Planning Tracks
Quick Flow: Bug fixes, small features (tech-spec only).
BMad Method: Products, platforms (PRD + Architecture + UX).
Enterprise: Compliance, multi-tenant (full spec suite + security).
Party Mode
Multiple agent personas in one session. The Orchestrator picks which persona responds. Under the hood: one LLM role-playing multiple characters.
Modules
Core modules: BMM (base methodology), BMB (custom agents), TEA (test architecture), BMGD (game dev), CIS (creative workflows).
Tradeoffs
Strengths: Structured document handoffs keep agents scoped. Full lifecycle coverage (~20 workflows). Modular. Analyst agent is genuinely good at requirements elicitation.
Weaknesses: Full flow adds hours of ceremony that may not help simple features. Errors compound (bad PRD ? bad architecture ? bad code). Greenfield bias; brownfield needs workarounds. Sequential only, no parallel execution like GSD. 12+ agents and ~20 workflows create a steep learning curve.
BMAD vs GSD
BMAD: Full agile lifecycle, sequential phases, document handoffs, active human each phase. Best for complex greenfield with teams.
GSD: Four commands, wave-based parallelism, fresh 200K windows per task. Best for solo dev with clear vision.
When to Use
Use BMAD: Complex greenfield where you don't know what to build yet. Team structures (real or simulated). Enterprise audit trails needed.
Skip it: Solo dev who knows what they want. Bug fixes. Brownfield projects. Speed over documentation.