balance-check

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

バランスチェック

すべての AskUserQuestion 呼び出しは .claude/docs/automation-modes.md に従います （協調モードでは常に質問し、ガイド付きモードでは主要な項目のみ、自律モードでは記録して続行します。 automation_always_ask カテゴリでは常に質問します）。

入力不足 — レポートを作成する前に確認してください

このスキルが必要とする入力が存在しない場合、回答は「実行できません」です。 入力を埋めたレポートではありません。 まず確認し、確認に失敗したら停止してください。

1. このスキルが読み取る入力（データファイル、以前のレポート、プロファイラーの出力、 テスト結果、レジストリ、ソースコード）を列挙します。
2. それぞれについて、「存在すると仮定」ではなく FOUND または ABSENT を記録します。
3. あるセクションに必要な入力が ABSENT の場合、そのセクションは NOT ASSESSED — NO DATA です。推定したり、隣接する成果物から推測したりしないでください。また、テンプレートを次に読む人が記入するよう、必須のセルを空欄のままにしないでください。
4. 必要な入力がすべて ABSENT の場合は、停止し、不足しているものと、それを生成するスキルを示して NOT ASSESSED — NO DATA を全体の判定として報告してください。

判定が NOT ASSESSED であれば成功です。 データがない場合に「データは何を示していますか？」と尋ねられたとき、これは正しく有用な回答です。防止する失敗は明確です。判定の列挙型に「実行できません」の状態がないレポートは、誤った問題なし判定を生み出します。たとえば、アセットも基準もないプロジェクトのアセット監査で COMPLIANT を返したり、プロファイラーデータも予算設定もないのに、パフォーマンスプロファイルで「16.67ms の予算に対して 99% 超の余裕」と報告したりするケースです。

証拠がないことは、不在の証拠ではありません。 スキャン対象のファイルがないため一致が見つからなかったスキャンでは、何も検証できていません。どちらが起きたのか明記してください。結果が緑色でも、読み手には判別できません。

---

フェーズ 1：バランスの領域を特定する

$ARGUMENTS 全体からバランスの領域を判断します。データファイルのパスに空白が含まれる場合があるためです。

• Combat → 武器／アビリティの DPS、キル時間、ダメージタイプの相互作用
• Economy → リソースの供給源／消費先、獲得率、アイテム価格
• Progression → XP／パワー曲線、停滞ゾーン、パワーの急上昇
• Loot → レアリティの分布、天井タイマー、インベントリの圧迫
• ファイルパスが指定された場合 → そのファイルを直接読み込み、内容から領域を推測します

引数がない場合は、どのシステムを確認するかユーザーに尋ねます。

---

フェーズ 2：データファイルを読み込む

特定した領域に関連する assets/data/ と design/balance/ のファイルを読み込みます。 レポートの「データソース」セクションに記載するため、読み込んだファイルをすべて記録します。

---

フェーズ 3：設計ドキュメントを読む

まずレジストリを確認します。 design/registry/entities.yaml が存在する場合は、GDD より先に読みます。constants セクションと formulas セクションには、GDD 間で共通する名前付きの値と出力範囲、つまりバランス目標がまとめられており、それぞれに source: として GDD、該当する場合は revised: の日付が記載されています：

Grep pattern="^  - name:" path="design/registry/entities.yaml" output_mode="content" -A 6

レジストリに記載されている定数や数式（constants: ブロックと formulas: ブロック）の値には、レジストリの値を使用します。これらはドキュメント間で共通する正式な数値であり、GDD と矛盾してはなりません。design/registry/entities.yaml が存在しない場合、またはエントリがない場合（/design-system が生成するまでは空のスタブとして提供されます）は、この手順を省略して GDD のみを使用します。

次に、design/gdd/ から対象システムの GDD を読み、意図された設計目標、調整項目、想定される値の範囲を把握します。レジストリにまだ記載されていない項目が対象です。これが「正しい」動作の基準になります。セクションごとに読みます。Grep ツールで必要な見出しを検索し（パターンは ^#、コンテンツモード）、該当する範囲を offset と limit を指定して Read します。

データファイルが見つかったものの、どちらの情報源にもこのドメインの目標が記載されていない場合、目標との比較を行うセクション（外れ値の検出、およびこのドメインにカーブがある場合の進行分析）は NOT ASSESSED — NO DATA になります。それぞれ、欠落している情報（design/gdd/ で検索した GDD と、レジストリが存在しなかったのか空だったのか）を明記し、両方を書き出す /design-system も記載します。

---

フェーズ 4：分析を実施する

すべてのドメインで、各値を目標と比較します。 データファイル内の名前付きの値ごとに、フェーズ 3 から目標を取得します。対象はレジストリ定数の value、レジストリ数式の output_range、または GDD に記載された範囲です。そのうえで比較します。目標範囲外の値は「検出された外れ値」に記載します（例：player_damage_base が 90～110 に対して 140）。どこにも目標が記載されていない値は、範囲内でも外れ値でもありません。「注意が必要な値」に no stated range — not judged として記載します。

