前两轮我们看的都是货架上的散件：第三方作者写的 Skill，各自为政，质量参差。这一轮换个刀法，拆一个更值得注意的信号——Claude Code 官方已经把「写完代码之后」这一段，做成了四个内置命令：/code-review 审、/simplify 简、/verify 验、/run 跑，外加一个安全特化的 /security-review。五件套分工明确、描述里互相引用，形成一条从「审出问题」到「亲手修掉」再到「跑起来证明确实好了」的闭环。本文基于本机实测的内置命令清单，逐件拆它的功能边界、触发描述写法和设计取舍，并顺带盘点同一台机器上装着的社区件，看官方下场之后，社区件还剩下哪些生态位。本期所有引文均来自装机实测，不引用任何未经核实的外部数据。
拆开来看，这四个命令不是四个孤立工具，而是一条流水线的四个工位。/code-review 负责发现问题，它的描述原文是："Review the current diff for correctness bugs and reuse/simplification/efficiency cleanups"——注意，它审的不只是 bug，连「可以复用、可以简化、可以提速」的质量问题也一并扫。发现问题之后有两条岔路，官方直接把后处理做成了旗标："Pass --comment to post findings as inline PR comments, or --fix to apply the findings to the working tree after the review"。--comment 把发现贴回 PR 行内评论，走人工流程；--fix 让它直接改工作区，走自动流程。一个命令，两种交付形态。
修完之后呢？/simplify 接力瘦身，/verify 负责验证，/run 负责把应用跑起来。四件的关系如下图：
flowchart TD
A["① /code-review 审diff"] --> B["问题清单"]
B -->|"评论模式"| C["贴回PR行内"]
B -->|"修复模式"| D["直接改工作区"]
D --> E["② /simplify 瘦身"]
E --> F["③ /verify 验行为"]
F --> G["④ /run 起应用"]
G --> F
这个闭环的妙处不在每个件多强，而在职责被切得足够干净——干净到每个件的描述里都写着「我不干什么」。这一点值得每个自己写 Skill 的开发者抄作业，后面细说。
评分说明：5 星为最好；「上手难度」星越多越容易上手；「社区活跃度」对内置件而言指随官方主版本的迭代维护，本轮未引用外部 star 数据，按保守口径评。
| Skill | 功能完整度 25% | 设计质量 25% | 实战效果 20% | 上手难度 15% | 社区活跃度 15% | 加权 |
|---|---|---|---|---|---|---|
| /code-review | ★★★★★ | ★★★★★ | ★★★★ | ★★★★★ | ★★★★ | 4.7 |
| /simplify | ★★★★ | ★★★★★ | ★★★★ | ★★★★★ | ★★★★ | 4.4 |
| /verify | ★★★★ | ★★★★ | ★★★★ | ★★★★ | ★★★★ | 4.0 |
| /security-review | ★★★★ | ★★★ | ★★★★ | ★★★★★ | ★★★★ | 3.9 |
| /run | ★★★ | ★★★★ | ★★★★ | ★★★★★ | ★★★★ | 3.8 |
定位：改动后的第一道守门，只看当前 diff，输出问题清单。
它最值得拆的一句是分档设计："low/medium: fewer, high-confidence findings; high→max: broader coverage, may include uncertain findings"。翻译过来：低档少而准，高档广而杂、可能混进不确定的发现。大多数审查工具会把「高分档」包装成纯增益，这里却把不确定性的代价写在了描述里——你调高档位，买的是覆盖面，付的是误报率。这种把取舍摆上台面的写法，比「更全面更强大」式的宣传诚实得多，也让使用者能按场景选档：合 PR 前快扫用低档，周度大扫除用高档。
--comment 和 --fix 两个旗标则解决了审查工具的经典痛点：发现一堆，然后呢？贴回 PR 是给人看的交付，直接修工作区是给流程吃的交付。短板也明显：只审 diff，跨文件的系统性问题（架构腐化、重复模式散落多处）不在它的视野里，那是 /simplify 的活。
定位：只管代码质量，只做瘦身，不抓虫。
它的描述里有一句堪称 Skill 写法范本的话："Quality only — it does not hunt for bugs; use /code-review for that"。先声明自己只管质量，再明确指路「抓虫请去隔壁」。这一句同时干了两件事：给使用者划清预期，给模型划清任务边界——模型读到这句，就不会在瘦身时顺手「修 bug」，把改动范围失控。它扫的范围是 "reuse, simplification, efficiency, and altitude problems"，前三项好理解，第四项 altitude（层级）问题指代码抽象层级错位：该调高层接口的地方摸了底层细节、一个函数里混着业务逻辑和胶水代码。这个词出现在官方描述里，说明质量审查已经细到「写得对但写得矮」这一层。
短板是与 /code-review 的 cleanup 项有重叠，先审后简还是只跑其一，需要使用者自己拿主意。
定位：把改动真的跑起来，观察行为，验证它干了它该干的事。
描述开门见山："Verify that a code change actually does what it's supposed to by running the app and observing behavior"。关键词是 running 和 observing——不是复述代码逻辑，不是跑两个单测交差，而是起应用、看行为。它的触发描述还列了一堆同义说法：verify a PR、test a feature works、validate a change manually……把用户可能脱口而出的问法全部枚举进去，这是触发词设计的「同义爆炸」策略：你换个说法它也接得住。
短板依赖前提：项目得能跑。纯库改动、没有可运行入口的改动，它施展不开。
定位：不是审查件，是验证的前置——把项目的应用跑起来。
描述第一句："Launch and drive this project's app to see a change working"。它先找项目里有没有现成的启动 Skill，没有就按项目类型套内置模式，覆盖 CLI、server、TUI、Electron、浏览器驱动这五类。它和 /verify 的分工值得玩味：run 负责「起」，verify 负责「证」。拆成两件而不是合成一件，意味着「起不来」和「起了但行为不对」是两类问题，分开诊断更清楚。
定位：安全特化的守门，审改动里的安全漏洞。坦白说，本轮装机清单里它没有附带描述原文，所以这节拆得最简、评分也最保守——但它是四个斜杠里唯一带安全标签的，加上本机同时装着 security-best-practices、security-threat-model、security-ownership-map 三个社区件，可以看出安全这件事被切成了「写码时守规矩」「设计时建模」「提交前审查」三个阶段，各自有件。
同一台机器的已装清单里，还有一圈开发效率相关的社区件，点名记录、不做评价：gh-fix-ci（CI 挂了去修）、gh-address-comments（处理 PR 审查意见）、gh-cli 与 github-actions-skill（GitHub 操作与工作流编写）、security 三件套、外围还有 fewer-permission-prompts——它的描述是 "Scan your transcripts for common read-only Bash and MCP tool calls, then add a prioritized allowlist"，扫你的历史记录，把常用只读操作加进白名单，减少权限弹窗打断。对比内置四件，社区件的生态位正在往「官方没覆盖的缝隙」退：官方管审改简验，社区管 CI、PR 协作、权限治理这些更贴近个人工作流的细活。
内置五件无需安装，随 Claude Code 直接可用：
/code-review # 审当前 diff，默认档位
/code-review low # 低档：少而准
/code-review high # 高档：广而杂
/code-review --comment # 发现贴回 PR 行内评论
/code-review --fix # 审完直接改工作区
/simplify # 只瘦身不抓虫
/verify # 跑应用验行为
/run # 起项目应用
/security-review # 安全审查
推荐的组合拳是审→简→验三连：先 /code-review --fix 修硬伤，再 /simplify 瘦身，最后 /verify 收口。社区件的通用装法是把含 SKILL.md 的文件夹放进 ~/.claude/skills/，或经 /plugin 走插件市场。
mindmap
root((写码闭环Skill分层))
内置命令层
code-review
simplify
verify
run
security-review
插件层
webapp-testing
mcp-builder
用户自装层
gh-fix-ci
gh-address-comments
security三件套
/verify——「跑起来看行为」最直观，还能顺带学会怎么描述验收标准。/code-review --fix——审修一体，省掉把发现转成改动的手工环节。/simplify——那句「抓虫去隔壁」的单一职责声明，是所有 Skill 作者的第一课。/code-review 的分档描述——把误报率写成高档位的价签。/security-review 加社区三件套，分阶段布防。/run——五类项目类型兜底，从此告别「起不来环境」的借口。第一，声明你不管什么。/simplify 用一句话挡住了任务蔓延，你的 Skill 也应该有一句「本 Skill 不做 X，X 请用 Y」。第二，把取舍写成价格。/code-review 高档位的描述承认「可能混进不确定发现」，使用者因此才信任低档位的「少而准」。第三，触发词同义爆炸。/verify 把用户可能说的五种问法全列进描述，模型匹配触发时就不会漏。第四，用结构化触发替代散文。本机另装的 claude-api 件把触发条件写成 TRIGGER when / SKIP when 两段结构：什么时候触发（代码引入 anthropic SDK）、什么时不触发（用的是 openai 等其他 SDK），机器可判，人可读。四条都不玄，抄就能用。
/code-review、/simplify、/verify、/run 的全部英文引文均出自其官方触发描述原文~/.claude/skills 已装社区件名录（2026-09-24 实读）——gh-fix-ci、gh-address-comments、security 三件套、fewer-permission-prompts 等点名出处webapp-testing、mcp-builder 等插件层条目出处[!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 等场景全覆盖。