content-audit

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

自動化モード：modes.automation を解決します（project.local.yaml → project.yaml → デフォルトの collaborative）。すべての AskUserQuestion 呼び出しと すべてのファイル書き込みは、.claude/docs/automation-modes.md に従います（collaborative は常に質問 · guided は主要な項目のみ · autonomous は記録して続行； automation_always_ask のカテゴリでは常に質問します）。

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

コンテンツ監査

監査の前に modes.workflow を解決してください。このスキルのティア依存の動作 （「必須セクションの仕様のみを監査する」）は、推測したティアではなく、解決済みのティアに従います。 design/gdd/systems-index.md などの必須入力が 存在しない場合は、ギャップ率を計算せず（指定内容がない場合はゼロ除算になるため）、 NOT ASSESSED — NO DATA と報告してください。

このスキルが呼び出されたとき：

引数を解析します：

• 引数なし → すべてのシステムを対象に完全監査
• [system-name] → そのシステムのみを監査
• --summary → 要約テーブルのみ。ファイルへの書き込みは行いません

---

workflow（.claude/docs/workflow-modes.md を参照）：

• full — すべての GDD 仕様を対象に、コンテンツ数の完全監査を行います。
• standard — 必須セクションの仕様のみを監査し、それ以外で見つかった数は、このティアでは監査対象外として一覧表示します。
• minimal — システムインデックスがないため、実行できません。

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

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

1. このスキルが読み込む入力（データファイル、過去のレポート、プロファイラーの出力、 テスト結果、レジストリ、ソースコード）を一覧表示します。
2. 各項目について、「存在する」と仮定するのではなく、FOUND または ABSENT を記録します。
3. セクションに必要な入力が1つでも ABSENT の場合、そのセクションは NOT ASSESSED — NO DATA です。推定したり、隣接する成果物から推論したりせず、次にテンプレートを読む人が記入することになる必須セルを空欄のままにしないでください。
4. 必須入力がすべて ABSENT の場合は、中止して 全体の判定を NOT ASSESSED — NO DATA と報告し、欠落している入力と、それを生成するスキル（design/gdd/systems-index.md は /map-systems、GDD は /design-system）を明記します。

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

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

フェーズ 1 — コンテキストの収集

1. design/gdd/systems-index.md を読み、 システム、カテゴリ、MVP／優先度ティアの一覧を確認します。セクションごとに読みます。Grep ツール（パターン ^#、コンテンツモード）で必要な見出しを見つけ、Read で offset と limit を指定して該当範囲を読みます。

2. レジストリを最初に確認してカウントする：design/registry/entities.yaml が存在する場合は、最初に読みます。entities セクションと items セクションには、監査対象となる GDD 横断の名前付きコンテンツがまとめられており、各エントリには source: として GDD が記載されています。

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

   - name: はレジストリの 4 つのセクションすべてに現れます。-A 2 のコンテキストで entities: または items: の下にあるものだけを残します（この監査でカウントする名前付きコンテンツです。formulas:／constants: は対象外です）。それらを、所有する GDD をすべて読み込まずに使える計画済みの名前付きコンテンツセットとします。 design/registry/entities.yaml が存在しない、またはエントリがない場合（/design-system が内容を追加するまでは空のスタブとして提供されます）、このステップをスキップし、以下の GDD スキャンを使います。動作は変わらず、処理コストだけが増えます。

