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