内建四件横评：描述里互相让路

概述

开发者效率赛道是本栏目翻地最勤的一块：代码审查、测试、调试、重构四个动词都各自横评过一轮，市场件的新面孔越挖越薄。这一轮换个挖法——不看货架，看出厂。随 Claude Code CLI 一起装机的内建件里，藏着一条完整的质检流水线：code-review（找错）、simplify（收拾）、verify（对行为）、run（开机器），外加 loop 与 fewer-permission-prompts 两个岗哨。六个件的描述原文全部取自 2026-09-15 本机会话注册表逐条比对，市场对照数据沿用本栏目 5 月存档抓取记录（已注明时点）。核心发现一句话：这组内建件最值钱的设计不在单个件里，而在描述与描述之间互相让路——每件的触发词都精确地把自己的边界、邻居的边界一起写清楚，像一份出厂时就签好的分工协议。

评测对比表

* 口径说明：内建件随 CLI 主程序分发，无独立仓库与 Star 数可观测，「维护活跃」按保守中性档三星计，不假造数据。综合分按功能 25%、设计 25%、实战 20%、上手 15%、维护 15% 加权，与全系列口径一致。

主四件：一条出厂自带的质检流水线

code-review：挡位拧在描述里

描述原文："Review the current diff for correctness bugs and reuse/simplification/efficiency cleanups at any effort level (low/medium: fewer, high-confidence findings; high→broad: more, lower-confidence findings). Pass --comment to post findings as inline PR comments, or --fix to apply the findings to the working tree after you review."

拆到行，这句描述里藏了四个设计决策。第一，以 diff 为界。 只审「当前改动」，不扫全库——这一刀把它和全库审计类市场件（如 5 月存档里 4.1K Star 的 Trail of Bits 安全套件）划清了赛道：内建件管日常，审计件管年检。第二，挡位即召回率旋钮。 low/medium 档给「少而高置信」的发现，high 档给「多而低置信」——把「宁缺毋滥还是宁可错杀」这个永远吵不完的问题，直接做成参数交给用户。这是全家族里最聪明的一行：审查工具最大的差评从来不是「找不到 bug」，而是「报了一堆噪音」，它把噪音量明码标价。第三，两个动作出口。 --comment 把发现贴成 PR 行内评论，--fix 直接把修复落到工作区。读和写分开卖，用户按场景点单。第四，人保留终审。 注意那半句 "after you review"——连 --fix 这种动手模式，描述里也要塞进「你先过目再改」的次序，这是整套内建件一以贯之的克制。

短板也在这：只认 diff 意味着存量代码的烂账它一概不管，老仓库第一件事仍得请外部的全库扫描件。

simplify：一句门规，两个件不打架

描述原文："Review the changed code for reuse, simplification, efficiency, and altitude cleanups, then apply the fixes. Quality gate, not bug hunter. Use /code-review for that."

这是六件里设计密度最高的三行字。四个清理维度依次排开：reuse（该抽公共函数的抽出来）、simplification（绕弯的拉直）、efficiency（明显的浪费砍掉），以及最值得单讲的 altitude——「高度」清理，即代码的抽象层级对不对：该在业务层说的话别沉到工具层，该一行调库的别手搓三十行。这个维度几乎从不出现在社区件的清理清单里，却是代码评审里最高频的争执。然后是那句门规： "Quality gate, not bug hunter. Use /code-review for that."——质量门卫，不是猎 bug 的。一句话把「我不干什么」写在脑门上，再把顾客推出门时顺手报了邻居的门牌。对照全系列看过的上百份市场件 SKILL.md，触发词抢地盘的见过一堆（同一套触发词三四个件都来应答），主动给邻居导流的，这是唯一一份写成白纸黑字的。还有一处易漏的细节：动词是 "then apply the fixes"——它不是只出报告，是直接动手改。同门两个件，code-review 默认只读、可选 --fix；simplify 默认动手。一柔一刚，用户用挡位和动词选择控制风险敞口。实战定位：提交前的最后一道收拾，专治「功能对了但代码没法看」。

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 feature works, or to observe behavior."

方法论只有一句：跑起来，观察行为——不是读代码找证据，是执行系统拿证据。这一句把它和静态审查件彻底分开：code-review 读出来的叫「疑似」，verify 跑出来的才叫「确认」。触发侧一口气列了五个短语：verify a PR、confirm a fix works、test a change manually、check a feature works、observe behavior——同义词铺到第五个，就是在给语义匹配撒网：用户嘴上说「帮我看看修好没」「手动测一下」「验收这个功能」，任何一个说法都能命中。这种「一条方法论 + 一网同义触发词」的写法，和市场件里常见的「堆功能清单」是两个流派：前者赌的是高频场景足够窄，窄到可以用五种说法反复占住。实测定位里它是四件中体感最强的一件——「改完→跑通→眼见为实」这个闭环一旦常态化，「我以为修好了」这类事故会肉眼可见地变少。

run：先问项目自己的意见

描述原文："Launch and drive this project's app to see a change working. Use when asked to run, start, or screenshot the app to see a change working, or to confirm it works manually. First looks for a project skill that already covers launching the app; otherwise falls back to built-in patterns per project type (CLI, server, TUI, Electron, browser-driven)."

