Skills 生态走到第三轮，开发者效率这个大方向里，代码审查和测试都已经有专文交代，唯独「调试」这块地一直空着。本期补上：只盯报错之后的那段流水线——线上报警了谁接、CI 红了谁修、notebook 炸了谁管、修完谁来验收。入选六件：内建三兄弟 verify / code-review / simplify，加上修虫三件 gh-fix-ci / notebook-fix / sentry。与前几轮抓 GitHub 门牌不同，本期素材来自一台真实 Claude Code 宿主的实装清单——能看到的是「装进机器之后、真正参与触发的那一行描述」，这恰是 SKILL.md 里最值钱的 frontmatter 字段。核心发现一句话：调试没有王者件，只有流水线上的工位件；单件都不完美，串起来才闭环。
前两轮横评，拆的是 GitHub 上 SKILL.md 的原文；本期换了个更刁的视角——拆宿主加载后的实装清单。区别在哪？一个 Skill 发布时写得天花乱坠，装进 Claude Code 之后，真正决定它「什么时候被叫起来」的，是 frontmatter 里那行 description。本机清单里，code-review 的描述塞了两句话、三个档位、两个开关参数；而 gh-fix-ci、notebook-fix、sentry 在清单里是裸名上架——连一行描述都没有，触发全靠名字里的关键词命中。这个差别本身就值得单独一篇，先记下。
另外交代边界：内建三件的描述行是宿主原文，可以逐词拆；修虫三件本机清单未载描述行，功能按其名字语义与同类件的常见实现推断，不做逐行硬拆——拿不准的宁可不说，这是本期底线。星级为定性评分（本机实装观察 + 设计分析），未引用任何第三方计数。
| Skill | 功能完整度 25% | 设计质量 25% | 实战效果 20% | 上手难度 15% | 社区活跃 15% | 加权综合 |
|---|---|---|---|---|---|---|
| code-review | ★★★★ | ★★★★★ | ★★★★ | ★★★★★ | ★★★★ | 4.4 |
| gh-fix-ci | ★★★★ | ★★★★ | ★★★★ | ★★★★ | ★★★ | 3.9 |
| verify | ★★★ | ★★★★ | ★★★★ | ★★★★★ | ★★★★ | 3.9 |
| simplify | ★★★ | ★★★★ | ★★★ | ★★★★★ | ★★★★ | 3.7 |
| sentry | ★★★★ | ★★★ | ★★★ | ★★★ | ★★★ | 3.3 |
| notebook-fix | ★★★ | ★★★ | ★★★ | ★★★★ | ★★ | 3.0 |
内建件，零安装。它的描述行是六件里工程化程度最高的，值得整段引出来：
Review the current diff for correctness bugs and reuse/simplification/efficiency cleanups at the given effort level (low/medium: fewer, high-confidence findings; high→max: 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.
拆到词：第一句划边界——只看当前 diff，不翻全仓库，这决定了它的运行成本可控；第二句给了 low/medium/high 三档「查得多准 vs 查得多广」的旋钮，并诚实标注 high 档「可能包含不确定的发现」；最后给 --comment（发到 PR 行内评论）和 --fix（直接改工作区）两个出口。一个 Skill 的触发描述里同时写清范围、档位、副作用边界和两个参数出口，这在整个生态里都属罕见——大多数社区件的描述还停留在「Helps you write better code」这种空话级别。短板：它只防不修，diff 之外的存量虫一律不管。
gh-* 系列的一员（同门还有 gh-address-comments、gh-cli），分工明确：CI 挂了，拉日志、定位失败用例、给出修复。它排在综合第二，靠的是「事件驱动」的准触发——红灯本身就是最强触发信号，不需要用户组织语言描述问题。亮点：把「读 CI 日志」这个最磨人的活整个吞掉，日志几十屏的滚动输出正是模型耐心比人强的场景。短板有二：一是裸名上架，描述行缺失意味着「CI 黄了但措辞不像 fix-ci」时可能漏触发；二是它默认「测试错了」，偶尔真实情况是测试本身写错，修虫修成了改题——用的时候要在指令里留一句「先判断是代码错还是测试错」。
内建件。描述行原文：
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 look at local changes before pushing.
它的设计亮点是那串 Use when... 场景清单——verify PR、确认修复有效、手动测试、检查功能、push 前过目，五个触发场景一口气列全，这是「场景清单式门牌」的标准范本。在调试流水线里它是缺了会出事的一环：修虫件说「修好了」，谁去真跑一遍？verify 的存在价值就是把「改完 = 修好」这个危险等式拆掉。短板：它要真跑应用，遇到没有本地运行环境的仓库（纯库、重依赖、要云服务）会直接力竭，描述行里也没写这种边界场景的降级策略。
内建件，描述行最有意思的一句是结尾：
Review the changed code for reuse, simplification, efficiency, and altitude cleanups, then apply the fixes. Quality only — it does not hunt for bugs; use /code-review for that.
「Quality only — it does not hunt for bugs; use /code-review for that.」——这是让路式门牌的活教材：一句话把自己的职责边界（只管质量不管虫）和邻件分流路径（找虫去找 code-review）都写死了。内建件之间靠描述行互相避让、避免双重触发，这个设计在生态里并不常见，多数社区件巴不得描述写得越宽越好、什么都接。局限：simplify 与 code-review 的第二职责（cleanups）故意重叠——一个只报告、一个直接动手，重叠是有意的分工而不是设计事故，但使用者很容易混淆该叫哪个，这是内建家族共同的认知成本。
唯一盯线上的一件。Sentry 本身是主流错误监控平台，这个 Skill 的角色是把线上报警台接进宿主：错误聚合、堆栈、影响面摆在对话里，让调试从「用户截图报错」升级为「哨兵直接递卷宗」。它站的位置最上游——线上错误 → 定位 → 修复的链条，没有它，前面几件全都在等人工喂料。短板实在：上手门槛三颗星不冤——要有 Sentry 账号、项目接入、凭据配置，三道门做完才能用；描述行缺失的问题它同样有。适合已经有 Sentry 存量接入的团队，零基础团队先别从它入手。
名字即定位：修 Jupyter notebook 的错。notebook 是种特殊的报错现场——报错藏在 cell 输出里、状态依赖执行顺序、修复后还要重跑验证，通用修虫件在这种场景经常水土不服。它窄到生态里几乎没有同类竞品（本期视野内未见第二个专攻 notebook 修虫的件），这是「缝隙件」的典型生存策略：不做全能修虫，只占一个别人看不上的工位。社区活跃度给两颗星是六件最低：小众场景 + 裸名上架 + 本机清单零描述，三重边缘化。但如果你日常就是和数据 notebook 打交道，它可能是六件里唯一每天都叫得动的。
六件不是互斥选项，是一条链上的六个工位：
flowchart TD
A["线上报错"] -->|sentry 哨兵| B["递上错误卷宗"]
C["CI 红灯"] -->|gh-fix-ci 接单| B
D["notebook 报错"] -->|notebook-fix 接单| B
B --> E["定位根因"]
E --> F["动手修复"]
F --> G["跑测试回归"]
G -->|不过| E
G -->|通过| H["verify 真跑验收"]
H -->|行为不对| F
H -->|行为对了| I["simplify 打扫"]
I --> J["code-review 闸门"]
J -->|打回| F
J -->|放行| K["合并收工"]
顺着链读一遍会发现：「报错之后」根本不是一个技能点，是六个技能点的接力。生态里那些号称「一站式修 bug」的大而全件，反而不如这条单件接力链可靠——每一段的职责边界都写在明面上。
# 内建三件：无需安装，Claude Code 直接可用
/verify # 修完后验收：真跑应用看行为
/code-review # 合并前找虫：可加 --fix 或 --comment
/simplify # 质量打扫：只管整洁不管虫
# 修虫三件：通用安装法——克隆仓库后拷入个人技能目录
mkdir -p ~/.claude/skills
cp -r <仓库>/skills/gh-fix-ci ~/.claude/skills/
cp -r <仓库>/skills/notebook-fix ~/.claude/skills/
cp -r <仓库>/skills/sentry ~/.claude/skills/
# 或走插件市场渠道（本机即通过 anthropic-agent-skills 市场分发官方件）
# 在 Claude Code 会话内执行 /plugin 浏览已配置的市场
本期最大的收获不是「哪件最强」，而是那条链：防虫在前（code-review）、修虫在中（gh-fix-ci / notebook-fix）、哨兵在上游（sentry）、验收和打扫在后（verify / simplify）。六件里有三件是内建、三件裸名上架，也印证了一个生态趋势——调试这类高频刚需，正在从社区件市场回流到宿主内建；社区件的机会只剩 notebook-fix 这样的窄缝。给你的行动建议：先把三个内建斜杠用熟（今晚就能用），再按自己报错最常出现在哪一层（线上 / CI / notebook）挑一件外装，最后照着那条链补齐缺的工位。
~/.claude/skills/（gh-fix-ci、notebook-fix、sentry 实装目录）与 ~/.claude/plugins/marketplaces/anthropic-agent-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 等场景全覆盖。