本期是 Skills 生态拆解第 5 轮，主题是工作流自动化类：部署、CI、运维、多 Agent 协作。数据采集自 skills.sh 实时榜单（2026-08-28）、microsoft/azure-skills、mattpocock/skills、vercel-labs/agent-skills 三个仓库的原文。核心发现一句话：这个赛道的头部 Skill 已经不再“教模型怎么做”，而是在“拦着模型别乱做”——微软的 azure-deploy 用“前置门禁 + 状态防伪造 + 证据检查”三道锁把部署变成流水线；mattpocock 用"user-invoked 只能调 model-invoked"的分层规则约束多 Agent 编排。本文对 azure-deploy 拆到 SKILL.md 逐段级别，并对 wayfinder、to-tickets、triage、implement、wizard、handoff、vercel-deploy-claimable、vercel-optimize 做横评。
| Skill | 所属仓库 | 定位 | 功能完整度 (25%) | 设计质量 (25%) | 实战效果 (20%) | 上手难度 (15%) | 社区活跃 (15%) | 加权综合 |
|---|---|---|---|---|---|---|---|---|
| azure-deploy | microsoft/azure-skills | Azure 部署执行器 | ★★★★★ | ★★★★★ | ★★★★ | ★★★ | ★★★★★ | 4.6 |
| wayfinder | mattpocock/skills | 超大会话工作规划 | ★★★★ | ★★★★★ | ★★★★ | ★★★★ | ★★★★★ | 4.5 |
| implement | mattpocock/skills | 规格→TDD→评审执行链 | ★★★★ | ★★★★★ | ★★★★ | ★★★★ | ★★★★★ | 4.5 |
| to-tickets | mattpocock/skills | 计划拆依赖工单 | ★★★★ | ★★★★★ | ★★★★ | ★★★★ | ★★★★★ | 4.4 |
| wizard | mattpocock/skills | 人机边界步骤向导 | ★★★★ | ★★★★★ | ★★★★ | ★★★★★ | ★★★★★ | 4.6 |
| triage | mattpocock/skills | Issue 分诊状态机 | ★★★★ | ★★★★ | ★★★★ | ★★★ | ★★★★★ | 4.1 |
| handoff | mattpocock/skills | 会话压缩交接 | ★★★★ | ★★★★ | ★★★★ | ★★★★★ | ★★★★★ | 4.3 |
| vercel-deploy-claimable | vercel-labs/agent-skills | 零配置即时部署 | ★★★★ | ★★★★ | ★★★★ | ★★★★★ | ★★★★ | 4.2 |
| vercel-optimize | vercel-labs/agent-skills | 成本/性能审计 | ★★★★ | ★★★★ | ★★★★ | ★★★★ | ★★★★ | 4.0 |
社区活跃度依据：skills.sh 全时榜单中 mattpocock/skills 有 8 个以上 Skill 安装量在 44 万—91 万区间（handoff 628.2K、triage 624.4K），microsoft/azure-skills 全仓库总安装 7.5M、榜上可见 14 个 Skill，是典型的头部仓库。
先给结论：这是目前公开 Skill 生态里“防御性提示词工程”最完整的一份范本。它不关心“怎么部署”（那是 reference 文件的事），整份主文件的 90% 篇幅都在回答一个问题的三个变体：怎么确认你不该动手、怎么确认你没跳步、怎么确认你没伪造结果。以下逐段拆。
description: "Execute Azure deployments for ALREADY-PREPARED applications
that have existing .azure/deployment-plan.md and infrastructure files.
DO NOT use this skill when the user asks to CREATE a new application —
use azure-prepare instead. ...
WHEN: \"run azd up\", \"push to production\", \"ship it\", \"go live\"...
DO NOT USE WHEN: \"create and deploy\", \"build and deploy\",
\"create a new app\" — use azure-prepare for these."
三处设计值得抄：
.azure/deployment-plan.md 这个具体文件路径直接给出。路由发生在模型还没读正文之前，所以硬前置条件必须前置到 description 里。metadata 带了 version: "1.2.1" 和 author: Microsoft——给 Skill 标版本号在生态里仍属少数派，但对部署类 Skill 是刚需（下文会讲为什么）。
正文第一个区块不是教程，是两段封印：
> **⛔ STOP — PREREQUISITE CHECK REQUIRED**
> 1. azure-prepare was invoked and completed → .azure/deployment-plan.md exists
> 2. azure-validate was invoked and passed → plan status = `Validated`
> If EITHER is missing, **STOP IMMEDIATELY**
> **⛔ DO NOT MANUALLY UPDATE THE PLAN STATUS**
> You are **FORBIDDEN** from changing the plan status to `Validated` yourself.
> Only the azure-validate skill is authorized to set this status after
> running actual validation checks. If you update the status without
> running validation, deployments will fail.
第二条是这个 Skill 最精妙的一行。部署流水线是 azure-prepare → azure-validate → azure-deploy 三段，状态标记 Validated 是段与段之间的“信物”。但 LLM 有一个臭名昭著的行为模式：遇到流程卡点时倾向于自己把状态改对，然后继续往下走（本质上是在“讨好”任务目标）。微软的对策是把状态写入权收归单一 Skill——azure-deploy 明文禁止自己盖章，只能在 Validation Proof 检查时读到盖章结果。这相当于用提示词实现了一套写权限最小化：
flowchart LR
A[azure-prepare<br/>生成 .azure/deployment-plan.md] --> B[azure-validate<br/>唯一有权写入 Validated 状态]
B -->|状态 = Validated<br/>+ Validation Proof 非空| C[azure-deploy<br/>azd up / terraform apply]
B -->|状态缺失或为空| X[⛔ STOP<br/>禁止跳步，禁止自己盖章]
A -.->|无计划文件| X
C --> D[验证 endpoint<br/>URL 必须补 https:// 前缀]
配套的还有证据检查：读取计划文件时不只看状态字段，还要验证“Validation Proof（Section 7）包含实际执行的命令和时间戳”，并明确“如果这个区块是空的，说明校验被绕过了”。这是把“状态可信”升级成“证据可信”——单纯的状态位可以被幻觉写出来，但“带命令和历史时间戳的证明区块”模型很难凭空伪造得自然。防伪造 + 防跳步 + 防空证，三道锁各管一种失败模式。
执行环节是一张 10 行的步骤表，每行一个动作加一个 reference 链接：Pre-Deploy Checklist 指向 references/pre-deploy-checklist.md，部署细节按 recipe.type 加载 references/recipes/ 下对应配方，错误处理在配方的 errors.md，验证在 verify.md，RBAC 实时核验单独一个 live-role-verification.md。
这正是 Anthropic 官方倡导的渐进式披露（progressive disclosure）在部署场景的落地：主 SKILL.md 保持一屏可读完的骨架（检查什么→加载什么→执行什么→验证什么），azd/Terraform/bicep 各自几百行的操作细节沉到 references，按需加载。对比很多社区 Skill 把所有操作塞进一个巨型 SKILL.md 的做法，这样做的好处是：模型在执行前置检查时不会被无关细节稀释注意力，token 成本也随步骤摊销。
连一个极小的坑都硬编码成规则：
> **⛔ URL FORMAT RULE**
> Many Azure CLI commands return bare hostnames without a scheme —
> always prepend `https://` before presenting them.
azd 返回 myapp.azurewebsites.net 这样的裸主机名，直接贴给用户就是一个不可点击的链接。这种“踩过坑才知道”的细节被固化成强制规则，是 Skill 相对于通用模型知识的真正护城河——模型“知道” URL 应该带协议，但没人规定它就总会补。
azure-deploy 里的 MCP 工具表只有 4 个条目（列订阅、列资源组、执行 azd、查角色分配），但整个 azure-skills 插件背后挂着 Azure MCP Server 的 200+ 结构化工具、覆盖 40+ Azure 服务，外加 Foundry MCP 处理模型目录与部署。仓库 README 里的定位说得直白：Skills 教 agent“Azure 的活怎么干、什么不能干”，MCP 让 agent“能真的动手”。这给所有想做部署类 Skill 的人一个架构启示：Skill 不该试图封装 API 调用细节，应该封装“流程 + 门禁 + 坑”，执行层交给 MCP 或 CLI。
一个容易被忽略的生态事实：这个仓库的说明写明它是从微软内部的 GitHub-Copilot-for-Azure 仓库自动同步过来的。也就是说，你在 Claude Code 里装的这套 Skill，和 GitHub Copilot for Azure 用户用的是同一份上游知识库，多端（Copilot CLI、VS Code、Cursor、Codex、Gemini CLI、IntelliJ）一个源头。这是“官方技能”和“个人技能”在生产方式上的代差。
部署只是工作流自动化的下半场，上半场是“活太大，一个会话装不下”。mattpocock/skills（skills.sh 上 tdd 722K、improve-codebase-architecture 747.2K、handoff 628.2K、triage 624.4K）给了一整套编排件。grill-me 前几轮已拆过，本期看编排侧的四个。
仓库 Reference 部分有一段值得全文引用的架构声明：
User-invoked skills are reachable only when you type them; their job is to orchestrate. Model-invoked skills can be invoked by you or reached for automatically by the agent when the task fits; they hold the reusable discipline. A user-invoked skill may invoke model-invoked skills, but never another user-invoked one.
把 Skill 分成“编排层”（用户显式调用，如 wayfinder、implement）和“原语层”（模型可自动调用，如 tdd、grilling、code-review），并且只允许单向调用：编排层可以调原语层，编排层之间互不调用。这本质上是把软件工程里的分层架构移植到了 Skill 生态——没有这条规则，多 Agent 编排很快会退化成 Skill 互相触发的意大利面。原语层的 grilling（489.5K 安装）就是最好的例子：它是 grill-me、grill-with-docs、triage、wayfinder、improve-codebase-architecture 五个上层 Skill 共用的“访谈原语”。
wayfinder 解决的痛点每个重度用户都遇到过：一个横跨十几处的重构，做到一半上下文爆了，下个会话从头再来。它的方案是把“超过单会话容量的工作”规划成 issue tracker 上的一张共享决策工单地图，然后逐个解决，直到通往终点的路全部清晰。关键设计是它存的不是“待办列表”而是“决策记录”——每个节点是“这里要做一个什么决定、选了哪条路、为什么”，下一个会话恢复的不是任务进度，而是决策上下文。这比 TODO 文件抗断裂能力强得多，因为任务进度丢了可以重推，决策依据丢了就会反复横跳。
三者组成一条链：
/tdd，收尾强制跑 /code-review 再提交。注意它自己是编排层，tdd 和 code-review 是原语层——又是那条分层规则。/setup-matt-pocock-skills 配置的标签体系，这也是它上手难度高一星的原因——先要跑一次 setup，约定 issue tracker（GitHub/Linear/本地文件）和标签语义。flowchart TD
U1[/wayfinder/] --> M1[grilling 原语]
U2[/implement/] --> M2[tdd 原语]
U2 --> M3[code-review 原语]
U3[/triage/] --> M1
U4[/to-tickets/] --> T[(issue tracker<br/>工单+阻塞边)]
U1 --> T
T --> U2
style U1 fill:#e8f0fe
style U2 fill:#e8f0fe
style U3 fill:#e8f0fe
style U4 fill:#e8f0fe
style M1 fill:#e6f4ea
style M2 fill:#e6f4ea
style M3 fill:#e6f4ea
（蓝色=编排层，只能被用户触发；绿色=原语层，可被模型自动调用。）
这可能是本期设计感最强的 Skill。自动化工作流里总有几个步骤机器干不了：去云控制台点开关、把 secret 粘进 CI、审批一次一次性割接。模型遇到这种步骤通常要么幻觉自己“已完成”，要么把用户问得晕头转向。wizard 的做法是生成一个交互式 bash 向导，一步步带着人完成只有人能执行的步骤——基础设施开通、凭据配置、CI secrets、不熟悉的第三方后台、一次性迁移。把人塞回流程的正确位置，而不是假装人不存在。这是对“Agent 自动化”的清醒补丁：自动化率的提升卡在 95% 之后，靠的往往是把剩下 5% 的人机交互做得更顺滑。
handoff 在总榜排第 10（628.2K），是编排套件里安装量最高的——很好理解，它是唯一每个会话都会用到的：把当前对话压缩成一份交接文档，让下一个 agent 无缝续摊。它和 wayfinder 是互补关系：wayfinder 管“跨会话的大计划”，handoff 管“当前会话的优雅退出”。两个都装，才是完整的断裂恢复方案。
vercel-labs/agent-skills 里的 vercel-deploy-claimable 代表了和 azure-deploy 完全相反的设计哲学。它的用户场景是“在 claude.ai / Claude Desktop 对话里直接把应用部署上线”：自动从 package.json 识别 40+ 框架，项目打成 tarball 上传，返回两个 URL——preview URL（能访问的现网页面）和 claim URL（把部署所有权转移到用户自己 Vercel 账号的认领链接）。没有前置校验、没有状态机、没有门禁，因为它的部署对象是原型和 demo，风险模型完全不同。
| azure-deploy | vercel-deploy-claimable | |
|---|---|---|
| 目标对象 | 企业级 Azure 应用 | 原型 / demo / 对话内产物 |
| 风险模型 | 生产事故 = 事故 | 最坏情况 = 重部署 |
| 核心机制 | 三段流水线 + 状态防伪造 | 框架自动检测 + 认领制所有权 |
| 前置成本 | az CLI + azd CLI + 登录 | 零 |
| 所有权模型 | 订阅内资源 | 部署先落地，后认领转移 |
“认领制”是个聪明的产品决定：部署动作不需要账号（Agent 环境里往往没有），所有权转移推迟到用户点 claim 链接那一刻。同仓库的 vercel-optimize 则展示了审计类 Skill 的正确姿势：先收集 Vercel 平台指标，再只深入指标指向的路由和文件——而不是全库扫一遍。这个“指标先行、定向排查”的顺序写进了 Skill 的流程里，是审计类 Skill 防止 token 失控的通用模式。
把 skills.sh 全时榜单按仓库聚合，2026-08 的格局已经很清晰：open.feishu.cn 一个来源贡献 14.2M 总安装（+23 个 Skill），microsoft/azure-skills 7.5M（+13 个），larksuite/cli 7.9M（+18 个）。个人开发者的明星仓库（mattpocock/skills、vercel-labs）霸占单品头部，但按仓库算总盘，企业官方仓库已经占了半壁江山。工作流自动化是重灾区——因为它直接触碰生产环境和账单，用户天然倾向选有 SLA 的官方出品。对独立开发者的启示：避开“官方能力覆盖区”（部署、云资源、企业套件），往“团队隐性知识的封装”走（比如 wizard 这种从真实工程痛点长出来的怪形状），生存空间大得多。
# 微软 Azure 全家桶（Claude Code 官方插件市场）
/plugin install azure@claude-plugins-official
# mattpocock 编排套件（插件制，自动更新）
claude plugins install mattpocock-skills
# 或可编辑文件版（选装单个 skill）
npx skills@latest add mattpocock/skills
# Vercel 官方技能集（含 vercel-deploy-claimable / vercel-optimize）
npx skills add vercel-labs/agent-skills
# mattpocock 套件装完记得每仓库跑一次配置
# /setup-matt-pocock-skills
这一轮横评最大的收获不是某个具体 Skill，而是一个正在固化的共识：工作流自动化的 Skill 设计重心已经从“教模型做对”转移到“保证模型不可能做错”。azure-deploy 的三道锁、mattpocock 的分层宪法、wizard 的人机边界，本质上都在做同一件事——承认 LLM 会走捷径、会幻觉状态、会越界，然后用提示词层面的机制设计把这些失败模式堵死。想写自己第一个工作流类 Skill 的读者，建议从模仿 azure-deploy 的 description 正反触发词开始，那是投入产出比最高的一行。
[!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 等场景全覆盖。