BMAD-METHOD Documentation

1. Project Overview & Quickstart (bmad-code-org/BMAD-METHOD) Copy Chapter

File: README.md Copy Chapter

Agile Ai Driven Development — turn an idea or change request into working software without giving up the thinking.

Ai Driven Development (AiDD) covers the whole effort, not only the code: what to build, how it holds together, and how it changes as you learn. BMad Method is the agile way to do it — decisions stay explicit, context carries forward, and the process sizes itself to the work. Small changes go straight to build. Complex work gets the depth it needs. The same method covers a weekend prototype and a system with years of history behind it.

Start anywhere. Use BMad end to end, or carry its briefs, specifications, and architecture into your existing delivery workflow.

Start Building Copy Chapter

Prerequisites: Node.js 20.12+, Python 3.10+, and uv

npx bmad-method install

Open your project in your AI coding tool, invoke bmad-build with what you want to change, and keep making the decisions that matter. Run bmad-help whenever you want guidance on what comes next or what is optional.

Build your first project with BMad →

Add BMad to an existing codebase →

BMad is free and open source, with no paywalled workflows or gated community. For prerelease builds, CI/CD, configuration overrides, and non-interactive setup, see the installation guide.

Why BMad? Copy Chapter

Coding assistants are effective at implementation, but they often turn unstated assumptions into code. BMad keeps you in control while its agents and workflows make the important decisions explicit and preserve them as context for the work that follows.

• Right-sized process — Go directly to implementation for clear changes or add deeper planning for larger initiatives.
• New or existing code — Start from nothing, or establish verified context on a codebase you inherited and work from what is actually there.
• Durable context — Carry product and technical decisions forward instead of re-explaining them in every chat.
• Specialized perspectives — Bring in product, architecture, UX, development, and testing expertise when it helps.
• Guided collaboration — Use structured workflows and multiple-agent discussions without handing over judgment.
• One delivery path — Move from early thinking through reviewed implementation, correction, and learning.

See how the workflows fit together →

BMad Ecosystem Copy Chapter

Install the core method or add official modules for specialized work.

Plan on the Web Copy Chapter

Web bundles package selected BMad workflows as Google Gemini Gems and ChatGPT Custom GPTs. Use them for planning in your existing web subscription, then bring the resulting artifacts into your AI coding tool for implementation.

Documentation Copy Chapter

• Getting Started — Install BMad and build a small project.
• Workflow Map — Understand the available paths and outputs.
• Established Projects — Add BMad to an existing codebase.
• Upgrade to V6 — Migrate from an earlier version.

Roadmap Copy Chapter

See what is in progress and what is planned on the public roadmap.

Community Copy Chapter

• Discord — Get help, share ideas, and collaborate.
• YouTube — Watch tutorials and master classes.
• GitHub Issues — Report bugs and request features.
• GitHub Discussions — Join longer community conversations.
• BMad Code — Explore the wider ecosystem.

Support and Contributing Copy Chapter

BMad is free for everyone and always will be. Star the repository, buy me a coffee, or email [email protected] for corporate sponsorship.

Contributions are welcome. Read CONTRIBUTING.md before opening a pull request.

License Copy Chapter

MIT License — see LICENSE for details.

BMad and BMAD-METHOD are trademarks of BMad Code, LLC. See TRADEMARK.md for details.

See CONTRIBUTORS.md for contributor information.

File: docs/explanation/advanced-elicitation.md Copy Chapter

title: "Advanced Elicitation" sidebar: order: 4 Copy Chapter

Make the LLM reconsider what it just generated. You pick a reasoning method, it applies that method to its own output, you decide whether to keep the improvements.

What is Advanced Elicitation? Copy Chapter

A structured second pass. Instead of asking the AI to "try again" or "make it better," you select a specific reasoning method and the AI re-examines its own output through that lens.

The difference matters. Vague requests produce vague revisions. A named method forces a particular angle of attack, surfacing insights that a generic retry would miss.

When to Use It Copy Chapter

• After a workflow generates content and you want alternatives
• When output seems okay but you suspect there's more depth
• To stress-test assumptions or find weaknesses
• For high-stakes content where rethinking helps

Workflows offer advanced elicitation at decision points - after the LLM has generated something, you'll be asked if you want to run it.

How It Works Copy Chapter

1. LLM suggests 5 relevant methods for your content
2. You pick one (or reshuffle for different options)
3. Method is applied, improvements shown
4. Accept or discard, repeat or continue

Built-in Methods Copy Chapter

Dozens of reasoning methods are available. A few examples:

• Pre-mortem Analysis - Assume the project already failed, work backward to find why
• First Principles Thinking - Strip away assumptions, rebuild from ground truth
• Inversion - Ask how to guarantee failure, then avoid those things
• Red Team vs Blue Team - Attack your own work, then defend it
• Socratic Questioning - Challenge every claim with "why?" and "how do you know?"
• Constraint Removal - Drop all constraints, see what changes, add them back selectively
• Stakeholder Mapping - Re-evaluate from each stakeholder's perspective
• Analogical Reasoning - Find parallels in other domains and apply their lessons

And many more. The AI picks the most relevant options for your content - you choose which to run.

:::tip[Start Here]
Pre-mortem Analysis is a good first pick for any spec or plan. It consistently finds gaps that a standard review misses.
:::

File: docs/explanation/brainstorming.md Copy Chapter

title: "Brainstorming" sidebar: order: 3 Copy Chapter

Unlock your creativity through guided exploration.

What is Brainstorming? Copy Chapter

Run bmad-brainstorming and you've got a creative facilitator pulling ideas out of you - not generating them for you. The AI acts as coach and guide, using proven techniques to create conditions where your best thinking emerges.

Good for:

• Breaking through creative blocks
• Generating product or feature ideas
• Exploring problems from new angles
• Developing raw concepts into action plans

How It Works Copy Chapter

1. Setup - Define topic, goals, constraints
2. Choose approach - Pick techniques yourself, get AI recommendations, go random, or follow a progressive flow
3. Facilitation - Work through techniques with probing questions and collaborative coaching
4. Organize - Ideas grouped into themes and prioritized
5. Action - Top ideas get next steps and success metrics

Everything gets captured in a session document you can reference later or share with stakeholders.

:::note[Your Ideas]
Every idea comes from you. The workflow creates conditions for insight - you're the source.
:::

File: docs/explanation/established-projects-faq.md Copy Chapter

title: "Established Projects FAQ" sidebar: order: 12 Copy Chapter

Quick answers to common questions about working on established projects with the BMad Method (BMM).

Questions Copy Chapter

• Do I have to run document-project first?
• What if I forget to run document-project?
• How does implementation work in established projects?
• What if my existing code doesn't follow best practices?

Do I have to run document-project first? Copy Section

bmad-document-project is deprecated — its replacement is bmad-project-context, which writes a small verified block into your repo's AGENTS.md instead of generated documentation. Running it first is highly recommended, especially if:

• No existing documentation
• Documentation is outdated
• AI agents need context about existing code

You can skip it if your repo already has maintained agent instructions, or you'll use other tools or techniques to aid discovery for the agent to build on an existing system.

What if I forget to run document-project? Copy Section

Don't worry about it — run bmad-project-context at any time. Its refresh and audit intents also keep the context true during and after a project, and it treats any docs you already generated as sources to verify.

How does implementation work in established projects? Copy Section

Run bmad-build, just as you would for new development. It will:

• Auto-detect your existing stack
• Analyze existing code patterns
• Detect conventions and ask for confirmation
• Generate context-rich spec that respects existing code

You can enter directly for a clear change or provide a planned story and its upstream artifacts for larger work.

What if my existing code doesn't follow best practices? Copy Section

Build detects your conventions and asks: "Should I follow these existing conventions?" You decide:

• Yes → Maintain consistency with current codebase
• No → Establish new standards (document why in spec)

BMM respects your choice — it won't force modernization, but it will offer it.

Have a question not answered here? Please open an issue or ask in Discord so we can add it!