続いて、ドメイン固有のチェックを実施します：

戦闘バランス：

• すべての武器／アビリティについて、各パワーティアで DPS を計算する
• 各ティアでのキルにかかる時間を確認する
• ほかのすべての選択肢より優れている選択肢がないか特定する
• 防御の選択肢によって倒されない状態が生じる可能性がないか確認する
• ダメージタイプと耐性の相互作用のバランスを検証する

経済バランス：

• すべてのリソースの供給源と消費先を、流量とともに整理する
• 時間経過に伴うリソースの蓄積を予測する
• 無限にリソースを得られるループがないか確認する
• ゴールドの消費先がゴールドの生成量に応じて増加するか検証する
• 購入する価値のないアイテムがないか確認する

進行バランス：

• XP カーブとパワーカーブをプロットする
• 意味のある進行が長期間ない停滞区間がないか確認する
• 能力が急激に上昇するパワースパイクがないか確認する
• コンテンツのゲートが想定されるプレイヤーのパワーと合っているか検証する
• スキップやグラインドの戦略によって意図したペースが崩れないか確認する

戦利品バランス：

• 各レアリティティアのアイテムを入手するまでの想定時間を計算する
• 天井システムの計算を確認する
• どの段階でも完全に役に立たない戦利品がないか検証する
• インベントリの圧迫度と入手率を確認する

---

フェーズ 5：分析結果を出力する

## Balance Check: [System Name]

### Data Sources Analyzed
- [List of files read]

### Health Summary: [NOT ASSESSED / HEALTHY / CONCERNS / CRITICAL ISSUES]

### Outliers Detected
| Item/Value | Expected Range | Actual | Issue |
|-----------|---------------|--------|-------|

### Degenerate Strategies Found
- [Strategy description and why it is problematic]

### Progression Analysis
[Graph description or table showing progression curve health]

### Recommendations
| Priority | Issue | Suggested Fix | Impact |
|----------|-------|--------------|--------|

### Values That Need Attention
[Specific values with suggested adjustments and rationale]

最も深刻な指摘に基づいてヘルスサマリーを選びます。最初に一致したものを採用します：

• CRITICAL ISSUES — 退化した戦略（ある選択肢がほかのすべての選択肢を圧倒する）、停滞するか完了できない進行、または消費先のない経済ループがある
• CONCERNS — 調整によって修正可能な外れ値やカーブの問題があるが、重大な問題は見つかっていない
• NOT ASSESSED — 分析対象がない（上記のデータなしの場合）、目標が必要なセクションが NOT ASSESSED — NO DATA、または判断対象の値に記載された範囲がない。どれに該当するかを明記します。測定された問題のほうが欠落情報よりも対処しやすいため、2 つの問題ありの判定より下位に位置しますが、HEALTHY より上位です
• HEALTHY — すべての値が明記された目標と照合され、外れ値や退化した戦略がなく、進行も明記された目標の範囲内にある

フェーズ 6：修正と検証のサイクル

レポートを提示した後、AskUserQuestion を使用します。

• プロンプト："バランスチェックが完了しました。次に何をしますか？"
• オプション：
  • [A] 最優先の問題を今すぐ修正する — 手順を案内してもらう
  • [B] レポートを design/balance/balance-check-[system]-[date].md に保存する
  • [C] ここで終了する — 指摘事項を自分で確認する

サブエージェントとして実行しますか？ game-designer はこのスキルを事前に読み込んでおり、サブエージェントには AskUserQuestion がありません。返信の最後に質問と以下の3つのオプションを短いリストで示して、そこで終了します。 呼び出し元がユーザーに質問し、回答をあなたに渡します。

[A] の場合：

• 最初に対応する問題を尋ねます（Recommendations テーブルの優先度の行を参照します）
• assets/data/ 内の該当するデータファイル、または design/balance/ 内の計算式を更新するようユーザーを案内します
• 修正のたびに、新たな外れ値が発生していないか確認するため、関連するバランスチェックを再実行するか尋ねます
• 修正によって GDD で定義されている、または ADR で参照されている調整値が変更される場合、次のようにユーザーに伝えます。

  「この値は設計ドキュメントで定義されています。コミットする前に、影響を受ける GDD に対して /propagate-design-change [path] を実行し、下流への影響を確認してください。」

[B] の場合：

• レポートを design/balance/balance-check-[system]-[date].md に書き込みます（必要に応じてディレクトリを作成します）。[date] には現在の日付を YYYY-MM-DD 形式で使用します。
• ファイルが書き込まれたことを確認してから、最後に「修正後に /balance-check を再実行して確認してください。」と伝えます。

[C] の場合：

• 未解決の問題を要約し、最後に「修正後に /balance-check を再実行して確認してください。」と伝えます。