# 总榜第10、11名：流程胶水Skill横评——分流、冲突、交接，代码之外的开发者效率 ## 概述 前几轮已经把开发者效率赛道最显眼的名字拆了个遍：审查、调试、TDD、架构。这一轮换个挖掘面——**流程胶水层**：issue 分流、merge 冲突、会话交接、规格到工单的供应链。主角是 skills.sh 总榜第 10 名 `handoff`（628.2K 安装）和第 11 名 `triage`（榜单口径 624.4K），加上同仓库腰部的 `resolving-merge-conflicts`（364.5K）、`to-spec → to-tickets → implement` 流水线和新人 `wayfinder`。它们全部来自同一个仓库 `mattpocock/skills`——据 skills.sh 仓库页统计，这套共 53 个 Skill 的套件累计安装约 1820 万次。核心发现：这一层 Skill 的价值不在“教模型写代码”，而在**把工程流程本身编码成状态机、门控和披露规则**，而且它的分层调用架构（user-invoked / model-invoked）本身就是一份可抄的 SKILL.md 设计范本。 ## 为什么盯住“腰部” 先看总榜上下文（数据来自 skills.sh All Time 榜，2026-08-29 抓取）：`find-skills` 3.0M、`grill-me` 911.2K、`frontend-design` 796.7K、`grill-with-docs` 775.3K、`improve-codebase-architecture` 747.2K、`tdd` 722.0K、`agent-browser` 702.8K、`vercel-react-best-practices` 647.0K——这八个全部在此前各轮覆盖过。**`handoff` 和 `triage` 是这套头部套件里最后两个没被拆过的高位 Skill**，再往下就是断层：第 68 名 `codebase-design`（436.0K）、第 69 名 `diagnosing-bugs`（430.2K）。 另一个背景：官方仓库 anthropics/skills 目前只有 19 个 Skill，重心在文档与设计（docx/pptx/pdf/canvas-design 等），开发者效率方向只有 `webapp-testing` 勉强沾边。也就是说，**工程流程这条赛道几乎被社区包场，而 mattpocock/skills 是其中统治级玩家**。作者在 README 里把立场说得很直白：GSD、BMAD、Spec-Kit 这类方法“试图通过接管流程来帮你，但同时也夺走了你的控制权”——他给自家套件的定位是小、可改、可组合（"small, easy to adapt, and composable"），素材则来自“几十年工程经验”和“每天真实在用”（"Skills for Real Engineers. Straight from my .agents directory"）。 ## 套件架构：先看它怎么组织，再看单个 Skill 这套 Skill 有一个绝大多数 Skill 仓库没有的东西：**明确的调用分层**。README 原文给出两条规则： - **user-invoked**：只有你手敲 `/命令` 才会触发，职责是“编排”（orchestrate）； - **model-invoked**：你可以召唤，模型也会在任务匹配时**自动触发**，职责是承载“可复用的纪律”（reusable discipline）。 并且有一条硬约束：*"A user-invoked skill may invoke model-invoked skills, but never another user-invoked one."*（user-invoked 可以调用 model-invoked，但绝不能调用另一个 user-invoked。）这一句值得所有想写 Skill 的人抄进自己的设计笔记——它禁止了编排层互相嵌套导致的失控链，和软件工程里“组合根唯一”是同一个思想。 ```mermaid mindmap root((mattpocock/skills
53个Skill 约1820万安装)) 工程类·用户召唤 grill-with-docs triage improve-codebase-architecture to-spec to-tickets implement wayfinder 工程类·模型召唤 tdd code-review diagnosing-bugs resolving-merge-conflicts codebase-design domain-modeling prototype wizard 生产力类 grill-me handoff teach to-questionnaire wait-what 底层原语 grilling writing-for-agents ``` 注意最底下的“底层原语”：`grilling`（拷问式访谈）在 README 里被明确列为 `grill-me`、`grill-with-docs`、`triage`、`wayfinder`、`improve-codebase-architecture` 五个 Skill 的共享原语。**一个原语、五个出口**，这是套件能压住 token 成本的关键设计——本文要横评的 triage 和 wayfinder 都直接受益于它。 ## 评测对比表 | Skill | 功能完整度 25% | 设计质量 25% | 实战效果 20% | 上手难度 15% | 社区活跃 15% | 加权总分 | |---|---|---|---|---|---|---| | triage | ★★★★ | ★★★★★ | ★★★★ | ★★★ | ★★★★★ | **4.25** | | handoff | ★★★★ | ★★★★ | ★★★★ | ★★★★★ | ★★★★ | **4.15** | | resolving-merge-conflicts | ★★★ | ★★★★ | ★★★★ | ★★★★★ | ★★★★ | **3.90** | | to-spec→to-tickets→implement | ★★★★ | ★★★★ | ★★★ | ★★★ | ★★★★ | **3.65** | | wayfinder | ★★★ | ★★★★ | ★★★ | ★★ | ★★ | **2.95** | 说明：实战效果分基于榜单规模、套件内定位与作者“每天在用”的自述推断，本文未做长周期实测；安装量数据来自 skills.sh（All Time 口径）。 ## 逐个拆：triage（624.4K，状态机驱动的分流） **定位**：把 issue tracker 上的 issue（以及 PR）按一个小型状态机推进。skills.sh 详情页显示它 First Seen 于 2026 年 4 月 28 日——不是新品，是靠半年爬上总榜第 11 的。详情页的 Summary 一句话概括其设计：*"State machine-driven issue triage with role-based workflow management and agent brief generation."* **三个值得抄的设计**： 1. **PR 被定义为“带代码附件的 issue"**（"an issue with attached code"）。一句定义就让同一套状态机覆盖了两种工件，这是建模功力。 2. **角色即状态**：2 个分类角色（bug / enhancement）+ 5 个状态角色（needs-triage / needs-info / ready-for-agent / ready-for-human / wontfix）。每条 issue 在任意时刻有且只有一个角色，模型不需要“理解”流程，只需要“执行”流转。 3. **强制 AI 披露**：所有发到 tracker 的 AI 评论必须以引用行 `> *This was generated by AI during triage.*` 开头。在一个 agent 大量代写 issue 评论的时代，这条规则把“这是 AI 说的”变成协议的一部分，产品化意识领先大多数 Skill 一个身位。 它还内建两件武器：对信息不全的 issue 发起 grilling（复用前述原语，与 README 的原语清单互相印证），以及按 AGENT-BRIEF.md 模板给下游 agent 写“派工简报”。审计方面，skills.sh 详情页显示 Gen Agent Trust Hub 与 Socket 均 Pass，**Snyk 为 Warn**（页面未给出原因，介意者自行评估）。 **短板**：强依赖 `/setup-matt-pocock-skills` 写入的 tracker 与 label 配置（GitHub / Linear / 本地文件三选一），裸仓库装上跑不起来。另外注意数据口径：triage 在 skills.sh 榜单页、仓库页、详情页分别显示 624.4K / 665.6K / 415.8K，页面未解释差异，本文以榜单页为准。 **触发方式**（user-invoked）：`/triage` ```mermaid flowchart TD A[新 issue 或 PR] --> B[needs-triage] B --> C{分类} C -->|bug| D[bug 角色判定] C -->|enhancement| E[enhancement 角色判定] D --> F{信息是否齐全} E --> F F -->|否| G[needs-info
发起 grilling 拷问] G --> F F -->|是| H{该谁来修} H -->|agent 能做| I[ready-for-agent
附 agent brief] H -->|需人类| J[ready-for-human] H -->|明确不做| K[wontfix] ``` ## 逐个拆：resolving-merge-conflicts（364.5K，五步纪律） **定位**：model-invoked，frontmatter description 写的是 *"Use when you need to resolve an in-progress git merge/rebase conflict."*——注意这个写法：**它不是给用户看的广告词，是给模型的触发器**。你不需要记命令，卡在冲突里时说一句“帮我解决冲突”就应该命中。 **全文只有 5 步**，但两处纪律直击 agent 解冲突的两大顽疾： 1. **意图溯源**：为每个冲突文件找 primary sources——读双方 commit message、关联 PR、原始 issue，理解“两边为什么改”，而不是在文本层面和稀泥。 2. **禁 止 弃 逃**：原文 *"Always resolve; never `--abort`"*。agent 遇到难缠冲突时 `git merge --abort` 溜号是高频失败模式，这一句把它焊死了。取舍时“不发明新行为”，兼容不了就按 merge 既定目标裁决并记录 trade-off。 3. 收尾固定为：跑项目自动检查（典型顺序 typecheck → tests → format）→ staging + commit → rebase 则 continue 直到所有提交重放完。 **短板**：没有门控、没有脚本，约束力纯靠提示词纪律；步骤 4 依赖 agent 自动发现项目的检查命令，异构项目覆盖不定。但反过来说，**5 步、零配置、无依赖**，是这套套件里上手成本最低的一个——拿来改写成自己团队版也最容易。 **触发方式**（model-invoked，自动）：会话中出现进行中的 merge/rebase 冲突时触发；也可显式说 "resolve this merge conflict"。 ## handoff（628.2K，最被低估的上下文管理器） **定位**：Productivity 分类、user-invoked。README 一句话：*"Compact the current conversation into a handoff document so another agent can continue the work."*——把当前会话压缩成交接文档，让另一个 agent 无缝续班。 它值得单独一节有两个理由。**第一是排名**：628.2K 安装、总榜第 10，比一堆明星 Skill 都高，却几乎没有内容创作者写过它——大家都在拆“怎么让 agent 写好代码”，没人拆“怎么让 agent 换班”。而长任务跨会话恰恰是 agent 工作流的第一大断点。**第二是位置**：它和 grill-me 同属 Productivity 区，说明作者的分类哲学是——grill-me 解决“开工前对齐”，handoff 解决“收工时交接”，两个都是“非编码但决定编码质量”的动作。 本文未逐行抓到其 SKILL.md 正文，以上基于 README 官方描述与榜单数据，深拆留待后续轮次。但仅凭“把交接文档化”这一个动作能拿到 62 万安装，就足以说明：**上下文交接是被系统性低估的效率杠杆**。 **触发方式**：`/handoff` ## to-spec → to-tickets → implement：一条被刻意打散的流水线 这三个单拆都不惊艳，合起来才见设计： - **to-spec**（372.6K）：*"Turn the current conversation into a spec and publish it to the issue tracker. No interview."*——注意"No interview"：它不做访谈，只综合你已经聊过的内容。访谈是 grill-with-docs 的活，职责切得干干净净。 - **to-tickets**（366.2K）：把任意计划/规格/对话拆成 *"tracer-bullet tickets"*（曳光弹工单），**每张工单声明自己的阻塞边**，可落本地文件，也可写进真实 tracker 的原生 blocking 链接。 - **implement**（429.3K）：*"Build the work described by a spec or set of tickets, driving `/tdd` at pre-agreed seams and closing out with `/code-review` before committing."* implement 这句描述是全套件分层架构的最佳标本：user-invoked 的 implement，在“预先约定的接缝处”驱动 model-invoked 的 `tdd`，提交前收尾调用 model-invoked 的 `code-review`（双轴并行 sub-agent 审查，此前“审查到调试”一轮已拆）。**编排层不含任何工程纪律，纪律全部下沉到 model-invoked 层**——这正是“user-invoked 不调用 user-invoked”规则的红利：流水线每一段都可以单独替换、单独魔改。 **短板**：三连击需要先跑 setup 配置 tracker，且对“先写规格再动手”的工作流有理念要求——只想让 agent 直接改两行代码的用户会觉得仪式感过重。 **触发方式**：`/to-spec` → `/to-tickets` → `/implement`（按序） ## wayfinder（新品观察，榜上暂无独立数据） README 里最新面孔之一：*"Plan a huge chunk of work, more than one agent session can hold, as a shared map of decision tickets on the issue tracker, and resolve them one at a time until the way to the destination is clear."*——解决“一个会话装不下的大活”：把巨量工作铺成 tracker 上的决策工单地图，每次会话只解一张，直到通往终点的路全部清晰。 思路本质是**把状态外置到 tracker**，会话可死，地图不死；并且它复用 grilling 原语做决策拷问（README 原语清单点名）。想法漂亮，但“解决超出单会话容量的问题”属于低频刚需，加上依赖 tracker 配置、上架时间短、尚无独立安装数据可查，实战分数只能先给保守值。**早期结论：值得观望，不适合当第一个装的**。 **触发方式**：`/wayfinder` ## 安装命令汇总 ```bash # 方式一：Claude Code 官方插件市场（托管、只读、自动更新） claude plugins install mattpocock-skills # 或会话内： /plugin install mattpocock-skills # 方式二：skills.sh 安装器（文件写入你的仓库，可魔改，手动 npx skills update 更新） npx skills@latest add mattpocock/skills # 安装器会让你勾选要哪些 Skill —— 务必把 setup-matt-pocock-skills 勾上 # 装完后每个仓库执行一次（配置 issue tracker、triage label、文档目录） # /setup-matt-pocock-skills ``` README 特别警告：**两种方式别同时装**（"installing both leaves you with every skill twice"）。只用 triage/handoff/merge-conflicts 三个轻量件的话，方式二单选这三个即可，不必背上整套。 ## 推荐排行榜 - **综合最值得装**：triage —— 状态机 + 披露协议 + agent brief，设计密度全场最高，前提是你愿意配 tracker - **零配置首选**：resolving-merge-conflicts —— 5 步、无依赖，model-invoked 自动触发，装了就忘不掉 - **最低成本高回报**：handoff —— 一条命令解决跨会话断点，628K 人用脚投票 - **团队流水线首选**：to-spec → to-tickets → implement —— 适合已经有 issue 流程的团队整体接入 - **设计最值得抄**：triage（状态机建模）+ 套件级 user/model 分层规则 —— 想写自己 Skill 的人先读这两样 ## 一条主线结论 把六个 Skill 放回一起看，这套腰部产品的共同配方是：**用状态机和门控把“流程纪律”编码进 SKILL.md，用原语复用压住 token 成本，用分层调用规则防止编排失控，再用一行披露声明处理 AI 身份问题**。没有一个是“教模型写更好的代码”——它们全部在管“代码发生之前的分派”和“代码发生之后的流转”。这或许解释了为什么官方仓库至今没下场这条赛道：流程纪律高度依赖各团队的 tracker、label 与协作习惯，天生是社区的活。对你而言，可操作的结论只有一条：如果你的 agent 工作流断在“换班、冲突、分派”这三个环节，总榜第 10、11 名已经替你把坑趟好了。 ## 参考来源 1. [mattpocock/skills — GitHub 仓库](https://github.com/mattpocock/skills) — README：套件定位、53 个 Skill 的 user/model-invoked 分类、安装方式与分层调用规则（2026-08-29 抓取） 2. [skills.sh — Skills 总榜](https://www.skills.sh) — 各 Skill All Time 安装量与排名（find-skills 3.0M、grill-me 911.2K、handoff 628.2K、triage 624.4K 等） 3. [anthropics/skills — Claude 官方 Skills 仓库](https://github.com/anthropics/skills) — 官方 19 个 Skill 清单，用于对照社区与官方的赛道分工 4. [skills.sh 上 mattpocock 套件各 Skill 详情页](https://www.skills.sh) — triage 状态机与 AI 披露行、resolving-merge-conflicts 五步正文及 frontmatter、triage 安全审计状态（Gen Agent Trust Hub/Socket Pass，Snyk Warn）；注：triage 安装量在不同页面存在 415.8K–665.6K 口径差异，文中已标注 > [!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 等场景全覆盖。