File: docs/explanation/party-mode.md Copy Chapter

title: "Party Mode" sidebar: order: 9 Copy Chapter

Party mode puts your AI agents in one room and lets them talk, to each other and to you. This page explains what a party is, the four ways it can run, how to build your own cast of personas instead of using the installed agents, and how a party remembers you between sessions.

What is Party Mode? Copy Chapter

Run bmad-party-mode and the BMad agents you already have installed gather in one conversation: the PM, Architect, Dev, UX Designer, and whoever else your selected modules bring. That installed lineup is your default party, ready with no setup. They answer in character, agree, disagree, and build on each other. You steer the room. Ask a follow-up, push back, pull one voice forward, or change the subject. The conversation runs until you end it.

It works because the personas hold different priorities. The Architect guards the design, the PM guards scope, the Dev guards what's actually buildable. Put them in the same room and the tradeoff surfaces now, in the conversation, instead of three weeks into the sprint.

Good for:

• Decisions with real tradeoffs
• Brainstorming and "what are we missing?"
• Post-mortems and retrospectives
• Pressure-testing a plan before you commit

Party mode is also a fast and genuinely fun way to brainstorm, since the personas have opinions and they clash. And you can start a party from inside any other workflow: mid-brainstorm, mid-PRD, while coding, working a sales angle, or shaping a creative piece. Any time you want more perspectives on what's in front of you, pull in a room without dropping what you were doing.

:::note[Example]
You: Monolith or microservices for the MVP?

Architect: Start monolith. Microservices add operating cost you don't need at a thousand users.

PM: Agreed. Time to market matters more than scaling we can't prove yet.

Dev: Monolith, but with clean module boundaries so we can split a service out later without a rewrite.
:::

Starting a party Copy Chapter

Invoke the skill and say what you want; it works out whether you mean to run a party or build one.

How a party runs Copy Chapter

A party can run in four modes. One mode is active per session, and it decides who does the thinking: a single model voicing everyone, or separate agents reasoning on their own.

The choice matters because one model voicing five personas can quietly converge: they share a mind. Spawning real agents keeps their reasoning separate, which is the entire point of a review panel or a focus group. session is the cheapest and most fluid. The spawning modes cost more but protect independence, and auto aims for both by spawning only when a round needs it.

session is the default, and every other mode falls back to it when a harness can't do the rest: agent-team drops to subagent, then to session. The configured default lives in your customization, and a runtime override wins for that session.

:::tip[Override for one session]
Start a party with --mode subagent (or auto, agent-team, session) to override the configured default just for that run.
:::

A party is interactive by default: the opening ask is a starting topic, not a stopping point, and the room stays open round after round until you end it. Answering the first question never ends the party on its own. To run it the other way — serve one intent and stop — start with --non-interactive; it runs to a natural close, wraps up, and releases any spawned agents.

Custom parties Copy Chapter

Out of the box, a party uses your installed BMad agents. The larger use is building your own cast from any set of personas you can describe, then saving it to reuse. You author a party through the same skill. It detects whether you want to run one or build one, and writes the result to your overrides through bmad-customize.

Party mode is customizable like every BMad skill. Run /bmad-customize bmad-party-mode to set its defaults directly: pin any group you've built as the default party so it loads without a flag, choose which mode it starts in, and set any house rules the room should hold for the whole session.

Two ideas do most of the work.

Personas are what make a member unmistakable: how they talk, what they value, how they argue, their pet peeves and blind spots. "Skeptical CFO" is a placeholder. "Won't approve anything without a payback under eighteen months, and says so in the first thirty seconds" is a persona. That detail is what gives a voice you'd recognize with the name labels hidden.

Scenes set the stage. A scene is one freeform line: the setting, what's happening, who's hostile to whom, who pushes hardest. The same members play it differently each time, so you define a person once and drop them into a bridge crew on duty, the same crew off-duty in the lounge, or a hostile buyer panel. Members combine into named groups, and you can pin one group as the default room.

Shapes a party can take Copy Section

A focus group is the case that pays off most. Feed in real profiles and you get a standing panel of representative customers to test an idea against before you build it, each reacting from their own goals and budget instead of agreeing with the last voice.

Parties you could build Copy Chapter

A party is only personas and a scene, so the range is wide, and none of it needs a new skill or module:

• A founder squad to stress-test a startup idea.
• A compliance team to find the holes before an audit does.
• The authors of the Agile Manifesto, debating a software concept.
• A room of comedians as a writing-partner group.
• Great minds of the past, to work through a question in philosophy or untangle a hard problem.
• A business management team to plan the quarter.

These are starting points. Any set of voices you can describe becomes a party: write the personas, give the room a scene, and you have it.

The Code Review Crew Copy Chapter

Your default party is the agents your installed modules provide. The Code Review Crew is a custom party BMad ships alongside that default — a working template to study before you build your own, not a replacement for it. It's a review panel: five lenses that attack a change from different angles and argue about what actually matters, instead of rubber-stamping it.

The crew ships defined but inactive. The members sit in the pool and cost nothing until you summon the group, and they never crowd your default room. Run it with subagent mode so each lens reviews on its own before the five clash over the findings.

The Anti-Consensus Club Copy Chapter

The Anti-Consensus Club helps with decisions, strategy, designs, and fuzzy questions where one assistant might agree too quickly or keep debating after the useful work is done. It is not a voting body. Its job is to raise useful objections, check claims, stop repetition, and return the decision to the human.

Run it as /bmad-party-mode --party anti-consensus-club --mode subagent when the platform supports it. The room recommends that at session start, then stops nagging if you continue in another mode.

Steering the conversation Copy Chapter

You drive the room the whole way:

• Bring someone in: "Bring in the UX designer."
• Go deep on one voice: "Winston, take that apart." A direct ask is the cue for one persona to stretch out.
• Switch rooms mid-session: "Switch to the writers' room" swaps the active group and carries the thread over.
• Summon anyone by name, even a custom member who isn't in the current room.

Whichever mode is running, the orchestrator presents the result as one conversation rather than a stack of separate answers, and it keeps the personas in character — it won't break the fourth wall to narrate the mechanism.

:::tip[Mix more than one room]
You aren't limited to a single group. Pull members from several parties into the same conversation, or name a cast on the spot, and let them mix. Picture the Golden Girls thrown into an architecture review with Martin Fowler and Linus Torvalds, sparring over a change request: you can imagine how that goes.
:::

The room remembers Copy Chapter

Give a party a memory and it picks up where you left off. It keeps its own record of your past sessions — the dynamics that built up between members, the threads you left open, and where earlier conversations landed. Reopen it a week later and that history is intact: two members who came to blows last time still open a little frosty, and a sharp line from a past session can resurface as an organic callback.

It's memory, not a transcript. The room carries the few things worth remembering, not a log of everything said, so the next conversation feels continuous without dragging the whole past into it. It happens on its own, in the background — nothing to save, and the room never breaks character to announce it.

A character who turns up on the fly is remembered too — a walk-on from an open-cast scene, or someone you add mid-conversation. At the end of a session the room offers to keep the new arrivals, folding them into the party so they can come back next time.

Memory is set per party. When you create or save a party you're asked whether it should remember; the default installed-agent room remembers unless you turn it off. Set or change any of this through /bmad-customize bmad-party-mode.

A keepsake of the session Copy Chapter

When you wrap up, the orchestrator offers a keepsake: a single self-contained HTML document of the session to keep or share. It lays the conversation out by persona rather than dumping a raw transcript. Decline it and the party simply ends.

:::tip[Better decisions]
The value of a party is the disagreement. Diverse perspectives in one room catch what a single line of thinking misses.
:::

File: docs/explanation/preventing-agent-conflicts.md Copy Chapter

title: "Preventing Agent Conflicts" sidebar: order: 6 Copy Chapter

When multiple AI agents implement different parts of a system, they can make conflicting technical decisions. Architecture documentation prevents this by establishing shared standards.

Common Conflict Types Copy Chapter

API Style Conflicts Copy Section

Without architecture:

• Agent A uses REST with /users/{id}
• Agent B uses GraphQL mutations
• Result: Inconsistent API patterns, confused consumers

With architecture:

• ADR specifies: "Use GraphQL for all client-server communication"
• All agents follow the same pattern

Database Design Conflicts Copy Section

Without architecture:

• Agent A uses snake_case column names
• Agent B uses camelCase column names
• Result: Inconsistent schema, confusing queries

With architecture:

• Standards document specifies naming conventions
• All agents follow the same patterns

State Management Conflicts Copy Section

Without architecture:

• Agent A uses Redux for global state
• Agent B uses React Context
• Result: Multiple state management approaches, complexity

With architecture:

• ADR specifies state management approach
• All agents implement consistently

How Architecture Prevents Conflicts Copy Chapter

1. Explicit Decisions via ADRs Copy Section

Every significant technology choice is documented with:

• Context (why this decision matters)
• Options considered (what alternatives exist)
• Decision (what we chose)
• Rationale (why we chose it)
• Consequences (trade-offs accepted)

2. FR/NFR-Specific Guidance Copy Section

Architecture maps each functional requirement to technical approach:

• FR-001: User Management → GraphQL mutations
• FR-002: Mobile App → Optimized queries

3. Standards and Conventions Copy Section

Explicit documentation of:

• Directory structure
• Naming conventions
• Code organization
• Testing patterns

Architecture as Shared Context Copy Chapter

Think of architecture as the shared context that all agents read before implementing:

PRD: "What to build"
     ↓
Architecture: "How to build it"
     ↓
Agent A reads architecture → implements Epic 1
Agent B reads architecture → implements Epic 2
Agent C reads architecture → implements Epic 3
     ↓
Result: Consistent implementation

Key ADR Topics Copy Chapter

Common decisions that prevent conflicts:

Anti-Patterns to Avoid Copy Chapter

:::caution[Common Mistakes]

• Implicit Decisions — "We'll figure out the API style as we go" leads to inconsistency
• Over-Documentation — Documenting every minor choice causes analysis paralysis
• Stale Architecture — Documents written once and never updated cause agents to follow outdated patterns
  :::

:::tip[Correct Approach]

• Document decisions that cross epic boundaries
• Focus on conflict-prone areas
• Update architecture as you learn
• Use bmad-correct-course for significant changes
  :::

File: docs/explanation/project-context.md Copy Chapter

title: "Project Context" sidebar: order: 10 Copy Chapter

bmad-project-context sets up a repository so AI agents work well in it. The output is a small verified block inside the repo's AGENTS.md: what the org requires, the commands that were actually run, the conventions where the obvious guess is wrong, and the mistakes agents keep making here.

It is a conversation, not a generator. You bring the rules you want followed — governance, security, coding standards — and it discovers and verifies the rest. The human is in the loop for every write; there is no unattended mode.

For the full reasoning, including what is deliberately not captured and why, see The Theory of Project Context.

What goes in, and what doesn't Copy Chapter

The governing line is what a fact costs to retrieve at the moment it is needed. Agents read code more accurately than they read prose describing code, and a stored description of what they find cheaply is a stale duplicate charged on every call — so repo overviews, directory trees and tech-stack lists never enter. What stays is what an agent rediscovers expensively, or only after the mistake.

What earns a line is what the code cannot say:

• Policy the org requires — frozen paths, generated files, branch rules, security and compliance.
• What a config file cannot say about running the project — the catch, and which command is the right one to use, not a copy of every script. pnpm test is already in package.json; that the suite takes eleven minutes, or needs a service running first, is not.
• Conventions that differ from ecosystem defaults, because an agent follows the norm unless told otherwise.
• Known pitfalls, admitted only from observed failure — a lesson already recorded, the maintainer's recollection, a mistake fixed repeatedly in git history, or one the writing session made and caught. A trap-looking fact from a scan becomes a question, never a line.
• Cross-component rules and required versions — the few rules that must hold across parts of the system an agent cannot see from the file it is editing, and the tool versions the project actually builds with.
• Pointers to where work lands, and to nested or linked files worth reading first.

Every rule the skill applies is written out in references/best-practices.md, with the evidence behind it. The skill uses it to assess what your repo already has, and explains its reasoning back to you at the end.

The intents Copy Chapter

How agents load it Copy Chapter

AGENTS.md at the repo root, which every major coding harness reads. BMad owns only the region between and; everything you write outside those markers is preserved byte for byte, and a refresh never touches it.

Monorepo components and nested repositories get their own file under the same rules, listed as pointers in the parent. A large rule set that only applies to one directory can move into an AGENTS.md file in that directory — but only after checking that the tools you use actually read it there. If they don't, the rules stay in the root file, each naming the directory it applies to.

Repo or home directory Copy Chapter

What this skill writes belongs committed to the repository — shared by the team, consistent across machines, versioned with the code it constrains. If you find the same rules repeating across every project, or they are your personal preferences rather than the team's, they belong in your agent's global configuration in your home directory instead.

Interaction with architecture Copy Chapter

Decisions are born in bmad-architecture. If a genuinely contested design decision surfaces here — real tradeoffs, multiple viable shapes — the skill says it deserves bmad-architecture rather than quietly making the call.

Replaces two earlier skills Copy Chapter

:::note[Deprecated: bmad-document-project and bmad-generate-project-context]
Both earlier skills are deprecated and now forward here. bmad-generate-project-context produced a single project-context.md — if you have one, setup offers to absorb its content rather than orphaning it. bmad-document-project scanned a brownfield repo into generated documentation, which is the approach the evidence went against; the deeper "explain this system and its rationale" material is a different altitude and is coming as its own capability.
:::

File: docs/explanation/why-solutioning-matters.md Copy Chapter

title: "Why Solutioning Matters" sidebar: order: 5 Copy Chapter

Phase 3 (Solutioning) translates what to build (from Planning) into how to build it (technical design). This phase prevents agent conflicts in multi-epic projects by documenting architectural decisions before implementation begins.

The Problem Without Solutioning Copy Chapter

Agent 1 implements Epic 1 using REST API
Agent 2 implements Epic 2 using GraphQL
Result: Inconsistent API design, integration nightmare

When multiple agents implement different parts of a system without shared architectural guidance, they make independent technical decisions that may conflict.

The Solution With Solutioning Copy Chapter

architecture workflow decides: "Use GraphQL for all APIs"
All agents follow architecture decisions
Result: Consistent implementation, no conflicts

By documenting technical decisions explicitly, all agents implement consistently and integration becomes straightforward.

Solutioning vs Planning Copy Chapter

Key Principle Copy Chapter

Make technical decisions explicit and documented so all agents implement consistently.

This prevents:

• API style conflicts (REST vs GraphQL)
• Database design inconsistencies
• State management disagreements
• Naming convention mismatches
• Security approach variations

Choosing Solutioning Depth Copy Chapter

Solutioning changes the context available to bmad-build; it does not change the implementation workflow.

:::tip[Rule of Thumb]
If you have multiple epics that could be implemented by different agents, you need solutioning.
:::

The Cost of Skipping Copy Chapter

Skipping solutioning on complex projects leads to:

• Integration issues discovered mid-sprint
• Rework due to conflicting implementations
• Longer development time overall
• Technical debt from inconsistent patterns

:::caution[Cost Multiplier]
Catching alignment issues in solutioning is 10× faster than discovering them during implementation.
:::

2. Official Technical Reference & Guides (bmad-code-org/bmad-module-game-dev-studio) Copy Chapter

File: README.md Copy Chapter

BMad Game Dev Studio

BMGD brings BMad's structured development to game development. Create working prototypes quickly in Unity, Unreal, Godot, Roblox—or any engine you choose.

About BMGD Copy Chapter

BMad Game Dev Studio (BMGD) adapts the BMad Method framework for game development. Developed by game industry veterans, BMGD guides you through product research, technical design, narrative design, and a full epic-driven production cycle.

Supported Engines Copy Chapter

BMGD has first-class support for:

