vertical-slice

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

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

バーティカルスライス

目的

バーティカルスライスでは、コンセプトプロトタイプとは異なる問いに答えます。 「このゲームループ全体を、予定どおりに、製品品質で構築できるでしょうか？」

標準的な用途 — Pre-Production の後半で、GDD、アーキテクチャ、UX仕様が完成してから実施します。製品に近い品質で作られたビルドで、[開始 → 挑戦 → 解決] の1サイクルを完全に実演します。

ピボット後は？ 以前のバーティカルスライスでPIVOTの判定が出て、GDDとアーキテクチャの修正に戻った場合は、修正後に再検証するためにもう一度実施してください。PROCEEDまたはKILLの判定が出るまで、必要に応じて何度でも実施できます。

次の項目を検証します。

1. パイプライン（チームは実際にこの品質のコンテンツを制作できるか？）
2. 実行可能性（アーキテクチャの決定は、このゲームに適しているか？）
3. 面白さの持続（コンセプトプロトタイプで感じられた面白さは、設計を進めても保たれるか？）
4. 開発速度（完了までにどれだけ時間がかかったか？これが実際の本制作ペースの見積もりになります。）

プロジェクトの初期段階の場合 — まだGDDを作成しておらず、設計に進む価値があるアイデアかどうかを検証したい場合は、代わりに /prototype（コンセプトプロトタイプ）を実施してください。

---

フェーズ1：レビュー方式の解決とコンテキストの読み込み

チェックの手順全体については .claude/docs/director-gates.md を参照してください。個々のゲートの定義は .claude/docs/director-gates/[gate-id].md にあります。起動されたエージェントが自身のゲートファイルを読み込むため、親セッションでは読み込まないでください。

すべての AskUserQuestion 呼び出しは .claude/docs/automation-modes.md に従います （collaborativeでは常に質問 · guidedでは主要な項目のみ · autonomousでは記録して続行； automation_always_ask のカテゴリでは常に質問します）。

設計の意図全体を把握するため、以下のファイルを読み込んでください。各GDD、ADR、control manifestはセクションごとに読み込みます。Grepツール（パターン ^#、contentモード）で必要な見出しを探し、offsetとlimitを指定して該当範囲をReadしてください。

• CLAUDE.md — 技術スタックとエンジン
• design/gdd/game-concept.md — 中核となるファンタジーとゲームの柱（または design/game-brief.md。rigor: minimal の場合に前者に代わる1ページの概要。 ピッチ、中核となるループ、「どのような気持ちになるか」の記述が含まれ、ゲームの柱はありません）
• design/gdd/systems-index.md — MVPシステムと優先順位
• docs/architecture/architecture.md — レイヤー構造
• docs/architecture/control-manifest.md — 実装に関する技術ルール
• スライス対象のシステムに関する主要なGDD

---

フェーズ 2：スライスの範囲と検証の問いを定義する

構築を始める前に、反証可能な検証の問いを定義します。

「プレイヤーは何もない状態から始めて、開発者のガイダンスなしに、[game-concept.md または game-brief.md に記載されたゲームの中核となる体験]を[N]分以内に体験できるか。そして、そのようなループを代表的な品質で[X]日以内に構築できるか？」

どちらの側面も重要です。プレイヤーの体験と、構築の実現可能性です。

スコープの規律：

• すべての中核ループシステムを最低限含めます。1回の[開始 → 課題 → 解決]サイクルを完了するために必要なシステムは、スライスに含める必要があります。
• **洗練された連続したゲームプレイを3～5分間にすることを目標にします。**これは業界標準の垂直スライスの長さです。メカニクスや雰囲気を示すには十分な長さで、代表的な品質で構築するには短い長さです。プレイに5分以上かかるスライスになる場合は、品質ではなくコンテンツを削ります。
• **品質を下げる前に、スコープを削ります。**意図したゲームにまったく似ていない低品質なスライスでは、製品版の開発可能性を検証できません。
• スコープが1～3週間で構築するには大きすぎると感じる場合、スライスの範囲が適切ではありません。構築するには大きすぎるのではなく、一度に証明しようとすることが多すぎるのです。

