make-game

ゲーム制作

ユーザーと一緒にビデオゲームを制作する際は、用意されているスキル、パイプライン、コマンドを参照して、ゲーム開発に最適なパイプラインを構築できるよう支援してください。

ユーザーの依頼内容、現在のコードベース、開発段階に基づいて、依頼を完了するためにユーザーと進める適切な手順を選択してください。

使用するタイミング

以下の場合にこのスキルを使用します。

• ユーザーがゲームのアイデアを考えている、または説明している場合（プロジェクトディレクトリは不要です。アイデア段階があるのは、まさにこのためです）
• 現在の作業ディレクトリがゲームプロジェクトの場合（docs/、ソースファイル、または Phaser/Three.js が設定された package.json、Unity の Assets/、Godot の project.godot などのエンジン設定ファイルがある）
• ユーザーがゲームプレイ機能の追加、ゲームプレイのバグ修正、アセット制作、またはゲームデザインの反復を希望している場合

以下の場合はこのスキルを使用しないでください。

• ユーザーの依頼がゲーム開発と無関係の場合（一般的なウェブアプリ、CLI ツール、ライブラリ、インフラストラクチャ、データ作業など）
• ユーザーがゲーム以外の成果物を明示的に求めている場合（例：「チャットアプリを作って」）
• ユーザーがツイート、ニュース記事、または短いプロンプトをもとに、マイルストーン計画なしで、1回のセッションで最初から最後まで完成する一発勝負のバイラルゲームを希望している場合は、代わりに /viral-game を使用します。このパイプラインは独自の方針を持ち（Phaser/Three.js、here.now、Play.fun）、約10分でデプロイできることと引き換えに、このスキルの計画の厳密さを省いています。/viral-game のセッションが大きくなり、ユーザーがマイルストーン、ADR、長期的な反復を求め始めた場合は、このスキルに戻ってください。

目次

1. ルール
2. フェーズ
3. マイルストーン
4. 重要なファイル
5. テンプレート
6. サブパイプライン
7. その他のスキル

1. ルール

• 計画より先にコードを書かないでください。 docs/gameplan.md が存在しない場合は、ソースファイルの作成、エンジンのスキャフォルダーの実行、依存関係のインストールなど、コードに手を加える前に、アイデアフェーズのパイプラインを最後まで実行する必要があります。ゲームプラン、docs/tech.md、ADR-0001 を作成し、ユーザーの確認を得てください。詳細に見えるユーザープロンプトも、アイデアフェーズでの質問の代わりにはなりません。たとえユーザーが「ピクセルアートのシェーダーを使った3Dレースゲーム」と言っても、ゲームプレイのループ、勝利条件、操作方法、スコープ、目標セッション時間はまだ分かりません。これらを即興で決めることが、後のリファクタリングを招く最大の原因です。これは厳格な停止条件として扱ってください。ユーザーが承認したゲームプランがないままプロジェクトをスキャフォールドしようとしていることに気づいたら、作業を止め、まずアイデアフェーズを実行してください。idea.mdの確認質問チェックリストが最低基準です。プロンプトが「明確そう」という理由で項目を省略しないでください。
• 既存のプロジェクトディレクトリでセッションを開始する際は、必ず最初にセッション開始サブパイプラインを実行してください。コンテキスト（docs/STATE.md、docs/gameplan.md、docs/tech.md、マイルストーン）を復元し、現在のフェーズを特定して、次のステップをユーザーに確認します。プロジェクトディレクトリがまだない場合（アイデアフェーズから始まる新規の会話）に限り、省略できます。
• ユーザーに質問する際は、AskUserQuestion ツールを使用してください。複数の選択肢を提示し、ユーザーが独自の回答も入力できるようにするのが理想的です。
  • 質問は焦点を絞り、明確かつ詳細にしてください。考えられる妥当な回答がある場合は、ユーザー向けの選択肢として提示してください。そうすれば、ユーザー自身で解決策を考えたい場合にも、提示した選択肢を参考にしながら最適な回答を組み立てられます。
  • ユーザーについての過去の記憶や経験がある場合は、技術的な能力や専門知識のレベルを見極め、そのレベルに合わせて質問を調整してください。技術に詳しくないようであれば、理解しやすい聞き方にしてください。より高度な話題について質問する際は、ユーザーが何も分からないまま答えることのないよう、質問とあわせて説明を提示してください。
