Communityコーディング&開発github.com

game-production-pipeline

アイデアからリリース可能なビルドまで、ハードなステージゲートを備えたエンドツーエンドのゲーム制作パイプラインを実行します。単一のドキュメントだけでなく、全体のフローをユーザーが望む場合に使用します。

game-production-pipeline とは?

このスキルは、ゲームプロジェクトをアイデアからリリース可能なビルドに導くための、厳格なステージゲート方式のエンドツーエンドパイプラインを提供します。各フェーズ(ブリーフ、GDD、技術計画、アート/オーディオスペック、プロジェクトテンプレートからのビルド、QA、リリース計画)には明確な成果物とゲートがあり、飛ばしは許可されません。Cocos、Unity、Godotなどの主要なゲームエンジンをサポートし、マイルストーンの追跡、アセット生成と検証、ビルドチェックのためのスクリプト/ツールを提供します。このパイプラインは、垂直スライスを作成することで中核となるループを早期に検証し、スプリントサイクルを利用して反復的な開発を可能にし、最終的なレビュー(アート、オーディオの圧縮、アセットマニフェストの検証など)を実施してからリリースに進みます。また、実際のビルド実行、スクリーンショットによる証拠、コードに含まれるTODOの完了によるゲート通過など、複数のチェックポイントを強制し、単なるドキュメントの完成を防ぎます。

対応~Claude Code✓Codex CLI~Cursor
npx skills add https://github.com/NextAgentX/omni-game-studio-codex/tree/HEAD/marketplace/plugins/omni-game-studio/skills/game-production-pipeline

Installed? Explore more コーディング&開発 skills: steipete/bluebubbles, steipete/eightctl, steipete/blucli · View all 6 →

お気に入りのAIに質問する

このエージェントスキルを事前に読み込んだ状態で新しいチャットを開きます。

ドキュメント

エンドツーエンドゲームパイプライン

アイデアをビルド可能なプロジェクト+リリース計画にまで推進します。各段階には固定の成果物、固定パス、実行可能なゲートがあり、段階のスキップは許可されません。

以下のロールはオプションの分業です。現在の環境がサポートし、委任が許可されている場合のみ使用します。それ以外の場合は現在のアシスタントが直接完了します。ユーザーの実際の承認とプロジェクト段階に応じて作業範囲を選択します。ステータススクリプトはドキュメントのタイトルとTODOのみをチェックし、リソース、実際のビルド、実機検証は自動チェックしません。これらは個別に実行し、結果を記録する必要があります。

制作の5フェーズ、G1~G5マイルストーン、スプリントサイクル、チーム規模の調整については、references/production-cycle.mdを参照してください。以下の表の7つのフェーズは、ドキュメント成果物のサブゲートであり、制作マイルストーンとは一対一対応ではありません。

フェーズと成果物

フェーズ成果物担当ロール
briefdocs/00-brief.md プロジェクトカードプロデューサー(あなた自身)
gdddocs/01-gdd.mdgame-narrative-designer
techdocs/02-tech.mdcocos-engineer、unity-engineer、または godot-engineer
artdocs/03-art.md + docs/art-style-bible.md + 正式アート + assets/manifest.jsongame-art-director
audiodocs/04-audio.md + 正式オーディオgame-audio-designer
qadocs/05-qa.mdgame-qa-engineer
releasedocs/06-release.mdgame-release-operator

スケルトンはすべてプラグインの templates/docs/ にあり、プロジェクトの docs/ にコピーしてから記入します。スケルトン内の [TODO] を記入し終えない限り、ゲートは通過できません。

ツール(プラグイン付属、Python で直接呼び出し)

スクリプトディレクトリ = 本プラグインのルート下の scripts/。絶対パスが不明な場合は、まず codex plugin list でプラグインパスを確認します。