**スコープクリープへの警告：**垂直スライスは、プリプロダクション段階でスコープクリープのリスクが最も高いタイミングです。機能が「もう少しで完成」と感じられ、「あと1つだけシステムを」追加したくなります。これを避けてください。延長するのではなく、削ります。

構築を始める前にスコープをユーザーに提示し、確認を得ます。

---

フェーズ 3：構築を計画する

箇条書きで以下を定義します。

• 実装するシステム（どのGDDセクションを検証するか）
• 完全なゲームループサイクル（[開始] → [課題] → [解決]を正確に）
• アートとオーディオの品質レベル（プレースホルダーでも問題ありませんが、代表的な品質が望ましいです）
• 検証の問いに対する、具体的で測定可能な成功基準
• 厳守する期限：[X]日。期限を超えた場合は、スコープが不適切だったということです。作業を止めて再評価します。

構築を始める前に、スコープの確認をユーザーに求めます。確認の中でチェックポイントファイルの名前を示します。「この計画をproduction/session-state/active.mdに記録してもよろしいですか？」

確認を得たら、セッションチェックポイントをproduction/session-state/active.mdに記録します（production/session-state/が存在しない場合は作成します）。コンセプト名、検証の問い、対象範囲内のシステム、アートの品質レベル、現在のフェーズ（「フェーズ4 — 実装」）を含めます。構築日の終わりに、完了した内容でこのファイルを更新します。セッションがスライスの途中で終了した場合、これが主な復旧手段になります。数週間にわたるエンジンの構築は、複数のセッションにまたがることになります。

---

フェーズ 4：実装

「prototypes/[concept-name]-vertical-slice/ に垂直スライス用のディレクトリを作成して、実装を開始してもよいですか？」と尋ねます。

承認されたら、ディレクトリを作成します。各ファイルの先頭には、次の内容を記述してください。

[comment] VERTICAL SLICE - NOT FOR PRODUCTION
[comment] Validation Question: [What this build is proving]
[comment] Date: [Current date]

各ファイルのコメント構文で [comment] を記述してください。GDScript（.gd）と Python では #、C#、C++、JavaScript では //、Lua では --、HTML と Markdown では `` を使います。別の言語の構文で記述したヘッダーはラベルではなく、構文解析エラーになります。コメントを記述できないファイル（JSON、エンジンが生成するシーンファイルおよびプロジェクトファイル）は対象外です。

品質基準 — コンセプトプロトタイプより高い品質を目指しますが、製品版レベルではありません。

• docs/architecture/control-manifest.md のアーキテクチャレイヤーに従います
• 命名規則 — project.yaml の naming.* を使用します。キーがない場合、または空の場合（project.yaml に naming ブロックがない場合を含む）は、.claude/docs/technical-preferences.md を使用します
• ゲームプレイの値をハードコードせず、定数または設定ファイルを使用します
• 重要な処理経路では基本的なエラー処理を実装します
• 仮のアートでもかまいませんが、ゲームをよく表すアートを推奨します

複数ターンの反復: 初期ファイルを書き込んだ後、ユーザーにビルドを実行してもらい、確認した内容を報告してもらいます。ゲームループ全体のサイクルを実演できるまで反復します。各ラウンドでは次の手順を行います。

1. ユーザーが実行し、エラーや確認内容を報告します
2. エージェントがエラーを修正するか、システムを調整します
3. ゲームループ全体の［開始 → 課題 → 解決］のサイクルをプレイできるまで繰り返します

サンクコストのチェックポイント（予定スケジュールの3日目）: ゲームループ全体のサイクルをまだ実演できない場合は、作業を止めて再評価します。スコープが大きすぎるか、アーキテクチャ上の前提が誤っています。反復を続けるのではなく、障害となっている点を明確に提示してください。

ゲームループを実演できるようになったら、少なくとも1回はプレイテストを実施します。

