context-audit

context-audit — 常時読み込まれるコンテキストスタックのトークン衛生

規約： conventions/brain-first.md を参照してください — 新しい監査を実行する前に、脳内に以前の監査レポートがあるか確認し （gbrain recall "context audit report"）、前回の実行からのトークンの変動を算出するとともに、 ユーザーがすでに却下した指摘を再度取り上げないようにしてください。

規約： conventions/quality.md を参照してください — 指摘にはすべてファイルと根拠を示し、出典のない主張はしません。

これは何か

すべてのターンで読み込まれるファイルは、トークン、遅延、そしてある程度を超えると 指示への追従品質に、ターンごとのコストをもたらします。常時読み込まれるファイルは 増え続けます（追記のみのリリースノート、誰も読み返さない昇格済みメモリブロック、 3つのファイルに重複して記載され、矛盾するようになったルールなど）。このスキルは、 常時読み込みスタック全体を一度に監査し、トークン削減量の多い順に並べた、 根拠を示すアクションリストを返します。

これは外科医ではなく、監査役です。測定し、問題を見つけ、順位付けし、推奨します。 変更を適用するのはユーザー（または、その後ユーザーが明示的に呼び出したスキル）です。

対象範囲：「常時読み込まれる」もの

このハーネスが実際に毎ターン読み込むものを列挙してください。固定リストがあると 決めつけてはいけません。一般的なスタックは次のとおりです。

ファイル	役割	修正先
プロジェクトの CLAUDE.md / AGENTS.md	オリエンテーション、ルーティング、不変条件	ファイル本体（ソースを編集可能）
ユーザー共通の CLAUDE.md	プロジェクトをまたぐ指示	ファイル本体（ソースを編集可能）
自動メモリの MEMORY.md	昇格済みメモリブロック	メモリストア（降格／期限切れ）
SOUL.md、USER.md、ACCESS_POLICY.md、HEARTBEAT.md、レンダリング済みの AGENTS.md	ブートストラップでレンダリングされるアイデンティティファイル	インタビュー回答バンク／テンプレート — レンダリング済みファイルは絶対に編集しない
ハーネスのシステムプロンプト断片（アイデンティティ／ツールのファイル）	ハーネスごと	そのハーネスが読み込む場所

スキル、リファレンスドキュメント、オンデマンドで読み込まれるものは、監査対象外です。 ただし、スキルへの抽出に関する指摘の移動先にはなります （特定のワークフローでのみ必要な内容は、常時読み込みスタックからスキルへ移す必要があります）。

契約

このスキルは、次のことを保証します。

• レポートのみ。 監査対象のファイルは編集せず、ページも作成せず、自動修正もしません — リスクゼロの指摘（🟢）も例外ではありません。出力は、ユーザーが意図的に適用する推奨リストです。
• レンダリング済みファイルの安全性。 ブートストラップでレンダリングされたファイルに関する推奨は、 回答バンクまたはテンプレートの変更として提示します （gbrain bootstrap interview --set KEY "..." の後に gbrain bootstrap render --only <FILE> --force）。直接編集を指示することはありません。 手順については skills/soul-audit/SKILL.md を参照してください。
• 根拠を明示した推定であり、数値を捏造しません。 トークン数は、決定論的な事前処理で算出します （wc -c のバイト数を2.8で割ります — Claude系のトークナイザーでは、パスやコードスパンの多いMarkdownは 1トークンあたり約2.6〜3.5バイトです。2.8は、常時読み込まれるMarkdownの実測値に基づく調整済みの中間値です。 #4988を参照してください）。レポートには除数を記載し、読者がすべての数値を再計算できるようにします。 ホストクライアントがカテゴリごとの正確なコンテキスト内訳（例：Claude Codeの /context）を報告する場合は、 その数値を推定値より優先し、引用してスタック合計に使用します。
• ネイティブな評価。 草案レポートは gbrain eval cross-modal で品質評価を受けます — 生のモデルAPI呼び出しは行わず、モデルIDもハードコードしません。
• コストの明示。 デフォルトの評価では、安価なモデルを1つだけ使用します （ユーザーのユーティリティ階層のモデル、3つすべてのスロット、--cycles 1 — 数セント程度）。 3プロバイダーによるフロンティアパネル全体を実行するのは、ユーザーが「full」または 「multi-model」監査を明示的に求めた場合のみです（1サイクルあたり約3倍以上のコスト）。

手順

1. スタックを列挙する（決定論的）

このハーネスで常時読み込まれるファイルを列挙し、それぞれを測定します。

