organize-rules

~/.claude/rules/ と ~/.claude/skills/ に置く資産の、書き方と整理の手順です。

プロジェクトルールとの違い

同じ「ルール」でも、置き場所によって性質が変わります。プロジェクト側の書き方をそのまま持ち込まないでください。

	グローバル (~/.claude/rules/)	プロジェクト (.claude/rules/)
ロード	常に全文（ paths 付きは合うファイルを扱ったときだけ）	paths にマッチしたときだけ
構成	1層（ルールに直接書く）	2層（ルールは入口、docs/ が本体）
内容	振る舞いの規約（コミット・レビュー・報告の仕方）	コードの規約（命名・配置・実装パターン）
命名	スネークケース (no_auto_ready_pr.md)	ケバブケース (data-fetching.md)

命名の型は3つある。どれでもよいが、ファイル名だけで何の規約か分かることを優先する。

型	使うとき	例
no_ 始まり	禁止が主題	no_auto_ready_pr / no_agent_coordination_in_pr
動詞始まり	「〜せよ」が主題	verify_before_asserting / summarize_after_each_task
名詞句	書式・スタイルそのものが主題	karma_commit_style / plain_language_explanation

改名は相互参照の追随コストが高い。 ## 関連 で参照し合っているので、型を揃えるためだけの改名は避ける。

paths は作業中のリポジトリのファイルにマッチします。グローバルのルールでも **/*.ts のような形なら効き、~/.claude/skills/** のようにリポジトリの外を指す形は効きません。グローバルで使うのは、コードを書くときだけ要る規約のように、ファイルの読み書きで始まるものに限ります（ rule_conventions.md ）。

期待する挙動

• 新設する前に ls ~/.claude/rules/ で近い主題を見る。 理由は verify_before_asserting.md （「無い」を語で判定しない）

• 節を足す前に grep '^## ' で章立てを出す。 章順の規約を知っていても、既存の並びを見ないと挿入先を誤る

• 例を書いたら、悪い側と良い側を並べて差分だけを見る。 節の主張も例の日本語もどちらも正しく、その差分が主張を示していないことだけが抜ける形がある。本文を読む動きでは通過する

  • 実際に、外部の記事から引いた例をそのまま貼ったところ、悪い側と良い側で語順が同じだった。節の主張は「長いものから並べる」なのに、差分は語を2つ足しただけだった
  • 引用元が正しくても、例として働くかは別。並べ替えを説く節なら、例も並べ替えでなければならない

• 量の絞り方・分割の判断・重複と既定の挙動に重なる文の削り方は /mattpocock-skills:writing-for-agents に従う（Pruning・When to split・Information hierarchy の節）。本スキルが持つのは、そこに無いユーザーの規約（章立て・命名・置き場・公開と非公開）だけ

• 主題ごとに分けたら、## 関連 で相互に参照する

• 章立ては次を基本にする。ただし内容に即して変えてよい

  # タイトル
  <1〜3 行の説明>
  これは全プロジェクト共通の規約です。
  
  ## 期待する挙動
  ## 禁止する挙動
  ## なぜ
  ## 例外
  ## 関連
  

• 見出し名は内容に合わせる。文体の規約なら ## 期待するスタイル、PR 説明の規約なら ## 期待する記述 でよい。機械的に ## 期待する挙動 へ揃えない

• 禁止が主題のルール（ no_ 始まり）は、禁止をタイトルとリード文で明示する。## 禁止する挙動 を節として置くなら ## 期待する挙動 より先。ただし1行で言える禁止に節を立てる必要はない

• ## なぜ は必ず書く。理由が分かると規約が想定していない場面でも判断できる

• ## 関連 で相互に繋ぐ。近い主題のルールが複数あるとき、どれが何を担うかを1行で示すと、読み手が両方を踏まえて判断できる

• 新規作成前に ~/.claude/skills/*/SKILL.md を Read で確認し、以下のフォーマット要素を既存に揃える

  • frontmatter の有無・キー（ name / description / etc）
  • 見出し構成（ ## 進め方 / ## 手順 / ## やってはいけないこと / ## 出力の目安 など、既存で頻出する見出し）
  • 語尾・トーン（体言止め寄り／敬体／命令形の使い分け）
  • 箇条書き / 表の使い方
  • コードブロックのフェンス種別・引用（HEREDOC 等）

