audit-agent-history について
audit-agent-historyは、Claude CodeとCodexのセッションログを分析し、繰り返されるエージェントへの修正やワークフロー上の問題を見つけるスキルです。傾向を数値化し、最大3件のルール変更案と、共有ハブへの移行候補を示します。
主な機能
- 01モデル別のセッション数とユーザーメッセージ数の集計
- 02修正パターンの分類と正規化
- 03監査ログからの事例引用
- 04問題のあるセッションと遅いセッションの調査
- 05移行候補となるローカルルールの特定
活用シーン
- 01セッションログからエージェントの反復ミスを発見
- 02モデル別・失敗モード別の修正率を比較
- 03根拠に基づくワークフロールール案を作成
インストール
コマンドをコピーしてターミナルで実行します。
npx skills add https:/インストール後、Claude Code で/audit-agent-historyを入力して読み込まれたか確認します。
同梱ファイルreferences/failure-modes.md
詳細
エージェントの履歴を監査する
推測に基づいて書かれたルールは外れます。ユーザー自身のログにある、数え上げた修正に基づいて書かれたルールは的を射ます。このスキルでは修正を数え、そのうえで bundles/workflow/rules/workflow-hazards.md に追加する行を最大3行まで提案し、ハブルールに引き上げる価値のある利用側のオーバーレイペアも示します。
ログの保存場所
まず ls で各パスの存在を確認してください。存在しないものはスキップし、レポートにその旨を記載してください。
| ハーネス | パス | 形式 |
|---|---|---|
| Claude Code | ~/.claude/projects/<project-slug>/*.jsonl | セッションごとに1ファイル。1行につき1つのJSONメッセージ。type は user または assistant。cwd はリポジトリを示し、assistant の行には model（claude-fable-5、claude-opus-5）が含まれます |
| Codex | ~/.codex/sessions/<yyyy>/<mm>/<dd>/rollout-*.jsonl | セッションごとに1ファイル。1行目は cwd を含む type: session_meta。後続の行には model（gpt-5.6）が含まれます |
プロジェクトのスラッグは、リポジトリのパス内の / を - に置き換えたものです。/Users/x/repo/skilly は -Users-x-repo-skilly になります。
対象範囲
次の項目を確認するか、デフォルト値を使用してください。
- リポジトリ：対象の
cwd値。デフォルトはすべて - 期間：デフォルトは30日。ファイルの mtime または
timestampで判定 - モデル：デフォルトは検出されたすべて
監査全体を1つのサブエージェントで実行してください。多数のログを対象とする深い推論が必要です。生ログをメインコンテキストに含めてはいけません。principle-guard-the-context-window を参照してください。サブエージェントが返すのはレポートのみです。
方法
- モデルとハーネスごとに、セッション数とユーザーメッセージ数を数えます。 どちらも手順4の分母になります。
- 修正を見つけます：assistant のアクションの後に続き、それを覆すユーザーメッセージを対象とします。
no、don't、stop、I said、why did you、undo、revert、not what I asked、I didn't askに一致するものを探します。各該当箇所の直前にある2つのメッセージを読み、誤検出を除外します（質問への回答としてのnoは修正ではありません）。 - 各修正を references/failure-modes.md にあるモードのいずれか1つに分類します。修正1件につきモードは1つです。一致しないものは
otherに分類し、2語のラベルを付けます。 - モデルごと、モードごとに数えます。 次の式で正規化します：
corrections / user messages * 100。生の件数では、使用頻度の高いモデルが有利になります。 - 上位3つのモードごとに、実際の例を2件引用します：assistant のアクションとユーザーの修正です。秘密情報とホームディレクトリ配下のすべてのパス（
~/...）を伏せてください。 - 問題のあるスレッドを1件詳しく調べます。 最悪のセッションを専用エージェントで開き、同じモデルを使って次の点を尋ねます：何が正しいと思わせたのか、ルールファイルまたは
CLAUDE.mdのどの行が古かったのか、最初にどこで依頼を誤読したのか。説明対象のモードの下に回答を記録してください。 - 時間のかかったスレッドを1件詳しく調べます。 ユーザーメッセージあたりのツール呼び出し数が最も多いセッションを選びます。ツール呼び出しをカテゴリ（状況把握のための読み込み、繰り返しの読み込み、確認、編集、検証）に分類します。結果に何の変化ももたらさなかったグループには「無駄」と印を付けます。
- オーバーレイペアを集めます。 対象範囲内の各リポジトリで
.claude/rules/*.local.mdを読みます。ここには、同期されたルールに対して利用側が記した不適切な例と適切な例のペアがあります。.claude/rules/workflow-writing-standards.mdを参照してください。2つ以上のリポジトリに現れるペア、または上位3つのモードに一致するペアは、拡張先のルールに引き上げる候補です。
出力
モデルとモードごとに1行を割り当て、100件あたりの降順で並べたレポート表：
| mode | model | count | per 100 messages | example |
続いて、## 提案するハザード ブロックを記載します。bundles/workflow/rules/workflow-hazards.md の形式でルールは最大3つとし、番号付きの1行に「決して〜しない」と行動、その理由を記載します。各ルールには、ログから悪い例を1つ、良い例を1つ添えます。
1. Never kill a process by port number alone. Two harness instances share a port range; the audit found four kills of the running session in two days. Bad: `kill $(lsof -t -i:3000)`. Good: `ps -o pid,command | grep <name>`, then kill the one pid.
続いて、## 集約候補 ブロックを記載します。オーバーレイのペアごとに1行で、リポジトリ名、拡張するルールファイルと項目、そしてペアをそのまま記載します。
引き継ぎ：
- レポートと両方のブロックをユーザーに提示します。その後、停止します。
- 承認を得たら、ハブルポジトリ（
timschoch/skilly）内のbundles/workflow/rules/にあるルールファイルのみを編集します。コンシューマーリポジトリでは決して編集しないでください。ルールはハブから同期され、次回の同期でローカルの編集が上書きされます。集約したペアは、それが拡張する項目の下に移動します。その後、コンシューマー側で.local.mdから該当するペアを削除します。
参照
- references/failure-modes.md：各モード、そのログ上のシグナル、および例1つ