verify 负责「对行为」，run 负责「开机器」，两者是上下游。run 的描述里有一条完整的寻路算法：第一步先找项目里已有的启动技能（project skill），没有才走内建兜底；兜底按五种项目形态分发——CLI、server、TUI、Electron、browser-driven。这个「先查项目自述、再按形态猜」的次序非常尊重现实：启动一个项目的知识本来就长在项目自己身上（README、Makefile、package.json scripts），通用件不该抢答。触发词里混进了 "screenshot" 很妙——很多人验证 UI 改动的第一诉求不是「跑起来」而是「截图给我看」，一个词把视觉验收也圈了进来。短板：五种形态之外的怪项目（嵌入式交叉编译、需要真实硬件的）它兜不住，得靠项目自带技能接管——好在描述里已经把这条路让出来了。

两个岗哨：值守与减摩擦

loop："Run a prompt or slash command on a recurring schedule... Use for autonomously iterating in a loop, or for periodic re-checks. Do NOT use for background tasks that finish on their own." 又是一件把「不适用」写进描述的：定时重复的活归它，自己会结束的后台任务不归它——正反两条触发边界一起划，防的是最常见的误用（拿它当后台任务跑，结果任务早完了它还在空转）。配合 verify 就是「每五分钟回归一次」的土法值守。

fewer-permission-prompts："Scan your transcripts for common read-only Bash and MCP tool calls, then add a prioritized allowlist to project .claude/settings.json to reduce permission prompts." 这件把「摩擦治理」做成了件：数据源是你自己的历史会话记录，找出高频只读操作，按优先级生成白名单写进项目配置。先分析后放行，放行的还只是只读操作——权限问题上官方同样收着劲。

工作流图

flowchart TD
    A["改完一段代码"] --> B["code-review 找错"]
    B -->|有bug| C["回炉修改"]
    C --> B
    B -->|干净| D["simplify 收拾"]
    D --> E["run 开机器"]
    E --> F["verify 对行为"]
    F -->|不符| C
    F -->|相符| G["loop 定时值守"]
    G --> H["扫记录发白名单"]

对照市场件：轻装版与重装版

同一批动词，市场上有重装版，数据沿用本栏目 5 月存档抓取记录（时点 2026-05，现为当时值）：superpowers 套件把 systematic-debugging、test-driven-development、verification-before-completion 等 12+ 个子技能做成完整工程纪律流水线（存档记 8K+ Star）；gh-fix-ci 专修 CI 红灯（5 月工作流轮已评）；Trail of Bits 安全套件管全库深度审计（4.1K Star）。对账结论：内建件赢在随身与零配置，市场件赢在深度与边界外。日常 diff 级别的找错、收拾、验证，出厂四件已经覆盖八成；剩下两成——全库审计、CI 事故、系统性调试方法论——仍是市场件的地盘。这也是本栏目 5 月存档里「Skills 2.0 渐进式加载」判断的延续：官方自己下场后，先做薄做全，把「厚」留给生态。

安装/使用命令

内建件无需安装，CLI 会话内直接调用：

# 找错：低噪音档审查当前 diff
/code-review low
# 找错：广撒网档，并把发现贴成 PR 行内评论
/code-review high --comment
# 提交前收拾代码（会直接动手改）
/simplify
# 把项目跑起来
/run
# 验证行为：确认修复真的生效
/verify
# 定时值守：每5分钟回归一次
/loop 5m /verify

市场对照件（安装命令来自 5 月存档原文，克隆前请自行确认仓库现况）：

# superpowers 工程纪律全家桶（5月存档：8K+ Star）
git clone https://github.com/obra/superpowers ~/.claude/skills/superpowers
# Trail of Bits 安全审计套件（5月存档：4.1K Star）
git clone https://github.com/trailofbits/skills .claude/skills/trailofbits

推荐排行榜

按场景找件

上手难度（从易到难）：六件全部零配置，差异在使用纪律——simplify 最需要谨慎（默认动手改码），verify 最需要环境（起不来的项目用不了），其余四件随叫随到。

关键发现

1. 描述即路由器。 六个内建件的描述里，每一份都同时写清「我管什么」和「邻居管什么」，simplify 甚至直接报出邻居的门牌。触发词从此不是抢地盘的战场，而是出厂就分好的户籍。
2. 动词分工精确到风险敞口。 只读（code-review 默认）、动手（simplify）、执行观察（verify/run）、定时（loop），四个风险等级一一对应四个动词，用户选件就是在选风险。
3. 「不适用条款」是内建件的标配。 simplify 的 not bug hunter、loop 的 do NOT use for tasks that finish on their own——把负向边界写进描述，是这批件区别于多数市场件的最外显特征。
4. 摩擦本身被做成了件。 权限弹窗、重复操作这类「使用体验税」，官方的解法不是改交互，而是做一件扫记录、发白名单的件——工具的问题用工具收尾。

参考来源

1. anthropics/claude-plugins-official — 官方插件与技能仓库（本栏目 5 月存档抓取记录，时点 Star 19.5K+）
2. trailofbits/skills — Trail of Bits 安全审计技能套件（5 月存档记录，4.1K+ Star）
3. obra/superpowers — 工程纪律全家桶，含 systematic-debugging、verification-before-completion 等子技能（5 月存档记录，8K+ Star）
4. skills.sh — Skills 生态市场与热门榜单（5 月存档记录收录）
5. 内建件描述原文 — 2026-09-15 本机 Claude Code 会话注册表逐条比对；市场件对照数据出自本栏目 2026-05-16 存档抓取文件（output/skills-ecosystem-*.md）

[!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 等场景全覆盖。