3. L0 の事前スキャン：GDD を全文読み込む前に、異なる質問に答える 2 つの grep を実行します。パターンを共用してはいけません。

   a. Summary がある GDD（分母／フェイルオープン確認）：

   Grep pattern="^## Summary" glob="design/gdd/*.md" output_mode="files_with_matches"
   

   b. コンテンツ数を実際に宣言している GDD（絞り込み）：

   Grep pattern="[0-9]+[[:space:]]+(enemies|enemy types|levels|areas|maps|stages|items|weapons|equipment|abilities|skills|spells|cutscenes|conversations|dialogue scenes|bosses|quests)|(enemy|item|weapon|ability|level) types:" glob="design/gdd/*.md" output_mode="files_with_matches"
   

   2 つのスキャンは分けてください。 ## Summary は準拠しているすべての GDD に一致するため、これと他のパターンを結合しても絞り込みにはなりません。また、N enemies のような文字どおりのプレースホルダーは、実際の GDD には一致しません。パターン (b) は、ステップ 5 で実際に抽出するコンテンツ名詞に続く数字に一致します。

   Summary がない場合はフェイルオープンにします。 分母を確定します。design/gdd/*.md を glob で検索し、N 件を数えます。スキャン (a) の一致件数が N 件より少ない場合、該当する GDD は ## Summary の導入前に作成されたものです。Summary がないことを、システムが監査対象外である証拠として扱ってはいけません。(a) の一致が 0 件の場合は、「Summary を含む GDD がまだない」という意味であり、「監査可能なコンテンツがない」という意味ではありません。スコープ内で一致しなかった GDD は全文を読みます。

   単一システムの監査では、このステップをスキップして、すぐに全文を読みます。 全体監査では、スキャン (b) に一致し、かつステップ 2 のレジストリエントリですでに完全に網羅されていない GDD と、スキャン (a) で見落とされたすべての GDD を全文読み込みます。この絞り込みよりフェイルオープンのルールが優先されます。つまり、## Summary がない GDD は、スキャン (b) に一致しなくても全文を読みます。Summary があり、コンテンツ数に関する記述がない GDD（純粋なメカニクスの GDD）だけは、全文を読まずに「監査可能なコンテンツ数なし」として記録します。

4. スコープ内の GDD ファイルを全文読み込みます（またはシステム名が指定されている場合は、その単一システムの GDD）。このステップでは GDD 全体が必要です。見出しごとの範囲に分けて読みます（Grep ツールでパターン ^#、コンテンツモードを使って見出しを見つけます）。40 KB を超えるファイル全体の Read は拒否されるためです。

5. 各 GDD から明示されたコンテンツ数やリストを抽出し、該当する ## セクションを記録します。standard ティアでは、必須セクション（.claude/docs/workflow-modes.md）の外にある数は「このティアでは監査対象外」のリストに記載し、一覧には含めません。次のようなパターンを探します。

   • 「N 体の敵」／「敵の種類：」／名前付きの敵のリスト
   • 「N 個のレベル」／「N 個のエリア」／「N 個のマップ」／「N 個のステージ」
   • 「N 個のアイテム」／「N 個の武器」／「N 個の装備」
   • 「N 個のアビリティ」／「N 個のスキル」／「N 個の呪文」
   • 「N 個の会話シーン」／「N 個の会話」／「N 個のカットシーン」
   • 「N 個のクエスト」／「N 個のミッション」／「N 個の目標」
   • 明示された列挙リスト（名前付きコンテンツの箇条書き）

6. 抽出したデータからコンテンツ一覧表を作成します。

   システム	コンテンツタイプ	指定された数／リスト	ソース GDD

   注：GDD にコンテンツの定性的な説明はあるものの、数の指定がない場合は「未指定」と記録し、フラグを付けます。数が未指定であることは、指摘する価値のある設計上の不足です。

---

フェーズ 2 — 実装状況のスキャン

フェーズ 1 で見つかったコンテンツの種類ごとに、該当するディレクトリをスキャンして、実装済みの数を数えます。Glob と Grep を使ってファイルを検索します。

Unreal では、コンテンツは Content/ にあります。マップとデータアセットの両方が含まれ、コードルート（Source/<Module>/）にあるのは C++ のみです。そのため Unreal では、以下の assets/… グロブもすべて Content/ 以下で実行します（データ拡張子の代わりに *.uasset を使用）。レベルは Content/**/*.umap です。この手順を省くと、すべての Unreal プロジェクトでレベルが 0 件と判定され、NOT STARTED と報告されます。

