关于 audit-agent-history
audit-agent-history 是分析 Claude Code 和 Codex 会话日志的技能，用于发现反复出现的 Agent 修正和工作流问题。它会统计模式、提出最多三条规则变更，并识别可纳入共享中心的本地规则配对。
主要功能
- 01按模型统计会话和用户消息
- 02分类并标准化修正模式
- 03引用审计日志中的实例
- 04检查问题会话和缓慢会话
- 05识别可提升的本地规则配对
适用场景
- 01从会话日志发现反复出现的 Agent 错误
- 02按模型和失败模式比较修正率
- 03准备有证据支持的工作流规则提案
安装
复制下面的命令，在终端中运行。
npx skills add https:/安装后在 Claude Code 中输入/audit-agent-history确认已加载。
附带文件references/failure-modes.md
详细介绍
审计 Agent 历史记录
凭猜测写下的规则往往无效。根据用户自己日志中统计出的纠正记录写下的规则才有效。此技能会进行统计，然后最多为 bundles/workflow/rules/workflow-hazards.md 提出三条规则，并找出值得提升到其中心规则中的消费者覆盖规则对。
日志所在位置
先用 ls 验证每个路径。不存在的路径跳过，并在报告中说明。
| Harness | 路径 | 格式 |
|---|---|---|
| Claude Code | ~/.claude/projects/<project-slug>/*.jsonl | 每个会话一个文件，每行一条 JSON 消息；type 为 user 或 assistant；cwd 表示仓库；assistant 行包含 model（claude-fable-5、claude-opus-5） |
| Codex | ~/.codex/sessions/<yyyy>/<mm>/<dd>/rollout-*.jsonl | 每个会话一个文件；首行为包含 cwd 的 type: session_meta；后续行包含 model（gpt-5.6） |
项目 slug 是将仓库路径中的 / 替换为 -：/Users/x/repo/skilly 会变成 -Users-x-repo-skilly。
范围
询问用户，或采用以下默认值：
- 仓库：指定哪些
cwd值；默认全部 - 时间窗口：默认 30 天，按文件修改时间或
timestamp计算 - 模型：默认全部已出现的模型
在一个子 Agent 中完成整个审计。这需要对大量日志进行深入推理。原始日志绝不能进入主上下文，参见 principle-guard-the-context-window。子 Agent 只返回报告。
方法
- 统计每个模型和 Harness 的会话数及用户消息数。这两项都是步骤 4 的分母。
- 查找纠正记录：用户消息紧跟在助手执行操作之后，并对该操作予以反转。按
no、don't、stop、I said、why did you、undo、revert、not what I asked、I didn't ask匹配。阅读每条命中记录之前的两条消息，排除误报（回答问题的no不算纠正）。 - 分类每条纠正记录，归入 references/failure-modes.md 中的一种模式。每条纠正记录只能归入一种模式。无法匹配的归入
other，并附上一个两个词的标签。 - 按模型和模式统计。归一化：
纠正记录数 / 用户消息数 * 100。原始数量会偏向使用次数更多的模型。 - 引用排名前三的模式中，每种模式各引用两个真实示例：助手执行的操作及用户的纠正。隐去机密信息以及主目录下的所有路径（
~/...）。 - 深入分析一个糟糕的对话线程。 在独立 Agent 中打开最糟糕的会话，使用相同模型并询问：是什么让你觉得这样做是对的，规则文件或
CLAUDE.md中的哪一行已经过时，最初是在哪里误解了请求。将答案记录在其所解释的模式下。 - 深入分析一个缓慢的对话线程。 选取每条用户消息对应工具调用次数最多的会话。将其工具调用分为几类（初步了解、重复读取、检查、编辑、验证）。标记对结果没有任何影响的类别为无用。
- 收集覆盖规则对。 在范围内的每个仓库中，读取
.claude/rules/*.local.md。这些文件包含消费者针对同步规则编写的错误做法/正确做法对，参见.claude/rules/workflow-writing-standards.md。在两个或更多仓库中出现，或与排名前三的模式相符的规则对，都可作为提升到其所扩展规则中的候选项。
输出
按每 100 条的数量降序排列，每个模型和模式占一行的报告表：
| mode | model | count | per 100 messages | example |
然后是 ## Proposed hazards 块。规则最多 3 条，格式遵循 bundles/workflow/rules/workflow-hazards.md：每条规则占一行并编号，以 Never 加上操作开头，然后说明原因。每条规则都要附带日志中的一个错误示例和一个正确示例。
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.
然后是 ## Hoist candidates 块：每个覆盖层配对占一行，注明仓库、其扩展的规则文件和条目，并原样列出配对内容。
然后交接：
- 向用户展示报告和两个块。停止。
- 获得批准后，仅在中心仓库 (
timschoch/skilly) 的bundles/workflow/rules/下编辑规则文件。绝不要在使用方仓库中编辑：规则会从中心仓库同步，下一次同步会覆盖本地编辑。提升的配对放在其所扩展的条目下；然后使用方从其.local.md中删除这些配对。
参考资料
- references/failure-modes.md：各种模式、每种模式对应的日志信号及一个示例