# bytes/2.8 (calibrated for Claude-family tokenizers on markdown, #4988); integer ceil: (n*10+27)/28
for f in CLAUDE.md AGENTS.md SOUL.md USER.md ACCESS_POLICY.md HEARTBEAT.md MEMORY.md; do
  [ -f "$f" ] && echo "$f: $(wc -c < "$f") bytes (~$(( ( $(wc -c < "$f") * 10 + 27 ) / 28 )) tokens)"
done

合計を記録します。脳内に以前の監査レポートがある場合は、前回からの変動を算出してください （トークンの純増減、変化したファイル）。

2. 読み取りと分析（エージェントが実施 — モデル呼び出しはまだありません）

スタック内のすべてのファイルを最後まで読みます。次の6つの観点で評価します。

1. トークン効率 — 行動上の価値の単位あたりに消費するトークン数
2. 冗長性 — 同じルールや事実が複数のファイルに記載されていること
3. 矛盾 — ファイル間でルール、数値、ポリシーが食い違っていること
4. スキル化の適性 — 特定のワークフローでのみ必要な内容 （抽出候補：スキルに移し、必要に応じて読み込む）
5. 古さ — 古くなった事実、削除済み機能への言及、枠を維持する価値がなくなった昇格済みメモリブロック
6. 明確さ — 挙動を変えずに簡潔にできる指示、または誤作動を招くほど曖昧な指示

3. リスクごとに指摘を分類

• 🟢 リスクなし — 完全な重複や不要な内容だけを削除
• 🟡 低リスク — 明確な適用条件を設けた簡潔化またはスキルへの抽出
• 🔴 中リスク — エッジケースの挙動が変わる可能性のある変更

3つの分類はすべて推奨事項です。リスク分類はユーザーがどの程度慎重に対応すべきかを示すものであり、このスキルに変更を実行する権限を与えるものではありません。

4. ネイティブの評価ランナーでドラフトを判定

ドラフトレポートを一時ファイルに書き込み、次のコマンドで判定します。

# Resolve the cheap judge from the user's model tiers — never hardcode an ID.
# (`gbrain models` shows all resolved tiers if the config key is unset.)
JUDGE=$(gbrain config get models.tier.utility)

gbrain eval cross-modal \
  --task "Context-stack token-hygiene audit: every finding cites file + quoted evidence; savings are estimated (bytes/2.8, divisor stated in the report), never invented; findings ranked by token savings; every rendered-file recommendation targets the interview answer bank or template, never a direct edit; risk class on every row" \
  --output /tmp/context-audit-draft.md \
  --slug context-audit-report \
  --cycles 1 \
  --slot-a-model "$JUDGE" --slot-b-model "$JUDGE" --slot-c-model "$JUDGE"

フルの複数モデルパネル（明示的なオプトインがある場合のみ — ユーザーが「フル」または「複数モデル」の監査を依頼した場合）：--slot-*-model の上書きを省略し、ランナーのネイティブな3プロバイダーのデフォルト設定を適用します。

終了コード：0 PASS — 提出します。1 FAIL — ドラフト内で指摘された弱点（通常は引用のない主張や、レンダリング済みファイルへの変更提案）を修正して再判定します。2 INCONCLUSIVE（プロバイダーまたはキーの問題）— レポートを提出しますが、目立つように「未判定」と明記します。

5. 提出

レポートを会話内に出力します（「出力形式」を参照）。ユーザーが保存を希望する場合は、brain-ops スキルに引き継ぎ、openclaw/（エージェント状態のメモ）に記録します。このスキル自体はページを書き込みません。

スタックへの大幅な変更後、またはスケジュールに従って再実行する方法は、ユーザーが設定できるハーネスのルーティング規約です（cron-scheduler スキルを参照）。ここでは自動実行も定期実行の保証もありません。

出力形式

# Context Audit — YYYY-MM-DD

Stack total: ~NN,NNN tokens across N files (drift since last audit: +/-N,NNN)
Estimate basis: bytes/2.8 | host-reported exact total (e.g. `/context`): NN,NNN or n/a
Findings: N (~NN,NNN tokens recoverable) | Contradictions: N
Judge verdict: PASS (single-model, utility tier) | receipt: <path>

| # | Save (tok) | Risk | File | Finding | Evidence | Recommended fix (and WHERE it lives) |
|---|-----------|------|------|---------|----------|--------------------------------------|
| 1 | ~2,400    | 🟢   | ...  | redundancy: X restated | "quoted line" | delete from A; canonical copy stays in B |
| 2 | ~1,100    | 🟡   | SOUL.md | stale: ... | "quoted line" | update answer bank key VOICE_REGISTER, re-render — NOT a SOUL.md edit |
...