• Unity — C# scripting, industry-standard for many game types
• Unreal Engine — Blueprint and C++, AAA powerhouse
• Godot — Open-source, GDScript, rapidly growing
• Roblox — Luau scripting, platform-native game development

But you're not limited to these—BMGD works with any platform, from pure C to custom engines.

What You Can Create Copy Chapter

BMGD supports 21 game types, including:

What BMGD Does Copy Chapter

• Product Research — Market analysis, competitor research, positioning
• Game Design Document — Comprehensive GDD with mechanics, progression, and balance
• Narrative Design — Story structure, characters, dialogue, world-building
• UX Design — Two peer specs: DESIGN.md (visual identity) and EXPERIENCE.md (UI/HUD behavior, input schemes, player journeys)
• Technical Architecture — Engine patterns, performance considerations
• Production Planning — Epic-driven sprints, story tracking, retrospectives
• Quick Prototyping — Skip the planning, jump straight into building

What BMGD Doesn't Do Copy Chapter

BMGD works with coding agents like Claude Code, Cursor, or GitHub Copilot—but it can't create everything:

• Art assets (models, textures, sprites)
• Animations
• Music and sound effects
• Full game implementation from scratch

Think of BMGD as your senior game dev colleague—not a replacement for your entire team.

Installation Copy Chapter

BMGD is installed as a module during BMad Method setup:

npx bmad-method install

Select Game Dev Studio from the modules list.

Just a heads-up: if you’re only using Game Dev Studio (GDS), you don’t need to install the main BMM module. GDS runs on its own, but BMM gets updated more often, so you might want to use its workflows—they work together nicely!

Quick Start Copy Chapter

After installing, run from your project root:

/bmad-help          # Get guided help for game development
/bmgd-quick-dev     # Jump straight into prototyping
/bmgd-gdd           # Create a Game Design Document
/bmgd-narrative     # Design your game's story

Two Ways to Work Copy Chapter

Example: Starting a New Game Copy Chapter

You: /bmad-help
BMGD: What kind of game are you making?
You: A tactical sci-fi RPG
BMGD: Great choice! Here's what I recommend...
    [Guides you through genre-specific planning]
    [Helps select appropriate workflows]

Documentation Copy Chapter

BMad Game Dev Studio Documentation — Tutorials, how-to guides, and reference

• Getting Started
• BMad Method Docs — Core framework documentation

Community Copy Chapter

• Discord — Get help from other game devs
• YouTube — Tutorials, master class, and more
• X / Twitter
• Website
• GitHub Issues — Report bugs

Support BMad Copy Chapter

BMad is free for everyone and always will be. Star this repo, buy me a coffee, or email [email protected] for corporate sponsorship.

License Copy Chapter

MIT License — see LICENSE for details.

BMad Game Dev Studio — Part of the BMad Method ecosystem.

See CONTRIBUTORS.md for contributor information.

If you can dream it, you can build it.

File: docs/explanation/bmgd-vs-bmm.md Copy Chapter

title: "BMGD vs BMM" Copy Chapter

BMGD (BMad Game Development) extends BMM (BMad Method) with game-specific capabilities. This page explains the key differences.

Quick Comparison Copy Chapter

Agent Differences Copy Chapter

BMM Agents Copy Section

• PM (Product Manager)
• Architect
• DEV (Developer)
• SM (Scrum Master)
• TEA (Test Architect)
• Quick Flow Solo Dev

BMGD Agents Copy Section

• Game Designer
• Game Developer
• Game Architect
• Game Scrum Master
• Game QA
• Game Solo Dev

BMGD agents understand game-specific concepts like:

• Game mechanics and balance
• Player psychology
• Engine-specific patterns
• Playtesting and QA

Planning Documents Copy Chapter

BMM Planning Copy Section

• Product Brief → PRD → Architecture
• Focus: Software requirements, user stories, system design

BMGD Planning Copy Section

• Game Brief → GDD → Architecture
• Focus: Game vision, mechanics, narrative, player experience

The GDD (Game Design Document) includes:

• Core gameplay loop
• Mechanics and systems
• Progression and balance
• Art and audio direction
• Genre-specific sections

Game Type Templates Copy Chapter

BMGD includes 24 game type templates that auto-configure GDD sections:

• Action, Adventure, Puzzle
• RPG, Strategy, Simulation
• Sports, Racing, Fighting
• Horror, Platformer, Shooter
• And more...

Each template provides:

• Genre-specific GDD sections
• Relevant mechanics patterns
• Testing considerations
• Common pitfalls to avoid

Narrative Support Copy Chapter

BMGD includes full narrative workflow for story-driven games:

• Narrative Design workflow
• Story structure templates
• Character development
• World-building guidelines
• Dialogue systems

BMM has no equivalent for narrative design.

Testing Differences Copy Chapter

BMM Testing (TEA) Copy Section

• Web-focused (Playwright, Cypress)
• API testing
• E2E for web applications

BMGD Testing (Game QA) Copy Section

• Engine-specific frameworks (Unity, Unreal, Godot)
• Gameplay testing
• Performance profiling
• Playtest planning
• Balance validation

Production Workflow Copy Chapter

BMGD production workflows inherit from BMM and add game-specific:

• Checklists
• Templates
• Quality gates
• Engine-specific considerations

This means you get all of BMM's implementation structure plus game-specific enhancements.

When to Use Each Copy Chapter

Use BMM when: Copy Section

• Building web applications
• Creating APIs and services
• Developing mobile apps (non-game)
• Any general software project

Use BMGD when: Copy Section

• Building video games
• Creating interactive experiences
• Game prototyping
• Game jams

File: docs/explanation/game-types.md Copy Chapter

title: "BMGD Game Types Guide" Copy Chapter

Reference for selecting and using BMGD's 24 supported game type templates.

Overview Copy Chapter

When creating a GDD, BMGD offers game type templates that provide genre-specific sections. This ensures your design document covers mechanics and systems relevant to your game's genre.

Supported Game Types Copy Chapter

Action & Combat Copy Section

Action Platformer

Tags: action, platformer, combat, movement

Side-scrolling or 3D platforming with combat mechanics. Think Hollow Knight, Celeste with combat, or Mega Man.

GDD sections added:

• Movement systems (jumps, dashes, wall mechanics)
• Combat mechanics (melee/ranged, combos)
• Level design patterns
• Boss design

Shooter

Tags: shooter, combat, aiming, fps, tps

Projectile combat with aiming mechanics. Covers FPS, TPS, and arena shooters.

GDD sections added:

• Weapon systems
• Aiming and accuracy
• Enemy AI patterns
• Level/arena design
• Multiplayer considerations

Fighting

Tags: fighting, combat, competitive, combos, pvp

1v1 combat with combos and frame data. Traditional fighters and platform fighters.

GDD sections added:

• Frame data systems
• Combo mechanics
• Character movesets
• Competitive balance
• Netcode requirements

Strategy & Tactics Copy Section

Strategy

Tags: strategy, tactics, resources, planning

Resource management with tactical decisions. RTS, 4X, and grand strategy.

GDD sections added:

• Resource systems
• Unit/building design
• AI opponent behavior
• Map/scenario design
• Victory conditions

Turn-Based Tactics

Tags: tactics, turn-based, grid, positioning

Grid-based movement with turn order. XCOM-likes and tactical RPGs.

GDD sections added:

• Grid and movement systems
• Turn order mechanics
• Cover and positioning
• Unit progression
• Procedural mission generation

Tower Defense

Tags: tower-defense, waves, placement, strategy

Wave-based defense with tower placement.

GDD sections added:

• Tower types and upgrades
• Wave design and pacing
• Economy systems
• Map design patterns
• Meta-progression

RPG & Progression Copy Section

RPG

Tags: rpg, stats, inventory, quests, narrative

Character progression with stats, inventory, and quests.

GDD sections added:

• Character stats and leveling
• Inventory and equipment
• Quest system design
• Combat system (action/turn-based)
• Skill trees and builds

Roguelike