• コードベースの現在の状態、ユーザーの依頼、ゲームエンジンやアートスタイルなどのアーキテクチャ上の決定に基づいて、ゲームが開発のどのフェーズにあるかを判断し、次のセクションで説明する該当フェーズのパイプラインから着手してください。
• 新規プロジェクトをスキャフォールドする際は、プロジェクトのセットアップ方法について、学習時に得た知識をそのまま使わないでください。学習後に変更されている可能性があります。ドキュメントの最新版を探すか、ユーザーにリンクを提示してもらってください。使用するフレームワークやライブラリの最新のインストール手順を読み、現在のスタックとプロジェクトのセットアップに従ってください。
• 手作業でファイルを作成するより、必ずエンジンまたはフレームワークの公式スキャフォールドコマンドを優先してください。 例：Phaser では npm create @phaserjs/game@latest、Three.js では npm create vite@latest（続けて npm install three）、Unity では -createProject CLI（Windows の場合は "C:\Program Files\Unity\Hub\Editor\<version>\Editor\Unity.exe" -createProject "<path>" -quit、macOS の場合は /Applications/Unity/Hub/Editor/<version>/Unity.app/Contents/MacOS/Unity -createProject <path> -quit）または Unity Hub の「New project」ダイアログを使用します。Godot と Unreal の場合は、エディターでプロジェクトを作成するようユーザーに依頼してください。手書きの package.json、バンドラー設定、エンジンのエントリーポイントは、2つ目のライブラリを追加した時点でバージョンの不一致を引き起こします。作成しないでください。公式スキャフォルダーが見つからず、ユーザーからも案内がない場合は、セットアップを即興で行うのではなく、ユーザー自身にプロジェクトの初期化を依頼し、準備ができたらセッションを再開してください。詳細なガイダンスとエンジン別の例は、scaffold.mdのステップ3を参照してください。
• ユーザーがゲームプレイのコアループやアーキテクチャなどに大きな変更を加える場合は、docs/ フォルダー内の関連ドキュメントを更新して変更内容を反映してください。大きなアーキテクチャ上の決定については、後で変更履歴とともに参照できるよう、docs/architectural-decisions に記録してください。変更履歴には変更理由を含め、詳細に記述する必要があります。また、これらの決定を行った際には、変更の根拠となる AD ドキュメントへの参照を含めて、docs/gameplan.md も更新してください。
• 開発フェーズでは、コードを変更するたびに必ずlive-iterate サブパイプラインを実行してください。 これは、コンソール → render_game_to_text() → advanceTime() →（視覚的な変更がある場合は）スクリーンショット → ユーザー確認、という正規のリアルタイム検証ループです。変更は、反復検証が完了するまで「完了」とはみなされません。
• 実装コードを書く前に、失敗するテストを書いてください。 テストは受け入れ基準を実行可能な形にしたものです。現在のマイルストーンで検証可能な受け入れ基準（AC）にはそれぞれ少なくとも1つ、それを検証するテストを用意してください。テストは先に書き、実装コードに触れる前に、正しい理由で失敗することを確認してください。ゲームプレイのロジックとビジュアルのベースラインには（/qa-gameに従って）Playwright を、純粋なヘルパー関数には単体テストを、マルチプレイヤーには複数クライアントの Playwright を使用してください。意味のある形で検証できない視覚効果や操作感の AC（演出、磨き込みなど）は、マイルストーンに**「ユーザーのプレイテストで検証」**と明記してください。黙って省略してはいけません。AC が曖昧でテストを作成できない場合は、検証可能な形にするため、先にプレイテスト／再現を実行してください。失敗するテストを通すために緩和することは禁止です。実装を修正するか、マイルストーンの AC を更新してテストを書き直してください。
• すべてのセッションで、1つの機能に集中してください。 ユーザーの依頼に複数の独立した機能や変更が含まれる場合は、コーディングを始める前にスコープ整理サブパイプラインを実行してください。依頼内容を列挙し、後回しにする項目を docs/backlog.md に記録したうえで、AskUserQuestion を使って、重要であり、1回の集中したセッションでリリースしやすい項目の中から最適な1つを選んでください。複数の無関係な機能を一度に進めると、コンテキストがぶれ、反復検証で何の機能が壊れたのか分かりにくくなり、マイルストーンの確認も中途半端になります。ユーザーが明確に希望し、そのトレードオフを了承した場合に限り、機能をまとめて進めることができます。
• ユーザーが言及した内容を、黙って取りこぼしてはいけません。 セッション中に機能、磨き込み項目、リファクタリング、未解決の質問が出てきてもスコープ外である場合は、templates/backlog.mdの形式に従って docs/backlog.md に追記してください。「後で対応する」項目を記録する場所はバックログのみです。今後の作業を覚えておくために、会話の記憶や docs/STATE.md のメモに頼らないでください。開発パイプラインとマイルストーン計画の両方で、このファイルを確認します。
• ユーザーがロードマップを必要としている場合は、即興で作成せず、マイルストーン計画を実行してください。 ユーザーが「次は何をするのか？」「どのマイルストーンが必要か？」「リリースまでに何が残っているか？」と尋ねた場合、または未完了のマイルストーンがなくなった時点で docs/gameplan.md の内容が満たされていない場合は、ゲームプランと現在の状態＋バックログとの差分から、次の1〜3件のマイルストーンを導き出してください。アーキテクチャを可能にする項目を優先し、マイルストーンファイルを書く前に AskUserQuestion で確認してください。提案は最大3件にしてください。次のマイルストーンが完了すれば、その先のマイルストーンは変わる可能性があるため、先まで約束しすぎると計画が無駄になります。終了条件を「ユーザーが X を実行すると、Y が確認できる」の形で記述できないマイルストーンは、決して提案しないでください。曖昧な目標は曖昧なマイルストーンにつながります。
• アイデアフェーズを終えたすべてのプロジェクトでは、プロジェクトのルートに AGENTS.md が存在する必要があります。 これは、スキル自体が自動的に適用されない場合でも、以後のセッションでこのスキルのルールに従うことを保証する、ツールをまたいで常に読み込まれる強制適用ファイルです。アイデアフェーズ後のプロジェクトに AGENTS.md がない場合は、ほかの作業を続ける前にagents-bootstrap サブパイプラインを実行してください。
• プロジェクトの現在のフェーズに基づき、各フェーズで定められたパイプラインに必ず従ってください。

