第5轮，按轮次规划进入工作流自动化赛道：部署、CI、监控、多Agent协作。部署与自动化框架在前几轮已经拆过，本期换一条纵轴——无人值守梯度。一份真实在用的 Claude Code 装机目录里，自动化件其实排成一条清晰的台阶：先有人喊你修（CI红灯救火），再有人替你写规则（Actions工作流），然后有人替你回话（评论跟进），最后干脆别叫你了（监控值守、长时自治、周期巡检）。本期沿这条梯度横评六件，外加一组内置对照件。
核心发现一句话：判断一件自动化 Skill 的成色，别数它有几个功能，看它的 SKILL.md 里有没有「时间」和「权限」两个变量。 只有事件的件是救火队员，带时间的件才是值班保安，把权限边界写清楚的件才敢让它独自守夜。
本期有个特殊之处：六个主角全部来自本文作者本地环境的真实装机名册，但其中一部分件本期没有开盖读原文。为了不把推断写成事实，全文采用证据分级标注——
| 证据等级 | 含义 | 本期涉及 |
|---|---|---|
| 明牌 | 装机在册，且官方描述可见可引 | run、verify、loop、code-review、claude-api、fewer-permission-prompts |
| 半明牌 | 装机在册，功能由命名与生态惯例可以高置信判断 | gh-fix-ci、gh-cli、gh-address-comments |
| 暗牌 | 装机在册，细节按名推演，已标注「未验证」 | github-actions-skill、sentry、long-running-agent |
这套分级本身就是今天的第一条行业观察：装机目录里躺着大量「只有名字、没有描述」的件——名字就是这个件的门面，命名即文档，这在自动化赛道尤其致命，因为用户要在深夜红灯亮起时决定把刀交给谁。
| 件 | 功能完整度 25% | 设计质量 25% | 实战效果 20% | 上手难度 15% | 社区活跃 15% | 加权 |
|---|---|---|---|---|---|---|
| loop（内置对照） | ★★★★ | ★★★★★ | ★★★★ | ★★★★☆ | ★★★★★ | 4.5 |
| gh-fix-ci | ★★★★ | ★★★★☆ | ★★★★ | ★★★★★ | ★★★★ | 4.3 |
| gh-cli | ★★★★☆ | ★★★☆ | ★★★★☆ | ★★★☆ | ★★★★☆ | 4.1 |
| sentry | ★★★★ | ★★★★ | ★★★☆ | ★★★★ | ★★★★☆ | 4.0 |
| github-actions-skill | ★★★★ | ★★★★ | ★★★☆ | ★★★★ | ★★★☆ | 3.8 |
| gh-address-comments | ★★★☆ | ★★★★ | ★★★☆ | ★★★★☆ | ★★★☆ | 3.8 |
| long-running-agent | ★★★☆ | ★★★★☆ | ★★★☆ | ★★★☆ | ★★★ | 3.7 |
评分为本期评审口径：明牌件依据可见描述与装机体验，暗牌件依据命名定位与生态惯例推演，社区活跃度分数对暗牌件偏保守。
半明牌。三段式命名 gh-动词-宾语，把用途钉死在门牌上：用 gh 命令行去修 CI。这类件是整个自动化梯度的地基件，它的场景极窄但极痛——CI 红灯、日志几百行、人只想知道「哪一行炸了、是不是我提交弄的」。好的救火件应该在 SKILL.md 里写清三件事：先用 gh run list 圈定失败的那次运行，再 gh run view --log-failed 只拉失败日志，最后把修复限制在最小改动范围内。
设计上它踩中了自动化件的第一条铁律：动词起手，名即命令。用户不需要读文档就知道喊它的口令。上手难度给到满星的原因也在这里——前提只是装好 gh CLI 并完成登录，其余全靠触发词自动接管。短板在边界场景：多个 workflow 并联失败、flaky 测试反复横跳时，救火件容易陷入「修一个红另一个又红」的循环，这类件通常需要人在关键改动处踩一脚刹车，本期未见其刹车条款，按需开盖确认。
暗牌。从命名推断，这是写 GitHub Actions 工作流的生成件：你描述「每次合并到 main 要跑测试再发布」，它产出 .github/workflows/ 下的 YAML。它和第一层是供弹关系——救火件处理已有的流水线，它负责铸造新流水线。装了它的团队，等于给「配置工程」这个苦差事找了个代笔。
推演中的设计要点在 YAML 这门方言上：Actions 的 action 版本 pin、secret 注入、matrix 组合、缓存层，全是新手高频翻车点。这类件的含金量取决于 SKILL.md 是否内置了这些坑位清单，而不是会不会拼 YAML 语法——语法模型本来就会，坑位清单才是 Skill 的增量。因未开盖验证其清单深度，实战效果给分保守。同类需求下，直接让通用模型配合官方文档写简单 workflow 的成功率已不低，这件的价值区间在复杂流水线上。
半明牌。命名直译「处理评论」：PR 挂出来之后，评审意见散落在 review threads 里，人工逐条回复是最消耗意志力的机械劳动。这件把「读评论、改代码、逐条回帖」打包成一个动作。
它在梯度里的位置微妙——它是件「社交自动化」件，处理的是代码之外的事务。设计上同样吃动词命名的红利，且场景边界比救火件更清晰（输入是评论列表，输出是修改加回复），理论上限很高。风险也在社交侧：自动回复评审意见的语气、对不认同意见的取舍策略，是这类件 SKILL.md 里最该写透却最常缺席的部分。回帖是署名行为，语气错一次，团队里就没人敢让它上号了。建议使用时保留人工过目一步，把它当草稿生成器而非发帖器。
半明牌。严格说 gh 本身是 GitHub 官方命令行工具，Skill 只是把它封装成 Agent 顺手的形状：告诉模型什么时候该用 gh pr、gh run、gh api 而不是裸 curl 或网页复制。前三层件全是它的上盖——救火、写工作流、回评论，底层调的都是它。
它的评分结构暴露了底座件的通病：功能完整度和实战效果双高（gh 覆盖面大、输出结构化，天然适合 Agent 消费），但设计质量分平平——底座件的 SKILL.md 往往就是一张命令速查表，提示词工程含量低，这是定位使然而非偷懒。对新手的提醒只有一条：装它之前先确认机器上有 gh 并完成 gh auth login，否则前两层件全是空中楼阁。
暗牌。与业界知名错误监控平台同姓，业内通常将其理解为把监控平台的事件流接进 Agent 的入口件：线上报错聚合、堆栈定位、影响面评估，然后在聊天窗口里叫醒你。它是整条梯度里第一个「反向触发」的件——前面四件都是你去找它，它是事件来找你。
因本期未验证其与官方集成的关系与具体实现，只讲这类件的通用设计要害：降噪比接入难十倍。监控件的 SKILL.md 必须回答「什么值得打断用户」，聚合规则、严重度分级、静默窗口，缺了任何一条，它就会在第三天被用户亲手拔线。这个未验证的位置恰好是读者开盖时应重点检查的章节。给分上，社区活跃沾平台本身的光给到四星半，实战效果按接入容易、调优难的现实给三星半。
long-running-agent 是暗牌，从命名看它管的是「跑不完的任务」：构建、迁移、批量处理这类按小时计的活，人不想挂着会话等，就交给它守着，分阶段汇报。这是多Agent协作在单人环境里的落地形态——主会话派发，子任务后台跑，完成后回来销项。设计质量的期待值在其拆分与汇报策略：长任务最大的失败模式不是失败，而是静默失败，所以它的 SKILL.md 里理应有「心跳」与「断点续跑」条款，未验证，读者开盖时先翻这两节。
loop 是明牌对照组，官方描述原文为："Run a prompt or slash command on a recurring interval (for example /loop 5m /foo, defaults to 10m /foo)"。短短一句，信息密度极高，下一节逐词拆它。内置身份让它免安装、即开即用，综合分登顶本期——梯度顶端的自动化，最后浓缩成了一个内置命令，这个事实本身就是对第三方值守件市场最有分量的压力测试。
内置件描述是少数可直接引证的官方原文，逐句拆出四条可复用的写法。
第一式：动词起手，范围钉死。 verify 的原文："Verify that a code change actually does what it's supposed to by running the app and observing behavior." 一个动词开头，紧跟着用 by 短语把手段（跑起来、看行为）钉死。run 同款："Launch and drive this project's app to see a change working." 自动化件的第一句话永远是「做什么+怎么做」，没有形容词的生存空间。
第二式：触发清单与反触发清单成对出现。 claude-api 的描述是最完整的范本——TRIGGER when 列出代码里 import 了哪些 SDK 时必须触发，SKIP when 列出用了别的 SDK 或只是泛泛聊 API 时必须闭嘴。正反两条清单等于给件画了领土边界，这是防止「件误触发、抢别人活」的唯一手段。对照之下，装机名册里那些只有名字没有描述的件，等于没有边防。
第三式：动作参数化，审查变工位。 code-review 的原文给审查件装了两个开关："Pass --comment to post findings as inline PR comments, or --fix to apply the findings to the working tree." 同一个件，默认只出报告，加 --comment 才发帖，加 --fix 才动代码。这就是自动化件的权限设计精髓：把「读」「说」「写」拆成递进的档位，默认停在最低档。回看第三层的 gh-address-comments，它最该抄的就是这一式。
第四式：限幅条款，无限循环变有界服务。 loop 描述里 "(defaults to 10m /foo)" 这半句是点睛之笔——给出默认间隔，就是宣告「不设参数也烧不穿」。配合周期任务自带的过期机制，值守件从第一天起就该写明自己的寿命和熔断条件。第四、五层暗牌件的开盖检查项也在这里：找不到限幅句的值守件，不要让它过夜。
四式合起来就是一条可以照抄的公式：动词开头钉死手段，正反触发画清领土，参数档位递进放权，默认值与过期条款兜底。 写第一个自动化 Skill，照这四句填空，成品不会低于市场中位数。
flowchart TD
ERR["线上报错或评论上门"] --> SEN["sentry 聚合定位"]
SEN --> Q1{"需要动代码吗"}
Q1 -->|否| LOG["归档与通报"]
Q1 -->|是| FIX["gh-fix-ci 接管红灯"]
FIX --> ACT["github-actions-skill 补改工作流"]
ACT --> API["gh-cli 提交与查询"]
API --> RET{"重跑转绿吗"}
RET -->|仍红| FIX
RET -->|转绿| REP["gh-address-comments 回帖销项"]
REP --> LONG["long-running-agent 接长任务"]
LONG --> LOOP["loop 定时巡检"]
LOOP -->|发现新红灯| SEN
六件不是竞品，是一班岗：从事件救火到周期巡检，每一层把「需要人到场」的时刻往后推一格。
# 前置：GitHub 官方 CLI 并完成登录（第一至第四层件的地基）
brew install gh && gh auth login
# 在 Skills 市场搜索各件的在架情况
npx skills find gh-fix-ci
npx skills find github-actions
npx skills find sentry
npx skills find long-running-agent
# 按市场返回的 owner/件名 安装
npx skills add <owner>/<skill-name>
# 或手动安装到个人技能目录
git clone https://github.com/<owner>/<repo> ~/.claude/skills/<skill-name>
# 内置对照件无需安装，直接喊口令
/verify 这个 PR 修的问题真的修好了吗
/loop 15m 跑一遍 gh run list，红灯就汇总原因发我
这条梯度走到头，会发现工作流自动化的终局不是更多件，而是更少的到场：救火件把人从日志里捞出来，供弹件把人从 YAML 里捞出来，值守件把人从「盯着」这个动作里捞出来。每一层件的 SKILL.md 里，「时间」与「权限」两个变量的写法，决定了它到底是替你值班，还是给你添了班。市场中大多数自动化件死在第一天，不是功能不行，是描述里没写清它几点上班、几点下班、钥匙交给谁。
npx skills 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 等场景全覆盖。