• 改修時も同様に、対象 SKILL.md 内および周辺 SKILL.md の慣習を尊重する

• 既存フォーマットが複数流派に分かれている場合は、頻度の多い側（正典）に寄せる。判断に迷うときはユーザーに確認する

整理の契機

このディレクトリに手を入れるときが、棚卸しのタイミングです。 定期的に見直す必要はありません。次のどれかに当たったらそのつど整理する。次の指示を待たず、提案まで出す。

契機	見直すこと
ルールを追加・変更・削除した	ディレクトリ全体。手を入れるたびに再編成する
ルールを守れなかった／守らなかったと気づいた	そのルール自体。逸脱はルール側の欠陥を示す信号
既定の挙動が変わったと分かった	埋めていた穴が塞がっていないか
スキルや AGENTS.md に汎用の規定を見つけた	ルールへ引き上げられないか（下記）
auto memory に書いた／書こうとした	ルールと重複していないか、そして実行時に読まれる場所へ落ちているか（下記）
失敗した／指摘を受けた	その失敗を防ぐ規定がどこに要るか。メモリで足りるか、ルールやスキルの手順が要るか

1行直しただけでも契機になります。 そのルールを読み返した時点で、隣に同じ主題が無いか・既定と重なっていないかが見えるためです。

守れなかったときに問うのは「次から気をつける」ではなく、なぜ守られなかったか。書き方が曖昧なのか、置き場所が悪いのか、そもそも不要なのか。原因に応じて書き直す・移す・消すのいずれかを選ぶ。同じ逸脱が繰り返されるルールは、内容ではなく形に問題がある。

学んだことを、どこに置くか

失敗から学んだとき、メモリへ書いて終わりにしない。 メモリは読まれるが、作業中に辿るのは手順のほうなので、次に同じスキルを打てば同じ失敗をします。

置き場は「次に同じ場面へ来たとき、何を見ているか」で決める。

学んだこと	置き場
そのリポジトリ固有の事実（設計の前提・落とし穴）	メモリ
どのリポジトリでも効く振る舞いの規約	ルール
特定の作業中に必ず踏む判断	そのスキルの手順

1つに決めきらなくてよい。 事実はメモリ、判断の基準はルール、実行時の手順はスキル。同じ学びが3か所に分かれることがあります。ただし同じ文を3回書かない。片方だけ古くなります。

「メモリに書いた」で止まったかを疑う。 失敗の再発を防げるのは、その場面で開くものに書いたときだけです。

置き場をまたぐ整理

良い規定が1つのスキルにだけ書かれていると、そのスキルを呼んだときしか効きません。 汎用のものを見つけたらルールへ引き上げる。

