start

ガイド付きオンボーディング

新規ユーザー向けの入り口です。ゲームのアイデアも、エンジンも、経験もない前提で進めます。プロジェクトを読み込み、ユーザーがどこから始めるのかを尋ね、プロジェクトについて想定している内容を示し、次の一歩をひとつ提示します。その手順を実行することはありません。

設定はすべてヘルパーを通じて、明示的な「はい」を得た後にのみ project.yaml に書き込みます。対象は project.stage（レガシーなミラーである production/stage.txt も含む）、modes.rigor、modes.automation です。modes.review_mode や production/review-mode.txt は書き込みません。また、rigor が展開するその他の設定（modes.workflow、docs.density、qa.level、modes.story_granularity、team.size）も書き込みません。値を書き込むと、その設定は rigor の展開より優先され、ミラーファイルがある場合はそちらが優先されます。

質問ツールを使って尋ねてください。質問ツールがない場合は、選択肢を番号付きで列挙し、回答を待つためにターンを終えてください。質問は返信の最後に置きます。質問の後にパス、注記、アドバイスを加えてはいけません。質問をスキップされたり、閉じられたりした場合は回答とはみなしません。平文でもう一度尋ねてください。

Phase 2、4、5 の質問はプロジェクトの方向性を決めるため、どの自動化モードでも尋ねます。エンジンはこれらの質問には含まれません。エンジンは /setup-engine で選択します。Phase 6 の最後の質問は、.claude/docs/automation-modes.md に従い、project.yaml にすでに設定されている modes.automation に基づいて行います。設定されていない場合は質問してください。

Phase 1: プロジェクトを読み込む

bash .claude/scripts/project-state.sh を実行し、その行を保持してください。まだ表示しないでください。Phase 2 でのユーザーの回答を確認するために使います。

行	用途
engine、code_root、source_files	エンジンが設定されているか、コードがどれだけあるかを確認します。source_files が unknown の場合は、コードルートを見つけられなかったという意味です。「コードがない」とは決して言わないでください
concept	design/gdd/game-concept.md または design/game-brief.md が存在するかを確認します
gdd_files、adr	ディスク上の設計ドキュメントとアーキテクチャ決定（Phase 4 でステージを決めるために使います）
prototype、sprint、milestone、story	その他の既存の作業
origin_url	donchitos/claude-code-game-studios と大文字・小文字を区別せずに一致するものが含まれている場合、クローンの参照先はまだテンプレートリポジトリです。そのため、プッシュやプルリクエストの送信先もそこになります。別の所有者のフォークはユーザー自身のものです
stage	すでに記録されているステージがあれば、その値

phase_inferred は無視してください。ファイル数から推測するものですが、コードがあっても設計ドキュメントがないプロジェクトは Production ではありません。ヘルパーが失敗した場合は、その旨を伝え、同じ情報を手動で確認してください（project.yaml のエンジン、2 つのコンセプトファイル、コードルート内のファイル、design/gdd/）。

ヘルパーは rigor と automation を報告しません。project.yaml が存在する場合は読み込み、modes.rigor と modes.automation が設定されているか確認してください。設定済みの値はそのまま保持し、その項目については質問しません（Phase 4 と 5）。

リピーターユーザー（エンジンが設定され、concept がある場合）：何も尋ねないでください。エンジン、見つかったコンセプトまたはブリーフ、レビュー方式を伝えてください。レビュー方式は、設定されていれば modes.review_mode、設定されていなければ modes.rigor が示すものです（minimal → solo、standard → lean、full → full）。次の手順として /help を提案し、該当する場合はテンプレートリモートに関する注記を加えて終了してください。

Phase 2: ユーザーがどこから始めるのか尋ねる

質問ツールを使って、次のように尋ねてください。「ようこそ！ゲームについて、どこから始めますか？」選択肢：

• A) まだアイデアがない：ゲームのコンセプトがありません。何を作るかを探ります。
• B) 漠然としたアイデアがある：テーマ、雰囲気、ジャンル（「宇宙がテーマの何か」、「ほのぼのした農場ゲーム」など）。
• C) 明確なコンセプトがある：核となるアイデアとジャンルは決まっていますが、まだ何も書き留めていません。
• D) すでに作業を始めている：設計ドキュメント、プロトタイプ、コード、計画のいずれかがすでにあります。

回答を待ちます。回答が Phase 1 の内容と矛盾する場合は、見つかった内容を一度だけ伝えてから、もう一度尋ねてください。空のプロジェクトで D が選ばれた場合（「新しいテンプレートのようですが、A または B のほうが近いですか？」）、またはディスク上にコードがあるのに A が選ばれた場合（「[code_root] にコードが見つかりました。D のつもりでしたか？」）が該当します。どの選択肢も当てはまらない場合は、ユーザーに状況を説明してもらい、その説明に沿って進めてください。