用途コマンド
状態の初期化python scripts/omni_state.py init --root . --engine godot --platforms web,android
フェーズ進捗の確認python scripts/omni_state.py status --root .
単一フェーズの検証python scripts/omni_state.py check --root . --stage gdd
フェーズの進行(ゲート付き)python scripts/omni_state.py advance --root .
プレースホルダアートの生成(パイプライン検証用)python scripts/gen_placeholder_art.py --manifest assets/manifest.json --root .
制作ロードマップtemplates/docs/07-production-roadmap.md を docs/ にコピー
スプリント計画と振り返りtemplates/docs/08-sprint-review.md をコピーし、各ラウンドで統合バージョン、テスト、フィードバックを記録
ゲートレビューtemplates/docs/09-milestones.md をコピーし、G1~G5 とリリース後の運用レビューを記録
正式アートの後処理python scripts/process_art.py --in raw/x.png --out assets/art/x.png --size 256x64 --key-color "#FFFFFF" --check-nine --nine-slice 24
AIアニメーションのフレーム分割python scripts/split_sprite_sheet.py --input raw/sheet.png --cols 4 --rows 2 --fps 12 --loop --out-dir assets/animation/run --backup-dir doc/temp/run-frames
AI画像 / GIFpython scripts/gen_ai_image.py --prompt "single game icon" --format png --out assets/art/icon.png --backup-dir doc/temp --dry-run
AI効果音python scripts/gen_ai_audio.py sfx --prompt "short sci-fi pickup" --duration 1 --out assets/audio/pickup.mp3
AI音楽python scripts/gen_ai_audio.py music --prompt "gentle space exploration" --duration 30 --instrumental --out assets/audio/main.mp3
BGM生成(チップチューン)python scripts/gen_music.py --style upbeat --out assets/audio/bgm_main.wav --tempo 132 --bars 16
効果音合成python scripts/gen_sfx.py --preset hit --out assets/audio/sfx_hit.wav
オーディオ圧縮計算python scripts/compress_audio.py --dir assets/audio --check
アトラスパックpython scripts/pack_atlas.py --input assets/art/ui --out-sheet assets/art/ui_atlas.png --out-data assets/art/ui_atlas.json
アセットマニフェスト検証python scripts/validate_assets.py --manifest assets/manifest.json --root .
リリース前最終チェックpython scripts/validate_assets.py --manifest assets/manifest.json --final --strict-license
ビルドチェック/検証python scripts/build_check.py --project . → --run を追加して実際にビルド

実行順序

0. プロジェクトスケルトンのセットアップ

