Skills 生态的观察写到这个阶段，市场侧的货架已经足够拥挤——skillsmp.com 收录了超过 2300 个 Skill，mcpservers.org 和 skillsdirectory.com 各自维护着经过筛选的目录，skills.sh 的热门榜每周都在换血。但真正值得逐行拆的，反而是随 Claude Code 本体分发的三件内置效率件：/code-review、/simplify、/verify。本文把三件的官方描述原文逐段拆开，做一次开发效率赛道的横向评测。核心发现只有一句话：这三件最值钱的设计不在正文里，而在描述（description）里——它们用“让路条款”互相划分地盘，而且其中有一条路让出去之后，没人接住。
拆 Skill 到家，就是把描述当合同读。以下是三件内置效率件的官方描述原文，一字未改。
第一件，找茬岗 /code-review：
Review the current diff for correctness bugs and reuse/simplification/efficiency cleanups, at the given effort level (low/medium: fewer, high-confidence findings; high→broader, may include uncertain findings). Pass --comment to post as inline PR comments, or --fix to apply the findings to the working tree.
三十八个词，写了五件事：范围（current diff，只看改动，不扫全库）、职责（correctness bugs 加三类清理项）、档位（low/medium 少而准，high 广而杂但可能混入不确定项）、交付形态一（--comment 贴成 PR 行内评论）、交付形态二（--fix 直接改工作区）。
第二件，收拾岗 /simplify：
Review the changed code for reuse, simplification, efficiency, and altitude cleanups, then apply the fixes. Design quality is out of scope for this skill; use /code-review for that.
同样短。前半句认领四类清理——复用、简化、效率、层次（altitude）——并且明确“then apply the fixes”，动手改，不是只报告。后半句是全文最值钱的十一个词："Design quality is out of scope for this skill; use /code-review for that." 设计质量不在本件职责内，去看 /code-review。这是一条标准的让路条款（routing clause）。
第三件，验收岗 /verify：
Verify that 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 that a change works in the real app (not just tests), or to validate local changes before pushing.
前半句给出方法论：跑应用、观察行为，用实证代替推断。后半句一口气罗列了五个触发场景：验证 PR、确认修复生效、手动测试、真机验证（括号里特意补刀“不只是跑测试”）、推送前本地校验。
评分维度沿用本栏目的固定权重：功能完整度 25%、设计质量 25%、实战效果 20%、上手难度 15%（星级越高越友好）、社区活跃度 15%。三件均为内置，随主程序更新，无独立仓库指标可考，社区活跃度按官方维护强度计。
| Skill | 功能完整度 | 设计质量 | 实战效果 | 上手友好 | 社区活跃 | 加权总分 |
|---|---|---|---|---|---|---|
| /code-review | ★★★★★ | ★★★★★ | ★★★★☆ | ★★★★★ | ★★★★☆ | 4.75 |
| /simplify | ★★★★☆ | ★★★★★ | ★★★★☆ | ★★★★★ | ★★★★☆ | 4.63 |
| /verify | ★★★★☆ | ★★★★☆ | ★★★★★ | ★★★★☆ | ★★★★☆ | 4.45 |
三件总分咬得很紧，差距全在设计细节和适用前提上。下面逐件展开。
定位是审查当前 diff 里的正确性 bug 和清理项。它最聪明的一处设计，是把召回率与精确率的权衡直接做成了档位参数：low/medium 档“fewer, high-confidence findings”，high 档“broader, may include uncertain findings”。翻译成人话：低档少报但条条可信，高档多报但你得自己筛。这个权衡本来是所有代码审查工具的内部难题，它直接把选择权交还给调用者，并且在描述里就把预期管理好了——你选 high，就别抱怨有噪音。
第二个亮点是动作分级。默认行为是只出报告，--comment 才把发现项贴到 PR 行内，--fix 才允许它碰你的工作区。三个交付层级，风险逐级上升，越权的动作全部藏在显式旗标后面。这是“AI 动手类工具”该抄的标准答案：默认只读，写入须明示。
短板也有：它管找、顺手提清理项，但描述里没有任何“测试”字样——审查完的代码对不对，它不背书。
定位是专职收拾工：复用、简化、效率、层次四类清理，而且是“then apply the fixes”——发现问题直接改，不像 code-review 默认只动嘴。对不想逐条确认的使用者，这是一条龙的爽点；代价是它默认就写你的代码，风险偏好低的人要先想清楚。
它真正的灵魂词是 altitude（层次）。前两类清理是所有 linter 都懂的常识，层次清理却是纯提示词工程产物：识别“在错误的抽象层级解决问题”的代码——比如在调用方层层补 if，而该改的是被调方的契约。这类坏味道没有任何静态规则能抓，只有语言模型能判断，是这个 Skill 不可替代的部分。
短板恰恰是那条让路条款。它说“设计质量归 /code-review 管”，但回头查 /code-review 的描述，人家认领的是"correctness bugs and reuse/simplification/efficiency cleanups"——正确性 bug 加三类清理项，通篇没有一个词提到设计质量。球传出去了，没人接。 使用者若真的拿着设计质量问题去敲 /code-review 的门，按描述字面理解，对方并不欠他一次解答。
定位是验收员，方法论写在描述第一句：running the app and observing behavior。它和前两件有本质区别——code-review 和 simplify 看的是文本，verify 看的是行为。测试全绿、审查零发现，应用照样可能一跑就崩：环境变量没配、端口被占、迁移没跑。这类问题只有把应用真正跑起来才能暴露，而 verify 是三件里唯一为此设岗的。
它的描述写法也值得单独一提：一口气罗列五个真实口语句场景——"verify a PR"“确认修复生效”“手动测一下”“推送前验一遍”——这是触发词工程的场景清单法。Skill 的触发靠描述与用户输入的语义匹配，与其堆形容词，不如把用户真会说的话原样列进去。
短板在前提：它需要一个跑得起来的目标应用。纯库代码、没法本地运行的远端服务，这套方法论就落空了。上手友好度因此扣掉一星。
把三件的职责和交付形态画成一张图，就是 Claude Code 改完代码后的标准分流：
flowchart TD
A["一次改动完成"] --> B{"下一步想要什么"}
B -->|找bug和清理项| C["/code-review"]
B -->|清理并动手改| D["/simplify"]
B -->|跑起来看行为| E["/verify"]
C -->|默认| F["只出报告"]
C -->|--comment| G["PR行内评论"]
C -->|--fix| H["写入工作区"]
D --> I["直接应用四类清理"]
E --> J["运行App观察后给结论"]
诊断（找茬）、治疗（收拾）、验收（跑真机）——三个岗位串起来恰好是一条完整的质量流水线。但注意两个空位：写测试的岗位不在编制内（官方插件货架上的 webapp-testing 属于另一条产品线，不在内置三闸之列），设计质量则在描述层面处于两件互相指向的缝隙里。
这组内置件的真正价值，是给所有想写自己 Skill 的人提供了可复制的模板。从三段描述里能提炼出五条：
第一条：负空间写法。 不只写“我做什么”，还要写“我不做什么、该去找谁”。simplify 的 "out of scope; use /code-review" 是范本。模型选 Skill 时只看描述，一条让路条款等于在入口处就完成了分流，省掉一次错误的全文加载。
第二条：动作分级。 默认只读，越权动作全部藏进显式旗标（--fix、--comment）。让“AI 会不会乱改我代码”这个顾虑变成一个用户自己按的开关。
第三条：权衡档位化。 精度与召回的矛盾不要自己拍板，做成 low/medium/high 之类的参数，并把每档的副作用写在描述里，提前管理预期。
第四条：场景清单触发词。 像 verify 那样，把用户真实会说的话（“确认修复生效”“推送前验一下”）原样罗列进描述。触发靠语义匹配，口语句子就是最好的关键词。
第五条：让路要双向确认。 这是 simplify 用教训示范的一条——你把某项职责指给隔壁，先确认隔壁的描述真的认领了这项职责。单向让路 + 对方没接 = 责任缝隙，用户两头碰壁。
一个可直接套用的描述骨架：
---
name: my-reviewer
description: 做 X 和 Y，不做了 Z——Z 请用 /other-skill。
默认只输出报告；传入 --apply 才允许修改文件。
档位 fast（少而准）/ deep（广而杂）。
触发场景：用户说「帮我看看」「上线前检查」时使用。
---
三件均为 Claude Code 内置，无需安装，升级主程序即得：
/code-review # 审当前 diff：bug + 清理项，档位可选 low / medium / high
/code-review --comment # 发现项贴成 PR 行内评论
/code-review --fix # 把发现项直接改进工作区
/simplify # 复用/简化/效率/层次四类清理，直接动手改
/verify # 把应用跑起来，用观察代替猜测，推送前最后一道闸
想在此基础上加装社区同类件（TDD 驱动、特定语言审查器等），可到 skillsmp.com（2300+ 条目的可搜索目录）、skills.sh（热门榜）或 mcpservers.org/agent-skills、skillsdirectory.com（含安全扫描评级）按 "code review"“refactoring”"tdd" 等关键词检索，挑带安全评级的源安装。
三件内置件说明了一件事：Skill 生态竞争到今天，正文写得漂亮不稀缺，描述之间划得清地盘才稀缺。单件时代拼的是一段提示词的功力，编队时代拼的是一张让每个岗位都知道自己边界在哪、队友是谁的地图。下次写自己的 Skill，先把邻居的描述读一遍，再动笔。
[!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 等场景全覆盖。