让 Claude 按规格、测试与审查流程开发

AI 写代码的问题，常常出在需求没问清、任务拆得太大、代码写完却没有验证。addyosmani/agent-skills 想补上这套流程：把资深工程师的工作习惯打包成技能，让代理按规格、计划、实现、验证和审查的顺序推进。

这套工具值得了解，但先划清证据边界：原文作者只整理了 README，没有完整跑通过流程。它提供的是一套可尝试的工程方法，还没有给出效率或质量提升的实测结论。

它要约束的是工作过程，而不只是提示词

README 按 define、plan、build、verify、review、ship 组织开发生命周期，并提供九个斜杠命令：

• /spec 先明确规格，/plan 把工作拆成小而独立的任务。
• /build 每次实现一个切片，/test 用测试提供验证证据。
• /constraints 提前确定质量标准，/review 检查并改善代码健康度。
• /webperf 要求先测量再优化，/code-simplify 强调清晰易懂，/ship 主张加快交付节奏。

这里的「切片」可以理解为一块能够单独实现、验证和审查的功能。任务边界小，审查者才容易判断代码有没有偏离需求。

它的核心价值，是让代理在写代码之前和之后都有明确动作。

技能也不完全依赖手动调用。按 README 的描述，设计 API 会触发 api-and-interface-design，构建 UI 会触发 frontend-ui-engineering。不过原文没有验证这些自动触发是否稳定，不能把它理解成每次都能准确识别场景。

安装不复杂，但有命名和依赖细节

Claude Code 的 marketplace 安装方式如下，两条命令分别添加市场和安装插件：

/plugin marketplace add addyosmani/agent-skills
/plugin install agent-skills@addy-agent-skills

第二行的 agent-skills@addy-agent-skills 是完整安装标识，复制时要保留。

如果出现 git@github.com: Permission denied (publickey)，README 给出两种处理方式：添加 marketplace 时使用完整 HTTPS URL，或者执行 git config --global url."https://github.com/".insteadOf git@github.com:。后者会修改全局 Git 配置，让匹配的 GitHub SSH 地址改走 HTTPS，影响范围不只这一个插件。

也可以先执行 git clone https://github.com/addyosmani/agent-skills.git，再用 claude --plugin-dir /path/to/agent-skills 从本地目录试用。目录参数需要替换成实际路径。

还有一个容易踩的坑：Claude Code 已有内置 /review，调用这套插件的审查技能时，应使用 /agent-skills:review。

面向其他代理，README 声称 open skills CLI 支持 Claude Code、Cursor、Codex、Copilot、Cline 等 70+ 个代理。下面两条命令分别安装全部 25 个技能，以及查看可安装列表：

npx skills add addyosmani/agent-skills            # install all 25 skills
npx skills add addyosmani/agent-skills --list     # browse before installing

留意第一行默认安装全部技能。按需安装可以使用 npx skills add addyosmani/agent-skills --skill code-review-and-quality，也可以把技能名换成 interview-me 或 test-driven-development。

但单技能安装只复制对应文件夹，不会带上共享的 references/ 目录，因此补充检查清单会缺失。需要这些资料时，README 建议安装整个仓库。Gemini CLI 的对应命令是 gemini skills install https://github.com/addyosmani/agent-skills.git --path skills。

这些数量、命令和支持范围均来自原文引用的 README，作者提醒它们可能变化。

先用一个小功能检验流程是否有用

原文建议从小功能开始，而不是直接重写项目。顺序很明确：运行 /spec 描述需求，让代理先提问；运行 /plan，检查每项任务是否小到可以独立审查；用 /build 实现第一个切片，再执行 /test；合并前运行 /agent-skills:review。

人仍然要检查计划。代理列出任务，并不等于任务已经拆得合理；测试通过，也只能证明已有断言覆盖的行为成立。

README 还提供 /build auto：先规划并请求批准，然后一轮实现全部任务。它声称每项任务仍采用测试驱动开发、单独提交，并在失败或遇到风险步骤时暂停。原文没有端到端验证这条路径，因此「会暂停」「逐项提交」目前都应视作工具声明。

我的判断

我认同先明确需求、缩小任务、验证后再合并的顺序。它对经常直接开写、最后把清理工作留给人的代理，提供了具体约束。

但「生产级技能」是 README 的定位，不是原文证明的结果。作者没有给出与普通提示词、仓库约定或现有团队流程的对照数据，也没有提供缺陷率、耗时或审查成本的变化。这部分仍是工程经验之谈。

已有严格流程的团队，更适合把它当作可编辑的起点：核对测试命令、审查标准和交付要求是否一致。额外增加一层技能，如果和现有规范冲突，反而会让代理收到相互矛盾的指令。

能拿来做什么

• 为前端或 Node 项目选一个边界清楚的小功能，完整走一遍 /spec 到 /agent-skills:review，检查每一步是否留下了可审查的结果。
• 在 /plan 阶段亲自判断任务大小，确保每项改动都有明确行为和验证方式，再让代理开始实现。
• 用 /constraints 固定项目已有的质量标准；遇到页面性能问题时，用 /webperf 的测量优先原则约束优化过程。
• 在尝试 /build auto 前，先确认手动流程里的测试、提交和失败暂停行为符合预期，再扩大自动执行范围。