## 1. Project Overview & Quickstart (bmad-code-org/BMAD-METHOD) ## File: README.md **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 **Prerequisites:** [Node.js](https://nodejs.org) 20.12+, [Python](https://www.python.org) 3.10+, and [uv](https://docs.astral.sh/uv/) ```bash 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 →](https://docs.bmad-method.org/tutorials/getting-started/)** **[Add BMad to an existing codebase →](https://docs.bmad-method.org/how-to/established-projects/)** 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](https://docs.bmad-method.org/how-to/install-bmad/). ## Why BMad? 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 →](https://docs.bmad-method.org/reference/workflow-map/) ## BMad Ecosystem Install the core method or add official modules for specialized work. | Module | Purpose | | --- | --- | | **[BMad Method](https://github.com/bmad-code-org/BMAD-METHOD)** | Plan and deliver software, from new prototypes to established codebases | | **[BMad Builder](https://github.com/bmad-code-org/bmad-builder)** | Skill, workflow, and agent builder | | **[BMad Creative Intelligence Suite](https://github.com/bmad-code-org/bmad-module-creative-intelligence-suite)** | Creative thinking partners for innovation, design thinking, and storytelling | | **[BMad Test Architect](https://github.com/bmad-code-org/bmad-method-test-architecture-enterprise)** | Enterprise testing add-on for BMad Method | | **[BMad Loop](https://github.com/bmad-code-org/bmad-loop)** | Builds, verifies, and retros a whole epic unattended | | **[BMad Game Dev Studio](https://github.com/bmad-code-org/bmad-module-game-dev-studio)** | Ideate, design, and build games in any framework, including Unity, Unreal, Godot, and Phaser | ## Plan on the Web [Web bundles](https://bmadcode.com/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 - **[Getting Started](https://docs.bmad-method.org/tutorials/getting-started/)** — Install BMad and build a small project. - **[Workflow Map](https://docs.bmad-method.org/reference/workflow-map/)** — Understand the available paths and outputs. - **[Established Projects](https://docs.bmad-method.org/how-to/established-projects/)** — Add BMad to an existing codebase. - **[Upgrade to V6](https://docs.bmad-method.org/how-to/upgrade-to-v6/)** — Migrate from an earlier version. ## Roadmap See what is in progress and what is planned on the [public roadmap](https://docs.bmad-method.org/roadmap/). ## Community - [Discord](https://discord.gg/gk8jAdXWmj) — Get help, share ideas, and collaborate. - [YouTube](https://youtube.com/@BMadCode) — Watch tutorials and master classes. - [GitHub Issues](https://github.com/bmad-code-org/BMAD-METHOD/issues) — Report bugs and request features. - [GitHub Discussions](https://github.com/bmad-code-org/BMAD-METHOD/discussions) — Join longer community conversations. - [BMad Code](https://bmadcode.com) — Explore the wider ecosystem. ## Support and Contributing BMad is free for everyone and always will be. Star the repository, [buy me a coffee](https://buymeacoffee.com/bmad), or email for corporate sponsorship. Contributions are welcome. Read [CONTRIBUTING.md](CONTRIBUTING.md) before opening a pull request. ## License MIT License — see [LICENSE](LICENSE) for details. **BMad** and **BMAD-METHOD** are trademarks of BMad Code, LLC. See [TRADEMARK.md](TRADEMARK.md) for details. [](https://github.com/bmad-code-org/BMAD-METHOD/graphs/contributors) See [CONTRIBUTORS.md](CONTRIBUTORS.md) for contributor information. [](https://www.npmjs.com/package/bmad-method) [](LICENSE) [](https://discord.gg/gk8jAdXWmj) --- ## File: docs/explanation/advanced-elicitation.md --- title: "Advanced Elicitation" sidebar: order: 4 --- 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? 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 - 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 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 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 --- title: "Brainstorming" sidebar: order: 3 --- Unlock your creativity through guided exploration. ## What is Brainstorming? 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 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 --- title: "Established Projects FAQ" sidebar: order: 12 --- Quick answers to common questions about working on established projects with the BMad Method (BMM). ## Questions - [Do I have to run document-project first?](#do-i-have-to-run-document-project-first) - [What if I forget to run document-project?](#what-if-i-forget-to-run-document-project) - [How does implementation work in established projects?](#how-does-implementation-work-in-established-projects) - [What if my existing code doesn't follow best practices?](#what-if-my-existing-code-doesnt-follow-best-practices) ### Do I have to run document-project first? `bmad-document-project` is deprecated — its replacement is [`bmad-project-context`](project-context.md), 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? 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? 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? 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](https://github.com/bmad-code-org/BMAD-METHOD/issues) or ask in [Discord](https://discord.gg/gk8jAdXWmj) so we can add it! --- ## File: docs/explanation/party-mode.md --- title: "Party Mode" sidebar: order: 9 --- 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? 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 Invoke the skill and say what you want; it works out whether you mean to run a party or build one. | Goal | Type this | | --- | --- | | Start a party in the default mode | `/bmad-party-mode` | | Start in a specific mode | `/bmad-party-mode --mode auto` (also `session`, `subagent`, `agent-team`) | | Run it once, non-interactively | `/bmad-party-mode --non-interactive "review this PR"` | | Open a saved party | `/bmad-party-mode --party code-review-crew` | | Conjure a cast on the spot | "party mode with the bridge crew of the Enterprise" | | Create or add a party | "party mode, create a new party" | | Edit an existing party | "party mode, edit the writers' room" | | Customize the skill | `/bmad-customize bmad-party-mode` | ## How a party runs 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. | Mode | What it does | Reach for it when | | --- | --- | --- | | `session` | Default. One model voices every persona inline. Fast and fully conversational. | Most conversations — banter, brainstorming, quick back-and-forth. | | `auto` | Voices inline for light rounds, spawns independent agents only when independence changes the answer. | You want speed most of the time but real independence on the hard rounds. | | `subagent` | Spawns a separate agent for each persona every substantive round, so no single mind colors them all. | Honest reviews and focus groups, where the voices must not bleed together. | | `agent-team` | Stands the personas up as a persistent team that address each other directly. Claude Code only. | A live, hands-off round-table where the agents talk among themselves. | 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 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](../how-to/customize-bmad.md). 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 | Shape | What it is | | --- | --- | | Themed cast | Famous investors, a TV ensemble — distinct voices gathered around a topic. | | One-off personas | A persona or two added to the pool, no group needed. | | Focus group from data | Hand it customer or survey data; it clusters people by what drives their behavior and builds representative personas. Pair it with `subagent` mode so the customers stay independent. | | Review panel | Purpose-built critical lenses that argue about what matters. The shipped Code Review Crew is one. | | Deliberation scaffold | A room that makes the human think harder without pretending to be an autonomous decision council. The shipped Anti-Consensus Club is one. | | Open-cast room | No fixed roster. The scene names a universe and the room is cast on the fly as the topic shifts. | 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 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 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. | Member | Lens | | --- | --- | | Vex | Security — threat-models everything and names the concrete exploit path. | | Grumbal | The adversary — assumes the code is broken and sets out to prove it. | | Boundary | Edge cases — every branch, null, race, oversized input, odd timezone. | | Yui | The craftsman — simplicity, naming, no needless cleverness or duplication. | | Dana | The pragmatist — counters the perfectionists and ranks what's real versus a nit. | 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 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. | Member | Lens | | --- | --- | | Wildcard | Option generator — suggests alternative problem statements, assumptions, and examples. | | Level | Claim checker — checks support, missing information, and confidence. | | Killjoy | Loop stopper — stops repetition, fake disagreement, and unsupported speculation. | | Splinter | Consensus challenger — questions easy agreement and ignored tradeoffs. | 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 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 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 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 --- title: "Preventing Agent Conflicts" sidebar: order: 6 --- 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 ### API Style Conflicts 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 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 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 ### 1. Explicit Decisions via ADRs 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 Architecture maps each functional requirement to technical approach: - FR-001: User Management → GraphQL mutations - FR-002: Mobile App → Optimized queries ### 3. Standards and Conventions Explicit documentation of: - Directory structure - Naming conventions - Code organization - Testing patterns ## Architecture as Shared Context Think of architecture as the shared context that all agents read before implementing: ```text 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 Common decisions that prevent conflicts: | Topic | Example Decision | | ---------------- | -------------------------------------------- | | API Style | GraphQL vs REST vs gRPC | | Database | PostgreSQL vs MongoDB | | Auth | JWT vs Sessions | | State Management | Redux vs Context vs Zustand | | Styling | CSS Modules vs Tailwind vs Styled Components | | Testing | Jest + Playwright vs Vitest + Cypress | ## Anti-Patterns to Avoid :::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 --- title: "Project Context" sidebar: order: 10 --- `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](project-context-theory.md). ## What goes in, and what doesn't 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 | Intent | What it does | |--------|--------------| | **Setup** | For a repo with no instructions worth preserving. Ask what you bring, discover and verify the rest, show you the block, then write it. | | **Adopt** | For instructions you already wrote. You see where every one of them went before anything is written; nothing is deleted without your sign-off. | | **Refresh** | The same run against an existing block: re-run its commands, diff deletions and renames since the recorded commit, update what moved. | | **Record** | Capture one observed agent mistake at the moment it happens. A recurring or costly one earns a line. | | **Audit** | Re-verify and prune. The block ends smaller or equal, never larger. | ## How agents load it `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 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 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 :::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 --- title: "Why Solutioning Matters" sidebar: order: 5 --- 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 ```text 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 ```text 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 | Aspect | Planning (Phase 2) | Solutioning (Phase 3) | | -------- | ----------------------- | --------------------------------- | | Question | What and Why? | How? Then What units of work? | | Output | FRs/NFRs (Requirements) | Architecture + Epics/Stories | | Agent | PM | Architect → PM | | Audience | Stakeholders | Developers | | Document | PRD (FRs/NFRs) | Architecture + Epic Files | | Level | Business logic | Technical design + Work breakdown | ## Key Principle **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 | Work characteristics | Solutioning guidance | |---|---| | Clear, local change with established patterns | Usually unnecessary | | Several related components with known constraints | Optional, based on coordination risk | | Multiple epics or cross-system decisions | Needed to align implementation | | Regulated, high-risk, or enterprise initiative | Follow required governance; solutioning is normally required | 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 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) ## File: README.md # BMad Game Dev Studio [](https://www.npmjs.com/package/bmad-game-dev-studio) [](LICENSE) [](https://www.python.org) [](https://docs.astral.sh/uv/) [](https://discord.gg/gk8jAdXWmj) **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 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 BMGD has first-class support for: - [Unity](https://unity.com) — C# scripting, industry-standard for many game types - [Unreal Engine](https://www.unrealengine.com/) — Blueprint and C++, AAA powerhouse - [Godot](https://godotengine.org/) — Open-source, GDScript, rapidly growing - [Roblox](https://www.roblox.com/create) — 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 BMGD supports **21 game types**, including: | Genre | Examples | |-------|----------| | Action | Platformers, shooters, hack-and-slash | | RPG | Action RPG, tactical RPG, dungeon crawlers | | Strategy | Turn-based, RTS, tower defense | | Simulation | Life sim, tycoon, management | | Adventure | Visual novels, point-and-click, walking simulators | | And more... | Survival, horror, puzzle, racing, etc. | ## What BMGD Does - **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 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 BMGD is installed as a module during BMad Method setup: ```bash 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 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 | Approach | When to Use | Workflow | |----------|-------------|----------| | **Quick Flow** | Rapid prototyping, small projects | `/bmgd-quick-dev` | | **Full Production** | Full games, teams, long-term | `/bmad-help` for guided path | ## Example: Starting a New Game ``` 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 **[BMad Game Dev Studio Documentation](http://game-dev-studio-docs.bmad-method.org)** — Tutorials, how-to guides, and reference - [Getting Started](http://game-dev-studio-docs.bmad-method.org/tutorials/) - [BMad Method Docs](http://docs.bmad-method.org) — Core framework documentation ## Community - [Discord](https://discord.gg/gk8jAdXWmj) — Get help from other game devs - [YouTube](https://youtube.com/@BMadCode) — Tutorials, master class, and more - [X / Twitter](https://x.com/BMadCode) - [Website](https://bmadcode.com) - [GitHub Issues](https://github.com/bmad-code-org/bmad-module-game-dev-studio/issues) — Report bugs ## Support BMad BMad is free for everyone and always will be. Star this repo, [buy me a coffee](https://buymeacoffee.com/bmad), or email for corporate sponsorship. ## License MIT License — see [LICENSE](LICENSE) for details. --- **BMad Game Dev Studio** — Part of the [BMad Method](https://github.com/bmad-code-org/BMAD-METHOD) ecosystem. [](https://github.com/bmad-code-org/bmad-module-game-dev-studio/graphs/contributors) See [CONTRIBUTORS.md](CONTRIBUTORS.md) for contributor information. *If you can dream it, you can build it.* --- ## File: docs/explanation/bmgd-vs-bmm.md --- title: "BMGD vs BMM" --- BMGD (BMad Game Development) extends BMM (BMad Method) with game-specific capabilities. This page explains the key differences. ## Quick Comparison | Aspect | BMM | BMGD | | -------------- | ------------------------------------- | ------------------------------------------------------------------------ | | **Focus** | General software | Game development | | **Agents** | PM, Architect, Dev, SM, TEA, Solo Dev | Game Designer, Game Dev, Game Architect, Game SM, Game QA, Game Solo Dev | | **Planning** | PRD, Tech Spec | Game Brief, GDD | | **Types** | N/A | 24 game type templates | | **Narrative** | N/A | Full narrative workflow | | **Testing** | Web-focused | Engine-specific (Unity, Unreal, Godot) | | **Production** | BMM workflows | BMM workflows with game overrides | ## Agent Differences ### BMM Agents - PM (Product Manager) - Architect - DEV (Developer) - SM (Scrum Master) - TEA (Test Architect) - Quick Flow Solo Dev ### BMGD Agents - 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 ### BMM Planning - **Product Brief** → **PRD** → **Architecture** - Focus: Software requirements, user stories, system design ### BMGD Planning - **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 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 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 ### BMM Testing (TEA) - Web-focused (Playwright, Cypress) - API testing - E2E for web applications ### BMGD Testing (Game QA) - Engine-specific frameworks (Unity, Unreal, Godot) - Gameplay testing - Performance profiling - Playtest planning - Balance validation ## Production Workflow 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 ### Use BMM when: - Building web applications - Creating APIs and services - Developing mobile apps (non-game) - Any general software project ### Use BMGD when: - Building video games - Creating interactive experiences - Game prototyping - Game jams --- ## File: docs/explanation/game-types.md --- title: "BMGD Game Types Guide" --- Reference for selecting and using BMGD's 24 supported game type templates. ## Overview 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 ### Action & Combat #### 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 #### 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 #### 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 #### 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 #### 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 #### 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 #### 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 #### 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 #### 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 #### 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 Many games combine multiple genres. BMGD supports hybrid selection: ### Examples **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 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 ### 1. Start with Core Fantasy 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 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 2-3 game types maximum. More than that usually means your design isn't focused enough. ### 4. Primary vs Secondary 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 When you select a game type, BMGD adds these GDD sections: | Game Type | Key Sections Added | | ----------------- | -------------------------------------- | | Action Platformer | Movement, Combat, Level Design | | RPG | Stats, Inventory, Quests | | Roguelike | Procedural Gen, Runs, Meta-Progression | | Narrative | Story Structure, Dialogue, Branching | | Multiplayer | Matchmaking, Netcode, Balance | | Simulation | Systems, Economy, AI | ## Next Steps - **[Quick Start Guide](/docs/tutorials/getting-started/quick-start-gds.md)** - Get started with BMGD - **[Workflows Guide](/docs/reference/workflows/gds-workflows.md)** - GDD workflow details - **[Glossary](/docs/reference/glossary/index.md)** - Game development terminology --- ## File: docs/explanation/index.md --- title: Explanation --- # Explanation Learn how BMad Game Dev Studio works under the hood. --- ## Development Approaches - **[Quick Flow vs Full Production](./quick-flow-vs-full.md)** — Choose the right development path for your project --- ## Module Concepts - **[Game Types](./game-types.md)** — Selecting and using game type templates (24 genres) - **[BMGD vs BMM](./bmgd-vs-bmm.md)** — Understanding the differences between BMGD and core BMad Method --- ## Framework Integration For foundational concepts about agents, workflows, and the BMad Method framework, see the [BMad Method Documentation](https://docs.bmad-method.org). --- ## File: docs/explanation/quick-flow-vs-full.md --- title: "Quick Flow vs Full Production" --- # 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 **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 - 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 ``` 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 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 - 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 - 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 **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 - 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 ``` 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 Full Production uses specialized agents for each phase: | Phase | Agent | Workflows | Outputs | |-------|-------|-----------|---------| | **Preproduction** | Game Designer | brainstorm-game, game-brief | game-brief.md | | **Design** | Game Designer | create-gdd, narrative | gdd.md, narrative.md | | **Technical** | Game Architect | create-architecture, project-context | architecture.md, project-context.md | | **Production** | Game Scrum Master | sprint-planning, create-story | sprint-status.yaml, stories/ | | **Implementation** | Game Developer | dev-story, code-review | Completed features | | **Testing** | Game QA | test-framework, automate | Test suites, test results | ### What You Get - **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 - 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 | Aspect | Quick Flow | Full Production | |--------|------------|-----------------| | **Team size** | Solo or tiny team | Any size | | **Speed** | Fast — prototype in hours | Thorough — planning takes time | | **Documentation** | Minimal (prototype spec) | Comprehensive (brief, GDD, architecture) | | **Tracking** | None (or informal) | Sprints, stories, retrospectives | | **Agents involved** | Game Solo Dev (Indie) | All 6 agents as needed | | **Best for** | Prototypes, jams, small projects | Full games, teams, publishers | | **Time to first playable** | Hours to days | Days to weeks | --- ## Can You Switch Between Paths? **Yes.** Quick Flow and Full Production aren't locked doors — they're different approaches to the same goal. ### Quick Flow → Full Production 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 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 **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 - **[Your first game project with BMGD](../tutorials/first-game-project.md)** — Try Quick Flow now - **[Set up Unity with BMGD](../how-to/setup-unity.md)** — Engine-specific Full Production setup - **[Agents Reference](../reference/agents.md)** — Learn about all 6 BMGD agents --- ## File: docs/how-to/index.md --- title: "How-To Guides" --- # How-To Guides Step-by-step guides for completing specific game development tasks with BMGD. --- ## Engine Setup Guides Get started with your preferred game engine: - **[Set up a Unity project with BMGD](./setup-unity.md)** — Configure Unity for full production development - **[Set up an Unreal project with BMGD](./setup-unreal.md)** — Configure Unreal for full production development - **[Set up a Godot project with BMGD](./setup-godot.md)** — Configure Godot for full production development --- ## Quick Flow Guides Rapid prototyping and fast iteration: - **[Quick Flow: Rapid prototyping](./quick-prototype.md)** — Create a playable prototype in hours (coming soon) --- ## Production Workflows Plan, track, and implement your game: - **[Run sprint planning](./sprint-planning.md)** — Plan and track development sprints - **[Conduct code reviews](./code-review.md)** — Review code quality (coming soon) - **[Course correction](./correct-course.md)** — Get back on track when implementation diverges (coming soon) --- ## Testing Guides Set up and run testing for your game: - **[Set up automated testing](./testing-setup.md)** — Initialize test frameworks (coming soon) - **[Design game tests](./test-design.md)** — Create comprehensive test scenarios (coming soon) - **[Plan playtesting sessions](./playtesting.md)** — Structure your playtesting (coming soon) - **[Performance testing](./performance-testing.md)** — Design performance testing strategy (coming soon) --- ## Reference For complete workflow and agent reference, see: - **[Workflows Reference](../reference/workflows.md)** — All BMGD workflows - **[Agents Reference](../reference/agents.md)** — All 6 BMGD agents - **[Game Types Reference](../reference/game-types.md)** — All 24 game type templates --- ## File: docs/how-to/setup-godot.md --- title: "Set up a Godot project with BMGD" --- # 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 - 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 - You just want to prototype quickly — use [Quick Flow](../tutorials/first-game-project.md) 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 > **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 ### Step 1: Create your Godot project 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 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 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 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) 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 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 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 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 After completing this setup, you'll have: | File/Folder | Purpose | |------------|---------| | `project-context.md` | AI context for consistency across all BMGD workflows | | `game-brief.md` | Your game's vision and positioning | | `gdd.md` | Complete game design document | | `architecture.md` | Technical architecture and Godot-specific patterns | | `sprint-status.yaml` | Sprint tracking with stories and progress | | `stories/` | Folder containing individual story files | --- ## Godot-Specific Considerations ### Project Structure BMGD recommends this Godot project structure: ``` res:// ├── scenes/ │ ├── levels/ │ ├── characters/ │ ├── ui/ │ └── components/ ├── scripts/ │ ├── autoload/ │ └── utils/ ├── assets/ │ ├── art/ │ ├── audio/ │ └── data/ └── project.godot ``` ### Scene Organization 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 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 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 > **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 | Mistake | Solution | |---------|----------| | Skipping project-context generation | Always generate `project-context.md` first — it guides all other workflows | Creating monolithic scenes | Break your game into reusable scene components — the Game Architect can help design this | Not using autoloads properly | Keep autoloads minimal — only use for true singletons (game state, save system) | Mixing GDScript and C# arbitrarily | Choose one primary language and stick with it — mixing adds complexity without benefit | --- ## Next Steps - **[Quick Flow vs Full Production](../explanation/quick-flow-vs-full.md)** — Understand both development approaches - **[Set up Unity with BMGD](./setup-unity.md)** — If you're considering Unity instead - **[Run sprint planning](./sprint-planning.md)** — When you're ready to start building - **[Agents Reference](../reference/agents.md)** — Learn about all 6 BMGD agents --- ## File: docs/how-to/setup-unity.md --- title: "Set up a Unity project with BMGD" --- # 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 - 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 - You just want to prototype quickly — use [Quick Flow](../tutorials/first-game-project.md) 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 > **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 ### Step 1: Create your Unity project 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 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 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 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) 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 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 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 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 After completing this setup, you'll have: | File/Folder | Purpose | |------------|---------| | `project-context.md` | AI context for consistency across all BMGD workflows | | `game-brief.md` | Your game's vision and positioning | | `gdd.md` | Complete game design document | | `architecture.md` | Technical architecture and Unity-specific patterns | | `sprint-status.yaml` | Sprint tracking with stories and progress | | `stories/` | Folder containing individual story files | --- ## Unity-Specific Considerations ### Project Structure BMGD recommends this Unity project structure: ``` Assets/ ├── _Project/ │ ├── Scripts/ │ ├── Art/ │ ├── Audio/ │ └── Data/ ├── Packages/ └── ProjectSettings/ ``` ### ScriptableObjects Use ScriptableObjects for game data — the Game Architect will include this in your architecture: - Game configuration - Character stats - Item definitions - Level data ### Performance Budgets 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 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 > **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 | Mistake | Solution | |---------|----------| | Skipping project-context generation | Always generate `project-context.md` first — it guides all other workflows | Choosing the wrong Unity template | Consult the Game Architect if unsure — your engine choice affects architecture | Starting implementation before GDD | Complete the Design phase first — changes are cheaper before code is written | Ignoring sprint planning | Even solo projects benefit from story tracking — it keeps you focused on ship | --- ## Next Steps - **[Quick Flow vs Full Production](../explanation/quick-flow-vs-full.md)** — Understand both development approaches - **[Set up Unreal with BMGD](./setup-unreal.md)** — If you're considering Unreal instead - **[Run sprint planning](./sprint-planning.md)** — When you're ready to start building - **[Agents Reference](../reference/agents.md)** — Learn about all 6 BMGD agents --- ## File: docs/how-to/setup-unreal.md --- title: "Set up an Unreal project with BMGD" --- # 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 - 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 - You just want to prototype quickly — use [Quick Flow](../tutorials/first-game-project.md) 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 > **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 ### Step 1: Create your Unreal project 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 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 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 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) 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 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 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 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 After completing this setup, you'll have: | File/Folder | Purpose | |------------|---------| | `project-context.md` | AI context for consistency across all BMGD workflows | | `game-brief.md` | Your game's vision and positioning | | `gdd.md` | Complete game design document | | `architecture.md` | Technical architecture and Unreal-specific patterns | | `sprint-status.yaml` | Sprint tracking with stories and progress | | `stories/` | Folder containing individual story files | --- ## Unreal-Specific Considerations ### Project Structure BMGD recommends this Content Browser structure: ``` Content/ ├── Game/ │ ├── Blueprints/ │ ├── Materials/ │ ├── Meshes/ │ ├── Textures/ │ ├── Audio/ │ └── UI/ ├── Developers/ │ └── [YourName]/ └── Collections/ ``` ### Blueprint vs C++ Your architecture should specify: | Approach | When to Use | |----------|-------------| | **Blueprints** | Rapid prototyping, gameplay logic, designer-iterable systems | | **C++** | Performance-critical systems, complex algorithms, platform-specific features | | **Mixed** | C++ for systems, Blueprints for gameplay (common approach) | The Game Architect will recommend the right mix for your project. ### Performance Budgets 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 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 > **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 | Mistake | Solution | |---------|----------| | Skipping project-context generation | Always generate `project-context.md` first — it guides all other workflows | Choosing the wrong template | Consult the Game Architect — starting from Blank is often cleaner than refactoring a template | Ignoring Unreal's project structure | Follow Content Browser organization from your architecture — don't create custom folder structures | Not using Unreal's built-in systems | Use Gameplay Abilities, Gameplay Tags, and Data Assets — don't reinvent the wheel | --- ## Next Steps - **[Quick Flow vs Full Production](../explanation/quick-flow-vs-full.md)** — Understand both development approaches - **[Set up Unity with BMGD](./setup-unity.md)** — If you're considering Unity instead - **[Run sprint planning](./sprint-planning.md)** — When you're ready to start building - **[Agents Reference](../reference/agents.md)** — Learn about all 6 BMGD agents --- ## File: docs/how-to/sprint-planning.md --- title: "Run sprint planning with BMGD" --- # Run sprint planning with BMGD Plan and track development sprints using BMGD's agile workflows for game development. --- ## When to Use This Guide - 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 - 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 > **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 ### Step 1: Generate sprint status from epics 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 The generated `sprint-status.yaml` includes: ```yaml 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 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 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) 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 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 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 | File/Folder | Purpose | |------------|---------| | `sprint-status.yaml` | Sprint tracking with stories, progress, and risks | | `stories/` | Folder containing individual story files | | Each story file | Complete definition with acceptance criteria and tests | --- ## Sprint Workflow Summary ``` sprint-planning → create-story → dev-story → code-review → sprint-status → retrospective ↑_____________| (repeat for each story) ``` --- ## Tips > **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 | Mistake | Solution | |---------|----------| | Writing stories manually | Use `bmgd-create-story` to generate complete stories from GDD/Architecture | Starting P2 stories before P0 | Follow priority order — P0 first, then P1, then P2 | Skipping acceptance criteria | Each story must have clear "definition of done" before implementation | Not testing after each story | Playtest after every story completes — catches issues early | --- ## Story States | State | Meaning | Next Action | |-------|---------|-------------| | **Pending** | Not yet ready to start | Move to Ready when dependencies complete | | **Ready** | Ready to implement | Run `bmgd-dev-story` | | **In Progress** | Currently being implemented | Complete implementation or flag if blocked | | **Complete** | Done and tested | Move to next story | | **Blocked** | Cannot proceed due to dependency | Resolve blocker or re-plan sprint | --- ## Next Steps - **[Quick Flow vs Full Production](../explanation/quick-flow-vs-full.md)** — Understand both development approaches - **[Set up Unity/Unreal/Godot](../how-to/setup-unity.md)** — Engine-specific setup guides - **[Agents Reference](../reference/agents.md)** — Learn about the Game Scrum Master agent