最小限のドキュメントモード

ユーザーがドキュメント作成の負担に異議を唱えた場合（「とにかくコードを書いて」「ドキュメントは省略して」など）、ドキュメントのルールを黙って放棄してはいけません。まさにそれが、セッションをまたいだ一貫性の崩れにつながるからです。代わりに、最小限のドキュメントモードに切り替え、その旨をユーザーに伝えます。

• マイルストーンドキュメント全体の代わりに、1行のマイルストーン項目（タイトル＋1行の受け入れ基準）を使ってもかまいません。
• docs/STATE.md の更新は引き続き必須です。1行だけでも更新してください。
• docs/gameplan.md と docs/tech.md がまだ存在しない場合は、引き続き作成が必須です（そうしないと、次のセッションで信頼できる情報源がなくなります）。
• ADRを延期できるのは、変更がトップレベルのアーキテクチャ上の決定ではない場合に限ります。エンジン、言語、スタックに関するADRは省略できません。

目的はドキュメントを簡潔にすることであり、削除することではありません。ユーザーがドキュメントを一切作成したくない場合は、別のツールを求めているということです。状態を劣化させたままこのスキルを実行するのではなく、その旨を正直に伝えてください。

2. フェーズ

アイデアフェーズ

ユーザーにはゲームのアイデアがありますが、それに関するコードベースやドキュメントはまだありません。コンセプトアートや、考案した世界設定があるかもしれません。このフェーズでは、ユーザーがゲームのアイデアやゲームプレイループをブレインストーミングし、発展させ、練り上げるのを支援します。

パイプライン

アイデアフェーズのパイプラインについては、このドキュメントを参照してください。その手順に従ってください。