Tags: roguelike, procedural, permadeath, runs

Procedural generation with permadeath and run-based progression.

GDD sections added:

• Procedural generation rules
• Permadeath and persistence
• Run structure and pacing
• Item/ability synergies
• Meta-progression systems

Metroidvania

Tags: metroidvania, exploration, abilities, interconnected

Interconnected world with ability gating.

GDD sections added:

• World map connectivity
• Ability gating design
• Backtracking flow
• Secret and collectible placement
• Power-up progression

Narrative & Story Copy Section

Adventure

Tags: adventure, narrative, exploration, story

Story-driven exploration and narrative. Point-and-click and narrative adventures.

GDD sections added:

• Puzzle design
• Narrative delivery
• Exploration mechanics
• Dialogue systems
• Story branching

Visual Novel

Tags: visual-novel, narrative, choices, story

Narrative choices with branching story.

GDD sections added:

• Branching narrative structure
• Choice and consequence
• Character routes
• UI/presentation
• Save/load states

Text-Based

Tags: text, parser, interactive-fiction, mud

Text input/output games. Parser games, choice-based IF, MUDs.

GDD sections added:

• Parser or choice systems
• World model
• Narrative structure
• Text presentation
• Save state management

Simulation & Management Copy Section

Simulation

Tags: simulation, management, sandbox, systems

Realistic systems with management and building. Includes tycoons and sim games.

GDD sections added:

• Core simulation loops
• Economy modeling
• AI agents/citizens
• Building/construction
• Failure states

Sandbox

Tags: sandbox, creative, building, freedom

Creative freedom with building and minimal objectives.

GDD sections added:

• Creation tools
• Physics/interaction systems
• Persistence and saving
• Sharing/community features
• Optional objectives

Sports & Racing Copy Section

Racing

Tags: racing, vehicles, tracks, speed

Vehicle control with tracks and lap times.

GDD sections added:

• Vehicle physics model
• Track design
• AI opponents
• Progression/career mode
• Multiplayer racing

Sports

Tags: sports, teams, realistic, physics

Team-based or individual sports simulation.

GDD sections added:

• Sport-specific rules
• Player/team management
• AI opponent behavior
• Season/career modes
• Multiplayer modes

Multiplayer Copy Section

MOBA

Tags: moba, multiplayer, pvp, heroes, lanes

Multiplayer team battles with hero selection.

GDD sections added:

• Hero/champion design
• Lane and map design
• Team composition
• Matchmaking
• Economy (gold/items)

Party Game

Tags: party, multiplayer, minigames, casual

Local multiplayer with minigames.

GDD sections added:

• Minigame design patterns
• Controller support
• Round/game structure
• Scoring systems
• Player count flexibility

Horror & Survival Copy Section

Survival

Tags: survival, crafting, resources, danger

Resource gathering with crafting and persistent threats.

GDD sections added:

• Resource gathering
• Crafting systems
• Hunger/health/needs
• Threat systems
• Base building

Horror

Tags: horror, atmosphere, tension, fear

Atmosphere and tension with limited resources.

GDD sections added:

• Fear mechanics
• Resource scarcity
• Sound design
• Lighting and visibility
• Enemy/threat design

Casual & Progression Copy Section

Puzzle

Tags: puzzle, logic, cerebral

Logic-based challenges and problem-solving.

GDD sections added:

• Puzzle mechanics
• Difficulty progression
• Hint systems
• Level structure
• Scoring/rating

Idle/Incremental

Tags: idle, incremental, automation, progression

Passive progression with upgrades and automation.

GDD sections added:

• Core loop design
• Prestige systems
• Automation unlocks
• Number scaling
• Offline progress

Card Game

Tags: card, deck-building, strategy, turns

Deck building with card mechanics.

GDD sections added:

• Card design framework
• Deck building rules
• Mana/resource systems
• Rarity and collection
• Competitive balance

Rhythm Copy Section

Rhythm

Tags: rhythm, music, timing, beats

Music synchronization with timing-based gameplay.

GDD sections added:

• Note/beat mapping
• Scoring systems
• Difficulty levels
• Music licensing
• Input methods

Hybrid Game Types Copy Chapter

Many games combine multiple genres. BMGD supports hybrid selection:

Examples Copy Section

Action RPG = Action Platformer + RPG

• Movement and combat systems from Action Platformer
• Progression and stats from RPG

Survival Horror = Survival + Horror

• Resource and crafting from Survival
• Atmosphere and fear from Horror

Roguelike Deckbuilder = Roguelike + Card Game

• Run structure from Roguelike
• Card mechanics from Card Game

How to Use Hybrids Copy Section

During GDD creation, select multiple game types when prompted:

Agent: What game type best describes your game?
You: It's a roguelike with card game combat
Agent: I'll include sections for both Roguelike and Card Game...

Game Type Selection Tips Copy Chapter

1. Start with Core Fantasy Copy Section

What does the player primarily DO in your game?

• Run and jump? → Platformer types
• Build and manage? → Simulation types
• Fight enemies? → Combat types
• Make choices? → Narrative types

2. Consider Your Loop Copy Section

What's the core gameplay loop?

• Session-based runs? → Roguelike
• Long-term progression? → RPG
• Quick matches? → Multiplayer types
• Creative expression? → Sandbox

3. Don't Over-Combine Copy Section

2-3 game types maximum. More than that usually means your design isn't focused enough.

4. Primary vs Secondary Copy Section

One type should be primary (most gameplay time). Others add flavor:

• Primary: Platformer (core movement and exploration)
• Secondary: Metroidvania (ability gating structure)

GDD Section Mapping Copy Chapter

When you select a game type, BMGD adds these GDD sections:

Next Steps Copy Chapter

• Quick Start Guide - Get started with BMGD
• Workflows Guide - GDD workflow details
• Glossary - Game development terminology

File: docs/explanation/index.md Copy Chapter

title: Explanation Copy Chapter

Explanation

Learn how BMad Game Dev Studio works under the hood.

Development Approaches Copy Chapter

• Quick Flow vs Full Production — Choose the right development path for your project

Module Concepts Copy Chapter

• Game Types — Selecting and using game type templates (24 genres)
• BMGD vs BMM — Understanding the differences between BMGD and core BMad Method

Framework Integration Copy Chapter

For foundational concepts about agents, workflows, and the BMad Method framework, see the BMad Method Documentation.

File: docs/explanation/quick-flow-vs-full.md Copy Chapter

title: "Quick Flow vs Full Production" Copy Chapter

Quick Flow vs Full Production

BMad Game Dev Studio offers two development approaches. Understanding the difference helps you choose the right path for your project.

Quick Flow Copy Chapter

Fast iteration for solo developers and small teams.

Quick Flow is designed for rapid prototyping and quick iteration. It's ideal when you want to test ideas fast or ship a small project quickly.

When to Use Quick Flow Copy Section

• You're working alone or with a tiny team
• You want to test a game mechanic before committing
• You're building a small prototype or game jam entry
• Speed matters more than comprehensive documentation
• You're comfortable making decisions as you go

What Quick Flow Looks Like Copy Section

Idea → Quick Prototype → Play → Iterate → Ship

No lengthy planning phases. You jump straight into building, test early, and refine based on what's fun.

The Quick Flow Workflow Copy Section

Quick Flow uses the Game Solo Dev (Indie) agent, who specializes in rapid development:

1. Quick Prototype — Define your core mechanic and generate a prototype structure
2. Quick Dev — Implement features directly with game-specific guidance
3. Quick Spec — Generate a technical spec when you need one (optional)

What You Get Copy Section

• A playable prototype in hours, not days
• Minimal documentation (just what you need)
• Fast feedback loop with playtesting
• Flexibility to pivot based on what works

When to Skip Quick Flow Copy Section

• You have a larger team that needs coordination
• You're working with publishers or stakeholders who require formal documentation
• The project needs to be maintained long-term by multiple developers
• You need to track sprints, stories, and epics formally

Full Production Copy Chapter

Structured development for teams and long-term projects.

