bmad-gds

BMAD Game Development Studio

このスキルは、リポジトリのゲーム開発クラスターにおけるゲームプロデューサー／オーケストレーションレイヤーとして使用します。

このスキルの役割は、ゲーム開発のすべてのタスクを直接こなすことではありません。次のことを行います。

1. 雑然としたゲーム制作資料を整理する
2. 現時点で最も重要なフェーズまたはリスクを判断する
3. 次の調整用成果物を作成する
4. 専門的な作業を適切な下流スキルに振り分ける

主な開始モードについてはreferences/operating-modes.mdを、このスキルとより範囲の狭いゲームスキルのどちらを選ぶかについては、references/scope-boundaries.mdを参照してください。

このスキルを使用する場面

• ゲームのアイデア、プロトタイプ、または既存のプロジェクトを、マイルストーン概要や制作計画にまとめる必要がある
• 小規模チームが、GDDやデザイン概要をエピック、ストーリー、レビューのチェックポイントに落とし込む必要がある
• プレイテストのメモ、バグ一覧、マイルストーンのプレッシャーを、部門横断で一度に優先順位付けし直す必要がある
• デモ、フェスティバル、プレイテスト、ローンチ目標などの公開イベントをきっかけに、デザイン、QA、制作の各判断を再調整する必要がある
• まず調整用の成果物を1つ作成し、その後、適切な専門スキルによるフォローアップを案内してほしい

このスキルを使用しない場面

• 主な問題が、生のUnityまたはUnrealのビルド／ログの失敗で、より広範な計画判断が関係しない場合 → game-build-log-triageを使用してください
• 主な問題が、パフォーマンスの計測とボトルネックの診断の場合 → game-performance-profilerを使用してください
• 主な問題が、プレイヤーやデモのフィードバックを重み付けした優先事項に振り分けることの場合 → game-demo-feedback-triageを使用してください
• 主な問題が、ストアページ、ウィッシュリストのファネル、またはローンチページの運用の場合 → steam-store-launch-opsを使用してください
• ゲーム固有の文脈を含まない、汎用的なエンジニアリングのスプリント計画だけが必要な場合 → task-planningを使用してください
• 制作の枠組みがまだなく、初期のアイデア出しや創造的な拡張だけが必要な場合 → bmad-ideaを使用してください

手順

ステップ1：制作の受付概要をまとめる

ワークフローを提案する前に、資料を次の概要にまとめます。

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?"

資料が不完全な場合でも、確認できる最善の段階をもとに進め、前提を明示してください。

ステップ2：運用モードを1つ選ぶ

今回の実行で主となるモードを、必ず1つだけ選びます。

1. コンセプト → マイルストーン概要

   • チームにアイデア、プロトタイプ、または曖昧な方向性がある場合に使用します
   • 目標：柱となる要素、スコープの制約、最初のマイルストーン、リスクを定めます

2. GDD → バックログの一部

   • デザインの意図はあるものの、実装単位への分割が弱い場合に使用します
   • 目標：GDDをエピック、ストーリー、受け入れ確認項目、レビューゲートに変換します

3. 複数のシグナル → 優先順位の再設定

   • プレイテストのメモ、バグ報告、マイルストーンのプレッシャーが重なっている場合に使用します
   • 目標：次のビルドまたは公開イベントの前に必ず行うべきことを決めます

4. ビルドの問題 → 振り分けの判断

   • ビルドの問題があるものの、それがマイルストーンを妨げるかどうかが本質的な問いである場合に使用します
   • 目標：マイルストーンとリスクの枠組みを示したうえで、詳細なログ分析をgame-build-log-triageに引き継ぎます

5. 公開イベント → 準備計画

   • チームがデモ、フェスティバル、プレイテスト、またはローンチ時期を目標にしている場合に使用します
   • 目標：デザイン、QA、ビルドの安定性、ストア／デモの準備を1つの計画につなげます

ステップ3：すべてではなく、次に必要な成果物を決める

次の一覧から、主となる成果物を1つ返します。

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

チームに並行する計画を大量に提示しないでください。現時点で曖昧さを最も減らす成果物を1つ選んでください。

ステップ 4：専門作業へ明示的に振り分ける

インテークから、より限定的な後続の課題が見つかった場合は、簡潔な理由を添えて振り分けます。