フェーズ完了の要件

• プロジェクトディレクトリに docs/ フォルダーが作成されている
• ユーザーとのブレインストーミングや計画に基づき、詳細なゲーム情報を記載した docs/gameplan.md が作成されている
• 使用する各ライブラリ／フレームワークの説明を含む、技術スタックの詳細を記載した docs/tech.md が作成されている
• docs/architectural-decisions/ フォルダーが存在し、エンジン、言語、アートスタイルに関する決定を確定する 0001-engine-and-stack.md がある

プロジェクトディレクトリがまだ作成されていない場合は、新しいプロジェクトディレクトリを作成し、その中にフォルダーやファイルを作成してよいか、ユーザーに許可を求めてください。次のフェーズに進む前に、ユーザーにプロジェクトディレクトリで新しいセッションを開始してもらい、そこを現在の作業ディレクトリにしてください。新しいセッション用の再開プロンプトを提示してください。

スキャフォールドフェーズ

ゲームのアイデアが固まったら、ユーザーがプロジェクトをスキャフォールドするのを支援します。プロジェクトのスキャフォールドに使う方法は、プロジェクトの技術スタックによって異なります。

パイプライン

スキャフォールドフェーズのパイプラインについては、このドキュメントを参照してください。その手順に従ってください。

フェーズ完了の要件

• プロジェクトディレクトリに初期プロジェクトファイルが存在する
• 依存関係がインストールされている
• ゲームがブラウザー（またはエンジンのプレイモード）で起動し、初期シーンが描画され、コンソールにエラーがない
• プロジェクトのルートに AGENTS.md と CLAUDE.md が存在する（agents-bootstrap サブパイプラインを参照）
• 今後のエージェントが、追加のセットアップなしに、よく知られた1つのコマンド（npm run dev またはエンジンに相当するコマンド）でプロジェクトを実行できる

「コンパイルエラーがない」だけでは不十分です。プロジェクトは正常にビルドできても、起動時にクラッシュすることがよくあります。このフェーズの完了を宣言する前に、scaffold.md のスモークテストを必ず実施してください。

開発フェーズ

このフェーズは最も長く、終わりがない可能性もあります。ここでのパイプラインは非常に重要で、プロジェクト内のあらゆる機能開発に適用してください。ユーザーからバグ修正を頼まれた場合は、バグを素早く修正することに集中するため、このパイプラインを後回しにしてもかまいません。

パイプライン

開発フェーズのパイプラインについては、このドキュメントを参照してください。その手順に従ってください。

このフェーズは進行中で、終わりがない可能性もあるため、フェーズ完了の要件はありません。パイプラインのドキュメントには、マイルストーンとその要件および受け入れ基準が記載されています。

3. マイルストーン

