help

Studio Help — 次に何をすればよいですか？

このスキルは読み取り専用です。調査結果を報告しますが、ファイルは書き込みません。

このスキルは、ゲーム開発パイプラインのどの段階にいるかを正確に判定し、次に何をすればよいかを案内します。軽量で、完全な監査ではありません。完全なギャップ分析には、/project-stage-detect を使用してください。

ライブプロジェクトの状態

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

これらは、このスキルの実行前に解決されます。そのまま使用してください。

• 設定ブロックの project.stage は、ステップ 2 で使用する正式なフェーズです。project.yaml から production/stage.txt へのフォールバックはすでに適用され、値にスペースが含まれる場合（Systems Design）もそのまま保持されます。
• 設定ブロックの workflow は、ステップ 2 と 5 で使用するティアです。再読み込みしないでください。
• 設定ブロックが出力されていない場合は、シェルによる前処理が無効です。.claude/docs/config-resolution.md のデフォルト値を使用してください。

---

ステップ 1：カタログを読む

.claude/docs/workflow-catalog.yaml を読みます。これは、すべてのフェーズ、各フェーズのステップ（順番を含む）、各ステップが必須か任意か、および完了を示す成果物の glob を定めた正式な一覧です。

---

ステップ 1b：カタログにないスキルを見つける

カタログを読んだ後、.claude/skills/*/SKILL.md を Glob して、インストール済みスキルの全一覧を取得します。各ファイルから frontmatter の name: フィールドを抽出します。

カタログ内の command: の値と照合します。名前がカタログ内のコマンドに存在しないスキルは、カタログ未登録のスキルです。使用はできますが、フェーズ制御されたワークフローの一部ではありません。

これらをステップ 7 の出力用に収集し、フッターブロックとして表示します。

### Also installed (not in workflow)
- `/skill-name` — [description from SKILL.md frontmatter]
- `/skill-name` — [description]

カタログ未登録のスキルが 1 つ以上ある場合に限り、このブロックを表示してください。ユーザーの現在のフェーズに応じて、最も関連性の高いものを最大 10 個まで表示します（本番環境では QA スキル、本番環境／仕上げ段階ではチームスキルなど）。

---

ステップ 2：現在のフェーズを判定する

まず、上記の設定ブロックから workflow を取得します。 minimal の場合、プロジェクトはフェーズラダーではなく最小構成のパス上にあります。このステップの残りをスキップし、セッションのコンテキスト（ステップ 3）を読んでから、ステップ 4m に進んでください。このティアでは project.stage を対応付けないでください。最小構成のパスでは /gate-check を実行しないため、プロジェクトがどこまで進んでいてもフェーズは Concept として読み取られます。Concept フェーズに沿って進めると、すでにストーリーがあるプロジェクトをコンセプトドキュメント、アートバイブル、システムマップへ戻すことになります。

それ以外の場合は、次の順に確認してください。

1. 上記の設定ブロックから project.stage を取得します。すでに解決済みです。その値をカタログのフェーズキーに対応付けます。

   • "Concept" → concept
   • "Systems Design" → systems-design
   • "Technical Setup" → technical-setup
   • "Pre-Production" → pre-production
   • "Production" → production
   • "Polish" → polish
   • "Release" → release

2. どちらも設定されていない場合は、成果物からフェーズを推定します（最も進んだ該当項目を優先）。

   • コードルートにソースファイルが 10 個以上ある → production
   • production/epics/**/story-*.md が存在する → pre-production
   • docs/architecture/adr-*.md が存在する → technical-setup
   • design/gdd/systems-index.md が存在する → systems-design
   • design/gdd/game-concept.md（または design/game-brief.md）が存在する → concept
   • 該当なし → concept（新規プロジェクト）

3. workflow は、このステップの冒頭で取得済みです（.claude/docs/workflow-modes.md に従います）。任意のドキュメントを次のステップとして提示するかどうかを決定します（ステップ 5）。

---

ステップ 3：セッションのコンテキストを読む

production/session-state/active.md が存在する場合は読み取ります。ただし、STATUS ブロックと CHECKPOINT ブロックのみです（スキーマ：.claude/docs/templates/session-state.md）。その下の説明文は長いことがあります。マーカーを見つけて （Grep pattern="" path="production/session-state/active.md" output_mode="content" -n）、最初から最後までを Read します。マーカーがないファイルはスキーマ導入前のものです。その場合は、最後の ## Session Extract ブロックを読み取ります。以下を抽出します。