プレイテストのヒント: ゲームを見たことがない人（友人、家族、オンラインコミュニティのメンバーなど）にプレイしてもらえる場合は、何も説明せず、黙って観察してください。誘導はしないでください。相手が戸惑う様子から、ゲームだけでは伝わっていないことが分かります。これは自分でテストするよりも、はるかに有益な情報が得られます。

外部のテスターがいない場合: チーム内で交代しましょう。Dev A がシステム X を構築した場合、システム Y については Dev A が初見のテスターになります。2人のチームでも効果的に交代できます。1人で開発している場合は、2～3日離れてから新規プレイヤーのつもりでプレイします。初見の印象を完璧に再現することはできませんが、重大な障害は見つけられます。また、「サイレントウォークスルー」も試してください。一度も立ち止まって修正せずに、自分のスライスを最初から最後まで一気にプレイし、ためらった瞬間をすべて記録します。

より詳細な観察データが必要ですか？ プレイ中に、テスターに考えていることを声に出してもらいましょう。何をしているのか、なぜそうしているのかをリアルタイムで話してもらいます。「攻撃方法を探しています……E を押しました……何も起きません……クリックでしょうか？」この方法なら、振り返ってからではなく、戸惑いが起きた瞬間に把握できます。オンボーディングや UI の分かりやすさの検証に最適です。操作感のテストでは、黙って観察する方が適しています。考えを声に出してもらうと体験が多少変わりますが、UX に関するデータをはるかに細かく収集できます。

非同期でリモートテストする方法: Loom または OBS でセッションを録画します。ビルドを誰かに渡し、画面と音声を録画して動画を送ってもらいます。同期して予定を合わせなくても、実際の初見データを得られます。タイムゾーンをまたいだテストにも対応できます。

AI、NPC、複雑なシステムの挙動を、実装が完了する前にテストしますか？ ウィザード・オブ・オズの手法を使いましょう。1人が通常どおりプレイし、もう1人が NPC やシステムの挙動をリアルタイムで密かに操作します。プレイヤーには自動化されているように見えます。この方法では、実装が完了する前に AI や経済システムの設計意図を検証でき、システムが適切だと感じられるために必要な挙動も正確に把握できます。AI システムがスコープに含まれているものの、誘導なしのテストに使えるほど洗練されていない垂直スライスで特に有効です。

---

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

ループを実演できる状態です。レポートを書く前に、実際にプレイして構造化された所見を集めます。レポートの作成に進むのは絶対に避けてください。レポートの品質は、ここで集める所見の質にかかっています。

次のとおり、正確に伝えてください。

"最初から、完全な［開始 → 挑戦 → 解決］のサイクルをプレイしてください。 これがどのように作られたかを知らない新規プレイヤーになったつもりで進めてください。先に進んだり、 開発者向けの近道を使ったりしないでください。サイクルを最後まで完了したとき、 または何かに行き詰まって先に進めなくなったときに戻ってきてください。"

ユーザーが戻ってきたら、次の質問を1つずつ尋ねてください。

1. ループの完了：

   "私からのガイダンスや、ビルドに関する事前知識なしで、自力で完全な［開始 → 挑戦 → 解決］のサイクルを完了できましたか？"

2. 所要時間の確認：

   "最初の意味のあるアクションにたどり着くまで、どのくらいかかりましたか？ゲームを実際にプレイしていると感じた最初の瞬間のことです。"

3. コアとなる体験：

   "このゲームでは［game-concept.md または game-brief.md に記載されたコアとなる体験］を感じられることを目指しています。そう感じられましたか？正直に答えてください。「なんとなく」ではなく、何をいつ感じたのかを具体的に教えてください。"

4. 障害要因：

   "プレイを妨げたり、混乱させたり、没入感を損なったりしたものは何ですか？何をすればよいか分からなくなったり、何かが壊れたりした瞬間はありましたか？"

5. パイプラインの確認：

   "プレイヤーではなく開発者として、製品版のゲーム全体をこの品質で実現できそうですか？制作にかかる時間について、意外だったことは何ですか？"