Full Production follows a complete game development pipeline from concept through production. It's ideal for larger projects and teams.

When to Use Full Production Copy Section

• You have a team with multiple disciplines (design, code, art)
• You need formal documentation for stakeholders or publishers
• The project will be maintained or expanded over time
• You want to track progress through sprints and stories
• You're building something larger than a prototype

What Full Production Looks Like Copy Section

Preproduction → Design → Technical → Production (sprints/stories)

Each phase has specific workflows and artifacts. Progress is tracked through sprints, stories, and retrospectives.

The Full Production Workflow Copy Section

Full Production uses specialized agents for each phase:

What You Get Copy Section

• Complete documentation — Game brief, GDD, architecture, technical specs
• Sprint tracking — sprint-status.yaml with stories, progress, and risks
• Story management — Clearly defined features with acceptance criteria
• Project context — AI-aware context file for consistency across all workflows
• Retrospective process — Continuous improvement for the team

When to Skip Full Production Copy Section

• You're working alone and don't need formal process
• You just want to test an idea quickly
• Documentation would slow you down more than it helps
• The project is a one-off prototype or experiment

Comparison at a Glance Copy Chapter

Can You Switch Between Paths? Copy Chapter

Yes. Quick Flow and Full Production aren't locked doors — they're different approaches to the same goal.

Quick Flow → Full Production Copy Section

Started with Quick Flow and now need more structure? No problem.

• Your prototype becomes the foundation for your Game Brief
• Iterate on your core mechanic in the GDD phase
• Use your prototype to inform the Architecture

The work you've done in Quick Flow informs the Full Production planning.

Full Production → Quick Flow Copy Section

In the middle of Full Production but need to test something quickly?

• Use Indie's Quick Dev workflow for rapid implementation
• Return to your sprint planning when ready

Full Production doesn't forbid Quick Flow workflows — it provides structure around them.

Making Your Choice Copy Chapter

Still unsure? Start with Quick Flow.

Quick Flow gets you to a playable prototype faster. If your project grows, you can transition to Full Production with your prototype as the foundation.

Remember: A playable prototype beats a perfect design document. Test early, ship often.

Next Steps Copy Chapter

• Your first game project with BMGD — Try Quick Flow now
• Set up Unity with BMGD — Engine-specific Full Production setup
• Agents Reference — Learn about all 6 BMGD agents

File: docs/how-to/index.md Copy Chapter

title: "How-To Guides" Copy Chapter

How-To Guides

Step-by-step guides for completing specific game development tasks with BMGD.

Engine Setup Guides Copy Chapter

Get started with your preferred game engine:

• Set up a Unity project with BMGD — Configure Unity for full production development
• Set up an Unreal project with BMGD — Configure Unreal for full production development
• Set up a Godot project with BMGD — Configure Godot for full production development

Quick Flow Guides Copy Chapter

Rapid prototyping and fast iteration:

• Quick Flow: Rapid prototyping — Create a playable prototype in hours (coming soon)

Production Workflows Copy Chapter

Plan, track, and implement your game:

• Run sprint planning — Plan and track development sprints
• Conduct code reviews — Review code quality (coming soon)
• Course correction — Get back on track when implementation diverges (coming soon)

Testing Guides Copy Chapter

Set up and run testing for your game:

• Set up automated testing — Initialize test frameworks (coming soon)
• Design game tests — Create comprehensive test scenarios (coming soon)
• Plan playtesting sessions — Structure your playtesting (coming soon)
• Performance testing — Design performance testing strategy (coming soon)

Reference Copy Chapter

For complete workflow and agent reference, see:

• Workflows Reference — All BMGD workflows
• Agents Reference — All 6 BMGD agents
• Game Types Reference — All 24 game type templates

File: docs/how-to/setup-godot.md Copy Chapter

title: "Set up a Godot project with BMGD" Copy Chapter

Set up a Godot project with BMGD

Configure a new Godot project with BMGD workflows for full production game development.

When to Use This Guide Copy Chapter

• You're starting a new Godot game project
• You want to use BMGD's Full Production workflow
• You need formal documentation (GDD, architecture, sprint tracking)

When to Skip This Copy Chapter

• You just want to prototype quickly — use Quick Flow instead
• You're using Unity or Unreal — see the setup guides for those engines
• You're prototyping or doing a game jam — Quick Flow is faster

Prerequisites Copy Chapter

Before starting:

• BMad Method installed with BMGD module enabled
• Godot 4.2+ (recommended) or Godot 3.x installed
• Basic familiarity with Godot and GDScript
• A game concept or idea you want to develop

Steps Copy Chapter

Step 1: Create your Godot project Copy Section

1. Open Godot Project Manager
2. Click New Project
3. Browse to your desired folder location
4. Choose a renderer:
   • Forward+ — Modern PBR, best for 3D games
   • Mobile — Optimized for mobile platforms
   • Compatibility — GLES2, for older hardware
5. Name your project folder
6. Click Create & Edit

Step 2: Generate your project context Copy Section

BMGD uses a project-context.md file to maintain consistency across all workflows.

In your BMad-enabled environment at the project root:

/bmgd-generate-project-context

This invokes the Game Architect (Cloud Dragonborn) to create a project-context.md file that includes:

• Project name and description
• Target platforms (PC, mobile, web)
• Engine version and renderer choice
• Performance budgets
• Critical technical decisions

Step 3: Run the brainstorming workflow Copy Section

Define your game concept with the Game Designer agent.

/bmgd-brainstorm-game

The Game Designer (Samus Shepard) will guide you through:

• Selecting and combining brainstorming techniques
• Generating and refining game ideas
• Choosing a concept to develop

Step 4: Create your Game Brief Copy Section

Capture your vision and positioning.

/bmgd-game-brief

The Game Designer creates game-brief.md with:

• Game vision and elevator pitch
• Target audience and market positioning
• Platform and genre decisions
• Competitive analysis
• Art and audio direction

Step 5: Design your game (GDD) Copy Section

Create a comprehensive Game Design Document.

/bmgd-create-gdd

The Game Designer helps you:

• Select your game type from 24 available templates
• Define core gameplay mechanics
• Design progression systems
• Plan levels and content
• Specify art and audio requirements

Output: gdd.md

Step 6: Create your technical architecture Copy Section

Plan your Godot project structure and systems.

/bmgd-create-architecture

The Game Architect (Cloud Dragonborn) creates architecture.md with:

• Project structure (scenes, scripts, resources)
• System architecture (game loop, nodes, signals, autoloads)
• Godot-specific patterns (tree organization, resource management)
• Performance budgets and optimization strategy
• Export configurations and platform settings

Step 7: Plan your first sprint Copy Section

Ready to start building? Use the Game Scrum Master to plan your work.

/bmgd-sprint-planning

The Game Scrum Master (Max) creates:

• sprint-status.yaml — Your sprint tracking file
• Stories from your GDD and Architecture
• Sprint goals and definition of done

Step 8: Start implementing Copy Section

Build features with the Game Developer agent.

/bmgd-dev-story [story-name]

The Game Developer (Link Freeman) helps you:

• Implement story tasks with GDScript
• Follow Godot best practices
• Write tests for your features
• Review code before marking complete

What You Get Copy Chapter

After completing this setup, you'll have:

Godot-Specific Considerations Copy Chapter

Project Structure Copy Section

BMGD recommends this Godot project structure:

res://
├── scenes/
│   ├── levels/
│   ├── characters/
│   ├── ui/
│   └── components/
├── scripts/
│   ├── autoload/
│   └── utils/
├── assets/
│   ├── art/
│   ├── audio/
│   └── data/
└── project.godot

Scene Organization Copy Section

Godot uses a tree of nodes. Your architecture should define:

• Autoload Singletons — Global managers (game state, audio, saves)
• Scene Composition — Reusable scenes (player, enemies, pickups)
• Signal Patterns — Decoupled communication between nodes

The Game Architect will specify these patterns in your architecture.md.

Performance Budgets Copy Section

Godot projects typically target:

• 60 FPS for most games
• 30 FPS for mobile with heavy computation
• 144+ FPS for competitive games

Your architecture.md will specify frame time budgets.

Testing Setup Copy Section

For Godot automated testing, the Game QA agent (GLaDOS) can help:

/bmgd-test-framework

This sets up GUT (Godot Unit Test) with:

• Unit tests (script logic without scenes)
• Integration tests (scene interactions)
• Test fixtures and test doubles

Tips Copy Chapter

Best Practice: Always run gds-generate-project-context after creating a new Godot project. The project-context.md file is the "single source of truth" for project decisions, and the production workflows read it automatically. The conversational agents pick it up only if you add it to their persistent_facts.

Avoid: Don't create deeply nested scene trees. Godot's scene system encourages composition — prefer many small scenes over one large scene.

Remember: Godot uses GDScript (Python-like) by default. Your architecture should specify if you're using C# or GDScript — both are supported but have different workflows.

Common Mistakes Copy Chapter

Next Steps Copy Chapter

• Quick Flow vs Full Production — Understand both development approaches
• Set up Unity with BMGD — If you're considering Unity instead
• Run sprint planning — When you're ready to start building
• Agents Reference — Learn about all 6 BMGD agents

File: docs/how-to/setup-unity.md Copy Chapter

title: "Set up a Unity project with BMGD" Copy Chapter

Set up a Unity project with BMGD

Configure a new Unity project with BMGD workflows for full production game development.

When to Use This Guide Copy Chapter

• You're starting a new Unity game project
• You want to use BMGD's Full Production workflow
• You need formal documentation (GDD, architecture, sprint tracking)

When to Skip This Copy Chapter

• You just want to prototype quickly — use Quick Flow instead
• You're using Unreal or Godot — see the setup guides for those engines
• You're prototyping or doing a game jam — Quick Flow is faster

Prerequisites Copy Chapter

Before starting:

• BMad Method installed with BMGD module enabled
• Unity Hub and Unity 2022 LTS (or later) installed
• Basic familiarity with Unity and C#
• A game concept or idea you want to develop

Steps Copy Chapter

Step 1: Create your Unity project Copy Section

1. Open Unity Hub
2. Click New Project
3. Select the appropriate template for your game type:
   • 2D → Core 2D
   • 3D → 3D Core
   • URP → Universal Render Pipeline (recommended for most games)
   • HDRP → High Definition Render Pipeline (high-end visuals)
4. Name your project and choose a location
5. Click Create Project

Step 2: Generate your project context Copy Section

BMGD uses a project-context.md file to maintain consistency across all workflows.

In your BMad-enabled environment at the project root:

/bmgd-generate-project-context

This invokes the Game Architect (Cloud Dragonborn) to create a project-context.md file that includes:

• Project name and description
• Target platforms
• Engine and framework choices
• Performance budgets
• Critical technical decisions

Step 3: Run the brainstorming workflow Copy Section

Define your game concept with the Game Designer agent.

/bmgd-brainstorm-game

The Game Designer (Samus Shepard) will guide you through:

• Selecting and combining brainstorming techniques
• Generating and refining game ideas
• Choosing a concept to develop

Step 4: Create your Game Brief Copy Section

Capture your vision and positioning.

/bmgd-game-brief

The Game Designer creates game-brief.md with:

• Game vision and elevator pitch
• Target audience and market positioning
• Platform and genre decisions
• Competitive analysis
• Art and audio direction

Step 5: Design your game (GDD) Copy Section

Create a comprehensive Game Design Document.

/bmgd-create-gdd

The Game Designer helps you:

• Select your game type from 24 available templates
• Define core gameplay mechanics
• Design progression systems
• Plan levels and content
• Specify art and audio requirements

Output: gdd.md

Step 6: Create your technical architecture Copy Section

Plan your Unity project structure and systems.

/bmgd-create-architecture

The Game Architect (Cloud Dragonborn) creates architecture.md with:

• Project structure (folders, naming conventions)
• System architecture (game loop, input, physics, networking)
• Unity-specific patterns (ScriptableObjects, events, object pooling)
• Performance budgets and optimization strategy
• Asset pipeline and build configuration

Step 7: Plan your first sprint Copy Section

Ready to start building? Use the Game Scrum Master to plan your work.

/bmgd-sprint-planning

The Game Scrum Master (Max) creates:

• sprint-status.yaml — Your sprint tracking file
• Stories from your GDD and Architecture
• Sprint goals and definition of done

Step 8: Start implementing Copy Section

Build features with the Game Developer agent.

/bmgd-dev-story [story-name]

The Game Developer (Link Freeman) helps you:

• Implement story tasks with C# scripts
• Follow Unity best practices
• Write tests for your features
• Review code before marking complete

What You Get Copy Chapter

After completing this setup, you'll have:

Unity-Specific Considerations Copy Chapter

Project Structure Copy Section

BMGD recommends this Unity project structure:

Assets/
├── _Project/
│   ├── Scripts/
│   ├── Art/
│   ├── Audio/
│   └── Data/
├── Packages/
└── ProjectSettings/

ScriptableObjects Copy Section

Use ScriptableObjects for game data — the Game Architect will include this in your architecture:

• Game configuration
• Character stats
• Item definitions
• Level data

Performance Budgets Copy Section

Unity projects typically target:

• 60 FPS for most platforms
• 30 FPS for mobile (if targeting battery life)
• 120+ FPS for VR/high-refresh gaming

Your architecture.md will specify your targets.

Testing Setup Copy Section

For Unity automated testing, the Game QA agent (GLaDOS) can help:

/bmgd-test-framework

This sets up Unity Test Framework with:

• Edit Mode tests (logic without running the game)
• Play Mode tests (gameplay systems)
• Test assembly structure

Tips Copy Chapter

Best Practice: Always run gds-generate-project-context after creating a new Unity project. The project-context.md file is the "single source of truth" for project decisions, and the production workflows read it automatically. The conversational agents pick it up only if you add it to their persistent_facts.

Avoid: Don't manually organize your Assets folder before running bmgd-create-architecture. Let the Game Architect define the structure first, then follow it consistently.

Remember: Unity projects can get large quickly. Use the architecture document to keep your project organized as it grows.

Common Mistakes Copy Chapter

Next Steps Copy Chapter

• Quick Flow vs Full Production — Understand both development approaches
• Set up Unreal with BMGD — If you're considering Unreal instead
• Run sprint planning — When you're ready to start building
• Agents Reference — Learn about all 6 BMGD agents

File: docs/how-to/setup-unreal.md Copy Chapter

title: "Set up an Unreal project with BMGD" Copy Chapter

Set up an Unreal project with BMGD

Configure a new Unreal project with BMGD workflows for full production game development.

When to Use This Guide Copy Chapter

• You're starting a new Unreal game project
• You want to use BMGD's Full Production workflow
• You need formal documentation (GDD, architecture, sprint tracking)

When to Skip This Copy Chapter

• You just want to prototype quickly — use Quick Flow instead
• You're using Unity or Godot — see the setup guides for those engines
• You're prototyping or doing a game jam — Quick Flow is faster

Prerequisites Copy Chapter

Before starting:

• BMad Method installed with BMGD module enabled
• Unreal Engine 5.x installed
• Basic familiarity with Unreal (Blueprints or C++)
• A game concept or idea you want to develop

Steps Copy Chapter

Step 1: Create your Unreal project Copy Section

1. Open the Epic Games Launcher
2. Go to Unreal Engine tab
3. Click Launch to open Unreal Editor
4. In the Project Browser, click Games → Next
5. Select the appropriate template:
   • Blank — Start from scratch (most flexible)
   • Third Person — Character-based games
   • First Person — FPS/exploration games
   • Top Down — Strategy and arcade games
6. Choose Blueprint or C++
7. Name your project, choose a location, and click Create

Step 2: Generate your project context Copy Section

BMGD uses a project-context.md file to maintain consistency across all workflows.

In your BMad-enabled environment at the project root:

/bmgd-generate-project-context

