Skill Review

---
name: skill-review
description: >
  对一个 skill（默认 diagnose）做**质量与体验**审视：静态审计 / 扰动实验 / 盲辨与走查 /
  坏路径体验 / 注意力预算 五个视角，产出评审报告（落 proposals/reviews/）与可选改进建议。
  **不做 CI 硬门**——体验是判断性规范，硬门化等于假硬化。用户显式要求"审视某个 skill 的
  质量/体验""诊断用起来是不是很机械/哪里别扭"时使用。
disable-model-invocation: true
---

# Skill Review（质量与体验审视）

> **定位**：`eval/` 管**正确性**（golden / S2：答对了没有）与**交互回归**（ixn：该问的问了没有）；
> 本 skill 管**质量与体验**——机械感、摩擦、坏路径、注意力预算。三者互补，不替代。
> 产出是**建议**，不是闸门。参数自包含，不依赖 `docs/` 也能执行。

## 何时用

> **不由内容流程自动触发**：issue-ingest / to-postmortem / to-reference / knowledge-groom 的收尾走的是
> `/skill:evolve-check`（轻量，无信号即止）；`evolve-check` 的 T8 只**累积**体验信号、不跑本协议。
> 本协议只有三条触发路径：**用户显式要求** / **`self-evolve` 深度轮按目标转接** / **大改某个 skill 之后**（建议，非强制）。
> 且它是 `disable-model-invocation: true`——agent 不会自发拉起。

- 用户问"这个 skill 用起来怎么样 / 是不是很机械 / 哪里别扭"；
- 大改某个 skill 之后（golden 全绿但体感变差——正确性回归测不出体验退化）；
- 深度自演进轮遇到"某 skill 的质量/体验"目标时转这里。

## 不做什么（边界，先读）

- **不进 CI**：体验是判断性规范，机器判不了（可机械检查 + 确定性后果 + 反复复发三条都不满足）。
  把它做成硬门 = 假硬化，比没有检查更坏——它制造虚假的安全感。强度如实标注为"判断"。
- **不替代 golden / S2 / ixn**：那三个管正确性与交互**回归**；本 skill 的结论不推翻它们，也不被它们替代。
- **不作为验收证据**：pilot 级样本（每格 1–3 次）只作方向性判据，报告必须写清样本量。
- **不自动改 skill**：发现该改的，产 EV 卡走既有流程（建议与决定分离）。
- **不给自己开后门**：本协议自身的改动与其他 skill 同等（走 methodology PR + 双签，不因"它是评审者"而降级），
  且每轮审视的**首个动作**是先用**档 0 审自己**——本文件的篇幅/强制词/预算档是否还成立。

## 预算分档（先选档，再动手——**别默认跑全套**）

| 档 | 花什么 | 跑哪些 | 什么时候值得 |
|---|---|---|---|
| **0 · 微** | **0 次 agent**（脚本级，秒级） | 视角 A 静态审计 + E 的 token/字数 | 想知道"有没有明显异常"；改完 skill 扫一眼 |
| **1 · 小** | 3–5 次探针 | A + **一格扰动**（挑最贴合当前疑点的：顺序 / 催促）+ **3 条坏路径** | 有具体疑点（"是不是背模板" / "坏路径会不会甩锅"） |
| **2 · 中** | 8–12 次 | A + 两格扰动 ×2 重复 + 六条坏路径 | 大改之后做一轮体检 |
| **3 · 全** | 15–20 次 | 五视角全跑（含盲辨） | **只在要改「输出契约 / 交互形态」时**——只有那类改动需要盲辨对照来证明"更好" |

**选档判据：要动的面决定档位。**
- 改措辞、加/删纪律 → 档 1 足够（改前改后各跑**一格**扰动即可对照）；
- 改输出结构、改交互形态 → **必须档 3**，否则"更清楚/更顺"没有对照数据，属未经验证的改动；
- 只是例行扫一眼 → 档 0。

**开跑前用一句话跟用户对齐档位与预算**（"这次按档 1 跑，约 3–5 次探针"），跑完在报告里写实际用量。
**不要为了"跑得全"默认上档 3**——那是本协议最容易犯的过度消费。

## 五个视角

### A 静态审计（读文本，零实验成本，可全量）

对目标 skill 的 SKILL.md 与其 `references/` 算下面几项，并**与上一次审计对照**（趋势比绝对值有意义）：

| 指标 | 怎么算 | 高了说明什么 |
|---|---|---|
| 强制词密度 | `必须/禁止/不得/一律/始终` 出现数 ÷ token | 规则密集，模型的注意力预算被挤占 |
| 输出必填段数 | 要求 agent 逐段输出的段落数 | 输出模板化风险 |
| 判据/步骤比 | flow 里 `check` 含阈值或"是/否"判定的步占比 | 低 = 流程退化成清单，执行者变清单工 |
| 分支/步骤比 | 真正分流的步数 ÷ 总步数 | 过低 = 没有分流，只是把步骤排了序 |
| 常驻 vs 按需 | SKILL.md token vs references token | 常驻部分是否已超预算（常驻每轮都付） |

```bash
python3 scripts/audit_skill_cost.py --skill <name> --dups   # 常驻/按需/重复面 + 强制词密度与输出段数
```

