system-audit

システム監査

Ane の MEL/SRHR システムに対して、品質／健全性／効率性の監査を実施します。ファイルパスと推奨する実施順序を記載した Tier 1 の作業概要を出力します。修正は実行しません。Ane がそれぞれを確認し、承認します。

使用する場面

• Ane が /system-audit、/audit、/system-check と入力したとき、またはシステムの健全性チェックを依頼したとき
• /li curate の実行前（監査で、curate が統合すべき問題を洗い出します）
• エージェントの改善に関する大幅な作業の後、ずれが生じていないことを確認するとき
• 気づかないうちに生じるずれを防ぐため、定期的な確認として

このスキルは、/test（ハーネスのみ）や /li lint（Wiki のみ）と重複するのではなく、それらを補完します。レイヤー間の不整合を検出する、より広範なチェックです。

ワークフロー

ステップ 1 — ハーネスの状態（迅速、機械的）

次の順序で実行します。

1. python tests/run_tests.py（静的。出力された件数を報告し、記憶している件数は使わないでください）
2. python tests/run_tests.py --output（フィクスチャモード。一部のフィクスチャは意図的に未キャプチャの場合があります）

失敗を解析します。各 [FAIL] 行を、表示されている file:line とともに検出事項リストに追加します。失敗を再実行したり、修正を試みたりしてはいけません。記録するだけです。

ローカルのハーネスがグリーンでも、ハーネス全体がグリーンとは限りません。最新の routine-reports/weekly-health-check-*.md を読み、そこにあるハーネスの行を、たった今実行した結果と比較してください。 週次のクラウドルーチンは、環境の準備方法が異なる環境で同じコミットを実行します。入力が環境に依存するチェックは、ローカルではパスしても、そこで失敗します。両方の数値を報告し、件数または判定に違いがあれば、クラウドの不安定さではなく検出事項として扱ってください。この差には、ローカル実行では見えない、互いに異なる失敗が 2 つ隠れています。リモートにインストールされていないファイルに語彙の半分が含まれているためリモートで FAIL になるチェックと、glob の走査対象が空のルートを回り、ファイルが 0 件なのに集計結果をパスと報告するためリモートのチェック件数が少なくなるケースです。後者のほうが危険です。成功に見えるためです。発端となったケース（2026-09-09 の移行後監査）：ローカルでは 380/380 で問題がなかった一方、クラウドルーチンでは少なくとも 2026-08-31 以降、10 日間気づかれないまま 318/319 のハード FAIL が報告されていました。workflow-drift:qa_block fields resolve は qa-block-schema.md と vi/SKILL.md の両方からフィールドの語彙を構築していましたが、2 つのフィールドがスキルにしか記載されていなかったためです。ローカル実行がパスしても、この問題は検出できません。件数が異なる場合は、チェック自体に手を加える前に、リモートで不足している入力を診断してください。通常は、正規ソースが不完全で、スキルファイルが気づかれないままその不足を補っているのが原因です。合計ではなくチェック名を比較し、診断の前にクラウド環境をシミュレートしてください。 HOME、USERPROFILE、PERSONAL_SKILLS_CLONE を空のフォルダーに設定し、CLAUDE_CODE_REMOTE=true としてハーネスを実行します。両方の実行から Suite.results の名前を収集し、セットを比較します。2026-10-07 の 417 対 358 の差は、主に重複した名前によるものでした（エージェントごとのチェックは、ローカルでは agents ディレクトリごとに 1 回実行されます）。リモートで本当に欠けていたチェックは 13 件だけでした。同じシミュレーションで、直近の修正では手をつけていなかったクラウドの赤判定も再現されました。シミュレーション中の git-identity の失敗は無視してください。空のホームフォルダーが原因です。

