聊开发者效率类 Skills，多数榜单还在数社区市场里那些花哨的货架。但这一轮横向评测拆下来，最值得逐行读的东西其实不在任何市场里，而是 Claude Code 近期版本直接内置的三个工程命令：/code-review（审查）、/simplify（重构清理）、/verify（运行验证）。它们分别接管 AI 写码循环里最高频的三件事——查 bug、改结构、证行为——而且三个的 description 文本互相引用、分工边界写在明面上，本身就是一份可以直接抄的提示词工程范本。外围再配一组 Anthropic 官方精选（curated）集合里的 GitHub 工作流技能：gh-fix-ci、gh-address-comments，以及官方示例库 anthropics/skills 中 example-skills 目录下的 webapp-testing。本文先逐行拆内置三件套，再看外围集群怎么补位。
Claude Code 的技能触发机制决定了：SKILL.md 里 frontmatter 的 description 字段会被注入系统提示，模型根据它判断当前对话该不该路由进这个技能。换句话说，description 既是说明书，也是 API 合同，还是触发条件。一个技能设计得好不好，八成看这几行字怎么写。
内置三件套的 description 都短得惊人——每个就两三句话——但信息密度极高。下面逐行拆。
它的 description 大意是（保留原文关键结构）：
Review the current diff for correctness bugs and reuse/simplification/efficiency cleanups at any effort level (low/medium: fewer, high-confidence findings; high→best for broader coverage, may include uncertain findings). Pass --comment to post findings as inline PR comments, or --fix to apply the findings to the working tree after the findings are collected.
这一段至少藏了四层设计：
第一层：范围锁定在 current diff。 不是「审查这个仓库」，不是「审查这个项目」，而是当前改动。这是信噪比意识：AI 全库扫一遍，产出的一半是噪音；只审 diff，每条发现都对应你刚写的东西。同时天然省 token——审查对象的大小和你的改动成正比，而不是和仓库成正比。
第二层：两类产出并轨。 correctness bugs（正确性缺陷）和 reuse/simplification/efficiency cleanups（复用、简化、效率类清理建议）放在同一次扫描里。查错和提质本来是两次工作，这里合并成一遍遍历，成本减半。
第三层：effort 旋钮把权衡写明。 low/medium 档明确标注「发现更少、但置信度高」，high 档标注「覆盖更广、可能包含不确定的发现」。绝大多数工具只会给你一个开关，不会告诉你开到最大会有什么副作用；这里把查全率/查准率的取舍直接写进了用户文档。想快速过一遍小改动用 low，提交前的最终把关用 high——用户不需要读任何额外文档就能做对选择。
第四层：输出侧双通道，默认不动手。 --comment 把发现以 inline 评论的形式贴到 PR 上；--fix 才会把修复应用到工作区。注意默认行为是只报告、不修改——审查者先看清单，再决定要不要让 AI 动手。而且 --fix 的描述里还有个容易被忽略的时序细节：「after the findings are collected」——先收集完全部发现，再统一应用修复。这避免了边审边改导致后面审查的对象已经被前面改过的经典混乱。
它的 description 更短：
Review the changed code for reuse, simplification, efficiency, and altitude cleanups, then apply the fixes. Quality bar — it does NOT hunt for bugs; use /code-review for that.
值得逐词看的两处：
「it does NOT hunt for bugs; use /code-review for that」。 一个技能的 description 里专门写一句「我不干什么」，并且明确把那件事移交给另一个技能。这是把单一职责原则从代码层面提到了技能编排层面：simplify 只管结构清理，查 bug 的事有专门入口。负面清单在技能设计里极其实用——模型路由靠语义匹配，如果不写清边界，「帮我看看这段代码」这种模糊请求就可能被错误吸进来做错事。
四个清理轴里，altitude 这个词选得妙。 reuse（复用既有实现，别重复造轮子）、simplification（砍复杂度）、efficiency（性能）都好理解，altitude 指的是抽象层级——代码常犯的错不是写错了，而是站错了高度：该调高层接口的地方扎进了底层细节，或者反过来，为一次性逻辑造了过度抽象。一个词把这类「说不清但一眼假」的问题归了类。
和 code-review 的重叠是故意的。 细看会发现 code-review 的产出清单里也有 reuse/simplification/efficiency cleanups——两处描述刻意重叠，但行为不同：code-review 报，simplify 改。同一次审查发现的问题，可以先看报告再一键执行，这组分工是成对设计的。
Verify a code change actually does what it's supposed to by running the app and observing behavior. Use when asked to verify a PR, confirm a fix works, test a change manually, check a feature works, or look at what the app looks like before committing.
方法论一句话说死：running the app and observing behavior。 静态审查（code-review）再仔细，也只能证明「代码看起来对」；verify 的存在就是为了补上这一段认识论鸿沟——把应用真的跑起来，观察实际行为。AI 写码最大的风险从来不是写不出，而是「看起来对了」。
五个触发短语的枚举是教科书级的路由设计。 verify a PR、confirm a fix works、test a change manually、check a feature works、look at what the app looks like before committing——用户嘴上会说出的五种不同说法，全部预先写进了 description。技能作者常犯的错是只写一句书面化的功能描述，结果用户换个说法就触发不了。这里示范了正确姿势：把用户口语的同义词全部塞进去，路由命中率完全取决于你对用户语料的想象力。
评分基于可直接观察的接口设计、触发设计与定位（三件套为内置分发，社区活跃度一档按「随主版本分发、迭代随官方」计），不虚构使用统计。
| 技能 | 功能完整度 (25%) | 设计质量 (25%) | 实战效果 (20%) | 上手难度 (15%) | 分发与迭代 (15%) | 综合 |
|---|---|---|---|---|---|---|
| /code-review | ★★★★★ | ★★★★★ | ★★★★★ | ★★★★★ | ★★★★ | 4.9 |
| /simplify | ★★★★ | ★★★★★ | ★★★★ | ★★★★★ | ★★★★ | 4.5 |
| /verify | ★★★★ | ★★★★★ | ★★★★ | ★★★★★ | ★★★★ | 4.5 |
内置三件套管的是「本地写码循环」，官方精选集合里还有一组技能把同一套纪律延伸到 GitHub 侧。本节按收录情况与命名定位介绍，不做逐行拆解：
内置三件套：随 Claude Code 近期版本自带，无需安装，升级后直接用：
# 会话内直接调用
/code-review # 默认：审当前 diff，只报告
/code-review high # 最终把关档：覆盖更广，接受不确定性
/code-review --comment # 发现以 inline 评论贴到 PR
/code-review --fix # 收集完发现后统一应用修复
/simplify # 对当前改动做结构清理并直接改
/verify # 跑起应用验证行为
精选集合技能（gh-fix-ci、gh-address-comments 等）：经 /plugin 的官方 marketplace 安装，或把技能目录整体拷贝进 ~/.claude/skills/ 即被发现；webapp-testing 在官方仓库 anthropics/skills 的 example-skills 目录下，同样拷入即用。
flowchart TD
W["改完一段代码"] --> CR["/code-review<br/>审查当前 diff"]
CR --> Q1{"有正确性问题？"}
Q1 -->|"有"| F["修掉问题"]
F --> CR
Q1 -->|"没有"| S["/simplify<br/>结构清理并应用"]
S --> V["/verify<br/>跑应用看行为"]
V --> Q2{"行为符合预期？"}
Q2 -->|"否"| F
Q2 -->|"是"| C["提交或开 PR"]
C --> AC["gh-address-comments<br/>跟进评审意见"]
AC --> W
注意循环里 /code-review 出现两次以上入边——审查是这个环的重心，另外两件都是围绕它的后续动作。
把这一轮拆解放回 Skills 生态看，趋势已经相当清楚：高频、普适的工程动作（审查、重构、验证）正在被官方从技能市场收编为内置能力，社区技能的生存空间被挤向两类——更长的尾（gh-fix-ci 这种特定卡点场景）和更重的活（webapp-testing 这种带浏览器依赖的重型流程）。对想写技能赚钱的开发者，这轮的启示很直接：别再做大路货的「代码审查助手」，去打磨内置三件套管不到的环节。而对所有技能作者，三件套的 description 就是现成的作业——范围写窄、取舍写明、边界写成互相引用的移交指针。
/code-review、/simplify、/verify 的 description 原文，任一近期版本会话内可通过内置技能列表查看，本文引文均出于此~/.claude/skills/ 目录[!tip] 51学通信知识星球 星主：爱卫生（微信：gprshome201101）——公众号「51学通信」创办者，19 年通信行业运维与讲师经验，著有《GPRS网络信令实例详解》《EPC原理与实践》《5G核心网原理与实践》三本纸质书（各大电商平台有售）。 星球定位：深耕 5G 核心网、IMS、NFV/AI、云原生等 ICT 领域，主打运维岗位与信令分析。 当前规模：5200 篇主题 / 990 个回答，198 元/年。 加入福利：加入星球后请加爱卫生微信，拉您进知识星球年度陪伴与答疑群——不限量回复您的各种问题，另有群内分享。 AI 加持：51学通信知识星球已作为 skill 接入 WorkBuddy，使用 deepseek-4-flash 在海量星球帖子中精准找贴、找视频、找 FAQ 和案例，做总结、找文档和 PPT 等场景全覆盖。