元の場所	引き上げる判断
skills/*/SKILL.md	その作業に固有かを見る。固有でないならルールへ移す
AGENTS.md	「〜せよ」と読めるならルールへ。前提の記述ならそのまま
auto memory	どのリポジトリでも効く好みならルールへ。移したら元は消す（下記）

引き上げたあとは、元を消さずに「土台はルール」と参照を張る。スキル側には固有の事情（ツールのレンダリング挙動、テンプレの構成）が残るので、丸ごと移すと失われる。

ルールが土台、スキルが上乗せ。 両方に同じことを書かず、差分だけを持たせる。

逆方向も見る（ルールにあるのに、手順に落ちていない）

引き上げだけでは足りません。 ルールに書いてあっても、そのとき呼ぶスキルの手順に無ければ実行時に落ちます。ルールは読まれても、作業中に辿るのは手順のほうだからです。

症状	直し方
ルールが求める作業が、対応するスキルの手順に無い	手順として節を足す
スキルが 「〜してよい」「必要なら」 で書いている	ルールが求めているなら手順へ格上げする
スキルの ## 例外 に、ルールの本則が入っている	例外から出す

「〜してよい」は最も見つけにくい形です。 書いてあるので抜けに見えず、実際には毎回やらない理由になります。

スキルとルールはどちらを触っても対で見る。 ルールを足したら「これを実行するスキルの手順に入っているか」、スキルを直したら「土台のルールと食い違っていないか」を確かめる。

対応するスキルが無いルールは、自分で手順を持つ

上の表は「対応するスキルがある」前提です。 ところがルールの多くは、特定のスキルから呼ばれるわけではありません。書く場面が作業のあちこちに散っているためです。この場合、手順を落とす先がありません。

そういうルールはルール自身が手順を持つ。 判断基準だけ書いて手順を書かないと、「何を書くか」は分かるが「いつ書くか」が決まらないまま実行時に落ちます。

ルールが要求すること	手順が要る合図
2つの操作を対にする（消したら別の場所へ置く、変えたら追随させる）	2つが別のタイミングで動くなら、順序を書く
後から確かめる（push 後・マージ後・CI 後）	その時点では別のことを考えているので、いつ戻るかを書く
先に控える（消す前・上書きする前）	失った後では再現できない

実際に「移ろう文脈は PR へ置く」というルールを守れませんでした。判断基準（どれを削るか）は明確でしたが、削るのは編集中・置くのは push 後という時間差に触れておらず、削った時点で作業が途切れています。

「1つの作業にする」と書く。 分かれていると片方だけで終わります。

守られなかったときは、型で当たる

逸脱はルール側の欠陥を示す信号です（上記「整理の契機」）。原因の5つの型と直す場所、文章を直しても止まらないときにフックへ寄せる判定（6つ目）は references/when-rules-fail.md にある。守られなかったルールを直すときに開く。

auto memory との境界

auto memory（ ~/.claude/projects/<project>/memory/ ）は自分が書く学習ノートで、ルールはユーザーが承認した規約です。MEMORY.md の索引は毎セッション読み込まれるので、ルールと同じことを書けば同じ規約が2回ロードされます。

	ルール	auto memory
書き手	ユーザーの承認を経て自分が書く	自分が判断して書く
効く範囲	全リポジトリ	そのリポジトリだけ
内容	汎用の振る舞いの規約	そのリポジトリ固有の事実（設計の前提・落とし穴・進行中の作業）

汎用の好みをメモリに書かない。 ルールへ引き上げてよいか尋ね、ルールにしたらメモリからは消す。ここはスキルと違い「元を残して参照を張る」をしない。どちらも常時ロードされるので、両方に残すと二重に読み込まれたうえ片方だけ古くなる。

逆に、リポジトリ固有の事実をルールへ書かない。 それはメモリか、そのリポジトリの .claude/rules/ の担当です。

残すと判断したら、なぜ残すのかを1行添える。 ルールと主題が近いメモリは、次に整理する人が同じ判定をやり直します。ルールに無い判定軸を名指しで書く。「ユーザー指示由来も対象」「理由語で判定する」のように、どこが覆われていないかを示す。

照合するのは主題ではなく判定軸。 主題が同じでも、そのメモリだけが持つ判定の手順があれば別物です。原文を開かずに「近いから重複」と決めない。

分割・マージ・削除

分けるか寄せるかの一般的な判断は /mattpocock-skills:writing-for-agents が持つ。ここでは手元のルールとスキルで見る3つを並べる。

操作	いつ	何をする
分割	1ファイルに主題が2つ以上ある（スキルなら責務が2つ以上ある）	主題ごとに分け、ルールは ## 関連 で、スキルは委譲で繋ぐ
マージ	同じ主題や手順が複数ファイルに散っている	1つに寄せ、残りは消すか委譲に置き換える。近い主題を新設するより既存へ足す
削除	無くても挙動が変わらない（既定の挙動や他のスキルで代替でき、呼ばれなくなった）	消す。判断に迷うものは残し、なぜ残すのかを1行添える

1つへ寄せるとき

「寄せた」と「届いている」は別です。 消す前に3つを確かめる。ルールどうしでも、スキルからルールへでも、スキルどうしでも同じ。

順	やること	見落とすと
1	消す行が寄せた先にあることを1つずつ照合する	寄せたつもりの規定が、どこにも無くなる
2	元にしか無い規定を、固有として残す	場面を限定していた規定が、広い側の規定で上書きされる
3	禁止の一覧から消したなら、なぜ書かないかを残す	消した跡が空白になり、次に書き戻される

2は「その規定が寄せた先にあると広すぎないか」で判定する。

固有側に残るもの	例
適用場面を限定するもの	「この経路だけ」「レビュー中は」／承認の範囲を狭める規定
例外の条件	## 例外 に書かれた限定
次の段の入力になるもの	後続の手順が使う値・対象の粒度

部分的に書き直された規定は、どこかが欠けています。 寄せると、寄せた先にしか無いものが全部に効くようになる。

削除の判断

グローバルのルールとスキルには、Claude Code の既定の挙動が足りない部分を埋めているものがあります。アップデートで既定に取り込まれたらその時点で消す。スキルの手順の一部だけが取り込まれた場合は、その節を削って残りに絞る。

スキルが既定に取り込まれることは稀です。 スキルは複数手順の組み立てや、そのユーザー固有の運用を束ねたもので、既定がそこまで代替することは多くありません。「たぶん無い」前提で見て、あれば消すくらいの重さでよい。

既定に入ったかは、ツールの説明文・実際に外して（スキルなら無しで）試す・リリースノートで確かめる。裏を取れないまま「もう既定に入った」と断定しない（ verify_before_asserting.md ）。

既定より厳しい運用を求めるもの、既定が不安定で明文化しておくと守られやすいもの（スキルなら手順を固定しておきたいもの）は残してよい。その旨を本文に書く。

実行できないルールも消す。 従いたくても自分の手で終えられない規定は、書いてあっても効かない（本スキルの「自分が実行できないことは規約にしない」）。

固有名は、判定に使う語にも残る

「プロジェクト固有の事情を書かない」は、主題だけでなく発動条件にも掛かります。 主題を汎用に書いても、それが発動する条件が特定領域の語なら、その領域でしか効きません。

実際に、並列レビューの分割軸は最初から言語非依存にしていたのに、観点を選ぶ条件に N+1 ループ内のクエリ が残っていました。軸は汎用、条件はサーバー側限定という状態です。

見る場所	例
主題・軸	気づきやすい。「レイヤー別に分ける」→「ディレクトリの近さで分ける」
発動条件	見落とす。 「〜が差分にある」「〜を触っているなら」の中身
例と対比	同じく見落とす。 汎用の規定に、片方の領域の例だけを添えている

直し方は2つ。 語を抽象化するか、両方の領域を並べる。

• 抽象化: ループ内のクエリ・N+1 → 繰り返し処理・重い再計算
• 並置: 「サーバー側なら N+1、画面側なら不要な再描画」

並置のほうが実用的なことがあります。 抽象語だけだと読んだ側が自分の領域へ翻訳する手間が残るためです。

どこに置くかの見立て

提案するときは置き場所まで示す。ユーザーが「どれにするか」ではなく「やるか否か」を判断できる形にする。

まず範囲で振り分ける

内容がグローバルならグローバル設定へ、そのリポジトリ固有ならプロジェクト設定へ置く。

内容	置き場	例
どのリポジトリでも効かせたい	~/.claude/	コミットメッセージの書式、報告の粒度、レビュー対応の進め方
そのリポジトリだけで効く	そのリポジトリの .claude/	ディレクトリ構成の規約、使用ライブラリの流儀、そのリポジトリ固有の点検手順

判断は「どこで書いたか」ではなく「どこで効くか」。 プロジェクトの作業中に生まれた規約でも、内容が汎用ならグローバルへ置く。逆に、グローバル資産を整理していて出てきた話でも、特定リポジトリの事情ならプロジェクトへ置く。

迷ったらプロジェクト側に倒す。グローバルは毎セッション全文が展開されるので、関係ないリポジトリでも展開されるコストがかかる。後からグローバルへ上げるのは容易。

プロジェクト固有の資産を促す仕組みは、その資産と同じ側に置く。 グローバルからプロジェクトのスキルやドキュメントを名指しすると、それが無いリポジトリでは存在しないものを案内することになります。

「条件付きにすれば他リポジトリでも壊れない」は、置き場所が違うことの証拠です。 回避策を足したくなったらその時点で置き場所を疑う。

次に種類で振り分ける

性質	置き場
常に効かせたい振る舞いの規約	rules/*.md
呼ばれたときに踏む複数手順	skills/<name>/SKILL.md
ツール実行に反応させたい自動処理	settings.json の hooks
知っていれば判断が変わる前提	AGENTS.md

プロジェクトのルールは paths で絞れる。 特定のディレクトリやファイル種別でだけ効かせたいなら frontmatter に書く。グローバルルールでも、作業中のリポジトリのファイルに合わせるパターンなら効く（ rule_conventions.md ）。

重複を見つけたら、効かせたい範囲で寄せる

同じ規定が2か所にあると、片方だけ古くなります。 どちらを残すかはいつ効いてほしいかで決める。

効かせたい範囲	寄せる先	残す側
どの作業でも	ルール	スキルには固有の事情だけ残し、土台への参照を張る
その作業を実行する間だけ	スキル	ルールには置かない。呼ばれない場面で読む価値が無い
必ず走らせたい	フック	規約は消さない。deny の理由がその文章になる
知っていれば判断が変わる前提	AGENTS.md	「〜せよ」と読めるならルールへ移す

判定は「呼ばれなくても効いてほしいか」。 効いてほしいならルール、その場だけならスキル。

フックは置き換えではなく上乗せです。 判断が挟まる段を消しますが、列挙した形しか捕まえないので、書いていない形はルールが受け持つ（ references/when-rules-fail.md の「6つ目」）。

メモリだけは参照を張らずに消す。 ルールもメモリも常時ロードされるので、両方に残すと同じ規約が2回読まれる（同上「auto memory との境界」）。

置き場は仕様を確認してから決める

Claude Code の資産の種類と置き場は変わる。 記憶で判断せず、公式ドキュメントで毎回確かめる（ verify_before_asserting.md ）。

実際に起きた変更の例。

• custom commands は skills へ統合された。 commands/*.md と skills/<name>/SKILL.md はどちらも /name を作る。既存は動き続けるが、新規は skills に置く
• /output-style コマンドは削除されたが、output-styles/ ディレクトリは現役

確認するのは次の3点。

見るもの	なぜ
その種類がまだ推奨されているか	統合・廃止された置き場に新規で足さないため
より適した種類が増えていないか	手で書いていた手順が、機能として入っていることがある
強制が要るなら hooks に寄せられないか	ルールは読み飛ばされうるが、hooks は必ず走る。「毎回必ず」が要件なら hooks が正解

自分が実行できないことは規約にしない

規約は自分が守るためのものです。 従いたくても実行できない規定を書くと、自分には効かず、残るのはユーザーの手作業を規約の形で増やしたことだけになります。

「手段が存在する」と「自分が実行できる」は別です。 ここを取り違えると調べた結果が逆向きの根拠になります。

確かめたこと	そこから言えること
その仕組みがリポジトリにある	ユーザーが使える
自分の手元から動かせる	自分が使える

実際に、画面の変更に Before / After のスクリーンショットを並べる規定を書いて撤回しました。Storybook が入っていることは確かめましたが、それはユーザーが開けるという意味で、こちらから撮れるという意味ではありませんでした。

判定は「その規定に従うとき、最後まで自分の手で終えられるか」。 途中でユーザーに渡すことになるならそれは規約ではなく依頼です。

重い / 軽いで判断しない。 手間の量は、実行できるかどうかとは別の軸です。

命名

動詞-目的語 のケバブケース（ create-pr / resolve-ai-reviews / review-tests ）。ユーザーがスラッシュコマンドとして打つ名前なので、名前だけで何をするスキルか分かることを優先する。

見るもの	判断
既存の動詞	同じ意味の動詞を新しく持ち込まない。resolve があるのに apply を足すと、どちらを打つのか毎回迷う
対になるスキル	動詞を揃え、差分だけを変える（ resolve-ai-reviews ↔ resolve-human-reviews ）。並べたとき何が違うかが一目で分かる
略語	使わない。名前だけで中身が分かる形にする（ commit-push を cp と略さない）

新設する前に ls ~/.claude/skills/ で既存の動詞を見る。 名前を後から変えると、## 関連 やスキル間の委譲、ユーザーの手の記憶まで追随が要る。

単数と複数は、扱える対象の広さで決める。 1件しか扱わないなら単数（ review-pr ）、複数を扱えるなら複数にする。1件を指定して呼べても、横断できるなら複数（ finalize-prs ）。 1件用と横断用を別のスキルに分けない。仕上げの手順が2本に分かれ、片方だけ古くなる。

引数の取り方

同じ種類のスキルは、引数の取り方も揃える。 揃っていないと打つたびに順序を思い出すことになる。

種類	第1引数
特定の PR を扱う	PR 番号 または URL（省略時は現在のブランチから特定）
横断で扱う	リポジトリ名（省略時は全部）
差分やファイルを扱う	対象（省略時はワーキングツリー差分）

裸の数値を PR 番号以外の意味で使わない。 回数・件数・上限は --rounds N のような名前付きにする。 数値が2つ並ぶと順序を間違えても通ってしまい、スキル側では区別できない。

argument-hint を必ず書く。 引数を取らないスキルにも「引数なし」と書く。 無いと、渡せるのか渡せないのかが打つ側に分からない。書式は "[...]" で揃える（角括弧は省略可、山括弧は必須の意）。

frontmatter と本文を食い違わせない。 argument-hint を変えたら、本文の引数解釈も同時に直す。 片方だけ直すと、表示と挙動が食い違って原因が分かりにくいバグになる。

グローバルはグローバル間、プロジェクトはプロジェクト間で揃える。 置き場をまたいで無理に合わせない。 プロジェクト側は扱う対象がリポジトリ固有なので、同じ形にならないことがある。

ルール名（ rule_conventions.md、スネークケース）とは別の体系。ルールは何の規約か、スキルは何をするかを名前にする。

スキルの形

Anthropic の Skill authoring best practices から、手元で数えて確かめられる基準だけを置く。量の絞り方と分け方の考え方は /mattpocock-skills:writing-for-agents が持つ。

見るもの	基準
SKILL.md の本文	500行未満。近づいたら、場面が限られる節を references/ へ移し、SKILL.md には見出しと参照の1行を残す
参照の深さ	SKILL.md から1段まで。参照ファイルから別の参照ファイルへ辿らせると、2段目は head などで一部しか読まれないことがある。サブエージェントへ渡す指示のファイルは、渡した先が全文を読むので対象外
100行を超える参照ファイル	冒頭に ## 目次 を置き、見出しを並べる。一部しか読まれなくても、ほかに何があるかが分かる
description	何をするかと、いつ使うかの両方を書く。上限は1,024文字
時点で変わる情報	「〜月までは旧 API」のように日付で手順を分けない。古い手順を残すなら、別の節へ畳む
同梱するスクリプト	実行させるのか、読ませるのかを書き分ける

節を足したら、行数を wc -l で数え直す。 500行は足していくうちに越えるので、足した側が気づくしかありません。

新設したら、リンクを張って読めることを確かめる

home/.claude/skills/ へ置いただけでは呼べません。 ~/.claude/skills/ はスキルを1本ずつシンボリックリンクで並べたディレクトリなので、新しい1本は張られていません。

D=$(cd ~/Documents/repositories/github.com/kotahashihama/dotfiles && pwd)
ln -s "$D/home/.claude/skills/<name>" "$HOME/.claude/skills/<name>"

張ったら3つ確かめる。リンクの有無だけでは足りません。

見るもの	なぜ
[ -L ~/.claude/skills/<name> ]	張り忘れ
[ -r ~/.claude/skills/<name>/SKILL.md ]	リンク先が壊れていても -L は真になる
存在しない名前で読めないこと	検査そのものが空振りしていないか（陽性しか見ないと、常に真を返す検査に気づけない）

一覧に出るかは自分では観測できません。 システムから届く形なので、別のセッションへ聞くのが手立てです。

リストアは通っています。 scripts/lib.sh の PARTIAL_DIRS に .claude/skills があり、新しいマシンでは自動で張られます。壊れるのは動いているマシンだけです。

常駐から出した規定をスキルへ移したときは、これを飛ばすと再編そのものが失敗します。 実際に4本を移して張り忘れ、どこからも読めない状態を他セッションの指摘まで見逃しました。

委譲を書いたら、宛先がその内容を持っているか引く

〜が持ちます と書いた時点では、まだ何も確かめていません。 参照先が実在することと、そこに答えがあることは別です。

名指しした語で宛先を引く。 実際に「描き方は /format-post が持ちます」と書いたところ、あちらは Mermaid を4回出すのに図の種類を1つも書いていませんでした（ sequenceDiagram も flowchart も0件）。ファイルは実在するので、参照切れの検査は通ります。

無ければ、条件を述べている側へ書く。 宛先の主題がずれるなら足さない（あちらは手段の一覧で、「跨ぐなら」という条件を持っていない）。

陰性対照も取る。 存在しない語で0件になることを見ないと、その語がどのファイルでも当たる壊れ方を排除できません。陽性対照は検査が動くかを見て、陰性対照は過剰でないかを見ます。 委譲では後者が要ります。sequenceDiagram のような一般的な語ほど、別の理由で当たりえるためです。

手を入れたら全体を整理する

スキルを追加・変更・削除したときが、棚卸しのタイミングです。 定期的に見直す必要はありません。上記「分割・マージ・削除」の3つを確かめ、整理まで済ませて1つの作業とする。分割・マージ・削除の判定と、寄せるときの照合（ ### 1つへ寄せるとき ）・削除の判断（ ### 削除の判断 ）は、ルールとスキルで同じ節を使う。

あわせて委譲の整合を見る。委譲先の手順を自前で再定義していないか、## 関連 や本文の相互参照が実態と合っているか。手順が2箇所に散ると、片方だけ直る事故が起きます。

## やってはいけないこと に「この処理は別スキルの責務」と書いてあるなら、その委譲が実装されているかも確かめる。

依存の向きを見る

基準	外れたとき
個別のスキルから汎用のスキルへ向ける	汎用の手順を個別のスキルが抱えていれば切り出す
手元のスキルから pstack・mattpocock-skills へ向ける	両プラグインが持つ手順を手元で書き直していれば、そのスキルを呼ぶ形に置き換える
手順の中で呼ぶ関係に循環を作らない	共通の部分を下の層へ移す
呼ばれる側を disable-model-invocation: true にしない	呼ぶ側の手順が止まる

循環に数えるのは、手順の中で呼ぶ関係だけです。 ## 関連 で互いを案内し合うのは使い分けの説明なので、両向きにあってよい。

どちら側を触ったかで分かれる

~/.claude/ の実体は dotfiles リポジトリで、シンボリックリンク越しに編集しています。

実体の置き場	git	編集後
home/.claude/ （rules / skills / hooks / agents / settings.json / AGENTS.md）	管理下	コミットが要る
private/.claude/ と private/.claude-memory/ （メモリ・社内固有名を含むスキル）	.gitignore 対象	不要

どちら側かの見分け方は no_internal_names_in_public_assets.md が持ちます（スキルは両側にあり、リンク越しでは判別できない）。private/ 側なら連絡は要りません。

home/ 配下は公開リポジトリなので、社内固有名を書けません。 何を書いてよいかは no_internal_names_in_public_assets.md が規定します。

home/ 側を編集したら、渡す前に固有名を走査し、dotfiles のセッションへ連絡する。 走査のコマンドと連絡のしかたは references/after-editing-public.md にある。