3. 何かを測定する前に SKILLS_DIR を解決し、返されたルートを報告してください。 python -c "import sys; sys.path.insert(0,'tests'); import run_tests as rt; print(rt.SKILLS_DIR, len(list(rt.SKILLS_DIR.glob('*/SKILL.md'))))" を実行します。複数のインストール先ルートに SKILL.md のコピーが存在し、それらの内容は互いに異なることがあります。そのため、誤ったルートを基準に測定した行数、予算チェック、カバレッジの主張は、単純に誤りです。CLAUDE.md やこのスキルに書かれたパスからルートを推測してはいけません。ハーネスで確認してください。 2 回の実行でチェック件数が同じでも、スキルの変更が影響しなかった証拠にはなりません。glob ベースの走査は、対象ファイル数にかかわらず、それぞれ集計チェックを 1 件だけ報告するためです。

   次に、そのルートを personal-skills クローンと比較し、ルートに存在しないスキルと、内容が異なるスキルの両方を一覧にします。2026-07-29 には、解決されたルートにはファーストパーティのスキルが 7 件まるごと欠け、さらに 6 件の古いコピーがあったにもかかわらず、ハーネスはグリーンでした。また、監査概要ではルートを解決せずに推測していたため、最初に誤ったディレクトリが指定されていました。両者が異なる場合は、何かをコピーする前に、どちらが古いかを診断してください（行数と diff の方向を比較します）。新しい側が常にインストール済みとは限らず、コピーすると指定した側のファイルが上書きされます。cmp ではなく diff -q --strip-trailing-cr を使って比較してください。Windows ではインストール先ルートに LF のソースから CRLF のコピーが置かれているため、2026-10-07 にはバイト単位の比較で 21 件の誤った差異が報告されました。

ステップ 2 — ドキュメントの整合性（中程度の重大度、高い影響）

並行して読みます。

• ~/.claude/CLAUDE.md — 自己矛盾がないか確認します。よくあるパターン：専門家の人数のずれ（同じファイル内に「16」と「20」がある）、バージョン番号のずれ、レイヤーテーブルのずれ。
• <work folder>/CLAUDE.md — 古い数値（専門家の人数、ハーネスのチェック数、ページ数、エージェントチームのメンバー数）がないか確認します。
• ステップ 1 で解決した SKILLS_DIR 配下の {ann,vi,li,researcher}/SKILL.md。ハードコードされたパスは使わないでください。行数が予算内か確認します（予算の現在の数値は tests/run_tests.py の SKILL_BUDGETS から読み取ってください。これが信頼できる情報源です。ここに記載された数値は古くなるため、信用しないでください）。合格か不合格かだけでなく、残りの余裕も報告します。予算まで 5 行以内のスキルは要指摘です。次の編集で、内容ではなく計算上の理由からハーネスに失敗するためです。本文の散文におけるエムダッシュの数も確認します（CLAUDE.md の文体規則に従います。ただし、スキルファイルのリスト項目の区切りとフロントマターは除外します）。
• agent-improvements/agent_registry.md — ### の項目数を数えます。完全性を確認するため、Vi の分類表と照合します。各名前について、~/.claude/agents/<name>.md が存在するか照合します。

各指摘について、ファイルパス、行番号（記載されている場合）、問題の内容、以下の失敗修正表に基づく修正案を記録します。

ステップ 3 — オーバーレイと CURATE の状態（中程度の重大度）

並行して読みます。

• agent-improvements/{ann,vi,li,researcher,community}-overlay.md — ファイルサイズ（上限 35KB）と Active 項目数（上限 10）を確認します。どちらかが上限を超えている場合は、アーカイブのみの CURATE ではなく、圧縮 CURATE を要指摘とします。community-overlay.md（主張スペースに関するフィードバックログ。2026-05-06 に作成）にも同じ上限を適用します。
• agent-improvements/coordination-log.md — STATUS: OPEN の項目数を数えます。
• agent-improvements/_pending-ingest.md — Status: PENDING の行数を数えます。対応のため Ane に伝えます。
• agent-improvements/PROPOSED-*.md — 各ファイルの Status: フィールドを確認します。7 日を超えて AWAITING APPROVAL のままのものがあれば指摘します。

ステップ 4 — 整理（低い重大度、目に見える雑然さ）

次を確認します。

