Bmad Gds

BMAD Game Development Studio

Use this skill as the game producer / orchestration layer for the repository's game-development cluster.

The job is not to do every game task directly. The job is to: 1. normalize a messy game-production packet, 2. decide which phase or risk matters most now, 3. produce the next coordination artifact, 4. route specialist work to the right downstream skill.

Read references/operating-modes.md for the main entry modes and references/scope-boundaries.md before choosing between this skill and the narrower game skills.

When to use this skill

• A game idea, prototype, or existing project needs to be turned into a milestone brief or production plan
• A small team needs help converting a GDD or design brief into epics, stories, and review checkpoints
• Playtest notes, bug lists, and milestone pressure need one cross-functional reprioritization pass
• A public beat such as a demo, festival, playtest, or launch target is forcing design, QA, and production decisions to reconnect
• The user needs one coordinating artifact first, then wants the skill to point toward the correct specialist follow-up

When not to use this skill

• The main issue is a raw Unity or Unreal build/log failure with no broader planning decision → use game-build-log-triage
• The main issue is performance capture and bottleneck diagnosis → use game-performance-profiler
• The main issue is triaging player/demo feedback into weighted priorities → use game-demo-feedback-triage
• The main issue is store-page, wishlist funnel, or launch-page operations → use steam-store-launch-ops
• The user only needs a generic engineering sprint plan with no game-specific context → use task-planning
• The user only needs early ideation / creative expansion before a production framing exists → use bmad-idea

Instructions

Step 1: Capture the production intake brief

Before proposing a workflow, normalize the packet into this brief:

project_brief:
  game_type: "genre, camera, platform, target audience"
  team_shape: solo | duo | small-team | unknown
  engine: Unity | Unreal | Godot | custom | unknown
  current_stage: concept | prototype | vertical-slice | demo | production | launch-prep | live-ops
  next_public_beat: none | internal-playtest | steam-playtest | next-fest | demo-drop | launch | patch
  source_packet:
    - idea-notes
    - gdd-or-design-doc
    - backlog-or-board
    - playtest-feedback
    - bug-or-build-issues
    - launch-or-store-constraints
  main_constraint: time | scope | quality | performance | unknown
  main_question: "what decision or artifact is needed next?"

If the packet is incomplete, still proceed with the best visible stage and state the assumptions.

Step 2: Choose one operating mode

Pick exactly one primary mode for the current run.

1. Concept → milestone brief

• Use when the team has an idea, prototype, or vague direction
• Goal: define pillars, scope guardrails, first milestone, and risks

2. GDD → backlog slice

• Use when design intent exists but implementation slices are weak
• Goal: convert the GDD into epics, stories, acceptance checks, and review gates

3. Mixed signals → reprioritization

• Use when playtest notes, bug reports, and milestone pressure are colliding
• Goal: decide what must happen before the next build or public beat

4. Build trouble → routing decision

• Use when a build issue is present but the real question is whether it blocks a milestone
• Goal: produce the milestone/risk framing, then hand detailed log work to game-build-log-triage

5. Public beat → readiness plan

• Use when the team is targeting a demo, festival, playtest, or launch window
• Goal: connect design, QA, build stability, and store/demo readiness into one plan

Step 3: Decide the next artifact, not the whole universe

Return one primary artifact from this list:

• milestone-brief
• gdd-to-backlog packet
• reprioritization brief
• specialist-routing brief
• public-beat readiness plan

Do not flood the team with parallel plans. Choose the single artifact that most reduces ambiguity right now.

Step 4: Route specialist work explicitly

If the intake shows a narrower downstream problem, route out with a short reason:

• game-demo-feedback-triage → clustered player/demo feedback and fix-first recommendations
• game-build-log-triage → build, packaging, CI, signing, cook, compile, or editor-log failures
• game-performance-profiler → frame-time, memory, hitches, GPU/CPU bottleneck, Steam Deck or console perf complaints
• steam-store-launch-ops → store-page, wishlist funnel, launch sequencing, public-facing launch prep
• task-planning → general engineering decomposition after the game-specific milestone decision is made

If you route out, still leave the team with a short milestone-aware handoff, not just a tool name.

Step 5: Produce the coordination artifact

Use this exact structure:

# Game Production Coordination Brief

## Scope
- Game / build stage: ...
- Engine / platform context: ...
- Team shape: ...
- Next public beat: ...
- Confidence: high | medium | low

## Primary mode
- concept-to-milestone | gdd-to-backlog | reprioritization | build-trouble-routing | public-beat-readiness

## What matters most now
- 2-4 bullets on the strongest production truths from the packet

## Recommended next artifact
- One of: milestone-brief | gdd-to-backlog packet | reprioritization brief | specialist-routing brief | public-beat readiness plan

## Priority decisions
| Decision | Why now | Owner | Risk if delayed |
|----------|---------|-------|-----------------|
| ... | ... | ... | ... |

## Immediate next steps
1. ...
2. ...
3. ...

## Specialist handoffs
- Skill: ...
- Why: ...
- What packet to pass: ...

## What not to do yet
- 1-3 bullets preventing scope drift or the wrong lane

Step 6: Keep the milestone thread visible

Every output must connect work back to the next meaningful beat:

• internal playtest
• Steam Playtest
• Next Fest / public demo
• launch target
• major patch or content drop

If there is no explicit beat, infer the next milestone from the packet and say so.

Output format

Always return a short producer-style coordination brief.

Required qualities:

• prefer concrete next artifacts over abstract game-design essays
• surface the main constraint and tradeoff clearly
• keep specialist routing explicit
• preserve cross-functional visibility across design, engineering, QA, and launch timing
• keep the result under roughly 450-700 words unless the user asks for a larger planning packet