6. 判定：

   "PROCEED、PIVOT、KILL のどれですか？理由も具体的に教えてください。"

回答が曖昧な場合は、「そのことが起きた具体的な場面を教えてもらえますか？」と尋ねてください。具体的な所見がレポートの内容になります。曖昧な所見では、役に立たないレポートしかできません。

検証項目に NO がある場合、PROCEED は選べません。/gate-check production は、Vertical Slice Validation に NO が1つでもあるビルド済みのスライスを FAIL とします。具体的には、プレイヤーが開発者のガイダンスなしでループを完了できたこと（質問1）、最初の2分以内に何をすべきか理解できたこと（質問2。2分を超えた場合は NO）、コアメカニクスが心地よいこと（質問3）、楽しさを損なう重大なバグがないこと（質問4）です。これらの回答に1つでも NO があれば、判定は PIVOT または KILL となります。どちらにするかはユーザーが選び、レポートには NO の項目を記載します。

NOT ASSESSED は4つ目の判定です。 まだ誰も最初から完全なループをプレイしていない場合、つまりユーザーが今回のセッションではプレイできない場合や、最後まで進む前に中断した場合は、検証が実施されていません。その場合の判定は、理由を添えて NOT ASSESSED とします。これは PROCEED より下、PIVOT と KILL より上の判定です。未プレイのスライスには PROCEED の資格がなく、失敗すると分かっているスライスのほうが、誰もプレイしていないスライスよりも次の対応を決めやすいためです。NOT ASSESSED が PROCEED として記録されることはありません。

---

フェーズ 6：垂直スライスレポートの作成

ビルド中は速度を記録してください。以下をログに残します。

• 1 日目：構築したもの
• 2 日目：構築したもの
• など

これは、実際の制作速度を示す最も正直なデータです。省略しないでください。スプリント計画に直接反映されます（workflow: minimal の場合はスプリントがないため、ブリーフのビルド順に反映されます）。

レポートの構成を確認するには、.claude/docs/templates/vertical-slice-report.md を読んでください。 テンプレートファイルが見つからない場合は、以下の代替構成を使用します。

• ## Vertical Slice Report — [Game Title] — [Date]
• ### Executive Summary（PROCEED / PIVOT / KILL / NOT ASSESSED の判定＋2 文の根拠）
• ### Core Loop Validation（テストした内容、合格した内容、不合格だった内容）
• ### Feel Assessment（アニメーション、操作、フィードバック — 主観的なメモ）
• ### Technical Findings（パフォーマンス、エンジンの問題、アーキテクチャ上のリスク）
• ### Velocity Log（日ごとの実際の進捗 — 省略しないでください）
• ### Lessons Learned（ほぼ本番品質まで構築して明らかになった前提の誤り、パイプラインやアーキテクチャについて意外だったこと、次回スライスの範囲で変更する点）
• ### Recommended Next Steps

このセッションで観察した内容と構築したものに基づき、すべてのセクションを記入してください。 速度ログには推定値ではなく、日ごとの実際の進捗を記載する必要があります。これは、実際の制作速度を示す最も正直なデータです。すべてのプレースホルダーテキストを実際の観察結果に置き換えてください。推奨事項には、NOT ASSESSED とその理由も含め、フェーズ 5 の判定を引き継いでください。

次のように尋ねてください：「このレポートを prototypes/[concept-name]-vertical-slice/REPORT.md に書き込み、その行を prototypes/index.md に追加してもよろしいですか？」

承認されたら、ファイルを書き込みます。その後、prototypes/index.md を更新します（存在しない場合は作成します）。垂直スライスの表に、コンセプト名、日付、判定、REPORT.md へのリンクを含む行を 1 行追加してください。これが初回のスライスか、PIVOT 後の再実行かも記録してください。このレポートの速度ログは、プロジェクト内でも特に価値の高いデータです。スプリントの見積もりと照合してください。

---

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

レビューモードの確認：

