context-audit

コンテキスト監査

プロンプトは1つのタスク向けに書かれますが、コンテキストはすべてのタスクで再利用されるため、特定のタスクに合わせることはできません。この差が、指示を陳腐化させます。実際にはもう起きない最悪のケースに備えて書かれたルール、3つのレイヤーに重複したガイダンス、モデルにひそかに相反する指示を出す2つのレイヤー。モデルはそのすべてを解決できますが、そのぶん、実際の作業を始める前に思考予算を消費します。このスキルは、削除すべきものを見つけます。

手順

1. モデルに届くすべてのレイヤーを洗い出します。ルートとネストされた CLAUDE.md／AGENTS.md、各スキルの説明と本文、フック、ツールと MCP サーバーの説明、ユーザーが制御するハーネスプロンプトです。各レイヤーのサイズを報告します。ユーザーが書いたことを忘れているレイヤーが、たいてい最も強く主張しています。
2. モデルが受け取るときと同じように、個別のファイルではなく、すべてをまとめて読みます。矛盾はレイヤー間でのみ生じます。
3. すべての指示を次の5つに分類します。
   • 矛盾 — 2つのレイヤーが正反対の方向へ導いています（「適宜ドキュメントを記述する」と「コメントを追加しない」など）。両方の文言をそのまま引用します。最もコストの大きい指摘なので、最初に挙げます。
   • 重複 — 同じ指示が2か所にあります。実際に使う場所に近い方を残します。ツールの動作はグローバルな前文ではなく、そのツールの説明に記載します。
   • 自明 — ファイルツリー、言語、または周辺のコードからすでにわかることを言い換えています。
   • その場で判断可能 — 最悪のケースを防ぐために書かれた一律のルールですが、実際の一部の依頼には当てはまらず、現在のモデルが適切に判断できる種類のものです。
   • 要点 — このリポジトリ固有の、明白ではない、重要な指示です。残すべきなのはこれです。多くのリポジトリでは、残りの4種類が大半を占めます。
4. 削除案を差分として提示します。まず矛盾を解決し、次に重複を整理し、その後に残りを扱います。残す価値はあるものの、必要なときにしか使わないものは、削除するのではなく、スキルやオンデマンドで読み込むリンク先ファイルへの移動を提案します。
5. 変更前後の行数と、削除に最も確信が持てない1項目を明示して締めくくります。人間が判断できるよう、その項目を明確に示します。

ガードレール

• 提案するだけにとどめ、適用しません。削除はすべてユーザーの承認を得ます。
• 過剰な制約に見えるルールが、実際のインシデントから生まれた再発防止策であることもあります。特定の失敗に言及しているものは削除せず、確認を求めます。
• 指示は、賢明に聞こえるかではなく、動作を変えるかどうかで判断します。モデルが既定で従う指示は、何も伝えていないのにトークンを消費します。
• ハーネスに独自の適正化コマンドが含まれている場合、この監査はそれに取って代わるのではなく、並行して実行します。
• 実際の不変条件を削除する監査は、節約したトークンよりはるかに大きな損失を招きます。目的が不明な行がある場合は、その曖昧さ自体が指摘事項です。推測せずに報告します。