consolidate-rules

相談者として規則ファイルの棚卸しを行う。指摘を提示し、user の裁可を得てから反映する。プロダクトコード（各リポの src/ 等）は書かない。書いてよいのは対象節に挙げた規則ファイルのみ。

前回どこまで見たかの記録は持たない。呼ばれるたびに対象を全件読む。差分だけを読む方式は、間が空くと差分が溜まって結局全件を読むことになり、差分に現れない陳腐化（モデルの世代交代・本リポ外のリポ）も拾えないため。

対象

• グローバル CLAUDE.md の実体: home-manager/config/claude/ 配下のガイド（~/.claude/CLAUDE.md はそれらの連結で、直接は編集しない）
• 各リポの CLAUDE.md と、そこから @import されるファイル（呼び出し元リポ、または user が指定したリポ）
• .claude/skills/*/reference/*.md（基準の実体）
• .claude/skills/*/SKILL.md のうち、frontmatter description が日本語で書かれているもの
• .claude/settings.json と .claude/hooks/（*.sh と README.md。層1）

層1 を含めるのは、ガイドが規定していて実体が別ファイルにある唯一の層だからである。repo-standardize スキルは deny の共通項目・attribution を、hooks/README.md はフックの書き方を規定しているが、満たしているかは settings.json と hooks/ を読まない限り分からない。

層1 だけは実体が正で、ガイドが従である。 deny の増減は運用の中で決まっており、それを追認していないガイドの側が古い。食い違ったら実体に合わせてガイドを直す。

description が英語の Skill（外部から取り込んだベンダーの写し）と Anthropic 標準搭載 Skill（anthropic-skills:* prefix 等）は対象外。user が書いた規則ではないため。判定は実行時に frontmatter を見て行い、固定の除外リストは持たない。

基準の実体は、それを使う skill が持つ。1本の skill しか読まない基準は SKILL.md 本体に、複数の skill が読むものや長いものはその skill の reference/ に置く。skill に寄せきれないもの（hooks/README.md のような仕組みの説明）だけを MD として残す。棚卸しで基準を独立した MD へ切り出す提案はしない。

再び指摘しない判断

user が裁可した方針。これに当たる乖離は指摘しない。

• 重複の解消 — 同一の規則が複数ファイルにあるとき、片方を消して正本1本にする（参照で繋いで両方残さない）。毎回自動で読まれる CLAUDE.md 層を残し、読まれる契機を持つガイド・skill 側を削るのを既定とする

• 自作 skill の disable-model-invocation — 一覧から消える skill は、別の skill・フック・シェル関数から名指しで引かれる前提の設計であり、不足ではない。判断軸は「自動発火が要るか」ではなく呼び口を持つかで、呼び口を持たないものは自動発火のまま残す

• 英語版（README.en.md・*.en.md） — 日本語版の従属物であり、規則の実体ではない。棚卸しの対象にしない

新たに「差分のまま残す」と裁可された乖離は、ここに1行で足す。

フェーズ1: 洗い出し

1. 対象を全件読む。対象が多いときは読み込みを読み取り専用の探索 subagent（Explore 等）に投げ、親のコンテキストを裁可の往復に残す。subagent には対象ファイルの一覧と下の観点を渡し、返させるのは乖離候補だけにする。1件につき「ファイル:該当箇所 → 何と何が食い違うか → 根拠になる原文の引用」。要約や所感は返させない

   親は返ってきた候補の引用箇所を読み直して裏を取る。裏が取れなかった候補は落とす。subagent は読むだけで、編集と裁可は親が行う

2. 次の観点で乖離を洗い出す

   1. 基準のガイド内部の相互矛盾（例: guarantee-audit/SKILL.md と local-issue/SKILL.md で基準がずれる）
   2. CLAUDE.md と基準のガイドの乖離（ガイドの更新で CLAUDE.md 側が置き去りになっていないか）
   3. Skill の description: と本文の乖離
   4. 参照切れ: 存在しないファイル・skill・関数・見出しを指している記述
   5. モデル世代による陳腐化。古いモデルの弱点を補う目的の記述が、現行モデルでは能力を削ぐ制約になっていないか。徴候は「モデル名やモデル系列で分岐している」「一度に触ってよい範囲を狭めている」「出力の長さ・粒度を一律に縛っている」。該当しても自動では消さない。 弱点が本当に消えたかは実地でしか分からないので、「まだ必要か」を問う形で指摘する
   6. 層1（settings.json / hooks/*.sh）とガイドの乖離。ガイドが規定する deny・フック一覧・attribution が実体に無い、または実体にあるものがガイドに無い。提案の向きは常に「ガイドを実体に合わせる」

洗い出しが終わるまで、見つけた乖離を1件ずつ user へ提示しない。

フェーズ2: 裁可と反映

1. 乖離ごとに、どちらが正かを判定する。重複しているだけなら正本を残し、他方を消す提案にする
2. 指摘一覧をチャットに提示する（ファイルに書き出さない）。各指摘は「対象ファイル:該当箇所 → 矛盾/陳腐化の内容 → 提案」の形で1件ずつ書く
3. 指摘ごとに user の裁可（YES/NO/修正）を得てから編集する。複数の指摘を「まとめてOK」で済ませず、内容ごとの同意を確認する
4. 編集は該当箇所の最小差分に留め、裁可を経ていない周辺の言い回しには手を入れない
5. 反映後、編集した Skill の description が本文と一致しているか、@import やガイドへの参照が実体のファイル名・見出しと一致しているかを確認する
6. 「差分のまま残す」と裁可された乖離を「再び指摘しない判断」節へ1行で足す
7. 変更ファイル一覧と反映済み指摘の要約を報告して終了する。subagent に読ませて裏を取らなかった候補があれば件数を添える

制約

• プロダクトコード（各リポの src/ 等）は書かない
• 裁可を経ていない指摘は反映しない
• コミット・push は user の指示があったときだけ行う