• agent-improvements/_temp_*.md — 7 日を超えたファイルは、古い候補です。日付を取得するには ls -la を使います。
• agent-improvements/proposed-agents/*.md — 各 .md（README を除く）について、~/.claude/agents/<same-name>.md が存在するか確認します。存在する場合、デプロイ時にステージングコピーを削除しているはずです。差異を確認するには diff -q を使います。
• agent-improvements/SESSION-STATE-*.md — 各ファイルを読み、内部矛盾（表のセルと箇条書きの記述が食い違っている、または進捗状況フィールドが一致していない）がないか確認します。
• mel_wiki/wiki/raw/ のサイズ — 空であってはなりません（不変性ルールでは、Li は読み取りのみで変更しないことになっています。空の場合、取り込みが停止しています）。

ステップ 5 — アーキテクチャ上の上限（バグではなく決定事項）

確認する項目：

• agent-improvements/qa-rejection-log.md — 率を測るメーターではなく、事例登録簿として読んでください（ヘッダーでは 2026-09-09 に率のトレンド分析が撤回されており、率を扱うのはトレンド対象の行が 20 件以上になってからです）。このログに記録するのは Ann/Vi がオーケストレーションした実行のみで、/wrap-up のチェック 4b を介して記録されます。そのため、ログが空だからといってテレメトリの欠落と判断する前に、同じ期間の cost-calibration-log.md でオーケストレーション実行の件数を数えてください。実行がなければ、ログが空なのは正しく、判明したのは不具合ではなく利用状況です（2026-10-07：前回の記録以降、140 行中オーケストレーションはゼロ）。qa-disagreement-log.md は履歴専用であり、Vi/Li の引き上げ監視トリガーは測定不能として撤回され、2026-07-30 に稼働中のカウンターとしての役割を終えています。その行を監視対象として数えないでください（2026-08-05 の監査では、古い評価システムのコピーを引き継いだ結果、数えてしまい、廃止済みの上限を「監視中」と報告しました）。
• agent-improvements/cost-calibration-log.md — 実測値が記録された行と not observed の行を数えてください。実測値がある行が 30% 未満なら、可観測性は依然として弱い状態です。
• claude.ai ミラーのサイズ — ミラーは現在 2 つのファイルで構成されています。mel-framework-reference.md（コア：常設ルール、クイックリファレンステーブル、レンズ、ECA のキャリブレーション）と mel-framework-appendix.md（番号付きのフレームワーク項目）に分割され、2026-07-30 に 194KB で分割されました。統合後のサイズ上限を再び持ち出さないでください。 上限は 3 回変更され（2026-04-28 に基準値 117KB、2026-05-10 に 174.7KB、そして 200KB）、変更のたびに約 1 週間しか効果がありませんでした。サイズがコストなのではなく、claude.ai にはファイル API がないため、編集のたびに編集対象ファイル全体を手動で再貼り付けする必要があることがコストだからです。この分割はその問題に直接対処しており、常設ルールを編集した場合に再貼り付ける量は 194KB ではなく 30KB になりました。サイズについて判断するのはあなたの役割ではなくなりました。/test が毎回、claude-ai:framework core ≤ 50KB によってこれを検証します。フレームワーク項目が付録からコアに戻ると失敗します。また、claude-ai:framework mirror build stamp current in both halves によっても検証し、2 つのファイルの内容にずれが生じると失敗します。ここでの判断チェックは Ane が監査を実行したときしか作動しませんでしたが、ハーネスは常に作動します。あなたに残された作業は python scripts/check_desktop_sync.py を実行し、claude.ai に対してどちらかのファイルが古くなっていないか報告することです。実際にプロジェクトナレッジに反映された内容を確認できるスクリプトはないためです。
• wiki 本文の散文全体における em ダッシュの使用ルール。単純な grep -c "—" は過剰に数えます。セクション見出し、title: のフロントマター、テーブル行、リスト項目内の 用語 — 定義 の区切り、引用文のタイトルにそのまま含まれる em ダッシュまで拾うためです。まず構造上のノイズを除外してください：grep -rnE "—" mel_wiki/wiki/ --include="*.md" | grep -vE ":[0-9]+:#|title:|\||\[\["。除外後の件数を直近の監査ドリフトの基準値と比較してください。絶対数よりも推移が重要です。リスト内の定義を区切るダッシュや引用文のタイトルは除外後にも残るため、残った箇所は目視で確認してください。コンマでは実際に曖昧さが生じる同格表現での使用は許容されます。

ステップ 6 — 最近の監査ドリフトの引き継ぎ

agent-improvements/audit-drift-*.md が存在する場合：

1. 最新のファイルを読みます（ファイル名の日付順に並べます）。
2. 以前に指摘された各項目について、解決済みかどうかを確認します。
3. 未解決の項目を、[carry-forward from audit-drift YYYY-MM-DD] と記して所見に引き継ぎます。
4. 再度指摘する前に、数値予算をその正式な定義元で確認してください。 引き継いだ項目の所見に数値予算（行数上限、ファイルサイズ上限、トークン上限）が記載されている場合は、まず正式な上限定義を確認します。定義元は tests/run_tests.py の SKILL_BUDGETS または P1_SECTION_TOKEN_CAP、あるいは所見で指定されている設定です。その指標が現在も存在し、同じ数値が適用されていることを確認してください。上限が廃止または変更されている場合は、所見を [stale heuristic, not a live breach] に格下げし、実際に適用されている指標を明記して、古い数値を再度指摘しないでください。背景となった事例：ハーネスが全体の行数上限をセクションごとのトークン上限（P1_SECTION_TOKEN_CAP）に置き換えた 2026-04-30 以降も、「index.md が 200 行を超えている」という違反が現行の問題として引き継がれていました。このサブステップではハーネスを再実装しません。予算の適用は /test が担い、監査では廃止された上限を再度指摘しないようにします。

これにより、同じ問題が監査のたびに新たな問題として再度指摘されるのを防ぎ、監査間で暗黙のうちに抜け落ちることも防ぎます。

ステップ 7 — スキルのトリガーと誘導の整合性（skill-quality）

スキルの 4 つの評価軸（トリガー、構成、誘導、整理）を適用します。このうち 3 つはすでに別の箇所で扱っています。トリガーの品質は skill-creator の評価で、構成は superpowers:writing-skills で、整理はステップ 3～4 とハーネスの予算で確認します。このステップで追加するのは、ほかの評価軸では見落とされる誘導です。つまり、実際に呼び出されたスキルがエージェントの行動を適切に制約しているかを確認します。

personal-skills の skills/ ツリー配下にあるファーストパーティスキルと、{ann,vi,li,researcher} チームのスキルを読みます。それぞれについて、次の 3 点を確認します。

• トリガーの競合。 description のトリガーフレーズが重複しているにもかかわらず、いずれのスキルも他方への委譲を明示していない、モデルから呼び出し可能なスキルが 2 つある状態です。description: のフロントマター行から共通するトリガー動詞（grill、review、plan、debate、design）を grep し、重複する組み合わせを目視で確認します。disable-model-invocation: true のスキルはユーザーが呼び出すものに限られ、競合しないため、対象から除外します。より具体的なスキルが、自身の担当範囲を明示し、説明内で近接するスキルに別の担当範囲へ誘導していれば、競合は解消されています（具体例は grill-mel を参照してください）。
• 誘導の強さ。 本文には、エージェントが取るべき具体的で順序立てられたアクション、番号付きのワークフロー、判断ルール、出力テンプレート、「してはいけないこと」の一覧がありますか？ それとも、トピックを示すだけで、あとはエージェントの即興に任せていますか？ 呼び出されても行動を制約しないスキルは、誘導の失敗です。本文に命令形のワークフロー、判断ルール、出力セクションのいずれもないスキルは指摘してください。指摘する前に本文を読み、見出しのキーワード検索だけでこの評価軸を判断してはいけません。 段階的開示を採用するスキルは、誤検出の典型です。SKILL.md が意図的に短く、誘導を references/ または scripts/ ディレクトリに委ねている場合も、誘導があると見なします。2026-08-15 の見出しキーワードによるチェックでは 7 つのスキルが指摘されましたが、すべて本文を読んだ結果、問題なしと判定されました。ゲート、モードの振り分け、番号付きの段階が、検索に一致しない見出しの下にあったためです。まず関連するディレクトリを確認し、その後、内容を読みます。
• 誘導の漏れ。 説明で禁じられている行動を、本文がエージェントに許していませんか？ 例：「ファイルを書き込まない」または「書き込みなし」をうたうスキルの本文に書き込みを防ぐ指示がない場合や、「判断しない」スキルの本文が判断に踏み込んでいる場合です。説明と本文の矛盾を指摘してください。
• リスト到達性 — ファイルを読む前に、まずこれを確認してください。 セッション開始時に読み込まれた、自身が利用できるスキル一覧を確認し、説明がなく名前だけが表示されているスキルを記録してください。説明が一覧に表示されないスキルは、トリガーとの一致によって選択できません。そのため、そうするつもりがなくてもユーザーによる呼び出し専用となり、説明内のルーティングに関する文言はすべて機能しません。この軸はファイルを調べても見えません。2026-07-30には、インストール済みの54個のスキルすべてが4つのインストール先で正常に解析され、description も問題なく設定されていた一方、ファーストパーティのスキル9個が名前だけの表示になっていました。また、影響の有無を分けるディスク上の属性はありませんでした（同じインストールバッチ、同じ更新日時、BOMなし、説明の長さも重複）。さらに、一覧はセッション開始時に固定され、あとから再確認できないため、あとからこの状態を復元することもできません。ですから、最初のターンで、ファイルを1つも開く前に記録してください。原因はすでに診断済みで、Aneも判断を下しているため、影響を受けたものを記録して先へ進み、原因を改めて調べないでください。 名前だけの表示は、ドキュメントに記載されたスキル一覧の予算上の仕様であり、不具合でもAnthropicのバグでもありません。skillListingMaxDescChars（デフォルト値は1536）が説明ごとの上限を定め、skillListingBudgetFraction（コンテキストウィンドウのデフォルト値の0.01）が一覧全体の上限を定めています。そのため、一覧が予算を超えると説明が短縮されます。Aneの当初の判断は、現状のままにし、重要なスキルが一覧から消えた場合にのみ再検討することでした（agent-improvements/handoffs/system-audit-follow-ups.md、決定事項1）。その条件は2026-10-07に満たされ、Aneは~/.claude/settings.jsonのskillListingBudgetFractionを0.02に引き上げました。新しいセッションでは、proposal、tor-procurement、toc-builderが再び表示されることを確認しました。モデルから呼び出し可能なスキルが再び一覧から消えた場合は、その旨を報告し、次の段階として設定のみを0.03に変更する案を推奨してください。Aneの承認を得てから変更します。2026-08-15の確認では、これを最初から調べ直し、原因不明の不具合として報告してしまいました。この段落は、まさにその無駄を防ぐためのものです。ですから、影響を受けたスキルと、その中に重要なものがあるかどうかを報告してください。原因の調査を始めてはいけません。また、修正のためにスキルファイルを編集してはいけません。失われているのはファイル内の情報ではなく、一覧への表示だからです。名前だけの表示が想定されるケースが1つあり、確認対象を絞り込めます。disable-model-invocation: trueを持つスキルは仕様上、名前だけで表示されるため、指摘する前に除外してください。Workflowの項目（.claude/workflows/*.js）を一律に除外してはいけません。 このルールの2026-08-05版では、ワークフローはメタ情報の内容にかかわらず常に名前だけが表示されるという考えから、一律に除外していました。2026-08-15に、この考えは誤りだと判明しました。3つのワークフローはいずれもdescriptionとwhenToUseを持っていましたが、citation-verificationでは説明が全文表示される一方、deliverable-qaとvi-executionは名前だけの表示でした。ワークフローは説明が表示されることがあるため、一律の除外によって、実際に確認すべき2件を見落としていました。ワークフローは、metaにdescriptionもwhenToUseも含まれていない場合に限り、除外してください。その場合、表示する情報がないためです。モデルから呼び出し可能なスキル、またはメタ情報に問題がないワークフローのうち、説明が一覧に表示されていないものはすべて指摘してください。

それぞれを、スキルのパスと、該当する不具合の軸（listing-unreachable、trigger-collision、steering-weak、steering-leak）を添えて所見として記録してください。この評価基準はPocock（2026）Building Great Agent Skills: The Missing Manualをもとにしています。この手順で監査に加わるのはsteering軸であり、リスト到達性の軸は、5つのスキルのルーティングが正しいと評価された一方、そのうち1つはルーティングではまったく到達できなかったことを受け、2026-07-30に追加されました。

ステップ 8 — 指示の競合監査（読み込み対象のリンティング）

重複し、矛盾する指示は、タスク開始前にモデルの判断力を消費します。Claude 5 世代のモデルでは、この失敗モードはルールの欠落よりも優先度が高くなります（Shihipar 2026、Anthropic のコンテキストエンジニアリングガイダンス）。すべてのセッションで読み込まれる対象を監査してください。~/.claude/CLAUDE.md、プロジェクトの CLAUDE.md、出力スタイルブロック、セッション一覧に表示されるモデル呼び出し可能なスキルの説明が対象です。

1. 重複して内容がずれた指示。 同じルールが、文言、範囲、数値を変えて複数の対象に記載されています。両方の CLAUDE.md ファイルで共通のアンカーフレーズ（ルール名、しきい値、ファイルパス）を grep し、一致する箇所を diff してください。ガバナンスマーカーの範囲が重複しているのは、Web との整合性のために意図的です。その範囲では、対応する governance:* マーカーペア間の共通ルール本文を比較し、ずれのみを指摘してください。重複自体は決して指摘しないでください。
2. 矛盾。 ある対象が別の対象で禁止されていることを要求している、または同じ行為に異なるしきい値（権限モード、文字数上限、引用の配置など）を設定しています。候補となる各組み合わせを目視で確認し、両方の該当ファイルと行番号を報告してください。
3. トリガーの所有権。 スキルの説明と CLAUDE.md のルールが同じトリガーを要求するなど、複数の対象が同じ動作を要求しています。プロジェクトの CLAUDE.md のスキルルーティングセクションにあるトリガー規律のルールに従って解決してください。

各検出事項を次のように分類してください。矛盾（中）、重複して内容がずれた指示（中）、またはガバナンス範囲外の問題のない重複（低、ゴールとポインターへの置き換え候補）。ガバナンスコンテンツの修正には governance-rules.md と sync_governance_rules.py を使ってください。マーカー間を手動編集してはいけません。

問題と修正の対応表（クイックリファレンス）

問題カテゴリ	可能性の高い修正
CLAUDE.md のスペシャリスト数のずれ	古い数値を現在の agent_registry.md の数に置き換える
Vi の分類表にスペシャリストがいない	agent_registry.md の項目に合わせた行を追加する
Vi のモデルルールがレジストリと競合している	Vi をレジストリの model_default フィールドに合わせる。レジストリが正です
スキルファイルが予算超過	説明文を簡潔にし、詳細を wiki に移す。tests/run_tests.py で Ann／Vi／Li／Researcher のスキル上限を編集するのは最終手段にする
本文の em ダッシュ	mel-report-writer の実例パターンに沿って変換する（同格表現 → コンマ、列挙の導入 → コロン、文の区切り → ピリオド）
古い _temp_*.md ファイル	7 日以上前のもので現在参照されていない場合は git rm を実行する
proposed-agents/ にデプロイ済みエージェントがある	ステージングされたコピーに git rm を実行する。~/.claude/agents/ にあるものが正規版です
オーバーレイが 35KB の上限を超えている	内容を実質的にキュレーションする（項目を圧縮し、アーカイブするだけにしない）。このサイズでは Li のアーカイブのみの処理では不十分です
qa_block のスキーマとスキルの不一致	スキーマが正です。スキルの文章をスキーマのフィールド名に合わせる
モデル呼び出し可能な 2 つのスキル間でトリガーが競合している	より具体的なスキルの説明に対象領域を明記し、隣接するスキルの対象から外す。または、Ane が常に名前を指定して呼び出す方に disable-model-invocation: true を設定する
誘導性の弱いスキル（発火するが制約を与えない）	本文に番号付きのワークフロー、判断ルール、または出力テンプレートを追加する。説明だけでは誘導できません
誘導の漏れ（本文が説明で禁止した行為を許可する）	説明の制約に対応する明示的なガードを本文に追加する（例：書き込み禁止のスキルでは、Write/Edit を使ってはならないと記載する）
読み込み対象間で指示が矛盾、または重複して内容がずれている	正規の記述を 1 つ残し、コピーはポインターに置き換える。ガバナンス範囲は governance-rules.md と sync_governance_rules.py で再生成し、手動で編集してはいけません

出力形式

Tier 1 の作業ブリーフ。最初の文に BLUF を記載してください。em ダッシュは使用しないでください。em ダッシュの規律を監査しているため、確認対象のルールに違反してはいけません。平易な英語を使ってください。能動態にしてください。各文は 25 語以下にしてください。CLAUDE.md の「Tier 1 working brief」ルールに従ってください。

次のテンプレートを使ってください。

# System audit — YYYY-MM-DD

**BLUF: [N issues found, M severity-medium, P severity-low, Q architectural decisions. None blocking. X are quick fixes.]**

## Tests run
- python tests/run_tests.py: N/N
- python tests/run_tests.py --output: M/N (deferred fixtures noted)
- Manual audit of: [list]

## Documentation drift (medium severity)

| # | Issue | File | Fix |
|---|---|---|---|

## Skill trigger and steering (medium severity)

| # | Skill | Axis (trigger-collision / steering-weak / steering-leak) | Fix |
|---|---|---|---|

## Conflicting instructions (medium severity)

| # | Directive | Surfaces (file:line vs file:line) | Class (contradiction / duplicate-drifted / benign duplicate) | Fix |
|---|---|---|---|---|

## Hygiene (low severity)

| # | Issue | Evidence | Fix |
|---|---|---|---|

## Architectural ceilings (decision points)

| # | Issue | Implication |
|---|---|---|

## What is working

- [5-8 bullet items: harness clean, qa_block schema operational, P1 triple-load fix landed, etc.]

## Recommended sequencing

- Quick batch (~30 min): [issue numbers; mechanical edits]
- Focused pass (~1 hour): [issue numbers; need judgement]
- Strategic decision: [issue numbers; require Ane's call]

**Evidence base:** [inline file paths]

してはいけないこと

• 修正を自動実行しないでください。Ane が各修正を確認して実行します。
• 既知の先送り項目を新しい問題として指摘しないでください。agent-improvements/system-audit-*.md と audit-drift-*.md を照合し、すでに文書化され、了承されている内容を確認してください。
• ハーネスの出力を重複させないでください。python tests/run_tests.py でチェックを静的に実施できる場合は、ハーネスの結果だけを報告し、指摘を独自に導き出さないでください。
• 評価を出さないでください。それは /grade-system の役割です。
• システムをお世辞で持ち上げないでください。指摘件数と深刻度を正直に伝えてください。

締めくくり

概要を提出する前に、メンテナンスの実施日時を記録してください：python ~/.claude/hooks/maintenance_due.py --mark system-audit 2>/dev/null || true（Web コンテナなど、フックがないマシンでは何も行いません）。

概要の末尾は次の文にしてください：「クイックバッチの修正を今すぐ実行しますか？」その後は待機してください。Ane が確認するまでは、何も実行しないでください。

Ane が確認した場合は、クイックバッチ（機械的な編集）を実行してください。重点的に確認する項目については、項目ごとにもう一度確認を求めてください。判断を伴うため、Ane に項目ごとに承認してもらう必要があります。戦略的な判断が必要な項目は、自動実行しないでください。

コストの目安

監査を問題なく完了する場合、約 30～60k トークンです。多くの指摘で相互参照の確認が必要な場合は、さらに増えます。200k のシステム改善上限内で、十分な余裕があります。