Unity では、コンテンツは Assets/ 以下にあります（大文字と小文字を正確に区別します — .claude/docs/code-root-resolution.md を参照）。data/ フォルダーにあることはまれです。そのため Unity では、以下の assets/… グロブもすべて Assets/ 以下で実行し、data/ セグメントは必須としません。アイテムの場合は、Assets/**/items/**、Assets/**/Items/**、Assets/**/*Item*.asset を使用します。また、データファイルには .asset（ScriptableObjects）と .prefab が含まれます。この手順を省くと、Unity プロジェクトでアイテム、アビリティ、クエスト、会話が 0 件と判定され、NOT STARTED と報告されます。

レベル／エリア／マップ：

• assets/**/*.tscn、assets/**/*.unity、assets/**/*.umap を Glob で検索します
• コードルートを Glob で検索してシーンファイルを探します。Godot では *.tscn、Unity では *.unity を検索します。Unreal では上記のとおり、代わりに Content/**/*.umap を検索します。コードルートの解決方法は .claude/docs/code-root-resolution.md を参照してください。コードルートを解決できない場合は、ヒット数を 0 とせず NOT ASSESSED — code root unresolved と報告してください。
• levels/、areas/、maps/、worlds/、stages/ という名前のサブディレクトリにあるシーンファイルを探します
• レベル／シーン定義と思われる一意のファイル数を数えます（UI シーンは除外）

敵／キャラクター／NPC：

• assets/data/**/enemies/**、assets/data/**/characters/** を Glob で検索します
• <code root>/**/enemies/**、<code root>/**/characters/** を Glob で検索します
• エンティティのステータスを定義する .json、.tres、.asset、.yaml データファイルを探します
• キャラクターのサブディレクトリにあるシーン／プレハブファイルを探します

アイテム／装備／戦利品：

• assets/data/**/items/**、assets/data/**/equipment/**、assets/data/**/loot/** を Glob で検索します
• .json、.tres、.asset データファイルを探します

アビリティ／スキル／魔法：

• assets/data/**/abilities/**、assets/data/**/skills/**、assets/data/**/spells/** を Glob で検索します
• .json、.tres、.asset データファイルを探します

会話／対話／カットシーン：

• assets/**/*.dialogue、assets/**/*.csv、assets/**/*.ink を Glob で検索します
• assets/data/ 内の会話データファイルを Grep で検索します

クエスト／ミッション：