• 直近で取り組んでいたこと
• 進行中のタスクや未解決の質問
• STATUS ブロックに記載された現在のエピック／機能／タスク（存在する場合）

これにより、ユーザーが直前に完了したことや行き詰まっていることが分かります。出力をパーソナライズするために活用してください。これはすべてのティアで実行します。minimal では、チェックポイントのステップ 4m が頼りにする唯一の読み取りです（「Next step: /story-done」と記されたチェックポイントは、作業が記録済みであることを意味します）。ここから minimal はステップ 4 ではなく、ステップ 4m に進みます。

---

ステップ 4：現在のフェーズのステップ完了状況を確認する

現在のフェーズ（カタログに記載）に含まれる各ステップについて、以下を行います。

成果物に基づく確認

これらは決定的に解決してください。ステップごとに glob を実行するのではなく、1 回の呼び出しで確認します。

Bash: bash .claude/scripts/artifact-check.sh --phase [current-phase]

ここおよび以下では、記載どおりにそのまま実行してください。プロジェクトルートから相対パスで実行し、絶対パス、cd、2>&1 は使用しません。このスキルの権限許可はこの形式に合致しています。それ以外の形式では、ユーザーの承認が必要になります。

このコマンドは、カタログ内のすべての glob、pattern、min_count、any_of を作業ツリーに対して評価し、ステップごとに 1 行を出力します。ステータスを以下のように報告します。

ステータス	報告内容
PRESENT	完了
ABSENT	未完了
SHORT	未完了 — 不足数を記載します（count=／min= が示されます）
PATTERN_MISS	未完了 — ファイルは存在するものの、マーカーがありません。その旨を記載します。「不足」とすると、すでにあるファイルをユーザーに再作成させてしまいます。
NO_CHECK	ステップに note= がある場合は 手動、それ以外は 不明 — 完了状況を追跡できません（例：繰り返し可能な実装作業）

Glob／Grep を使って、これらを改めて確認しないでください。特に any_of は選択肢のリストであり、1 つでも一致すれば十分です。手作業で評価すると、誤って「未完了」と判断するおそれがあります。engine-setup は、project.yaml の engine.name、または .claude/docs/technical-preferences.md の旧形式の Engine: 行のどちらかを満たせば条件を満たします。スクリプトは一致した選択肢を (alt=／match=) で報告します。

NO_CHECK は決して完了を意味しません。 スクリプトは行の前に NO_CHECK: の合計を出力します。フェーズの大半が NO_CHECK の場合、フェーズがほぼ完了しているかのように示すのではなく、そのことを明確に伝えてください。

特殊ケース：production フェーズ — sprint-status.yaml を読む

現在のフェーズが production の場合、ストーリーの glob チェックを行う前に production/sprint-status.yaml を確認します。存在する場合は、直接読み取ります。

• status: in-progress のストーリー → 「現在進行中」として提示
• status: ready-for-dev のストーリー → 「次の作業」として提示
• status: done のストーリー → 完了としてカウント
• status: blocked のストーリー → blocker フィールドとともにブロッカーとして提示

これにより、Markdown のスキャンを行わずに、ストーリーごとの正確なステータスを確認できます。implement ステップと story-done ステップでは、glob による成果物チェックを省略します。YAML を正式な情報源とします。

特殊ケース：repeatable: true（production 以外）

production 以外の、繰り返し可能なステップ（例：「System GDDs」）では、成果物チェックで分かるのは、何らかの作業が行われたかどうかであり、完了したかどうかではありません。これらは異なる方法で示してください。検出された内容を示したうえで、作業が継続中の可能性があることを明記します。

---

ステップ 4m：最小パス（workflow: minimal のみ）

minimal では、ルートはフェーズではなく、カタログの paths.minimal です。engine → design/game-brief.md → ストーリー → /dev-story ↔ /story-done の順です。1 回の呼び出しで解決します。

Bash: bash .claude/scripts/artifact-check.sh --path minimal

ステータスはステップ 4 とまったく同じようにマッピングします。implement と story-done は設計上 NO_CHECK です。以下のストーリーステータス行がそのチェックになります。次のステップは、該当するもののうち最初のものです。

