gate-check

!bash "${CLAUDE_SKILL_DIR}/../../hooks/yaml-helper.sh" resolve_config --keys review_mode,workflow,qa.level,testing.strict,performance.enforce,team.size,project.stage,system_overrides

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

フェーズゲートの検証

このスキルは、プロジェクトが次の開発フェーズに進む準備ができているかを検証します。必須の成果物、品質基準、阻害要因を確認します。

/project-stage-detect とは異なります：このスキルは診断的です（「現在どの段階にいるか？」）。こちらのスキルは処方的です（正式な判定を行い、「次に進む準備ができているか？」を確認します）。

本番開発の各ステージ（7段階）

プロジェクトは次のステージを順に進みます。

1. コンセプト — ブレインストーミング、ゲームコンセプト文書
2. システム設計 — システムのマッピング、GDD の作成
3. 技術的なセットアップ — エンジンの設定、アーキテクチャに関する決定
4. プリプロダクション — プロトタイピング、垂直スライスの検証
5. 本番開発 — 機能開発（エピック／機能／タスクの追跡が有効）
6. 仕上げ — パフォーマンス、プレイテスト、バグ修正
7. リリース — ローンチ準備、認証

ゲートを通過した場合（または、ユーザーが CONCERNS 判定のリスクを明示的に受け入れた場合 — セクション 6）、project.yaml のステージ（project.stage: <new-stage>）を更新するとともに、新しいステージ名を production/stage.txt に書き込みます（1 行のみ。例：Production）。両方に書き込むことで、まだ移行していないフックとの後方互換性を維持します。これにより、ステータス行が直ちに更新されます。

---

1. 引数を解析する

対象フェーズ： $ARGUMENTS から任意の --review <mode> ペアを取り除いたもの（空欄の場合は、現在のステージを自動検出してから次の移行を検証します）。/gate-check --review full ではフェーズ名を指定していません。

注：solo モードでは、ディレクターの起動（CD-PHASE-GATE、TD-PHASE-GATE、PR-PHASE-GATE、AD-PHASE-GATE）はスキップされ、gate-check は成果物の存在確認のみを行います。lean モードでは、フェーズゲートのディレクターも実行されます（フェーズゲートは lean モードの目的です）。実行されるディレクターの数は、後述の workflow で設定します。

workflow（.claude/docs/workflow-modes.md に記載）：

gate-check はプロジェクト全体を対象とするため、ゲート全体の成果物チェックリスト（読み込まれたゲートファイル）にはプロジェクトレベルの workflow を使用し、MVP GDD を検証する際には、システムごとに workflow_overrides.system_overrides.<system> も参照します。上位ティアに固定されたシステムは、プロジェクトレベルのワークフローにかかわらず、ゲートを通過する前にそのティアのセクション数を満たす必要があります（セクション 2b「システムごとのオーバーライド」を参照）。

gate-check は workflow に従いますが、automation の対象外です。 成果物チェックリストはティアごとに変わりますが、協調プロンプトプロトコル（Collaborative Protocol セクション）は常に適用されます。フェーズゲートは意図的に設けられた人間によるチェックポイントであり、自動実行されることはありません。

qa.level：フェーズゲートでのテスト適用を制御します。必要な成果物を制御するのは workflow です。modes.rigor はこの両方をまとめて設定します。テスト適用のみを変更する場合は、qa.level を明示的に設定してください。minimal ではテストゲートは適用されません。テストエビデンスとユニットテストの成果物項目は必須ではなくなり、セクション 3 の testing.strict チェックは何もしません。スモークチェックは緩和されません（セクション 2b）。ただし、このレベルでは /smoke-check がゲームテストなしで実行されるため、自動化された行には WAIVED と表示されます。そのため、ビルドチェック（設定されている場合は commands.smoke、なければ commands.build）と、起動およびクリティカルパスのチェックが最低条件となります。起動されていないビルドは評価対象外であり、テストのないプロジェクトでも合格できます。standard では Logic テストと Integration テストに合格する必要があります。full では、完全なカバレッジチェックと回帰テストスイートが必要です（カバレッジの最小値は、設定されている場合は qa.coverage_minimum に従います）。UI と Visual/Feel ストーリーで必要となる保持済みスクリーンショットはテスト項目ではないため、どの qa.level でも緩和されません（セクション 2b）。

