review · diff
git:20261009.9da739b to git:20261009.affea9a
47 added, 10 removed. Audit A to A.
---
name: review
- description: Review captured TracePoint skill defects and decide whether to iterate the skills. User-invoked only; does not auto-trigger and does not change skills on its own.
+ description: Describe the problem just hit while using a TracePoint skill so the user can verify it, record it as a defect, then review all captured defects and decide whether to iterate the skills. User-invoked only; does not auto-trigger and does not change skills on its own.
disable-model-invocation: true
---
# 技能自迭代复查
- 复查 tracepoint 使用中记下的缺陷, 把反复出现的归因后交用户决定是否迭代技能. 本技能只呈现事实与建议, **不自行改任何技能** — 改技能必须由用户批准.
+ 用户遇到问题时调用本技能: 先把本会话里遇到的问题按事实说清楚, 供用户核实并记成缺陷; 再汇总全部缺陷记录, 把反复出现的归因后交用户决定是否迭代技能. 本技能只呈现事实与建议, **不自行改任何技能** — 改技能必须由用户批准.
- 缺陷是怎么来的: 用户纠正时 hook 会提示代理往 `.tracepoint/defects/` 追加一条只含事实的记录 (看到什么, 依据哪条规则, 做了什么, 结果如何). 代理不下 "是规则错还是自己错" 的结论 — 那不可靠 (代理对自己理由的陈述常不忠实, 定位决定性错误也很难), 归因留到这里由人按固定分类表做.
+ 缺陷记录有两个来源: 用户纠正时 hook 提示代理当场记一条; 用户调用本技能时由第 1, 2 步补记. 两者都只记事实 (看到什么, 依据哪条规则, 做了什么, 结果如何). 代理不下 "是规则错还是自己错" 的结论 — 那不可靠 (代理对自己理由的陈述常不忠实, 定位决定性错误也很难), 归因留到第 4 步由人按固定分类表做.
## 步骤
- 1. **汇总**: 运行
+ 1. **说清本会话遇到的问题**: 回顾本会话中使用 tracepoint 技能 (analyze, protected-code) 的过程, 找出出问题的地方: 用户纠正过的, 结果被证明不对的, 反复尝试仍卡住的, 照规则做却行不通的. 用户调用时附带了说明的, 以说明所指的那件事为准. 对每个问题, 在回复里按下面的格式写出来给用户核实:
```
- node ${CLAUDE_PLUGIN_ROOT}/runtime/tools/review-defects.mjs
+ 问题 <序号>: <一句话概括>
+ - 技能与任务: <哪个技能, 当时在做什么>
+ - 看到: <当时的输入, 现象或工具返回>
+ - 依据: <照的是技能里哪条规则或哪一步, 引原文; 没有对应规则时写 "无对应规则">
+ - 做了: <实际做了什么>
+ - 结果: <得到什么, 与用户的期望或纠正差在哪>
```
- 它按模式键去重计数, 列出全部模式和达到提升阈值 (默认复现 >=3, 跨任务 >=2, 30 天内) 的模式. 未达阈值的不提请改技能 (避免把偶发当成规律).
+ - 只写本会话里实际发生过, 能指出出处的事实; 记不清的地方写 "记不清", 不要补全.
+ - 不写原因分析, 不写 "本应怎样", 不判断是规则错还是自己错.
+ - 本会话没有用过 tracepoint 技能, 或找不到这类问题时, 说一句 "本会话没有发现与 tracepoint 技能有关的问题", 跳到第 3 步.
- 2. **读记录**: 对每个达阈值的模式, 读 `.tracepoint/defects/` 下对应的记录原文, 看清事实. 只问 "当时是什么情况, 怎么发生的", 不急着归一个 "根因".
+ 2. **记成缺陷记录**: 把第 1 步的每个问题存成 `.tracepoint/defects/` 下的一个 JSON 文件 (文件名不与已有文件重复, 如 `<日期>-<模式键>.json`), 字段如下:
- 3. **按固定分类表归因**: 给每个模式选一个类别 (这一步可交无本次上下文的子代理按同一张表做, 一致性更好):
+ ```json
+ {
+ "plugin": "tracepoint",
+ "skill": "",
+ "rule": "",
+ "patternKey": "",
+ "sawWhat": "",
+ "didWhat": "",
+ "result": "",
+ "task": "",
+ "at": ""
+ }
+ ```
+
+ - `sawWhat`, `rule`, `didWhat`, `result` 照第 1 步写给用户的内容填; `task` 填任务标识 (目标名); `at` 填当前时间 (ISO 格式).
+ - `patternKey` 是这一类问题的短名 (小写英文加连字符, 如 `repeat-analysis`). 先看收件目录里已有的模式键, 同一类问题沿用已有的键, 这样才能统计复现.
+ - 本会话已经为同一个问题记过 (hook 提示时记的) 就不重复记; 那条记录与第 1 步写的不一致时, 以第 1 步为准改掉.
+ - 找不到 `.tracepoint/` 案卷目录时不要新建 (它是 hook 的开关), 只保留回复里的描述, 并告诉用户这次没有存档.
+ - 用户核实后指出哪里写得不准时, 改正回复里的描述, 并同步改那条记录.
+
+ 3. **汇总**: 运行
+
+ ```
+ node ${CLAUDE_PLUGIN_ROOT}/runtime/tools/review-defects.mjs
+ ```
+
+ 它按模式键去重计数, 逐条列出每条记录的事实, 并标出达到提升阈值 (默认复现 >=3, 跨任务 >=2, 30 天内) 的模式. 用户不一定看得到脚本输出: 把每个模式下各条记录的事实完整转述给用户核实, 不要只报条数.
+
+ 4. **按固定分类表归因**: 对每个达阈值的模式, 只问 "当时是什么情况, 怎么发生的", 不急着归一个 "根因", 然后选一个类别 (这一步可交无本次上下文的子代理按同一张表做, 一致性更好):
- `rule-gap` 规则没覆盖这种情形.
- `not-triggered` 有规则但技能/hook 没触发到.
- `lost` 规则在, 但长会话漂移或压缩后丢了.
- `unclear` 规则有歧义, 照着做仍会错.
- `ignored` 规则清楚也在, 但没遵守.
- `not-skill` 不是技能能解决的 (模型能力或目标难度), 记为已知限制.
- 4. **提给用户决定**: 按类别给出改法建议, 交用户批准后再改:
+ 未达阈值的模式只呈现事实, 不主动提请改技能 (避免把偶发当成规律); 用户明确要就某个未达阈值的问题改技能时, 照同一张表归因后给建议.
+
+ 5. **提给用户决定**: 按类别给出改法建议, 交用户批准后再改:
- `rule-gap` / `unclear`: 建议新增或改清一条规则 (对应技能的 `SKILL.md`).
- `not-triggered`: 建议把该规则从技能正文移到插件 hook (hook 不依赖技能被选中).
- `lost`: 建议缩短/前置规则, 或让 hook 在压缩后重注入.
- `ignored`: 若能做成确定性检查 (如校验器), 建议下沉; 否则记为已知限制.
- `not-skill`: 记为已知限制, 不改技能.
- 用户批准前不改任何 `SKILL.md`.
- 5. **收尾**: 把已处理的模式与决定记下来 (可在 `.tracepoint/defects/` 内加一个 resolved 标记), 未达阈值的留着继续累积.
+ 6. **收尾**: 把已处理的模式与决定记下来 (可在 `.tracepoint/defects/` 内加一个 resolved 标记), 未达阈值的留着继续累积.
跨插件: 本复查针对 tracepoint 自己命名空间下的技能; 其它插件 (如 waypoint) 各自复查自己的, 不重复处理同一条. 共用的是 `runtime/lib/self-iteration.mjs` 的逻辑, 不是同一个收件目录.