prototype

!bash "${CLAUDE_SKILL_DIR}/../../hooks/yaml-helper.sh" resolve_config --keys review_mode,automation,workflow

上記で解決済みです。そのまま使用してください。今回の実行では、--review が review_mode を上書きします。 ブロックがない場合は、.claude/docs/config-resolution.md のデフォルト値を使用します。

プロトタイプ

目的

これはコンセプトのプロトタイプです。次の1つの問いに答えるための、すばやく作って使い捨てるビルドです。 「この核となるアイデアは、実際に操作して楽しいだろうか？」

デフォルトの用途 — /brainstorm と /setup-engine の直後、GDD やアーキテクチャ文書を作成する前に実行します。その判断によって、コンセプトに本格的な設計ドキュメントを作成するだけの価値があるかどうかが決まります。

開発の途中ですか？ 特定のメカニクス、設計変更、技術的な疑問を検証するために、どの段階でも実行できます。--spike を渡すとスパイクモードが有効になります。GDD の事前準備は不要で、フェーズゲートにも影響しない、軽量な約4時間のビルドです。

GDD とアーキテクチャの作成がすでに完了していますか？ Production に進む前にゲームループ全体を検証するには、代わりに /vertical-slice を実行してください。

---

フェーズ1：問いを定義する

今すぐ references/1-question.md を読み、その指示に従ってください — このフェーズの手順はここではなく、そのファイルに記載されています。このフェーズ中に会話が圧縮または再開された場合は、もう一度読み直してください。

フェーズ2：コンセプトのコンテキストを読み込む

今すぐ references/2-load-context.md を読み、その指示に従ってください — このフェーズの手順はここではなく、そのファイルに記載されています。このフェーズ中に会話が圧縮または再開された場合は、もう一度読み直してください。

フェーズ3：プロトタイプの進め方を選ぶ

今すぐ references/3-choose-path.md を読み、その指示に従ってください — このフェーズの手順はここではなく、そのファイルに記載されています。このフェーズ中に会話が圧縮または再開された場合は、もう一度読み直してください。

フェーズ4：プロトタイプを計画する

今すぐ references/4-plan.md を読み、その指示に従ってください — このフェーズの手順はここではなく、そのファイルに記載されています。このフェーズ中に会話が圧縮または再開された場合は、もう一度読み直してください。

フェーズ5：実装する

今すぐ references/5-implement.md を読み、その指示に従ってください — このフェーズの手順はここではなく、そのファイルに記載されています。このフェーズ中に会話が圧縮または再開された場合は、もう一度読み直してください。

フェーズ6：プレイテストの振り返り

今すぐ references/6-debrief.md を読み、その指示に従ってください — このフェーズの手順はここではなく、そのファイルに記載されています。このフェーズ中に会話が圧縮または再開された場合は、もう一度読み直してください。

フェーズ7：プロトタイプレポートを生成する

今すぐ references/7-report.md を読み、その指示に従ってください — このフェーズの手順はここではなく、そのファイルに記載されています。このフェーズ中に会話が圧縮または再開された場合は、もう一度読み直してください。

フェーズ8：クリエイティブディレクターによるレビュー

今すぐ references/8-cd-review.md を読み、その指示に従ってください — このフェーズの手順はここではなく、そのファイルに記載されています。このフェーズ中に会話が圧縮または再開された場合は、もう一度読み直してください。

フェーズ9：概要と次のステップ

今すぐ references/9-summary.md を読み、その指示に従ってください — このフェーズの手順はここではなく、そのファイルに記載されています。このフェーズ中に会話が圧縮または再開された場合は、もう一度読み直してください。

スパイクモード

開始条件： --spike フラグ、またはフェーズ1で「開発途中のスパイク」を選択した場合。

今すぐ references/spike-mode.md を読み、その指示に従ってください — このフェーズの手順はここではなく、そのファイルに記載されています。このフェーズ中に会話が圧縮または再開された場合は、もう一度読み直してください。

重要な制約

• プロトタイプのコードから本番用のソースファイルをインポートしてはいけません
• 本番用のコードからプロトタイプのディレクトリをインポートしてはいけません
• 推奨結果が PROCEED の場合、本番用の実装はゼロから作成します。プロトタイプのコードを本番用にリファクタリングしてはいけません
• 作業時間の上限は厳格に 1 日です（コンセプトのプロトタイプでは、1 つの仕組みをテストします）
• テストする仕組みは 1 つだけです。範囲が広がったら、作業を止めて問いを絞り込みます
• 磨き込みは不要です。メニュー、ゲームオーバー、音楽、UI は、それ自体がテスト対象の仕組みでない限り作成しません
• エンジンの反復作業で 2 時間経っても行き詰まった場合は、問いを捉え直すか、別の方法に切り替えます
• PIVOT が 3 回続いたら、KILL の判断を強制します。 同じコンセプトで 3 回目の PIVOT 判定になった場合、そのコンセプトはうまくいかない可能性があります。「これは適切なアイデアなのか、それともサンクコストの罠にはまっているのか？」と問いかけてください。新しいコンセプトで最初からプロトタイプを作るほうが、行き詰まったコンセプトで 4 回目の反復を行うより、ほとんどの場合よい結果になります。
• 1 つのコンセプトを延々と反復するより、異なるコンセプトのバリエーションを 2～3 個作り、その中から最良のものを選ぶほうが健全な戦略です。プロトタイプ同士の自然選択は、意志の力に勝ります。
• ネットワーク対応／マルチプレイヤーゲーム： ローカルのプロトタイプでは、ネットワーク対応の仕組みの手触りを検証できません。レイテンシーは戦闘、移動、予測の感覚を根本的に変えます。レイテンシー 0ms のローカル環境で動くプロトタイプは、ネットワーク遅延が 80ms の環境ではまったく異なる感触になります。ローカルのプロトタイプは、その仕組みが面白いかどうかの検証に使ってください。実際のネットワーク環境でも心地よく感じることの根拠として使ってはいけません。ネットワーク上での手触りを検証するには、実際のピア、または遅延をシミュレートするツール（例：スロットルツール、ネットワーク状況シミュレーター）が必要です。