• solo → スキップします。注記：「CD-PLAYTEST skipped — Solo mode.」
• lean → スキップします（PHASE-GATE ではありません）。注記：「CD-PLAYTEST skipped — Lean mode.」
• full → Agent を使って creative-director を CD-PLAYTEST ゲート （.claude/docs/director-gates/cd-playtest.md）で起動します。ただし、スライスの判定が NOT ASSESSED の場合を除きます。プレイが行われていなければレビューするものがないため、注記として 「CD-PLAYTEST skipped — the slice has not been played yet.」と記録します。

REPORT.md の全内容、検証の質問、ゲームの柱とコアファンタジーを design/gdd/game-concept.md から渡します（または rigor: minimal の場合は、 design/game-brief.md のピッチと「what they feel」の行を渡します）。

クリエイティブディレクターは、ゲームのクリエイティブビジョンと柱に照らして垂直スライスの結果を評価し、 ゲートの判定である APPROVE、CONCERNS、REJECT のいずれかを返します。判定を推奨事項に反映します。

• APPROVE → 推奨事項を維持します。
• CONCERNS → 懸念事項を推奨事項と併せて提示し、その後 AskUserQuestion を使って、Revise the recommendation ／ Accept with noted concerns ／ Discuss further のいずれかを尋ねます。決定するのはユーザーであり、ディレクターではありません。
• REJECT（コアファンタジーが実現されていない）→ PROCEED の推奨事項は維持できません。 AskUserQuestion を使って、ユーザーに PIVOT または KILL を選ぶよう尋ね、その選択に応じて フェーズ 8 を実行します。PIVOT または KILL の推奨事項は維持されます。
• NOT ASSESSED [missing input] → ディレクターは判断を下していないため、推奨事項を支持も覆しも しません（.claude/docs/director-gates.md）。不足していたものを明示してから、それを補ってゲートを 再実行するか、レポートに CD-PLAYTEST: NOT ASSESSED — [input] と記録します。

ディレクターが CONCERNS、REJECT、または NOT ASSESSED を返した場合は、 「prototypes/[concept-name]-vertical-slice/REPORT.md とその prototypes/index.md の行を更新してもよいですか？」と尋ね、その後、ディレクターの判定と理由を REPORT.md に記録します。最終的な推奨事項が変更された場合は、両方に記録します。

---

フェーズ 8：まとめと次のステップ

検証の質問、ベロシティデータ、最終的な推奨事項をまとめます。 prototypes/[concept-name]-vertical-slice/REPORT.md へのリンクを記載します。

PROCEED の場合： 垂直スライスでゲームループ全体を検証できました。プロジェクトは Production に進む準備が整っています。

workflow: minimal の場合：/create-stories（ブリーフから）を実行し、続けて最初のストーリーで /dev-story を実行します。それ以外の手順は standard／full のパスです。

推奨される次のステップ（standard／full）：

• /create-epics layer:foundation — Foundation レイヤーのエピックを計画します
• /create-epics layer:core — Core レイヤーのエピックを計画します
• /create-stories [epic-slug] — 各エピックを実装可能なストーリーに分割します
• /sprint-plan — スライスのベロシティデータを使って最初のスプリントを計画します
• /gate-check production — ステージを正式に Production に進めます

プレイテストに関する注意： /gate-check では、文書化されたプレイテストの証拠が確認されます。 ゲートを通過するには、少なくとも 1 回のセッションを文書化し、PROCEED を示す REPORT.md が必要です。 セッション数が多いほど、より信頼性の高いシグナルが得られます。Production にチーム全体で取り組む前に 3 回以上実施することを推奨しますが、必須条件ではありません。

PIVOT の場合：

GDD の改訂に戻る前に、引き継ぎメモを記録します。次の 2 つの質問を、プレーンテキストで 1 つずつ尋ねます。

1. 「この品質レベルでうまく機能し、改訂後のデザインでも維持すべきシステムやメカニクスは何ですか？」
2. 「具体的に何がうまくいきませんでしたか。コアループ、アーキテクチャ、パイプライン、それとも楽しさですか？」

「これを prototypes/[concept-name]-vertical-slice/PIVOT-NOTE.md に書き込んでもよいですか？」と尋ねます。