## Contradictions (fix these first, savings aside)
- FILE-A says "..." but FILE-B says "..." — resolve toward <one>, delete the other.

## Skill-extraction candidates
- <content> only matters when <workflow> — extract via skill-creator, load on demand.

トークン削減量の多い順に並べます。ただし矛盾は、規模にかかわらず最初に指摘します（トークンだけでなく正確性にも影響するためです）。各行には根拠（引用または行番号）を記載し、修正箇所（ソースファイル、回答バンク／テンプレート、メモリストア、新しいスキル）を明示します。

失敗時の対応

gbrain のエラー code、終了コード、[AGENT] ブロック、または通知ブロックについては、エージェント運用者プロトコルに従います。このスキル固有の対応は次のとおりです。

• gbrain eval cross-modal が終了コード1（FAIL）で終了した場合：指摘された弱点を修正して再実行します。失敗した監査を合格として提出してはいけません。
• 判定モデルまたはプロバイダーキーが設定されていない場合：監査は構造のみを対象に実行されたと伝え、不足しているキーを明記します。スコアを捏造してはいけません。
• 有料の複数モデル監査で no_pricing またはコスト上限に達した場合：デフォルトの低コストな単一判定モデルに切り替え、その理由をユーザーに伝えます。

アンチパターン

• 監査対象ファイルを編集すること。 報告のみです。🟢 リスクゼロの削除であっても、推奨事項であり、実行する操作ではありません。「自動修正」を約束すると、レンダリング済みファイルの保護ルールに反し、契約の範囲外となります。
• レンダリング済みファイルへの直接編集を推奨すること。 SOUL.md / USER.md / ACCESS_POLICY.md / HEARTBEAT.md への編集は、次回の gbrain bootstrap render で上書きされます。回答バンクまたはテンプレートを対象にしてから、再レンダリングしてください。
• 判定にモデル API を直接呼び出すこと。 プロバイダー設定、レシート、判定の集約は評価ランナーが担います。gbrain eval cross-modal を介してください。
• モデル ID をハードコードすること。 ユーザーのモデルティアから判定モデルを解決してください。スキル本文に記載したモデル名は古くなります。
• デフォルトで複数モデルのパネル全体を実行すること。 これは明示的なオプトインです。コスト上の理由から、デフォルトでは低コストの単一モデルによるパスを使用します。
• オンデマンドのコンテンツを常時読み込み対象として監査すること。 スキルとリファレンスドキュメントにはターンごとのコストがかかりません。これらを指摘すると、節約量が水増しされます。
• トークン数を捏造すること。 事前パスを実行してください。推定値には除数を明記したうえで ~N と表示し、ホストが報告した正確な数値があれば、常にそちらを優先します。
• アイデンティティに関するコンテンツを自分で書き換えること。 指摘事項がアイデンティティファイルの記述内容（誤ったペルソナ、古いプロフィール）に関するものであれば、soul-audit に引き継いでください。そのコンテンツを作成するのはインタビューのみです。

重複排除

• soul-audit — インタビューを通じたアイデンティティの内容：SOUL.md/USER.md に何を記載すべきかを、ユーザー自身の言葉に基づいて判断します。context-audit はトークン／構造の整理を担当し、スタックがターンごとにどれだけのコストを要するか、どこで重複や矛盾が生じているかを確認します。「USER.md のプロフィールが古い」という指摘は soul-audit に引き継ぎます。「USER.md が SOUL.md にすでにある 800 トークンを繰り返している」という指摘は、ここで扱います。どちらも同じレンダリング済みファイルのルールを守ります。
• skill-optimizer — ベンチマークに照らして単一のスキルの本文を調整し、変更することもできます。context-audit は変更を行わず、常時読み込み対象のファイルのみを確認します。スキルは抽出先としてのみ登場します。
• functional-area-resolver — サイズが大きすぎる（>=12KB）ルーティングテーブルを圧縮する技法です。ルーティングセクションに関する指摘に対する推奨修正として、context-audit がこれを挙げることはありますが、適用することはありません。
• skillpack-check — インストール／ランタイムの健全性（DB、ワーカー、マイグレーション）を確認します。コンテキストサイズやプロンプトの内容は対象外です。
• cross-modal-review — 任意の成果物に対する一般的なセカンドオピニオンのゲートです。context-audit は同じ基盤のランナーを使用しますが、監査固有の合格基準を設けた独自の固定判定ステップとして使用します。「このコードについてセカンドオピニオンがほしい」という依頼は、ここではなくそちらに回します。