addyosmani/agent-skills

解决什么问题

AI 编程 Agent 写代码快，做工程却弱。让它实现一个功能，经常拿到一份看起来合理的 diff：没有先写规格，测试是事后补的，也没有一轮真正的代码评审。每次开工你都得重新把同样的要求讲一遍，换个 Agent 或换个同事，产出质量就漂移。这个项目把工作流本身做成可安装的 skill，让流程跟着 Agent 走，而不是留在某个人脑子里。

有什么不同

常见做法是写一份很长的 AGENTS.md 或规则文件，或者每个任务手搓提示词。这类内容本质上是一段散文式指令，模型遵不遵守看运气，而且往往是一份扁平的大文档。这里把流程拆成 25 个有名字的独立 skill，每个都是带步骤、验证关卡和“反自我合理化”表格的结构化工作流，外加 9 个斜杠命令，覆盖从 /spec 到 /ship 的生命周期节点；skill 还会根据上下文自动触发，比如设计接口时拉起 API 设计 skill。另一个区别是 /build auto：批准一次计划后，Agent 自主完成全部任务，但仍逐任务提交、遇到失败即停。它比通用 Agent 框架更窄也更激进——这是一套方法论，不是运行时。

适合谁

已经在用终端或 IDE Agent（Claude Code、Cursor、Codex、Gemini CLI、Copilot，以及可通过 skills CLI 接入的几十种宿主）的开发者，并且想要的是纪律而不是单纯的生成速度。关注 TDD 和评审关卡、希望把这些约定一次编码下来的团队最合适。如果你只用聊天式 AI 辅助，或者你所在的技术栈与这套生命周期阶段对不上，又或者你希望 Agent 自己摸索流程，那它不合适——这套东西是刻意规定性的。

上手成本

运行时就是你现有的 Agent，内容全是纯 Markdown。但各宿主的安装体验差别很大：有的是一条命令，有的要手动同步目录或把内容贴进规则文件，斜杠命令是 Claude Code 专有的——在 Copilot 里只能按 skill 名称调用。还有一个已知的可移植性缺口：用 npx 单独装某个 skill 时只复制 skills/<name>/，不会带上共享的 references/ 清单，补充材料会缺失（见 issue #361）。MIT 协议，没有法务摩擦。在既有代码库里推广之前，需要花点时间读完 adoption guide。

点评

项目约八个月，约 11 万星，单月追踪期内就涨了约 1.17 万——对于一个以 Markdown 为主的仓库来说斜率相当陡，关注度明显在上升，但其中相当一部分可能是猎奇而非持续使用。外部讨论很薄：Hacker News 最热帖子只有 2 分、零评论，社区验证基本停留在星数层面。把它当作一份整理良好、维护活跃的方法论合集，而不是已被验证的标准。如果 Agent 的产出纪律确实是痛点，可以挑一个仓库先试；判断标准应该是你的 diff 是否开始自带测试、评审意见是否变少，而不是星数。