開発フェーズのパイプラインでは、規模の大きなさまざまなタスクの信頼できる情報源として、マイルストーンを使用します。これらのマイルストーンは docs/milestones/*.md にあります。

各マイルストーンには、以下の内容を含める必要があります。ただし、これらに限定されません。

• Objective：マイルストーンの主な目標と、実施する変更内容の詳細な説明。
• Scope：タスクの対象となる変更の一覧。
• Acceptance Criteria：マイルストーンを完了としてマークする前に検証・完了する必要があるサブタスクのチェックボックス一覧。
• Exit Condition：マイルストーンを完了としてマークするために、ユーザーが確認する必要がある最終条件。

大規模な変更は、すべてマイルストーンのドキュメントに基づいて進めるか、既存のマイルストーンのドキュメントに基づいていることを確認しなければなりません。例外は、過度な計画を必要としない小さな変更、一般的なバグ修正、またはユーザーから依頼されたフォローアップの変更のみです。ただし、作業中のマイルストーンの範囲内である必要があります。

マイルストーンを設けるほどではない小さな機能追加や変更は、先送りしてもかまいません。将来重要になる変更であれば、マイルストーンに記録する必要があります。このようなケースでは、マイルストーンのドキュメントを改訂してもかまいません。

実装の最後に、マイルストーンのドキュメントが最新の状態に保たれ、AC のチェックボックスにチェックが付いていることを確認してください。そうしないと、マイルストーンが完了しているにもかかわらず、今後のセッションで未完了と判断されます。次に進む前、または完了としてマークする前に、ユーザーが各マイルストーンの Exit Condition をテストするようにしてください。

ルール

1. マイルストーンには順序を付け、それぞれに上記の必須セクションを含める必要があります
2. 作業の提供順序を説明するために必要な、最小限のマイルストーンを選びます
3. アーキテクチャを整える作業は、UX の仕上げより先に行います
4. マイルストーン同士に依存関係がある場合は、どの順序で完了する必要があるかをマイルストーンのドキュメントに記載することが重要です

マイルストーンへの追記と新規作成

セッション中に新しい作業が見つかった場合は、現在のマイルストーンを拡張するか、新しいマイルストーンを作成するかを判断します。

• 現在のマイルストーンに AC を追記する：作業がマイルストーンの既存の目標の範囲内での調整である場合に使用します。たとえば、動作を明確にする、チェックを厳密にする、既存の AC を個別にチェックできる 2 項目に分割する場合です。
• 新しいマイルストーンを作成する：作業が現在の目標の範囲外ではあるものの、プロジェクトには関連している場合に使用します。新しいシステム、新たな機能領域、将来のマイルストーンを可能にするリファクタリングなどが該当します。順序の関係を記録するには、新しいマイルストーンのフロントマターに Depends on: フィールドを使用します。
• フォローアップ課題を作成する（マイルストーンなし）：作業が小規模かつ独立しており、事前に計画する必要がない場合に使用します。誤字、1 行の修正、明白なクリーンアップなどが該当します。ごくわずかな関連作業であれば、現在のマイルストーンに含めてもかまいません。

判断に迷った場合は、現在のマイルストーンを肥大化させるより、新しいマイルストーンを作成してください。肥大化したマイルストーンでは進捗が見えにくくなり、Exit Condition のテストも難しくなります。

4. 重要なファイル

docs/gameplan.md

ゲームとゲームのアイデアに関する主要な信頼できる情報源です。ゲームプレイのループ、ルール、ゲームの主なアイデア、アートスタイルなどが記載されています。

読むタイミング

各セッションの開始時、マイルストーンを読むとき、ユーザーの依頼に関連するゲームの情報を集めるときに読みます。

書き込むタイミング

ユーザーがゲームの動作の変更を希望するときや、ルールが変わるときなどに書き込みます。ゲームがどのように動作すべきかを示す、主要な信頼できる情報源です。

docs/tech.md

技術スタックに関する主要な信頼できる情報源です。

読むタイミング

各セッションの開始時、マイルストーンやアーキテクチャ上の判断を計画するときに読みます。

書き込むタイミング

新しい技術をスタックに追加するときや、使用中の主要なゲームエンジン、ライブラリ、フレームワークを変更するときに書き込みます。

docs/milestones/*.md

最終的にゲームを構築する、さまざまな機能やタスクの詳細なマイルストーンです。

読み込むタイミング

実装に着手する前です。ユーザーからコードベースの変更を依頼されたときです。これまでの作業に関する情報が必要なときはいつでも読み込みます。

書き込むタイミング

コードベースにまだ実装されていない新機能や変更などをユーザーが依頼したときです。ユーザーが古いマイルストーンへの全面的なリファクタリングなどを希望するときです。

ユーザーから明示的な変更依頼があった場合や、受け入れ条件の完了を確認する場合を除き、いったん作成したマイルストーンを更新する必要はありません。

docs/architectural-decisions/*.md

トップレベルのさまざまなアーキテクチャ上の決定を詳述するADRです。作成時はtemplates/adr.mdを使用します。最初のADR（0001）は、エンジン、言語、アートスタイルに関する決定を確定するため、アイデアフェーズの最後に作成します。

docs/backlog.md

ユーザーが言及したものの、その内容を記録したセッションでは対応が先送りされた機能、仕上げ項目、リファクタリング、未解決の質問をすべて記録する、単一ファイルの追記専用カタログです。「後で」対応する項目を記録します。スコープのトリアージで初めて項目が先送りされたときに、templates/backlog.mdから作成します。

昇格した項目にはチェックを付け、引き継ぎ先のマイルストーンへのリンクを記載します。削除はしません。却下した項目には取り消し線を引き、理由を1行で記載します。履歴は重要です。今後のセッションで、何が、いつ、なぜ検討され、先送りまたは却下されたのかを確認する必要があります。

読み込むタイミング

• 新しいマイルストーンを作成する前（開発パイプラインのステップ2）。
• scope-triageのステップ2で、項目の重複を避けるため。
• session-startで、ユーザーが昇格させたい可能性のある項目を提示するため。
• ユーザーから「次は何をする？」と尋ねられ、未完了のマイルストーンに明確な答えがないとき。

書き込むタイミング

• スコープのトリアージで項目を先送りするたび。
• セッション中に機能、仕上げ、リファクタリングの案が出たものの、現在のマイルストーンの範囲外であるたび。
• ユーザーが何気なくアイデアを口にしたとき（「そういえば、いずれは……したい」など）。失われないよう、すぐに記録します。

docs/STATE.md

セッション引き継ぎ用の単一ファイルです。前回のセッションで最後に行った作業、現在のマイルストーン、次に行う具体的なステップを記載します。session-start sub-pipelineで最初に読み込み、進捗があったセッションの終了時に更新します。templates/state.mdを使用します。

読み込むタイミング

既存のプロジェクトでセッションを開始するときは、ほかのドキュメントを読む前に、必ず最初に読み込みます。

書き込むタイミング

コード、ドキュメント、決定事項を変更したセッションの終了時です。1行だけでも、何も書かないよりは適切です。次のセッションに作業を引き継ぐことが目的です。

AGENTS.mdとCLAUDE.md（プロジェクトルート）

セッションをまたぎ、ツールをまたいでルールを適用するためのファイルです。AGENTS.mdは、Cursor、Aider、Codex、Claudeなどのエージェントツールがセッション開始時に無条件で読み込むため、スキルの説明と照合するよりも確実です。CLAUDE.mdはAGENTS.mdへの1行のポインターであり、2つのファイルの内容にずれが生じないようにします。

agents-bootstrap sub-pipelineで、templates/agents.mdを使用して生成します。

読み込むタイミング

AGENTS.mdはほかのエージェントが読み込みます。通常のmake-gameセッションでは、情報源はdocs/にあるため、読む必要はありません。内容のずれを監査するとき、外部のエージェントがルールを無視したとユーザーから報告されたとき、または再生成する前に読み込みます。

書き込むタイミング

• スキャフォールドフェーズの終了時（必須）。
• gameplan.mdとtech.mdが存在する状態で、session-startのドキュメント補完ブランチを実行するとき。
• トップレベルの技術スタックまたはアーキテクチャを変更した後（再生成します）。
• doc-drift auditでAGENTS.mdが古いと指摘されたとき。

AGENTS.mdに記載するアーキテクチャ上のルールはすべて、docs/tech.mdまたはADRにも記載する必要があります。AGENTS.mdは信頼できる情報源であるドキュメントを反映するものであり、それ自体が情報源ではありません。

5. テンプレート

このスキルで作成が必須とされているドキュメント（gameplan.md、tech.md、マイルストーン、ADR、STATE.md）を作成する際は、独自に構成を考えるのではなく、templates/ の構成をコピーしてください。セッションをまたいで構成を一貫させることが、このスキルにおけるドリフトを防ぐ最も効果的な方法です。

6. サブパイプライン

これらのサブパイプラインは、アセットの生成、ロアの構築、ゲームプレイループの構築、リサーチなど、開発中の個別のステップで使用できます。

現在利用可能なサブパイプラインをすべて確認するには、このドキュメントを参照してください。タスクで必要な場合にのみ使用してください。独自の作業パイプラインを始める前に、使用できるサブパイプラインがあるかどうか、必ず確認してください。

7. その他のスキル

プロジェクトにほかのスキルをインストールすると便利な場合があります。game-creator スキルスイートとプラグインには、このスキルと連携できるスキルが多数あります。

開発、計画、アセット生成など、取り組むプロジェクトに応じてプロジェクトディレクトリにインストールできるスキルについては、このドキュメントを参照してください。