cp -r <plugin>/templates/godot4/* .        # または unity / cocos3
mkdir -p docs assets/art assets/audio doc/temp
cp <plugin>/templates/docs/*.md docs/
cp <plugin>/templates/assets-manifest.json assets/manifest.json
python scripts/omni_state.py init --root . --engine godot --platforms web,android
python scripts/omni_state.py checkpoint --root . --task "プロジェクト開始" --next "briefを書く"

作業を始める前に .omni/active.md(存在する場合)を読んでください。前のセッションで残した現在のタスクと課題が記録されており、圧縮後やセッションの切り替え後には会話よりも信頼性が高いです。

3つのテンプレートは成熟度が異なるため、ユーザーに正確に伝える必要があります:

テンプレート状態必要な手動手順
godot4そのまま実行可能(インポート+メインシーン実行を確認済み)なし
unity開くことは可能、シーンの生成が必要メニュー Tools ▸ Omni ▸ Create Main Scene
cocos3コードと設定は準備完了新しいシーンを作成 → GameRoot を Canvas にアタッチ → 開始シーンとして設定

1. プロジェクト開始とコンセプト(G1)

5つの質問を明確にします: コア体験、プラットフォームの優先順位、MVP範囲、収益化とコンプライアンス、既存アセットとエンジン。docs/00-brief.md と docs/01-gdd.md を記入し、検証すべき仮説と Go / No-Go の決定を記録します。予算とマイルストーンはチーム規模に基づいて見積もり、不確実性を明記します。

2. gdd

game-narrative-designer を派遣します。要件: 数値は具体的な値を指定し、各項目は検証可能にし、「エンジン能力に関する要件」を別途記載します。記入後 advance を実行。

3. プレプロダクションと垂直スライス(G2)

エンジンに応じて cocos-engineer、unity-engineer、または godot-engineer を派遣します。要件: まずプロファイリングデータを提供し、その後最適化を提供します。プラットフォーム別のビルド設定は、テクスチャフォーマットとバンドル分割戦略まで具体的にします。早期にプレイ可能なプロトタイプを実装してコアループを検証します。

4. art(正式アセットの作成)

game-art-director を派遣して docs/03-art.md と assets/manifest.json を出力し、game-art-production スキルに従って実行します:

  1. まずスタイルバイブル docs/art-style-bible.md を作成: 固定のスタイルアンカーテキスト + カラーパレット + 禁止事項
  2. アセットを1つずつ生成: 現在のセッションの画像ツールまたは設定済みのAI画像APIを呼び出し、必要に応じてバリエーションを生成。透明背景が必要な場合は透明出力を要求し、プロジェクトの画像バックアップルールに従います。アニメーションは game-animation-production に従ってGIFまたはスプライトシートを生成し、フレーム分割をチェックします。
  3. 仕様に合わせて後処理:
python scripts/process_art.py --in raw/btn_raw.png --out assets/art/ui/ui_btn_primary.png \
  --size 256x64 --mode fit --key-color "#FFFFFF" --key-tolerance 14 \
  --nine-slice 24 --check-nine
  1. マニフェストに登録: tier: "final" + source + license + commercial_ok + ai_generated
  2. 最終チェック: validate_assets.py --final --strict-license

G2の前に、範囲は小さいが完全な垂直スライスを1つ作成し、プログラム、企画、アート、オーディオをターゲットエンジンに統合します。実際に画質、アセットパイプライン、ビルド、パフォーマンスをテストします。スライスによって、アプローチが再現可能でコストが許容範囲内であることが証明されるまでは、デモに基づいて量産スケジュールを計画してはいけません。プラグイン内のステータススクリプトはドキュメントのみをチェックし、このゲートを自動検証することはありません。

5. オーディオ制作

game-audio-designer を派遣して docs/04-audio.md を出力し、game-audio-production スキルに従ってルートを選択します:

  • ルート A(AI生成): 現在利用可能なオーディオ生成ツールを優先的に使用。または gen_ai_audio.py を使用して ElevenLabs API に接続。詳細は game-audio-production を参照。サービスのキー、権限、課金、ライセンスは事前に明確にしておく必要があります。
  • ルート B(8-bit、オフラインでコストゼロ):
python scripts/gen_music.py --style upbeat --out assets/audio/bgm_main.wav --tempo 132 --bars 16
python scripts/gen_sfx.py --list
python scripts/gen_sfx.py --preset hit --out assets/audio/sfx_hit.wav
  • 圧縮は必須: python scripts/compress_audio.py --dir assets/audio --bitrate 96k。ffmpegがない場合は、スクリプトの指示に従い、エンジンインポート時の圧縮(Godot QOA / Unity Vorbis / Cocos mp3-ogg)を使用します。
  • プラットフォームの違いを必ず記載: ミニゲームではインタラクション後の再生が必要、iOSのミュートボタン、Webの自動再生ポリシーなど。

量産(G3)とスプリントサイクル

G2通過後にのみ、垂直スライスの実際の生産能力に基づいて量産を計画します。docs/07-production-roadmap.md を記入。各ラウンドで企画、プログラム、アート、オーディオのバックログから検証可能な目標を1つ選択し、docs/08-sprint-review.md を使用して範囲、責任者、統合ビルド、テスト、フィードバック、振り返りを記録します。サイクルはチームの能力に応じて決定し、通常2〜4週間。小規模チームではさらに短くすることも可能。各ラウンドは実際にプレイ可能なバージョンでレビューし、失敗した、または統合されていない作業は明確にマークします。

6. テストと磨き込み(G4 / G5)

game-qa-engineer を派遣してテスト計画を作成。Alpha 後は Beta としてコンテンツをロックし、デフォルトで新機能の追加を停止します。どうしても機能を追加する必要がある場合は、工数、テスト範囲、ゲートへの影響を記録し、再レビューを実施します。Gold の準備の前に必ず実際にビルドを実行し、さらに画面を確認してください:

python scripts/build_check.py --project .                            # まずコマンドを確認
python scripts/build_check.py --project . --run --capture g4-beta     # ビルド + 起動 + スクリーンショット
python scripts/omni_state.py check --root . --stage qa --evidence     # ドキュメント + 証拠を一緒に検証
python scripts/omni_state.py advance --root . --to release            # 証拠がないとブロックされる

スクリーンショットは docs/qa/evidence/<名前>/ に保存され、receipt.json がカバーするファイルの sha256 を記録します。その後、いずれかのファイルが変更されると、この証拠は期限切れとして表示されます。期限切れのスクリーンショットは証拠として扱われず、再取得が必要です。

パースが通っても起動するとは限らず、起動しても表示が正しいとは限りません。文字が色ブロックにはみ出したり、パネルがはみ出したり、要素が表示されなかったりするのは、画像を見て初めてわかります。Unity と Cocos には組み込みの無人スクリーンショット機能がないため、スクリプトは正直に NOT ASSESSED を返します。その場合は --capture-cmd でコマンドを指定するか、「画面を確認していません」と明言してください。通過として扱ってはいけません。どうしても --no-evidence で先に進める必要がある場合は、納品時に確認していないことを明記しなければなりません。

ビルドが失敗した場合は、ログをそのまま該当のエンジニアに渡し、自分で推測しないでください。実際のテスト、プラットフォーム互換性、およびリリース候補パッケージの証拠を記録し、責任者を招待してレビューしてから Gold / Release を確定します。ドキュメントの advance は Alpha、Beta、Gold、またはリリース署名を自動的に通過させません。

docs/09-milestones.md を使用して、G1~G5 の責任者、証拠パス、決定事項を記録します。Alpha = 機能完全、Beta = コンテンツロック、Gold = ターゲットプラットフォームのリリース候補がレビューに合格。これらのステータスは実際の証拠に基づいて人間が確認する必要があり、ドキュメントのフェーズから推測することはできません。

7. リリースと運用

game-release-operator を派遣して docs/06-release.md を作成します。すべてのプラットフォームの数値には「公式最新情報を確認」の注記と、再確認可能なリンクを付けます。

リリース後は、本番環境の問題、クラッシュ/ビジネス指標、ユーザーフィードバック、ホットフィックスの状況を記録し、次期バージョンのバックログとロードマップに反映します。必要に応じて次のスプリントサイクルを開始します。done は今回の成果物が完了したことを示すだけで、運用を停止することを意味しません。

ユーザーへの納品時

## 現在のフェーズ
state.json 内の stage + ゲートステータス

## 作成済み成果物
docs/ と assets/ のリスト、まだ placeholder の数を明記

## ビルドと証拠
build_check の結果: 成功 / 失敗 / 未実行。スクリーンショットの有無、カバーファイル、有効期限切れかどうか

## 未完了の実際のギャップ
まだ人間が行う必要があることを明確に説明

鉄則

  1. フェーズのスキップ禁止: advance がブロックします。迂回しないでください。迂回した納品は信頼できません。
  2. ドキュメントは終点ではない: tech フェーズ以降は、必ず実際にコードとリソースファイルを生成する必要があります。ドキュメントだけでは完了とはみなされません。
  3. ビルドは必ず実際に実行: qa フェーズでビルド結果がないまま release に進むことは許可されません。ステータススクリプトは自動的にブロックしないため、人間が確認する必要があります。
  4. draft は完了ではない: tier: "draft" のリソースはリリースに含めてはいけません。--final 最終チェックがブロックします。納品時には、draft がいくつ残っているかを明確に伝える必要があります。
  5. 数値には出典を: パッケージサイズ上限、エンジン能力などは、すべてバージョンと確認方法を明記します。
  6. 毎ラウンドのスプリントでプレイ可能なビルドを納品: タスク完了数では、ビルド、テスト、レビューの代わりにはなりません。
  7. ゲートはレビュー証拠を基準とする: omni_state.py はドキュメントのタイトルとTODOのみをチェックし、ゲームプレイ、ビルド、デバイス、リリース承認を自動検証できません。
  8. 成果物が説明より優先: 派遣したロールがファイルを作成したと主張した場合、そのパスが存在することを検証します。存在しなければ PHASE FAILED です。進行せず、完了としてまとめないでください。流暢な「これから…」は証拠ではありません。ディスク上のファイルこそが証拠です。
  9. qa 以降は必ずスクリーンショットが必要: docs/qa/evidence/ 内の有効なスクリーンショットなしでは release に進めません。advance がブロックします。NOT ASSESSED は合格ではありません。

このパイプラインでできないこと

  • 3Dモデルとボーンアニメーション: 本パイプラインは2Dに焦点を当てています。AIによるフレームごとの結果は確認が必要であり、修正が必要な場合があります。
  • AI音楽と効果音: 現在利用可能な生成ツール、またはアクセス権限のある外部サービスが必要です。プログラムによる合成はAI生成とは同等ではありません。
  • 商用フォント: OFLオープンソースフォントのみ使用可能。商用フォントはユーザーが自らライセンスを購入する必要があります。
  • あなたの代わりに署名、アップロード、審査通過: チェックリストとスケジュールを提供することはできますが、バックエンド操作を代行することはできません。
  • 実機互換性検証: 実際のデバイスが必要です。
  • コードにバグがないことの保証: ビルドが通っても機能が正しいとは限らず、機能が正しくても楽しいとは限りません。

Individual skills in this repo

This repo contains 1 individual skill — each has its own dedicated page.

関連スキル