把资深工程师的评审直觉做成可安装的 skill：25 个技能，9 条命令
TL;DR 速览
- 事件：
addyosmani/agent-skills提供 25 个面向 AI 编码 agent 的生产级工程 skill，把资深工程师的工作流、质量门禁和最佳实践打包成 agent 能一致执行的模块- 结构：6 个生命周期阶段（定义/规划/构建/验证/评审/发布）对应 9 条 slash 命令，每条命令自动激活对应 skill
- 关键取舍：
/build auto去掉的是人在任务之间的步骤，不是验证——每个任务仍然测试驱动、单独提交，遇失败或风险步骤会暂停- 真正的影响力在接口：通过安装 CLI 可装进 70 多个 agent（Claude Code、Cursor、Codex、Copilot、Cline 等）——同一份 skill 定义跨模型复用
- 口径校准：仓库 ★95,899 / fork 10,148 / MIT，创建于 2026-02-15，已积累七个月，今天只是重新冲上日榜（单日新增约 680）
addyosmani/agent-skills 是一个把工程纪律编码成 skill 的仓库，官方描述是"面向 AI 编码 agent 的生产级工程技能"。它的核心主张很直接：skill 应该承载资深工程师在构建软件时用的工作流、质量门禁和最佳实践，而不是指望模型自己每次都做对。实时数据是 ★95,899、fork 10,148、MIT 协议。
有一条事实必须先校准：这个仓库创建于 2026 年 2 月 15 日，已经积累了七个月。 它今天重新出现在 GitHub 日榜上，单日新增约 680 星——不是"刚发布就爆"，而是一个成熟仓库被重新发现。这个区分很重要：下面是七个月迭代出来的东西，不是一份刚写完的设计稿。
一、把开发流程切成六段，再配九条命令
仓库的骨架是一张流程图，六个阶段依次推进：
DEFINE PLAN BUILD VERIFY REVIEW SHIP
┌──────┐ ┌──────┐ ┌──────┐ ┌──────┐ ┌──────┐ ┌──────┐
│ Idea │ ───▶ │ Spec │ ───▶ │ Code │ ───▶ │ Test │ ───▶ │ QA │ ───▶ │ Go │
│Refine│ │ PRD │ │ Impl │ │Debug │ │ Gate │ │ Live │
└──────┘ └──────┘ └──────┘ └──────┘ └──────┘ └──────┘
/spec /plan /build /test /review /ship
九条命令各带一句原则，我按它们的实际约束力分三类来看：
管"先做对的事"的三条：/spec（先写规格再写代码）、/plan（拆成小而原子的任务）、/constraints（定一次，处处执行）。
管"做对"的四条：/build（一次一个切片）、/test（测试就是证据）、/review（改善代码健康度）、/code-simplify（清晰优先于机巧）。
管"发得稳"的两条：/webperf（先测量再优化）、/ship（更快即更安全）。
这个拆法值得注意的地方在于：它把质量要求前置到了命令层。/constraints 那句"定一次，处处执行"对应的是一个很具体的工程问题——约束如果靠每次提醒模型，就一定会漂移；做成一次定义、反复执行的机制，才稳定。
skill 也会按上下文自动激活：设计 API 会触发 api-and-interface-design，构建界面会触发 frontend-ui-engineering。也就是说，除了显式敲命令，还有一条隐式路径——你正在做什么，决定加载什么技能。
二、/build auto：去掉的是"人"，不是"验证"
这是整个仓库里设计最讲究的一处。
/build auto 让 agent 在规格确定之后，生成计划并自主实现每一个任务：你批准一次计划，然后它自己跑完。官方对它的说明里有一句关键限定：
它去掉的是人在任务之间的步骤，而不是验证——每个任务仍然是测试驱动的、仍然单独提交，并且在失败或风险步骤上会暂停。
拆开看，这个限定做了三件事：
第一，"批准一次"没有取消计划环节。 计划仍然要生成、要被人看一眼。
第二，任务粒度没变。 每个任务测试驱动、单独提交——这意味着出问题时能定位到具体提交，而不是面对一个巨大的混合改动。
第三，暂停条件被明确保留。 失败或风险步骤会停下来。"自主"的边界被写在失败路径上，而不是成功路径上——这恰恰是对的：成功路径上不需要人，失败路径上才需要。
这套设计对做 agent 自动化的人有直接参考价值：自动化的范围应该由"失败时谁能接手"来定义，而不是由"成功时能跑多快"来定义。
三、真正的影响力在"可移植"
比 25 个 skill 内容更重要的，是它们的分发方式。
仓库支持通过开源的 skills CLI 安装，官方说这套 CLI 能装进 70 多个 agent——Claude Code、Cursor、Codex、Copilot、Cline 等等。安装全量：
npx skills add addyosmani/agent-skills # 安装全部 25 个 skill
npx skills add addyosmani/agent-skills --list # 先浏览再装
也可以只装单个：
npx skills add addyosmani/agent-skills --skill code-review-and-quality # 合并前的五轴评审
npx skills add addyosmani/agent-skills --skill interview-me # 需求追问，一次一个问题
npx skills add addyosmani/agent-skills --skill test-driven-development # 红-绿-重构，强制执行
"同一份 skill 定义，可以跑在不同模型上"这件事，影响比单个 skill 的质量大。
它把标准化的对象从模型换成了行为。以前团队想统一"我们怎么评审代码"，方式是写文档 + 靠人记；现在可以写成 skill，让不同的人、不同的 agent、不同的模型执行同一套流程。vendor 依赖被绕开了——skill 是模型无关的资产。
这也是它星标量级能到这个位置的原因：它的价值不在于它自己多好用，而在于它可能成为别人必须兼容的事实接口。 从生态位置看，这比任何一个单点功能都更难替代。
我自己沉淀流程的习惯也是这个顺序：先写下来，再改成能被重复执行的形态，最后才是考虑能不能被别人复用。顺序反了，内容就会变成没人看的方法论。墨衍 里我把素材和操作约定收在同一处，省掉工具之间来回搬。
四、一个被明确记下来的可移植性缺口
仓库里有一段关于安装方式的警告，很实在，值得原文转述：
只装单个 skill 时，per-skill 的
npx安装只会复制skills/<name>/，不会复制仓库级的references/目录。 skill 本身仍然可用，但指向共享清单的路径会失效。解决方案是用整仓库集成、克隆仓库，或者把需要的清单手动复制到已安装 skill 内部的references/目录。
这个缺口被记在仓库的 issue #361 里，没有藏起来。
它揭示的问题比它本身更重要：skill 的依赖关系是分层的。 单个 skill 可以独立安装，但它可能依赖仓库级的共享资源——这类"部分安装即降级"的情况，是所有做模块化分发的人都会遇到的。官方选择把它写进 README 顶部而不是藏在 issue 里，这个处理方式本身值得学。
五、能直接抄走的三件事
第一，把你团队反复出现的评审意见变成 checklist，而不是留在聊天记录里。 官网那三个示例 skill 的选题很说明问题：code-review-and-quality（合并前的五轴评审）、interview-me（需求追问，一次一个问题）、test-driven-development（红-绿-重构）。这三件事共同点是：说了很多遍、但每次执行都不一样。 这类"高频 + 高漂移"的环节最适合先 skill 化。
第二，命令要绑定原则，而不只是绑定动作。 /webperf 对应的原则是"先测量再优化"，/code-simplify 是"清晰优先于机巧"——动作会被记错，原则不会。 写自己团队的命令时，把原则跟动作一起写。
第三，自动化的边界写在失败路径上。 参照 /build auto 的处理：允许自主执行，但明确列出会停下来等人的条件。
最后一个判断： 25 个 skill 里你不一定都用得上，但**"skill 是可移植资产"这个认知值得先接受**——它决定了你接下来会怎么组织团队的工程知识。如果你的团队正在用多个不同的 AI 编码工具，把流程写成 skill 的收益，会随着工具数量增加而变大。