フェーズ 3：次のステップを案内する

直近の次のステップだけを伝えます。全体の流れは、厳密さが分かった後のフェーズ 6 で示します。

• **A、まだ何も決まっていない：**ゼロから始めても問題ありません。/brainstorm open で自由にアイデアを広げられます。/brainstorm [hint] では、言葉やテーマをきっかけに始められます。次のステップは /brainstorm open、または思いつく場合はヒントです。「次のステップで土台にする、文章化された設計へと、何も決まっていない状態から導く」と説明します。設計の長さは厳密さによって変わるため、フェーズ 6 まで説明は待ちます。
• **B、漠然としたアイデアがある：**アイデアを数語で尋ね、そのまま受け止めて、/brainstorm [their words] を案内します。
• **C、明確なコンセプトがある：**コンセプトをジャンルと中核となるメカニクスを含む一文で、プレーンテキストとして尋ねます。続けて「どのように進めたいですか？」と尋ねます。選択肢：まず具体化する（/brainstorm [concept] で書き起こします）／すぐに始める（今すぐ /setup-engine を実行し、設計は後で書き起こします）。次のステップはユーザーの選択に従います。
• **D、既存の作業がある：**フェーズ 1 で見つかった内容を伝えます（「[code_root] にソースファイル N 個、設計ドキュメント N 個、エンジン [X / 未設定]」）。エンジンが未設定で、コンセプト以上のものがない場合は /setup-engine、それ以外の場合は /project-stage-detect が次のステップです。

続けて「全体の流れは、すぐに説明します」と伝えます。

フェーズ 4：前提を示してから保存する

2 つの値を決めます。

**ステージ。**パス A、B、C の場合は Concept。パス D の場合は、フェーズ 1 の表に基づきます。

ディスク上の状態	ステージ
エンジンがない、またはコンセプト以上のものがない（gdd_files が 0）	Concept
gdd_files が 1 以上、adr が 0	Systems Design
adr が 1 以上	Technical Setup

厳密さ。project.yaml ですでに modes.rigor が設定されている場合は、その値を維持して、その旨を伝えます。それ以外の場合は、フェーズ 2 と 3 でユーザーが話した内容から、.claude/docs/settings-guidance.md §3 のシグナルを使って推定します。

ユーザーが言及した言葉	厳密さ
オープンワールド、RPG、シミュレーション、サンドボックス、派閥、クラフト、経済、MMO、マルチプレイヤー、多数のシステム	full
リリース、商用、Steam、明確なコアループが 1 つ	standard
ゲームジャム、週末、プロトタイプ、初めてのゲーム、小規模、試してみたいだけ	minimal
上記に該当しない、またはまだ何も決まっていない	minimal（デフォルト）

パス B のヒントも説明として扱います。「オープンワールドのサバイバルシミュレーションのようなもの」は full です。

次のカードを表示します。