team.size：フェーズゲートで起動されるディレクターの数は変わりません。パネルの規模を決める軸は workflow です（セクション 4b）。この値が影響するのは、各ディレクターのレビューにおけるスペシャリストの詳細度のみです。 individual ではコアスペシャリストセット、small では標準セット、studio ではエンジンのサブスペシャリストが追加されます。ディレクターがスキップされることはありません。ディレクターをスキップするのは review_mode の役割です。review_mode と team.size はどちらも modes.rigor で設定されます。1 つの rigor 選択で両方が設定され、それぞれの軸は明示的に設定されている場合、引き続きその設定が優先されます（full-rigor のプロジェクトには studio セットが適用され、軽いティアには individual が適用されます）。

• 引数ありの場合：/gate-check production — 指定したフェーズに対する準備状況を検証します

• 引数なしの場合：/project-stage-detect と同じヒューリスティックを使って現在のステージを自動検出し、実行前にユーザーに確認します：

  AskUserQuestion を使用します：

  • プロンプト：「検出されたステージ：[current stage]。 [Current] → [Next] の移行ゲートを実行します。よろしいですか？」
  • 選択肢：
    • [A] はい — このゲートを実行する
    • [B] いいえ — 別のゲートを選択する（選択された場合、すべてのゲートの選択肢を一覧表示する 2 つ目のウィジェットを表示します：Concept → Systems Design、Systems Design → Technical Setup、Technical Setup → Pre-Production、Pre-Production → Production、Production → Polish、Polish → Release）

引数が指定されていない場合、この確認手順を省略してはいけません。

---

2. フェーズゲートの定義

各ゲートのチェックリスト（必須成果物、品質チェック、およびワークフローティアによる削減内容）は、それぞれ独自のファイルに記載されています。対象のフェーズ遷移に該当する行だけを読み込み、ほかの行は読み込まないでください。

ゲート	定義ファイル
コンセプト → システム設計	references/gate-systems-design.md
システム設計 → 技術セットアップ	references/gate-technical-setup.md
技術セットアップ → 本番前	references/gate-pre-production.md
本番前 → 本番	references/gate-production.md
本番 → 仕上げ	references/gate-polish.md
仕上げ → リリース	references/gate-release.md

各ファイルには、まず full のベースラインが記載され、その後にそのゲートでの standard と minimal の削減内容が記載されています。セクション1で決定したティアを適用してください。

2b. ワークフローティアの調整

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

3. ゲートチェックの実施

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

4. 共同評価

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

5. 判定の出力

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

6. PASS 時のステージ更新

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

7. 次のステップを示すウィジェット

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

共同作業のプロトコル

このスキルは、共同で設計する原則に従います。

1. まず確認する：すべての成果物と品質ゲートを確認します
2. 不明点を尋ねる：検証できない項目を PASS と決めつけないでください
3. 調査結果を提示する：ステータス付きのチェックリスト全体を示します
4. ユーザーが決定する：判定は推奨事項であり、次に何をするかはユーザーが最終決定します。判定に従うのはステージの書き込みのみです（セクション6）
5. 承認を得る：「このゲートチェックレポートを production/gate-checks/ に書き込んでもよいですか？」
6. 自動修正しない：必須の成果物が欠けている場合は FAIL 判定を報告し、実行すべきスキル（例：「/test-setup を実行してください」）を伝えます。不足しているファイルを作成したり、ゲートを自動的に再実行したりしないでください。PASS にするためにファイルを作成するのは、ゲートの目的に反します。

ユーザーの作業を妨げないでください。判定によって決まるのは、このスキルが新しいステージを書き込むかどうかだけです。CONCERNS の場合、ユーザーは記載されたリスクを明示的に受け入れたうえで先に進むことができ、その内容はレポートに記録されます（セクション6）。FAIL または NOT ASSESSED の場合は、再実行して PASS になるまでステージはそのままですが、それまでユーザーが阻害要因に取り組むことを妨げるものはありません。