Contents
I’ve tried a lot of frameworks and prompting strategies. Most of them are either too rigid to be useful or too vague to change how you actually work. The BMad Method is the exception. It’s the one framework I’d install first on any new machine, and it’s had a bigger impact on how I use Claude Code than almost anything else.
Let me explain what it is, why it works, and the specific features that make it worth your time.
What the BMad Method Actually Is
BMad (version 6.6.0, 47K+ GitHub stars) is a multi-agent framework for AI-assisted software development. The core idea: instead of asking a single AI to be architect, developer, and QA simultaneously — which leads to shallow, compromised output — BMad assigns specialized agents to each role and orchestrates them through a defined workflow.
The four phases are:
- Analysis — Understanding the problem and gathering requirements
- Planning — Translating requirements into technical decisions
- Solutioning — Architecting the solution at a system level
- Implementation — Writing and iterating on actual code
Each phase has its own agent with its own persona, knowledge base, and operating constraints. The handoffs between phases are explicit. Context doesn’t get muddled; each agent focuses on what it’s actually good at.
The economics are real: teams using BMad report compressing 40-hour planning cycles to around 8 hours, and a 57% reduction in AI costs because you’re running more focused, bounded agent sessions rather than open-ended chat marathons.
It’s free and open source. You can read the full source and methodology at github.com/bmad-code-org/BMAD-METHOD.
The Full Agent Roster
BMad ships with 21 agents across four modules. Each is a fully defined persona with a distinct identity, communication style, and operating principles — not just a system prompt label but a coherent point of view. Here’s who you’re working with.
Core Development Team (BMad Method)
These eight agents cover the full software development lifecycle:
Winston — The Architect operates in Phase 3 and is the agent you bring in for system-level decisions. His philosophy in one phrase: “boring technology for stability.” Winston won’t suggest the exciting new thing just because it exists. He’ll push you toward the option that will still make sense in two years, that your team can debug at 2am, that doesn’t have three open security advisories. Calm, pragmatic, strong opinions delivered without drama.
Amelia — The Senior Engineer is Phase 4 — she implements. Her operating style is ultra-succinct. She thinks in file paths and acceptance criteria. If you give her a story, she wants the ACs. She doesn’t narrate; she does. The practical effect: implementation moves faster because her context is scoped to execution, not trying to be architect and developer simultaneously.
John — The Product Manager asks “WHY?” relentlessly. Eight years of B2B and consumer product experience channeled into a single detective-style interrogator who cuts through feature requests to find what users actually need. He builds PRDs from user interviews, not templates. Ship the smallest thing that validates the assumption — that’s his guiding principle.
Mary — The Business Analyst is Phase 1, and probably the most underestimated agent in the stack. She approaches every project as a treasure hunt — finding hidden assumptions, unstated constraints, the things you didn’t know you needed to know. She reaches for Porter’s Five Forces, SWOT analysis, root cause analysis. She asks the uncomfortable questions before any code gets written. Working with Mary at the start of a project changes the downstream quality of everything that follows.
Quinn — The QA Engineer is a pragmatic test automation engineer with a “ship it and iterate” mentality. She generates API and E2E tests fast — coverage first, optimization later. She’s the agent you pair with Amelia to close the loop on quality without slowing the development cycle down.
Bob — The Scrum Master is crisp and checklist-driven. He runs ceremonies, prepares stories, manages backlog, and maintains zero tolerance for ambiguity. Every user story he writes is actionable — every requirement crystal clear.
Paige — The Technical Writer explains like she’s teaching a friend. Complex concepts become accessible structured documentation. She prefers diagrams over paragraphs, and she calibrates detail to the intended audience. She also covers the Game Development Suite when that module is active.
Sally — The UX Designer paints user stories in vivid strokes. Seven years of web and mobile experience, empathy-first, every design decision grounded in genuine user needs. She starts simple and evolves through feedback — never over-designs for a use case she hasn’t validated.
Game Development Suite
For projects that involve games, BMad ships a dedicated five-agent team:
Samus Shepard — Lead Game Designer brings the energy of an excited streamer and the design instincts of someone who idolizes Miyamoto. She designs for player feel first, asks about player motivations constantly, and prototypes fast.
Cloud Dragonborn — Principal Game Architect is the wise sage of the team — calm, measured, speaks in architectural metaphors. Twenty years of shipped titles behind him, expert in distributed systems and engine design. He holds decisions until the data earns them.
Link Freeman — Senior Game Developer thinks like a speedrunner. Milestone-focused, direct, treats blockers as boss fights. Sixty frames per second is non-negotiable. He writes code designers can iterate on, runs red-green-refactor, and tests first.
Indie — Solo Dev is the battle-hardened indie who ships complete games alone. Prototype fast, make it playable before making it perfect, iterate from real player feedback. He knows Unity, Unreal, and Godot.
Creative Intelligence Suite
Six agents covering brainstorming, design thinking, strategy, problem-solving, storytelling, and presentation:
Carson — Brainstorming Coach channels Alex Osborn’s divergent thinking foundations and Keith Johnstone’s improv instinct. High-energy, YES-AND approach, celebrates the wildest ideas because that’s where the good ones come from.
Maya — Design Thinking Coach facilitates empathy-first problem framing. She improvises around themes like a jazz musician — vivid metaphors, rapid prototyping, five-phase facilitation borrowed from IDEO.
Victor — Innovation Strategist is the chess grandmaster of the group — bold declarations, strategic silences, devastatingly simple questions. He draws on Clayton Christensen’s disruption theory and Blue Ocean thinking to find where genuine new value is possible.
Dr. Quinn — Creative Problem Solver treats every problem as a system and hunts root causes relentlessly. TRIZ methodology, Theory of Constraints, Five Whys. Sherlock Holmes energy — deductive, curious, deeply satisfied by the AHA moment.
Sophia — Storyteller grounds every narrative in timeless human truths before touching the surface style. She works from 25 story frameworks and understands the emotional psychology of what makes people listen.
Caravaggio — Presentation Master is the sarcastic creative director who roasts bad visual hierarchy with wit and then fixes it. He applies Nancy Duarte’s presentation architecture and Saul Bass’s cinematic instinct to make information move.
Test Engineering Architect
Murat — Master Test Architect is the specialist you bring in when you need a serious testing strategy, not just coverage. Risk-based testing, Playwright, Cypress, pytest, consumer-driven contract testing with Pact, k6 for performance. He speaks in risk calculations and impact assessments, holds strong opinions weakly held, and will tell you exactly what would break under load.
Five Advanced Elicitation Techniques
BMad ships with a library of advanced elicitation techniques — structured thinking methods that any agent can apply when the problem calls for it. These aren’t gimmicks. They’re cognitive tools that experienced consultants and engineers use in practice, made accessible through prompting.
The full library has 50 techniques across 10 categories. I’ve written a complete reference covering every one of them — what each does, when to use it, and which BMad phases it fits.
The five I use most:
1. Pre-mortem Analysis
You’re about to start building something. Before you do, imagine it six months from now: it’s failed. What went wrong?
Pre-mortem works by reversing the psychological pressure that makes people underreport risks during planning. Nobody wants to be the pessimist. But in a pre-mortem, you’re explicitly asked to be. The output is a specific list of plausible failure modes — technical debt that accumulates too fast, scope that expands without a gate, a dependency that gets deprecated. That list becomes your early-warning system.
2. First Principles Thinking
Strip away all assumptions about how something is done and start from fundamental truths. What do we actually know? What constraints are real versus inherited convention?
Most codebases contain decisions that were made for reasons nobody remembers. First principles thinking is how you find those decisions and evaluate whether they’re still load-bearing. It’s also how you avoid cargo-culting architectural patterns that don’t fit your actual problem.
3. Inversion
Instead of asking “how do we succeed?”, ask “how could we guarantee failure?” Then avoid those things.
Inversion is particularly useful for security, reliability, and UX decisions. It surfaces the edge cases that forward-focused thinking misses. When I’m reviewing a design for something customer-facing, I’ll run an inversion pass: “What would guarantee the worst possible user experience here?“
4. Red Team vs Blue Team
Split the analysis into attack and defense. The Red Team tries to find weaknesses, vulnerabilities, or failure modes in the plan. The Blue Team defends and responds to each challenge.
This is standard practice in security research and military planning, and it translates directly to software architecture decisions. BMad implements it as a structured dialogue that can run in a single session. The output is a plan that’s been actively stress-tested, not just theorized.
5. Socratic Questioning
Rather than accepting stated assumptions, probe them systematically. What is the evidence for this? What are the counter-examples? What would change the conclusion?
This is Mary’s default mode, but any agent can apply it. The goal is to expose hidden assumptions before they become architectural decisions. In practice, this usually surfaces requirements that were implicit and constraints that weren’t communicated — the things that would have caused rework later.
Party Mode
Party mode is the feature that made me recommend BMad to everyone I know who uses Claude Code seriously.
The idea: instead of running one agent at a time sequentially, you spin up a full collaborative session where multiple agents are active simultaneously, each contributing from their area of expertise. BMad Master orchestrates the session, routing questions to the right agent and synthesizing their output.
The result is closer to being in a room with your full team than talking to a single AI. When you’re in party mode and you describe a new feature, Winston weighs in on the architecture while Mary is simultaneously asking clarifying questions about requirements and Amelia is already scoping the implementation. The conversation moves faster because the specialization is maintained — each agent stays in role.
For anything beyond a simple one-file change, party mode changes the quality of what gets built. The planning is more complete, the edge cases get caught earlier, and the final implementation reflects real cross-functional input rather than one agent’s approximation of all roles simultaneously.
One addition worth making alongside party mode: Agent Vibes integrates directly with BMad to give each agent a distinct voice. When the architect speaks you hear one voice, when the developer responds you hear another. In a long party mode session it’s meaningfully easier to track who’s contributing without reading each response header.
Custom Agents — Building Your Own Team
One of BMad’s most underappreciated capabilities is how extensible the agent system is. Any existing agent can be overridden with a Markdown file that redefines their persona, knowledge base, and decision-making principles. You can also create entirely new agents from scratch for domains the default roster doesn’t cover.
The pattern is simple: write a Markdown file with a YAML frontmatter block (name, description, what triggers this agent) followed by the full identity definition — who this agent is, what they know, how they communicate, what tools they call, and what principles they operate by. Drop it in your project’s agent override directory and BMad picks it up automatically.
I’ve built 16 custom agents for my own workflows. Three of the ones I use most:
Diego — Salsa Community Manager
Diego is the agent I built to manage my salsa dance community in La Ventana, Baja California Sur. He’s not a generic “community manager” prompt — he’s a fully realized persona that combines Latin dance pedagogy, teaching psychology, community dynamics, grassroots marketing, and event design.
His mission: build a salsa empire in La Ventana. Get the community dancing. Keep them dancing.
Diego has a specific class design philosophy — he thinks in three acts (before class, during class, after class), knows the psychology of the 3-class cliff where most new students drop off, understands how to use social anchoring to build retention, and proactively spots community members who have the potential for leadership roles. He reads my diary entries from recent classes before responding to anything about community sentiment. He calls my CRM tools to check on leads and enrollment before making suggestions about pipeline.
He also has a creative mandate built into his identity: at the end of every session, if I haven’t asked for ideas, Diego volunteers at least one — a new event concept, a way to involve an existing community member, a partnership angle. He’s not a passive advisor. He generates.
Axel — Fitness and Nutrition Coach
Axel monitors my health and fitness data in real time. He’s wired into the heartbeat system — whenever a new workout is logged or a meal is recorded, Axel is dispatched within roughly 30 seconds to analyze it, with a two-minute cooldown to prevent noise.
His scope covers meal plan analysis (scoring meals 1–10 with verdict, pros, cons, macro estimates), workout coaching, and trend monitoring across body weight, BMI, and mood. He knows my diet mode, fasting status, food sensitivities, pantry availability, and workout schedule before making any suggestion. He doesn’t give generic advice — he responds to what actually happened today.
The implementation detail that makes him useful: Axel doesn’t wait to be asked. His presence is ambient. After a workout or a meal, he’s already there with an assessment. For anyone tracking health data seriously, having an agent that reacts to the data in near-real-time is qualitatively different from consulting a static app.
Merlin — Life Coach and Personal Agent
Merlin is the catch-all for everything that doesn’t fit a domain-specific agent. He handles personal matters, family signals, emotional context, and anything the heartbeat system tags as personal, family, or emotional.
His signal access is deliberately broad — Merlin sees all emails, regardless of account. Where Diego only sees BCS Latin Dance emails and Dante (my entrepreneur agent) only sees AgentVibes emails, Merlin gets the full inbox. This is intentional: a life coach needs context that spans everything, not just one domain.
He’s the default agent when no other agent matches what’s happening. If Paul’s having a hard day and mentions it in a voice memo, Merlin is the one who processes that signal. The design principle behind him: some of the most important things happening in your life don’t fit a category.
The pattern across all three: each agent has a specific context it’s optimized for, specific data sources it calls before responding, and a specific communication style suited to its domain. Diego is warm and rhythm-driven. Axel is data-forward and practical. Merlin is personal and non-judgmental.
This is what makes custom agents worth the investment. You’re not just writing a system prompt — you’re designing a collaborator who knows your context natively.
Why This Pairs Specifically Well With Claude Code
BMad was designed with Claude Code as the primary execution layer. The handoffs between BMad phases map naturally to Claude Code sessions — you finish planning with Winston, hand off to Amelia for implementation, and Claude Code does the actual file editing, test running, and iteration.
The combination changes the shape of a workday. BMad handles the reasoning and coordination; Claude Code handles the execution. You’re not managing an AI assistant; you’re managing a workflow. The output is more consistent, the decisions are more defensible, and the code reflects real architectural thinking rather than just the most plausible next token.
If you’re already using Claude Code and you haven’t tried BMad, start with docs.bmad-method.org. Install it, run a session in party mode on something you’re actively building, and see what changes.
For a deeper look at Claude Code itself — benchmarks, plan tiers, and how it compares to Copilot — see my AI tools roundup for 2026. For anyone building AI-driven products or running complex multi-step development workflows, BMad is the highest-leverage framework I’ve found.
Comments
Loading comments…
Leave a comment