Skills 生态拆解第3轮，方向是开发者效率类横评。这条赛道的四个子方向里，调试与测试、重构、CI 都已被此前各期包圆，本期补上最后一块空白：代码审查与 PR 收尾。拆解对象不是市场新架的社区件，而是本机 Claude Code 环境随装即用的七件“出厂件”——code-review、security-review、simplify、verify、gh-fix-ci、gh-address-comments、gh-cli。核心发现有两条：其一，这条赛道被出厂件整体接管，七件恰好按 PR 生命周期一字排开，拼起来是一条完整流水线；其二，这批件的 SKILL.md 描述里出现了生态中少见的设计——互相引用、互相划界，simplify 甚至把“我不找 bug，找 bug 找 code-review”直接写进了触发描述。需要说明：本期评测基于装机实录与描述文本的静态拆解，社区 Star 与下载量未做联网核验，相关维度按分发渠道代理评估。
权重按生态惯例：功能完整度 25%、设计质量 25%、实战效果 20%、上手难度 15%、社区活跃度 15%（出厂件无独立社区，按“随 CLI 分发、零安装”计）。
| Skill | 功能完整度 | 设计质量 | 实战效果 | 上手难度 | 社区/分发 | 加权总分 |
|---|---|---|---|---|---|---|
| code-review | ★★★★★ | ★★★★★ | ★★★★★ | ★★★★★ | ★★★★★ | 5.0 |
| verify | ★★★★★ | ★★★★★ | ★★★★★ | ★★★★★ | ★★★★ | 4.85 |
| simplify | ★★★★ | ★★★★★ | ★★★★ | ★★★★★ | ★★★★ | 4.35 |
| gh-fix-ci | ★★★★ | ★★★★ | ★★★★★ | ★★★★ | ★★★★ | 4.20 |
| security-review | ★★★★ | ★★★★ | ★★★★ | ★★★★★ | ★★★★ | 4.15 |
| gh-address-comments | ★★★★ | ★★★ | ★★★★ | ★★★★ | ★★★★ | 3.80 |
| gh-cli | ★★★ | ★★★ | ★★★ | ★★★★ | ★★★★ | 3.25 |
另有 review 一件与本组同场装机，定位与 code-review 相近但描述极简，疑似轻量入口，本期不计分，仅在文末备注。
把七件按 PR 生命周期排开，就是下面这条线。前半段是推送前的本地双闸加实证，后半段是推送后的 CI 抢修与意见回复，最后回到改动起点，形成闭环。
flowchart LR
A["本地改动 diff"] --> B["code-review 找正确性bug"]
A --> C["security-review 扫安全洞"]
B --> D{"有 finding"}
C --> D
D -->|有| E["--fix 落盘修复"]
D -->|无| F["verify 跑应用实证"]
E --> F
F --> G["simplify 质量清理"]
G --> H["push"]
H --> I{"CI 绿灯"}
I -->|否| J["gh-fix-ci 红灯抢修"]
J --> H
I -->|是| K["评审意见到达"]
K --> L["gh-address-comments 逐条处理"]
L --> A
mindmap
root((评审流水线七站))
找问题
code-review 正确性与质量
security-review 安全专项
清质量
simplify 四维清理
实证
verify 跑起来看行为
收尾
gh-fix-ci 红灯抢修
gh-address-comments 回复意见
gh-cli 仓库操作底座
定位是审当前 diff，描述里承诺两类产出：correctness bugs（正确性 bug） 和 reuse/simplification/efficiency cleanups（复用、简化、效率类质量清理）。一次扫描、两份清单，这是它和单一职责社区件的第一个差异——它先抓致命问题，顺手记录质量问题，但自己不动手清理，清理权交给了 simplify。真正的杀手锏是两个开关：--comment 把 findings 直接贴成 PR 行内评论，产出物从终端落到了评审现场；--fix 在审完后把修复应用到工作区，注意是工作区而非直接推远端，等于在“发现”和“修复”之间留了一道人工确认闸。亮 点是档位化的查全查准承诺和三形态出口；短板是描述未承诺跨文件架构级问题，大重构场景仍需人主导。
如果说 code-review 是“读代码找问题”，verify 就是“跑应用看行为”——它的描述写得很硬：通过真正运行应用并观察行为来验证改动是否达到了目的，适用场景包括手动测试一项改动、确认改动在真实应用里生效、以及在 push 前建立信心。这句 "before pushing" 是时机设计的点睛之笔：它把自己卡在推送前的最后一个闸口，和流水线里所有静态审查件形成互补而非竞争。审查工具再严，也审不出“代码逻辑对但产品行为错”这类问题，verify 补的正是这个洞。亮点是把“运行—观察”的实证方法论写成了可触发技能；短板是依赖项目可运行，遇到需要复杂环境（数据库、外部服务）的仓库，成本会陡增。
定位是审改动代码中的复用、简化、效率和 altitude（抽象层级） 四类清理点，然后直接应用修复。四个维度里 altitude 最值得展开：它管的不是代码风格，而是抽象高度——这段逻辑是该内联还是该提函数，是“写得太低”还是“悬得太高”，这是多数 lint 工具和审查件都不碰的地带。但 simplify 真正的课堂价值在描述的最后一句："Quality only — it does not hunt for bugs; use /code-review for that"。这是一句划界声明：明确宣布自己不找 bug，并把用户导向隔壁的 code-review。两句描述互相引用，触发冲突在源头被消解——在动辄十几件同场待命的机器上，这种“描述即路由”的写法比任何调度器都便宜。短板：默认动手改码，胆小的团队需要先在小分支试它的手感。
站位极其清晰：CI 红灯后的专项抢修。流水线前半段的一切审查都在防患于未然，但红绿灯终究会亮，此时需要的不是再审一遍代码，而是一个懂得读 CI 日志、定位失败步骤、修复并重新触发的执行者。gh-fix-ci 的实战分给到五星，因为“CI 红灯”是开发者日程上摩擦最大的事件之一——上下文切换成本极高，而这类问题的输入输出都高度结构化（日志进、修复出），恰好是 agent 最擅长的形态。短板是名字绑定了 gh 生态，GitLab/Gitea 用户需要确认兼容性；且描述未见对“修不动时的止损策略”作出承诺，遇到系统性损坏的流水线仍需人来叫停。
从名字与流水线站位看，它的分工是安全专项审查——正确性 bug 丢功能，安全漏洞丢数据，两者严重度不同，值得分闸把守。它和 code-review 构成“双闸”结构：前者管“代码做没做对”，后者管“代码有没有洞”，注入、越权、敏感信息泄漏这类问题在专项审查里的召回率理应高于混在通用审查里。本机清单未附带它的长描述，评分按站位价值与出厂件的一致性水准给出，此为诚实声明。短板同理：无法从描述确认它覆盖 OWASP 哪些类别、是否支持自定义规则，重合规场景的团队别把它当唯一安全门。
评审意见到达之后的处理件。PR 协作里最琐碎的环节不是写代码，而是逐条回应评审意见：确认、修改、解释、礼貌地反驳。gh-address-comments 承接的正是这一段——把站外反馈拉回流水线，处理完又回到改动起点，是图上那条回边的物理载体。设计分只给三星，因为它天然是“翻译件”：价值取决于上游评审意见的质量，遇到表达模糊的意见，它把模糊变成代码的能力存疑。但站位价值无可替代——没有它，流水线止步于 push，有了它，“评审—修改—再提交”的循环才由 agent 端到端接管。
它不是流水线上的专职站，而是 gh 命令行的通用封装，建 PR、查状态、管 issue 都能干。评分垫底的原因很朴素：前三件专职站都能被它以“通用能力”名义覆盖一部分，但反过来，专职站提供的结构化承诺（档位、划界、时机）它一概没有。它的价值在流水线之外的自由场景——当你需要的是“操作 GitHub”而非“审代码”，它是唯一入口。建议把它当备件库，不当主力件。
七件里唯一值得逐句拆的描述是 code-review，它的每一句都对应一个可复用的设计决策。
第一句：双清单。 "Review the current diff for correctness bugs and reuse/simplification/efficiency cleanups" ——一次扫描承诺两类产出。设计含义：审查的边际成本几乎全在“读代码”，分类输出近乎免费，那就该免费送。
第二句：档位即承诺。 "low/medium: fewer, high-confidence findings; high→max: broader coverage, may include uncertain findings" ——这是把检索工程里 precision/recall 的权衡直接写进了用户接口，并翻译成了人话：低档卖“报出来的都靠谱”，高档卖“多报，容许误报”。用户不再需要理解参数含义，选档就是在选容忍度。生态里大量社区件的描述只写“能做什么”，不写“不同用法下表现如何”，这句是范本。
第三、四句：三形态出口。 默认输出报告，--comment 变 PR 行内评论，--fix 变工作区补丁。同一引擎，三种交付形态，且危险度递增：报告只读、评论写远端但不改码、补丁改本地码但不推远端。每个出口都停在“可撤销”的边界内，没有一步直通生产。给想写 Skill 的读者的建议照抄这套表：先列你的产出物形态，再为每种形态设一个最小参数，最后检查每条路径的止盈点是否安全。
顺带一提 simplify 那句划界声明与 code-review 描述末尾的分工呼应，构成生态里少见的“件间协议”：不是靠调度器硬分流量，而是每件在自我介绍时就把路由规则说清楚。这套写法成本为零，值得所有 Skill 作者抄走。
同场装机还有一件不审代码的：fewer-permission-prompts，扫描历史 transcript 里的只读 Bash 与 MCP 调用，生成优先级排序的 allowlist 写进项目 settings，减少整条流水线的权限弹窗。它提醒了一件事：流水线的效率瓶颈不总在审查逻辑里，还在每一步的摩擦里。这件放在任何一期“工作流自动化”横评里都成立，本期记录在案。
# 前半段：推送前，本地执行
/code-review # 默认档审 diff，输出报告
/code-review --comment # findings 贴成 PR 行内评论（审前可选 low/medium/high/max 档）
/code-review --fix # 审完把修复落到工作区
/security-review # 安全专项闸
/simplify # 四维质量清理并动手修复
/verify # 跑应用实证行为，push 前最后一闸
# 后半段：推送后，自然语言触发即可
# "用 gh-fix-ci 修一下这条 CI 红灯"
# "用 gh-address-comments 处理 PR 上的评审意见"
# "用 gh-cli 建一个 draft PR"
# 市场检索（对比社区件时用）
npx skills find code review
review 件与本组同场装机，定位近似 code-review 的轻量入口，因描述信息过少未纳入计分；init 属工程初始化件，与评审赛道无关，均记录备查。社区热度数据（Star、下载量、榜单位次）本期未做联网核验，评分中该维度按“随 CLI 出厂分发”这一事实代理计分，读者引用时请注意此边界。
[!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 等场景全覆盖。