• game-demo-feedback-triage → プレイヤー／デモのフィードバックの分類と、優先して修正すべき項目の提案
• game-build-log-triage → ビルド、パッケージング、CI、署名、クック、コンパイル、エディターログの失敗
• game-performance-profiler → フレームタイム、メモリ、カクつき、GPU／CPU のボトルネック、Steam Deck やコンソールのパフォーマンスに関する不満
• steam-store-launch-ops → ストアページ、ウィッシュリストのファネル、ローンチの段取り、一般公開に向けたローンチ準備
• task-planning → ゲーム固有のマイルストーンを決定した後の、一般的なエンジニアリング作業の分解

振り分ける場合も、ツール名を伝えるだけでなく、マイルストーンを踏まえた簡潔な引き継ぎをチームに残します。

ステップ 5：調整用の成果物を作成する

次の構成をそのまま使用します。

# 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

ステップ 6：マイルストーンの流れを見える状態に保つ

すべての出力で、作業を次の重要な節目に結び付けます。

• 社内プレイテスト
• Steam Playtest
• Next Fest／一般公開デモ
• ローンチ目標
• 大型パッチまたはコンテンツの追加

明確な節目がない場合は、提供された情報から次のマイルストーンを推測し、その旨を伝えます。

出力形式

常にプロデューサー形式の簡潔な調整ブリーフを返します。

必須の要件：

• 抽象的なゲームデザイン論より、具体的に次に作る成果物を優先します
• 主な制約とトレードオフを明確に示します
• 専門チームへの振り分けを明示します
• デザイン、エンジニアリング、QA、ローンチ時期を横断して状況を共有します
• ユーザーがより大きな計画パケットを求めない限り、全体をおおむね 450～700 語未満に収めます

例

例 1：コンセプトから Steam デモまで

入力

3 人の Unity チームで、協力型サバイバルゲームを開発しています。大まかなメカニクスのメモとプロトタイプがあり、8 週間後に Steam デモを公開したいと考えています。bmad-gds を使ってください。

出力の概要

• 主なモード：concept-to-milestone
• 次に推奨する成果物：milestone-brief
• 優先して決める内容は、デモで味わえる体験、スコープの削減、1 つのプレイ可能なループ、テストの頻度
• 専門チームへの引き継ぎは、マイルストーンブリーフの確定後に限り、task-planning を指示する場合があります

例 2：プレイテストとバグが混在

入力

Discord のフィードバック、バグ一覧、Next Fest の日程があります。プレイヤーは序盤で混乱しており、最新ビルドにはパッケージング上の問題も 2 件あります。

出力の概要

• 主なモード：reprioritization
• 次に推奨する成果物：reprioritization brief
• game-demo-feedback-triage にフィードバックのパケットを渡します
• game-build-log-triage にパッケージングの失敗を渡します
• 調整ブリーフでは、両方の作業を Next Fest のマイルストーンに結び付けます

例 3：ビルドの問題のみ

入力

Unreal の CI ビルドがパッケージング中に失敗します。助けてください。

出力の概要

• メインのスキルとして bmad-gds にとどまらないでください
• 簡潔な specialist-routing brief を返します
• 必要なログ／ビルドのパケットを具体的に示し、game-build-log-triage に振り分けます

ベストプラクティス

1. ファンタジーのスタジオシミュレーターではなく、プロデューサーのように振る舞います — 曖昧さを、次に役立つ 1 つの成果物へと変換します。
2. 1 回の実行につき主なモードは 1 つにします — コンセプト作成、ローンチ運用、プレイテストのトリアージ、ログのデバッグを混在させると、出力の質が下がります。
3. パケットの大半がフィードバック、ログ、パフォーマンス、ストアページ運用に関する場合は、積極的に専門スキルへ振り分けます。
4. スコープにかかる圧力を明示します — 小規模なゲームチームは、アイデア不足よりも作業の拡散によって失敗することのほうが多くあります。
5. マイルストーンの文脈を保ちます — ビルドの問題やデザイン変更の重要度は、次の節目がデモ、フェスティバル、ローンチのどれかによって変わります。
6. 再計画のワークフローを優先します — プレイテストやビルドの失敗をきっかけに、チームが計画に戻ることはよくあります。それを通常のこととして扱います。

参考資料

• 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