1. engine-setup が PRESENT ではない → /setup-engine
2. game-brief が PRESENT ではない → コードルートにゲームがすでにある場合（ソースファイルが 10 個以上。これはステップ 2 で production に使うテストです）は /reverse-document design [code root]。minimal では、ビルド済みの内容から design/game-brief.md を作成します。それ以外の場合は /brainstorm（minimal では 1 ページのブリーフを作成します）。ゲームがすでにビルドされている状態で実行すると、新しいアイデアの作成が始まります。
3. create-stories が PRESENT ではない → 引数なしで /create-stories（minimal では、ブリーフの MVP リストから直接ストーリーを作成します）
4. ストーリーが存在する → 以下のリストは、このスキルを読む前に .claude/scripts/story-status.sh が出力したものです。未完了のストーリーごとに 1 行で、すでにルートの順序に並んでいます。ビルド順で IN_REVIEW、次に IN_PROGRESS、次に TODO（Ready または Not Started のストーリー）が続き、その後に BLOCKED、OTHER、NO_STATUS と COMPLETE の件数が表示されます。

!bash "${CLAUDE_SKILL_DIR}/../../scripts/story-status.sh"

次に着手するのは、最初の IN_REVIEW、IN_PROGRESS、または TODO の行にあるストーリーです。 リストはすでに最新です。スクリプトを再実行したり、ストーリーファイルを読み直したり、順序を付け直したりしないでください。 In Review のストーリーを先に完了してから、In Progress のストーリーを続けます。その作業内容はすでに書かれており、/story-done はすぐに済みます。

• IN_REVIEW → 作業内容は書かれており、完了処理待ちです： /story-done [path]
• IN_PROGRESS → 完了ではありません。コードやコミットから何が読み取れるとしても、ストーリーを Complete にできるのは /story-done だけです。ユーザー、active.md、または git ログに実装が書かれていると示されている場合に限り /story-done [path] を推奨します。それ以外の場合は、作業を続けるために /dev-story [path] を推奨します
• TODO → /dev-story [path]
• BLOCKED のストーリー → ストーリー名とブロッカーを伝えます。次に着手する対象にはなりません
• IN_REVIEW、IN_PROGRESS、TODO の行がなく、BLOCKED、OTHER、または NO_STATUS の行が残っている → 次にビルドできるものはなく、ビルド順は完了していません。これらのストーリーをステータス表記どおりにそれぞれ挙げ、ブロックされているストーリーについてはブロッカーも伝えます（該当ストーリーのファイルから確認してください）。次に着手するのは、これらのうち最初のストーリーの問題を解消することです。ブロッカーを解決するか、OTHER または NO_STATUS のストーリーに、ルートが読み取れる Status: 行を追加します（ビルド可能になったら Ready にします）
• すべてのストーリーが Complete（または Done） → ブリーフのビルド順は完了です。その旨を伝え、次の 3 つの方法を提案します。ビルドしたゲームをプレイする、/create-stories でブリーフから次のストーリーを追加する、またはゲームが 1 ページのブリーフに収まらなくなっている場合は /settings で modes.rigor を引き上げる。

minimal では、次のいずれも必須事項やブロッカーとして提示してはいけません。 ゲームコンセプト文書、アートバイブル、システムマップ、GDD、/create-epics、スプリント計画、/gate-check、スプリントの締めくくり（/smoke-check、/team-qa、/retrospective）です。ブリーフが設計文書に代わり、そのビルド順がスプリント計画に代わります（.claude/docs/workflow-modes.md — minimal の最低要件）。ユーザーが求めた場合は、これらすべてを引き続き実行できます。ユーザーの依頼で尋ねられた場合にのみ、いずれかに触れてください。

その後、ステップ 5 と 8 をスキップし、ステップ 7 の minimal 形式で提示します。

---

Step 5: 位置を確認し、次のステップを特定する

完了データから、次の項目を判断します。

1. 最後に完了が確認されたステップ — 完了した必須ステップのうち、最も先のもの
2. 現在のブロッカー — 最初の未完了の必須ステップ（ユーザーが次に行うべきことです）
3. 任意の機会 — ブロッカーの前または並行して実施できる未完了の任意ステップ。ワークフローのティアに応じて提示します。full ではすべて列挙し、standard では現在のシステム／フェーズに必須の任意ドキュメントのみを列挙します（真に任意のドキュメントを不足項目として指摘しないでください）。minimal ではこのステップは実行されず、Step 4m が置き換わります。
4. 今後の必須ステップ — 現在のブロッカーより後にある必須ステップ（ユーザーが計画できるよう、「次に控えている項目」として表示します）

ユーザーが引数（例：「design-review を終えたところ」）を指定した場合、成果物の確認が曖昧でも、指定されたステップは完了したものとして先に進みます。

---

Step 6: 進行中の作業を確認する

active.md に進行中のタスクやエピックが記載されている場合：

• 冒頭で目立つように提示します：「[X] に取り組んでいたようです」
• それを続けるよう提案するか、完了しているか確認します