前四项（强制词密度、输出必填段数）由该脚本按同一把尺算，第五项（常驻 vs 按需）也在它的输出里——**不要另抄一份内联片段**：同一把尺、可对照趋势，是这项审计能"与上一次对照"的前提。判据/步骤比与分支/步骤比要看 flow 语义，仍由人读（脚本不判）。

判读：**不设合格线**。要找的是"某处突然变多/变密"，并逐条回答两个问题——
①这条规则是为了**安全**（误诊代价不对称）还是为了**可观测**（能演进）？两者都答不上来 = 为了整齐，该砍。

### B 扰动实验（反事实 / 对抗）

每类扰动取 1–2 个场景、每个 2–3 次（小样本定性）。**同一份输入只改一处**，其余不变：

| 扰动 | 做法 | 看什么 |
|---|---|---|
| **顺序扰动** | 把用户提供的信息换顺序给 | 追问链是否随之改变——**完全不变 = 背模板** |
| **信息饱和** | 一次给全 vs 挤牙膏分三轮给 | 是否仍逐条问已经给过的部分 |
| **错误前提** | 用户给一个明显错误的假设 | 盲从还是先质疑（质疑能力是诊断域的核心能力） |
| **催促** | 用户说"别问了直接给结论" | 是否跳过验证直接给 fix——**闸门强度与体验的正面张力**，结果要记下来交人判 |
| **表述漂移** | 同症状换口语 / 错别字 / 英文 | 路由与命中是否稳定（词法脆性；漂移即路由失效的信号） |

判读口径：扰动只改一处，**差异可归因**；报告写清"改了哪一处、变了什么、没变什么"。

### C 盲辨与走查（人读 / agent 读）

- **盲辨（最便宜也最尖锐）**：取**两个不同问题**的输出，去掉来源信息，让不知情的人或另一个 agent 判断"哪份对应哪个问题"。**判不出 = 输出没有区分度 = 模板化。**
  对照臂：换两份**同一问题**的输出，应当同样判不出（若反而能判出，说明输出里混进了与问题无关的固定话术）。
- **persona 走查**：三种用户各走一遍——赶时间的客户工程师 / 第一次用的新人 / 只想验证假设的老手——记摩擦点：哪一步让人停顿、哪一步让人重复输入、哪一步结论看不懂。
- **干跑**：让一个执行者**照输出步骤真的做一遍**，只回答"这条能不能执行"（不判断对错）。

### D 坏路径体验（fixture 几乎只测好路径）

逐个触发，看输出是**给出路**还是**甩锅**：

- 知识库为空（冷启动）/ 候选全不命中 / 无测量数据 / 连续两次未解决（串联保护触发）/ 流程与现场证据矛盾 / 信息不足以分类（优雅退化）。

判读：坏路径的三条底线——① **明说现状**（不假装有能力）；② **给下一步**（哪怕只是"转人工"也要给可执行动作）；③ **不把责任推给用户**（"你没给够信息"是事实陈述，"你去查清楚再来"不是）。

### E 注意力预算（可测，别靠感觉）

| 项 | 怎么测 |
|---|---|
| 等多久 | 首轮到首个有效输出、到结论的轮数 |
| 贴多少 | 每轮用户输入字数；是否重复贴同一份东西 |
| 读多长 | 输出字数/段数 **与问题复杂度的相关性**——基本恒定 = 模板化 |
| 常驻成本 | SKILL.md + 常驻 references 的 token（视角 A） |

> **历史轨迹**（`traces/`）是做 E 的现成材料，但**只在样本新鲜时才用**：旧 trace 的口径可能已漂移，
> 用它下现状结论是拿旧数据说新问题。样本过旧或不覆盖目标场景 → **明确跳过并说明**，不为凑数用旧数据。

## 判读纪律（强度如实标注）

- **确定性**：A 的计数、E 的 token/字数——可直接引用；
- **半确定**：B 的扰动对比（同输入只改一处，差异可归因）——给样本量；
- **主观**：C 的盲辨与走查——写清是谁判的、判了几份、是否盲。

强度不标注的观察不要写进"结论与优先级"一节。

## 产出

- **报告** → `proposals/reviews/skill-review-<skill>-<yyyy-mm-dd>.md`（本地留存，不进 git）：
  每个视角一节（做了什么 / 样本量 / 观察 / 判断 / 建议），末节"结论与优先级"（按"用户可感知程度 × 修复成本"排序）；
- 有**具体可执行**的改进 → 产 EV 卡（走 `/skill:evolve-check` 第 3 步的同一条产卡链）；
- **不把数字型"基线"写进 skill 文本**——基线随 skill 变更腐烂，只进报告。

## 与既有机制的关系

| | golden / S2 | ixn（交互） | skill-review（本） |
|---|---|---|---|
| 管什么 | 答对了没有 | 该问的问了没有 | 机械感 / 摩擦 / 坏路径 / 预算 |
| 判据 | 机械断言 | 半机械（召回、决定性字段） | 判断性（人 / agent 评审） |
| 强度 | CI 硬门 | 约定 | **只建议** |
| 触发 | 改检索/路由面时 | 改交互面时 | 用户显式要求、大改之后、深度轮 |

## 为什么需要它

正确性回归全绿，不等于用起来不别扭。机械感来自两种东西：**规则过细**（把模型挤成清单执行器）与
**规则互相打架**（两处文档写反，模型行为随机）。这两类都测不出来——它们不改变命中率，只改变体感。
专门的审视视角把它们变成可讨论、可记录、可改进的对象，而不是"感觉有点怪"。