skill-doctor给skill诊断看病，一个反过来的 skill，告诉你手上哪条根本没用

skill-doctor：一个"给 skill 看病"的元 skill，读你本地机器上真实 agent 对话历史，按效率、代码质量两个维度的评分表打分，只对打分失败的会话当证据反推该改哪条 skill，必须援引具体会话与时刻、禁止拿通用最佳实践充数。

比如：一条已安装、但在失败会话里从未触发过的 skill，通常是它的"触发描述"出了问题。这比"再给你加十条最佳实践"有用得多——问题往往不在 skill 写得不好，而在它压根没被叫起来，问题多半出在描述上。

它生成的报告：C 级、总分 76，效率 72 / 代码质量 72 / skill 覆盖率 100，下面 12 个会话、16 条已装、13 条被用过（图源：作者演示）

01工作流共五步

先验 harness，验不出就停。官方 SKILL.md 里写得很死：识别不出当前 harness 就停，连报告目录都不建、对话历史一个字都不读。

问你要评什么范围。本仓库 / 全部对话 / 指定几个项目；只评项目 skill，还是连全局 skill 一起评。

采集。--harness auto扫所有本地可用的源，默认回看 45 天、最多采样 12 个会话。

打分。两套评分表：效率、代码质量。轨迹超过 50 条就分批并行（每批 20）。只在本机进程、或"把轨迹留在本机的本地子 agent"里评。

而且代码质量分只在轨迹里确实有代码改动时才算，否则记为"证据不足"并从均值里剔除——不硬凑。

聚合，并起草具体的 skill 修改。

02打分公式

overall = 0.5×效率 + 0.35×代码质量 + 0.15×skill覆盖率

其中skill 覆盖率 = 采样会话里"至少触发了一条已装 skill"的比例。

官方还定义了什么叫"失败会话"：一次对话里只要有任何一项适用的效率或代码质量分低于 0.5，就算失败；"证据不足"不算失败。只有失败会话能拿来当改进依据。

03最狠的是证据规则

这是我觉得它最不一样的地方。官方原文的要求是：每条建议都必须能追溯到失败会话里观察到的具体浪费或缺陷，不能是通用最佳实践——要引用是哪次失败会话、哪个评分项、哪个时刻促成了这条建议。

看它实际生成的东西就明白了：

每条建议下面挂着 Evidence：会话 ID + 当时具体发生了什么，然后直接给出对 SKILL.md 的改动（图源：作者演示）

比如图里那条：某次会话调用了taste-review，claude -p返回"Not logged in · Please run /login"，agent 又原样重跑了一遍同样的命令，挂了 29 秒、什么也没产出，然后干脆自己从代码里瞎猜答案。诊断是——这条 skill 没写失败路径，所以每次 CLI 没登录都会重演同一个死胡同。给出的修改是往 SKILL.md 里加四行：把空输出当失败而不是当同意、别重跑同一条命令、让用户去/login、并在回答里说明这次没拿到第二意见。

这种建议你会真的合进去，因为它指着你自己的一次翻车说话。

04它反过来了

最近聊的 skill 类项目，全都是"给你新的更多 skill"。

skill-doctor 是第一个反过来的：告诉你手上这些，哪条根本没用。

原作者 Ben Holmes 在推上给的一句话总结是：这是一个能改进你其它 skill 的 skill——爬你过去在 Claude Code、Codex 或 Warp 里的对话，按效率和代码质量打分，然后给出你真的会合并的 diff。那条推现在 1600 多赞、10 万多浏览。

05隐私这块

官方写得挺明确：全程本地跑，绝不上传任何转写、会话文件或其中任何片段；唯一可对外分享的东西，是你自己选择去发的那份报告。产物写进一个临时目录，不往你的仓库里塞文件。

项目地址SKILL.md：https://github.com/warpdotdev/common-skills/blob/main/.agents/skills/skill-doctor/SKILL.md介绍页：https://www.warp.dev/skill-doctor