• assets/data/**/quests/**、assets/data/**/missions/** を Glob で検索します
• .json、.yaml の定義ファイルを探します

エンジン固有の注意事項（レポートに記載）：

• カウントは概算です。このスキルでは、すべてのエンジン形式を完全に解析したり、エディター専用ファイルと製品に含まれるコンテンツを区別したりすることはできません
• シーンファイルにはゲームプレイ用コンテンツとシステム／UI シーンの両方が含まれる場合があります。スキャンではすべての一致を数え、この注意点を記載します

---

フェーズ 3 — ギャップレポート

ギャップ表を作成します。

| System | Content Type | Specified | Found | Gap | Status |
|--------|-------------|-----------|-------|-----|--------|

ステータスのカテゴリ：

• COMPLETE — 指定数以上を検出（100% 以上）
• IN PROGRESS — 指定数の 50〜99% を検出
• EARLY — 指定数の 1〜49% を検出
• NOT STARTED — 検出数が 0

優先度フラグ： 次の条件を満たすシステムを、レポートで HIGH PRIORITY としてマークします。

• ステータスが NOT STARTED または EARLY であり、かつ
• システムインデックスで MVP または Vertical Slice のタグが付いている、または
• システムインデックスで、そのシステムが下流システムのブロッカーとして示されている

サマリー行：

• 指定されたコンテンツ項目の合計数（Specified 列の値の合計）
• 検出されたコンテンツ項目の合計数（Found 列の値の合計）
• 全体のギャップ率：(Specified - Found) / Specified * 100

Found が NOT ASSESSED（コードルート未解決）の行には、Gap も Status も設定しません。また、NOT STARTED として扱わず、どちらの合計からも除外します。サマリーにはその行を記載します。

---

フェーズ 4 — 出力

完全監査と単一システムモード

ギャップ表と概要をユーザーに提示します。次のように尋ねます。「完全なレポートを docs/content-audit-[YYYY-MM-DD].md に書き込んでもよろしいですか？」

はいの場合は、ファイルを書き込みます。

# Content Audit — [Date]

## Summary
- **Total specified**: [N] content items across [M] systems
- **Total found**: [N]
- **Gap**: [N] items ([X%] unimplemented)
- **Scope**: [Full audit | System: name] — [all GDD sections | required sections only (workflow: standard)]
- **Not audited at this tier**: [counts found only outside the required sections — or "none"; omit at `full`]

> Note: Counts are approximations based on file scanning.
> The audit cannot distinguish shipped content from editor/test assets.
> Manual verification is recommended for any HIGH PRIORITY gaps.

## Gap Table

| System | Content Type | Specified | Found | Gap | Status |
|--------|-------------|-----------|-------|-----|--------|

## HIGH PRIORITY Gaps

[List systems flagged HIGH PRIORITY with rationale]

## Per-System Breakdown

### [System Name]
- **GDD**: `design/gdd/[file].md`
- **Content types audited**: [list]
- **Notes**: [any caveats about scan accuracy for this system]

## Recommendation

Focus implementation effort on:
1. [Highest-gap HIGH PRIORITY system]
2. [Second system]
3. [Third system]

## Unspecified Content Counts

The following GDDs describe content without giving explicit counts.
Consider adding counts to improve auditability:
[List of GDDs and content types with "Unspecified"]

レポートを書き込んだ後、次のように尋ねます。

「コンテンツのギャップについて、バックログのストーリーを作成しますか？」

はいの場合：ユーザーが選択した各システムについて、ストーリーのタイトルを提案し、ギャップの規模に応じて /create-stories [epic-slug] または /quick-design を案内します。

--summary モード

ギャップ表と概要を会話に直接出力します。ファイルは書き込みません。 最後に次のように記載します。「完全なレポートを書き込むには、--summary を付けずに /content-audit を実行してください。」

---

Phase 5 — 次のステップ

監査後、最も価値の高いフォローアップアクションを提案します。

• いずれかのシステムが NOT STARTED で、MVP タグが付いている場合 → 「実装を開始する前に、不足しているコンテンツ数を GDD に追加するには、/design-system [name] を実行してください。」
• ギャップの合計が >50% の場合 → 「今後のスプリントにコンテンツ作業を割り当てるには、/sprint-plan を実行してください。」
• いずれかのシステムに HIGH PRIORITY のフラグが付いている場合 → 「HIGH PRIORITY のギャップごとに、/create-stories [epic-slug] を実行してください。」
• --summary が使用された場合 → 「完全なレポートを docs/ に書き込むには、/content-audit（フラグなし）を実行してください。」

実行結果に応じた判定で締めくくります。

• Verdict: COMPLETE — コンテンツ監査が完了しました。
• Verdict: NOT ASSESSED — NO DATA — 必須の入力が不足していた（上部の注記を参照）、スコープ内の項目に件数がない（レジストリエントリがなく、すべての GDD が「Unspecified」または「No auditable content counts」）、または Found 件数を確認できなかった（NOT ASSESSED — code root unresolved）場合です。該当する理由を明記してください。件数が不足している場合は、/design-system も明記してください。ギャップを算出できなかった実行結果に対して、COMPLETE を出力してはいけません。