What I'll set up
  Stage:  [stage]  ([why, from what was found or picked])
  Rigor:  [value]  ([why, in the user's words] | already set)
          minimal: short brief, coarse stories, tests optional; about 4 steps to code
          standard: about 8 design documents before code; standard QA evidence
          full: everything in standard plus validation builds; evidence everywhere
  /settings changes either of these any time.

次に、質問ツールを使って尋ねます。「これらを project.yaml に保存しますか（ステージは production/stage.txt に保存します）？」選択肢：保存する／保存しない。厳密さ自体については尋ねません。カードに表示されており、/settings で変更できます。

• 保存する：bash .claude/scripts/set-stage.sh "[stage]" を実行し、厳密さがまだ設定されていない場合に限り、bash .claude/scripts/config-set.sh modes.rigor [value] を実行します。読み戻した行が一致することを確認します。「保存しました。厳密さ [value] によって、ほかの 6 つの設定が決まります。/settings で確認や変更ができます」と伝えます。
• 保存しない、または明示的な「はい」以外の回答：何も書き込まず、この実行中は値を保持し、保存しなかったことを伝えます。

ヘルパーが 0 以外の終了コードを返した場合は、その出力を表示し、書き込まれなかった設定を伝え、この実行中の値で続けます。

フェーズ 5：どの程度確認するか尋ねる

modes.automation がすでに設定されている場合は、「自動化は [value] です」と伝えて続けます。それ以外の場合は、「最後に、作業中にどの程度確認を入れればよいですか？」と尋ねます。選択肢：

• ガイド付き（推奨）：細かなことは判断し、大きなこと（スコープの変更、削除、スキーマの変更）については引き続き確認します。
• 協調的：重要な手順ごとに確認し、書き込む前に下書きを提示します。
• 自律的：判断を記録しながら進め、必ず確認するカテゴリについてのみ停止します。最も速く、トークンを最も多く使います。

対応関係：Guided → guided、Collaborative → collaborative、Autonomous → autonomous。選択することが書き込みへの同意です。フェーズ 4 で保存しない選択をしていない限り、bash .claude/scripts/config-set.sh modes.automation [value] を実行します（フェーズ 4 で保存しない選択をしていた場合は、保存しなかったことを伝えます）。

フェーズ 6：進む道を示す

次のように伝えます：「厳密度 [value] での進め方はこちらです。どの厳密度でもすべてのスキルを実行できます。厳密度によって変わるのは必須事項であり、実行可能なことではありません。」

進め方は、フェーズ 3 で指定されたステップから始めます。それが /brainstorm だった場合（パス A、B、および C の Formalize it first）は、最初に /brainstorm、次に /setup-engine を挙げます。それぞれ単独で実行できます。

minimal：実行可能なコードまでの 4 ステップ

1. /setup-engine：エンジンを選択して設定する
2. /brainstorm：1 ページの design/game-brief.md を作成する
3. /create-stories：ブリーフの MVP リストをストーリーにする（エピックやスプリント計画は不要）
4. /dev-story：ゲームコードの最初の行を書く

standard

• コンセプト：/setup-engine → /brainstorm → /prototype → /art-bible → /gate-check
• システム設計：/map-systems → /design-system（システムごとに 1 回）→ /review-all-gdds → /gate-check
• アーキテクチャ：/create-architecture → /architecture-decision（決定ごとに 1 回）→ /create-control-manifest → /architecture-review → /test-setup → /ux-design （アクセシビリティとインタラクションパターン）→ /gate-check
• プリプロダクション：/ux-design（HUD と主要画面）→ /create-epics → /create-stories → /sprint-plan → /gate-check
• プロダクション：/dev-story

各 /gate-check は、合格した場合にのみプロジェクトを次のステージに進めます。

full： standard のすべてに加えて、プリプロダクションに /vertical-slice と /playtest-report を含め、各 GDD の後に /design-review を実施します。

既存の作業があるパス D（ステージが Systems Design 以降、またはディスク上にコードがある場合）では、代わりに以下を使用します。当てはまるステップだけを表示し、ブリーフについては該当するソースだけを 1 つ表示します。minimal の場合：

1. /project-stage-detect：プロジェクトの現在のステージと不足しているものを確認する
2. /adopt：既存ファイルがスキルで読み込める形式かどうか確認する
3. /setup-engine：エンジンが設定されていない場合のみ実行する。engine にエンジン名が指定されている場合は省略する
4. ブリーフ：concept がない場合のみ作成する。コードルートにソースファイルが 10 個以上ある場合は /reverse-document design [code_root] を実行する（ゲームからブリーフを作成します）。その場合、/brainstorm には一切触れないでください。コードルートにソースファイルが 10 個未満の場合のみ、/brainstorm を実行します

standard と full の場合は、ステップ 1～3 の後に /design-system retrofit [path]、/architecture-decision retrofit [path]、/architecture-review、/gate-check を実行します。

minimal は劣ったモードではなく、文書化された最低ラインとして提示し、その代わりに GDD がないため設計上の問題がコード上で明らかになることを一度だけ伝えます。

origin_url がテンプレートリポジトリを指していた場合は、次のように伝えます：「クローンの origin はまだ CCGS テンプレートリポジトリを指しているため、プッシュやプルリクエストはそこに送られます。準備ができたら、git remote rename origin template を実行してから、git remote add origin <your repo URL> を実行してください。UPGRADING.md は template から更新を取得します。このリモートはすでに存在するため、記載されている git remote add template の手順は省略してください。」提案するだけにとどめ、実行はしないでください。

次のように尋ねます：「[first step] から始めますか？」選択肢：Yes, start with [first step] ／ Something else first。どちらを選んでもフェーズ 7 に進み、ステップの実行には進みません。

フェーズ 7：引き継ぐ

「[skill] と入力して開始してください。」の 1 行だけで応答します。そのスキルは開始せず、ユーザーが「はい」と答えた場合でもスキルツールを呼び出しません。ユーザーが別のものを先に実行したい場合は、同じ要領で該当するスキルを指定します。

判定：完了。ユーザーは状況を把握し、次の手順へ引き継がれています。ユーザーがフェーズ 7 より前に中断した場合は、保存された設定と保存されなかった設定を伝えます。