許可された場合は、うまくいったこと、うまくいかなかったこと、改訂が必要な具体的なシステムやアーキテクチャの決定事項、次のスライスで異なる点を何によって検証すべきかをファイルに記載します。PIVOT 後に /vertical-slice を次に実行するときは、prototypes/ ディレクトリに PIVOT-NOTE.md があるか確認し、それを新たな検証の質問の枠組みづくりとスコープ決定に活用します。

• /design-system [mechanic] で影響を受ける GDD を改訂します
• /architecture-decision でアーキテクチャの問題に対処します
• その後、改訂した方向性を検証するために /vertical-slice を再実行します

KILL の場合：

コンセプトを断念する前に、判定が妥当か確認します。

• 経験豊富なプレイヤーでも、ゲームループ全体に 5 分以上かかりますか？
• いずれのプレイテストセッションでも、感情が高まる瞬間（喜び、驚き、満足感）が見られませんでしたか？
• 2 回以上スライスを試した後も、テスターの 50％以上が同じ箇所で混乱したり行き詰まったりしていますか？
• アーキテクチャの問題により、構築済みのものの 50％以上を作り直す必要がありますか？
• 同じコンセプトで垂直スライスを試すのは今回で 3 回目ですか？

2 項目以上に該当する場合 → KILL 判定は妥当です。0～1 項目の場合 → 対象を絞った PIVOT を 1 回行えば、コンセプトを立て直せる可能性があります。

prototypes/GRAVEYARD.md に KILL を記録します（存在しない場合は作成します）。 「これを prototypes/GRAVEYARD.md に追記してもよいですか？」と尋ねます。許可された場合は、次の項目を 1 件追加します。

## [Concept Name] Vertical Slice — YYYY-MM-DD
- **Kill reason:** [what specifically prevented the player from experiencing the core fantasy]
- **What worked at slice quality:** [systems or mechanics that held up]
- **What failed:** [core loop issue, architecture decision, or pipeline blocker]
- **Next time:** [one specific change for the next time a similar concept is attempted]

• 学んだことを携えて /brainstorm に戻ります
• または /prototype [new-concept] を実行して、新たな方向性をまず低コストで試します

NOT ASSESSED の場合：

スライスは完成していますが、検証はされていません。該当する理由を伝えてから、フェーズ 5 のプレイスルーと振り返りを完了します。再開する場所は production/session-state/active.md のチェックポイントです。その後、尋ねてから REPORT.md と prototypes/index.md の該当行を判定結果で更新します。合格したかのようにスライスを /gate-check production に進めてはいけません。NOT ASSESSED は PROCEED ではありません。

---

重要な制約

• 垂直スライスのコードを本番環境用にリファクタリングしてはなりません。あくまで参考用です
• 本番環境用のコードから prototypes/ をインポートしてはなりません
• 推奨事項が PROCEED の場合、本番環境用の実装はスライスを設計上の参考としてのみ使用し、一から作成します
• スコープの縮小は許容されますが、品質の低下は許容されません。低品質のスライスでは何も証明できません
• 総作業期間は1～3週間です。それ以上かかる場合はスコープが大きすぎます。品質ではなく、スライスの範囲を縮小してください。
• 3日目の埋没費用ルール：その日までにゲームループの全サイクルを実演できない場合は、中止して阻害要因を報告してください
• ネットワーク対応／マルチプレイヤーゲーム： ローカルの垂直スライスでは、ネットワーク対応のメカニクスの操作感を検証できません。レイテンシーによって、戦闘、移動、予測の操作感は根本的に変わります。ネットワーク遅延が0ミリ秒のローカル環境でのテストと、80ミリ秒のネットワーク遅延下での操作感はまったく異なります。スライスで検証できるのは、ゲームループに面白さがあり、完成しているかどうかです。現実的な条件下でネットワーク対応のメカニクスの操作感が良いかどうかは検証できません。ネットワーク環境での操作感を確かめるには、実際のピア、またはシミュレートしたレイテンシーが必要です。