Examples

Example 1: concept to Steam demo

Input

We are a 3-person Unity team building a co-op survival game. We have rough mechanic notes and a prototype, and we want a Steam demo in 8 weeks. Use bmad-gds.

Output sketch

• Primary mode: concept-to-milestone
• Recommended next artifact: milestone-brief
• Priority decisions cover demo fantasy, scope cuts, one playable loop, and test cadence
• Specialist handoff may point to task-planning only after the milestone brief is locked

Example 2: mixed playtest plus bugs

Input

We have Discord feedback, a bug sheet, and a Next Fest date. Players are confused early, and the latest build also has two packaging issues.

Output sketch

• Primary mode: reprioritization
• Recommended next artifact: reprioritization brief
• game-demo-feedback-triage gets the feedback packet
• game-build-log-triage gets the packaging failures
• The coordination brief keeps both tied to the Next Fest milestone

Example 3: raw build problem only

Input

Our Unreal CI build is failing during packaging. Help.

Output sketch

• Do not stay in bmad-gds as the main skill
• Return a short specialist-routing brief
• Route to game-build-log-triage with the exact log/build packet required

Best practices

1. Act like a producer, not a fantasy studio simulator — convert ambiguity into one useful next artifact. 2. Use one primary mode per run — mixing concepting, launch ops, playtest triage, and log debugging weakens output quality. 3. Route aggressively to specialist skills when the packet is mostly feedback, logs, performance, or launch-page operations. 4. Keep scope pressure explicit — small game teams fail more often from spread than from under-ideation. 5. Preserve milestone context — build issues and design changes matter differently depending on whether the next beat is a demo, festival, or launch. 6. Prefer re-entry workflows — playtests and build failures often push teams back into planning; treat that as normal.

References

• references/operating-modes.md
• references/scope-boundaries.md
• ../bmad-idea/SKILL.md
• ../task-planning/SKILL.md
• ../game-demo-feedback-triage/SKILL.md
• ../game-build-log-triage/SKILL.md
• ../game-performance-profiler/SKILL.md
• ../steam-store-launch-ops/SKILL.md

bmad-gds Reference

Full upstream documentation: https://github.com/bmad-code-org/bmad-module-game-dev-studio

Module code: gds · Version: 0.1.4

---

Full Command Reference

---

Artifact Locations

Planning artifacts (GDD, architecture, narrative, test design, playtest plan, performance strategy, change proposal):

• Default: {output_folder}/planning-artifacts/

Implementation artifacts (sprint status, stories, reviews, retrospectives):

• Default: {output_folder}/implementation-artifacts/

Project knowledge (docs, research, references):

• Default: docs/

---

Agent Capabilities

---

Module Configuration

Configured via module.yaml at project init. Key settings:

BMAD-GDS Operating Modes

Use bmad-gds when the team needs a producer-style coordination artifact, not when one specialist lane already dominates the packet.

Mode 1: Concept → milestone brief

Best when the packet contains:

• pitch or idea notes
• rough prototype observations
• target platform / audience
• a near-term demo or milestone goal

Produce:

• design pillars
• scope guardrails
• first milestone definition
• top risks and cuts

Mode 2: GDD → backlog slice

Best when the packet contains:

• GDD, design brief, or mechanic spec
• unclear ownership or sequencing
• a need to turn intent into epics/stories

Produce:

• epics
• story slices
• acceptance checks
• review cadence

Route to task-planning after the game-specific milestone framing is stable.

Mode 3: Mixed signals → reprioritization

Best when the packet contains:

• playtest notes
• bug lists
• build concerns
• milestone pressure from a demo/festival/release

Produce:

• a short reprioritization brief
• one recommended next artifact
• specialist handoffs for the noisy parts

Mode 4: Build trouble → routing decision

Best when the packet contains:

• build/log failures
• milestone impact uncertainty
• uncertainty about whether the issue is truly ship-blocking

Produce:

• short milestone-aware framing
• route details to game-build-log-triage

Mode 5: Public beat → readiness plan

Best when the packet contains:

• Steam Playtest target
• Next Fest or public demo timing
• launch-window constraints
• store/demo readiness questions

Produce:

• readiness plan
• owner/risk table
• explicit follow-ups into steam-store-launch-ops or specialist gameplay/testing lanes

BMAD-GDS Scope Boundaries

bmad-gds is the coordinating skill for game-production packets. It should not swallow every game problem.

Use bmad-gds when

• the packet mixes design, production, QA, build, or launch context
• the team needs the next milestone-aware artifact first
• the user is unsure which game skill to use
• a specialist result needs to be stitched back into one production brief

Route away from bmad-gds when

bmad-idea

Use for early ideation, design-thinking, story framing, and creative expansion before production coordination matters.

task-planning

Use for generic engineering decomposition once the game-specific milestone or scope decision is already made.

game-demo-feedback-triage

Use when the core input is player/demo/creator feedback that needs weighted clustering and fix-first prioritization.

game-build-log-triage

Use when the core input is editor/build/package/cook/compile/CI failure data.

game-performance-profiler

Use when the core question is profiling, performance diagnosis, or bottleneck planning.

steam-store-launch-ops

Use when the dominant problem is store-page quality, wishlist funnel, launch sequencing, or public-facing launch operations.

Stitch-back rule

After a specialist skill runs, bmad-gds can be used again to merge the result back into:

• milestone priorities
• owner / risk decisions
• next public-beat readiness
• scope cuts or re-sequencing

Anti-patterns

• treating bmad-gds as a replacement for detailed engine debugging
• using it for every game task just because the project is a game
• returning multiple competing next artifacts instead of one decisive coordination brief
• hiding milestone risk behind generic design prose