---

Step 7: 出力を提示する

簡潔で直接的にします。レポートではなく、手短な状況確認です。

## Where You Are: [Phase Label]

**In progress:** [from active.md, if any]

### ✓ Done
- [completed step name]
- [completed step name]

### → Next up (REQUIRED)
**[Step name]** — [description]
Command: `[/command]`

### ~ Also available (OPTIONAL)
- **[Step name]** — [description] → `/command`
- **[Step name]** — [description] → `/command`

### Coming up after that
- [Next required step name] (`/command`)
- [Next required step name] (`/command`)

---
Approaching **[next phase]** gate → run `/gate-check` when ready.

minimal では、代わりに次の形式を使用します — フェーズラベルとゲート行はありません。N は、ステータス行が Complete または Done のストーリーのみを数え、そのストーリーだけを ✓ Done に記載します。N と M は COMPLETE 行にある2つの数値です。この行には完了したストーリー名は記載されないため、✓ Done にはタイトルではなく件数を記載します。

## Where You Are: Minimal path — [N] of [M] stories complete

**In progress:** [from active.md, if any]

### ✓ Done
- Engine: [engine] · Game brief · [N] stories

### → Next up
**[Story NNN: title]** — [what it delivers]
Command: `/story-done [story-path]` for an In Review story, or an In Progress one whose work is written; otherwise `/dev-story [story-path]`

### Coming up after that
- [the next Ready stories in build order, at most 3]

書式ルール：

• 完了が確認された項目には ✓ を使用します
• 現在の必須の次のステップには → を使用します（1つだけ — 最初のブロッカー）
• 現時点で実施できる任意のステップには ~ を使用します
• コマンドはバッククォートで囲んでインライン表示します
• ステップにコマンドがない場合（例：「Implement Stories」）は、スラッシュコマンドを表示する代わりに、何をすればよいか説明します
• MANUAL ステップでは、ユーザーに「[step] が完了しているか判断できません — 完了していますか？」と尋ねます

判定：COMPLETE — 次のステップが特定されました。

---

Step 8: ゲートに関する警告（近づいている場合）

minimal ではこのステップを省略します — minimal パスにはフェーズゲートがありません。

現在のフェーズのステップの後で、ユーザーがゲートに近づいている可能性を確認します。

• 現在のフェーズの必須ステップがすべて（またはほぼすべて）完了している場合は、次を追加します：「[Current] → [Next] ゲートが近づいています。準備ができたら /gate-check を実行してください。」
• 必須ステップが複数残っている場合は、ゲートに関する警告を省略します — まだ関係ありません。

---

Step 9: エスカレーションパス

推奨を示した後、ユーザーが行き詰まっている、または混乱しているようであれば、次を追加します。

---
Need more detail?
- `/project-stage-detect` — full gap analysis with all missing artifacts listed
- `/gate-check` — formal readiness check for your next phase
- `/start` — re-orient from scratch
- `/settings` — if the process feels mismatched to your project, adjust
  `modes.rigor`. Apply the change-triggers in
  `.claude/docs/settings-guidance.md § 4`: a **lower** tier when the user sounds
  overwhelmed by process (and rigor isn't already `minimal`), or a **higher** tier
  when the project has outgrown it (many systems, or in Production on
  `workflow: minimal`)

これは、ユーザーの入力から混乱がうかがえる場合（例：「わかりません」「行き詰まっています」「迷っています」「自信がありません」）にのみ表示します。単純な「次は何ですか？」という問い合わせでは表示しないでください。/settings の厳密さに関する行は、settings-guidance.md § 4 の条件に実際に該当する場合にのみ表示します。つまり、ユーザーが圧倒されているように見える場合（かつ厳密さがすでに minimal ではない場合）、またはプロジェクトが現在のティアに合わなくなっている場合です。混乱を示す問い合わせのたびに表示するものではありません。minimal では /gate-check の行を省略します。minimal パスにはフェーズゲートがありません（Step 4m）。

---

協働プロトコル

• 次のスキルを自動実行しないでください。 推奨するにとどめ、ユーザー自身に呼び出してもらいます。
• MANUAL ステップについては、完了または未完了と決めつけずに確認します。
• ユーザーの口調に合わせます — 「もう完全にわからなくなりました」のように焦っている場合は、安心できる言葉をかけ、6つの項目を列挙するのではなく、1つの行動を提示します。
• 主な推奨事項は1つに絞ります — ユーザーが次に何をすればよいか、はっきりわかるようにします。任意のステップと「次に控えている項目」は補足情報です。