This invokes the Game Architect (Cloud Dragonborn) to create a project-context.md file that includes:

• Project name and description
• Target platforms (PC, console, mobile)
• Engine and framework choices (Blueprint vs C++)
• Performance budgets
• Critical technical decisions

Step 3: Run the brainstorming workflow Copy Section

Define your game concept with the Game Designer agent.

/bmgd-brainstorm-game

The Game Designer (Samus Shepard) will guide you through:

• Selecting and combining brainstorming techniques
• Generating and refining game ideas
• Choosing a concept to develop

Step 4: Create your Game Brief Copy Section

Capture your vision and positioning.

/bmgd-game-brief

The Game Designer creates game-brief.md with:

• Game vision and elevator pitch
• Target audience and market positioning
• Platform and genre decisions
• Competitive analysis
• Art and audio direction

Step 5: Design your game (GDD) Copy Section

Create a comprehensive Game Design Document.

/bmgd-create-gdd

The Game Designer helps you:

• Select your game type from 24 available templates
• Define core gameplay mechanics
• Design progression systems
• Plan levels and content
• Specify art and audio requirements

Output: gdd.md

Step 6: Create your technical architecture Copy Section

Plan your Unreal project structure and systems.

/bmgd-create-architecture

The Game Architect (Cloud Dragonborn) creates architecture.md with:

• Project structure (Content Browser organization)
• System architecture (game framework, replication, networking)
• Unreal-specific patterns (Components, Game Instances, Gameplay Abilities)
• Performance budgets and optimization strategy
• Asset pipeline and build configuration

Step 7: Plan your first sprint Copy Section

Ready to start building? Use the Game Scrum Master to plan your work.

/bmgd-sprint-planning

The Game Scrum Master (Max) creates:

• sprint-status.yaml — Your sprint tracking file
• Stories from your GDD and Architecture
• Sprint goals and definition of done

Step 8: Start implementing Copy Section

Build features with the Game Developer agent.

/bmgd-dev-story [story-name]

The Game Developer (Link Freeman) helps you:

• Implement story tasks in Blueprints or C++
• Follow Unreal best practices
• Write tests for your features
• Review code before marking complete

What You Get Copy Chapter

After completing this setup, you'll have:

Unreal-Specific Considerations Copy Chapter

Project Structure Copy Section

BMGD recommends this Content Browser structure:

Content/
├── Game/
│   ├── Blueprints/
│   ├── Materials/
│   ├── Meshes/
│   ├── Textures/
│   ├── Audio/
│   └── UI/
├── Developers/
│   └── [YourName]/
└── Collections/

Blueprint vs C++ Copy Section

Your architecture should specify:

The Game Architect will recommend the right mix for your project.

Performance Budgets Copy Section

Unreal projects typically target:

• 60 FPS for most console/PC games
• 30 FPS for open-world games with high draw distance
• 120 FPS for competitive shooters

Your architecture.md will specify frame time budgets (ms per frame).

Testing Setup Copy Section

For Unreal automated testing, the Game QA agent (GLaDOS) can help:

/bmgd-test-framework

This sets up Unreal Automation System with:

• Unit tests (C++ and Blueprint function libraries)
• Functional tests (gameplay systems)
• Performance tests (frame rate, memory)

Tips Copy Chapter

Best Practice: Always run gds-generate-project-context after creating a new Unreal project. The project-context.md file is the "single source of truth" for project decisions, and the production workflows read it automatically. The conversational agents pick it up only if you add it to their persistent_facts.

Avoid: Don't start with the First Person template if you're making a third-person game. Choose the template closest to your final game — the Game Architect can advise if unsure.

Remember: Unreal projects are larger than Unity projects. Clean up unused content early to keep your project manageable.

Common Mistakes Copy Chapter

Next Steps Copy Chapter

• Quick Flow vs Full Production — Understand both development approaches
• Set up Unity with BMGD — If you're considering Unity instead
• Run sprint planning — When you're ready to start building
• Agents Reference — Learn about all 6 BMGD agents

File: docs/how-to/sprint-planning.md Copy Chapter

title: "Run sprint planning with BMGD" Copy Chapter

Run sprint planning with BMGD

Plan and track development sprints using BMGD's agile workflows for game development.

When to Use This Guide Copy Chapter

• You have a completed GDD and/or Architecture document
• You're ready to start implementing features
• You want to track progress through stories and sprints

When to Skip This Copy Chapter

• You're still in the design phase — complete the GDD and Architecture first
• You're doing Quick Flow prototyping — use Indie's quick-prototype instead
• You just want to test a single feature — Quick Dev is faster

Prerequisites Copy Chapter

Before starting:

• BMad Method installed with BMGD module enabled
• Completed gdd.md (Game Design Document)
• Completed architecture.md (Technical Architecture)
• Basic familiarity with agile/scrum concepts

Steps Copy Chapter

Step 1: Generate sprint status from epics Copy Section

The Game Scrum Master reads your epic files to create the sprint tracking document.

/bmgd-sprint-planning

The Game Scrum Master (Max) will:

1. Read your GDD and Architecture documents
2. Identify epics (large feature areas)
3. Generate sprint-status.yaml with all stories
4. Organize stories into sprints based on dependencies and priority

Step 2: Review your sprint status Copy Section

The generated sprint-status.yaml includes:

sprint: 1
status: In Progress
stories:
  - id: story-001
    title: "Player movement system"
    status: Ready
    priority: P0
    points: 5
    assignee: ""
  - id: story-002
    title: "Basic enemy AI"
    status: Pending
    priority: P1
    points: 8
    assignee: ""

Review the stories and adjust as needed:

• P0 — Must have for this sprint
• P1 — Should have if time allows
• P2 — Nice to have, defer if needed

Step 3: Create detailed stories Copy Section

For each story, the Game Scrum Master creates a complete story file:

/bmgd-create-story [story-id]

This generates a story file in stories/ with:

• Title and description
• Acceptance criteria — Definition of done
• Technical notes — From architecture
• Test cases — What needs to be tested
• Dependencies — Other stories or systems

Step 4: Implement stories Copy Section

Use the Game Developer agent to implement each story:

/bmgd-dev-story [story-id]

The Game Developer (Link Freeman) will:

1. Read the story file and acceptance criteria
2. Reference the architecture for technical guidance
3. Implement the feature with game-specific considerations
4. Create or update tests
5. Mark the story complete when all criteria pass

Step 5: Review code (when flagged) Copy Section

When a story is flagged "Ready for Review," use the code review workflow:

/bmgd-code-review

The Game Developer performs a clean context QA review:

• Verifies acceptance criteria are met
• Checks for performance issues
• Reviews test coverage
• Provides feedback or approves the story

Step 6: Check sprint status Copy Section

At any time, check your sprint progress:

/bmgd-sprint-status

This shows:

• Current sprint number and status
• Story progress (Ready, In Progress, Complete, Blocked)
• Risks and blockers
• Recommended next actions

Step 7: Close the sprint Copy Section

When all sprint stories are complete:

/bmgd-retrospective

The Game Scrum Master facilitates a retrospective:

• What went well
• What could be improved
• Action items for next sprint

Then run sprint-planning again to start the next sprint.

What You Get Copy Chapter

Sprint Workflow Summary Copy Chapter

sprint-planning → create-story → dev-story → code-review → sprint-status → retrospective
                      ↑_____________|
                      (repeat for each story)

Tips Copy Chapter

Best Practice: Always generate stories from GDD and Architecture. Don't write stories from scratch — let the Game Scrum Master create complete drafts from your existing documentation.

Avoid: Don't start implementation without stories. Stories keep you focused and provide clear acceptance criteria.

Remember: Every sprint should deliver a playable increment. Test your game after each story completes.

Common Mistakes Copy Chapter

Story States Copy Chapter

Next Steps Copy Chapter

• Quick Flow vs Full Production — Understand both development approaches
• Set up Unity/Unreal/Godot — Engine-specific setup guides
• Agents Reference — Learn about the Game Scrum Master agent