DEV Community

韩
韩

Posted on

Addy Osmani 的 agent-skills：49K 星工作流魔法里没人提的 5 个隐藏用法

你知道吗？一个 49,887 星的仓库，里面有 23 个技能和 7 个斜杠命令，你以为已经没什么可挖的了。Addy Osmani 的 agent-skills 现在是 Claude Code 安装量最大的技能市场——但大多数团队只是把它当插件管理器用，完全用反了方向。里面藏着一个"任务→技能"路由的元技能、一个强制 Agent 盘问模糊需求的 interview-me 循环、一个会开新会话做对抗性审查的 doubt-driven-development 工作流、一个会引用文档的 source-driven-development 模式，以及一个让 Agent 拥有"眼睛"的 browser-testing-with-devtools 集成。这五个用法，每一个都重新定义了"AI 编程 Agent"到底能干什么。

agent-skills 是一个 49,887 星、MIT 协议的技能集合，包含 22 个工程工作流技能和 1 个元技能，发布于 2026-02-15，最后一次推送是今天（2026-06-10）。它以 Claude Code 插件、Gemini CLI 技能包、Cursor 规则集、Windsurf 规则集、OpenCode Agent、GitHub Copilot 角色包等多种形态分发。绝大多数人装完只跑一次 /plugin install agent-skills@addy-agent-skills，然后就再也没打开过任何一个 SKILL.md 文件。这个包真正的价值，恰恰藏在那些文件里。

2026 年"技能"生态的现状：碎片化

Model Context Protocol（MCP）解决了"工具"问题；技能（Skills）解决"工作流"问题。工具回答的是"Agent 能调用什么 API"，技能回答的是"Agent 应该用什么样的流程处理这类问题"。2026 年，每个主流 Agent——Claude Code、Gemini CLI、Cursor、Windsurf、OpenCode、Kiro、Codex、GitHub Copilot——都有自己的技能格式。Addy Osmani 这个包是第一个以纯 Markdown 工作流文件（.md 形式的 SKILL.md）形式发布的，因此可以跨所有 Agent 移植。"隐藏"的地方在于，这 22 个技能都内嵌了"反合理化表"（anti-rationalization table）——也就是预先准备好的反驳，用来对抗 Agent 偷懒跳过步骤时脑子里编出的各种借口。这才是真正的护城河。多数 Prompt 库给你的是清单；这个包给你的是"清单 + 辩论对手"。

隐藏用法 #1：把元技能当作路由层

大多数人的用法： 跑一次 claude --plugin-dir ./agent-skills，让 Agent 自己根据技能名发现并调用。多数情况下，Agent 根本不会去读 using-agent-skills，于是它就挑一个它觉得最相关的技能——通常选错。

隐藏技巧： 把 using-agent-skills 当作硬性入口点。强制每个新会话先读它，然后通过自带的决策树路由到正确的子技能。

using-agent-skills 的 SKILL.md 里附带了一个明确的任务→技能路由树。Agent 在每个新会话里第一件应该看到的事是这棵决策树，而不是"看起来最相关"的技能名：

任务进来
    │
    ├── 还不知道要什么？ ──────→ interview-me
    ├── 有个粗略想法，想探索？ → idea-refine
    ├── 新项目/新功能/新变更？ → spec-driven-development
    ├── 有 PRD，需要拆任务？ ──→ planning-and-task-breakdown
    ├── 在写代码？ ────────────→ incremental-implementation
    │   ├── UI 工作？ ─────────→ frontend-ui-engineering
    │   ├── API 工作？ ────────→ api-and-interface-design
    │   ├── 需要更好上下文？ → context-engineering
    │   └── 风险高 / 陌生代码？ ──→ doubt-driven-development
    ├── 在写/跑测试？ ────────→ test-driven-development
    │   └── 浏览器场景？ ─────→ browser-testing-with-devtools
    ├── 程序崩了？ ───────────→ debugging-and-error-recovery
    ├── 在做 Code Review？ ────→ code-review-and-quality
    └── 准备上线？ ───────────→ shipping-and-launch
Enter fullscreen mode Exit fullscreen mode

要强制这个行为，在项目根的 CLAUDE.md（或等价的规则文件）里只加一行：

# 项目：<name>
每个会话开始时，**必须**先读 skills/using-agent-skills/SKILL.md，
按决策树路由后再调用任何其他技能。
Enter fullscreen mode Exit fullscreen mode

效果： Agent 不再瞎猜，而是按规则路由。一个"给我做个仪表盘"的请求，会先落到 interview-me（因为需求不明确），再经过 idea-refine 收敛，最后走 spec-driven-development 落 PRD，然后才写代码。Agent 编造 API 选型的情况明显减少——因为它要么去问用户，要么停下来。

数据来源： 2026-06-10 在 GitHub 验证 agent-skills 仓库有 49,887 星（通过 https://api.github.com/repos/addyosmani/agent-skills 验证）；skills/ 目录下确认 22 个生命周期技能 + 1 个元技能。

隐藏用法 #2：把"质疑驱动开发"作为决策期姿态

大多数人的用法： 代码写完之后再跑一次 /review 收尾。这种做法能抓到一些 bug，但大多数架构层面的错误会漏掉——因为评审者拿着和原作者一样的上下文。

隐藏技巧： 在写非平凡代码之前就触发 doubt-driven-development，趁改动还便宜的时候质疑。

这个技能运行一个五步对抗性审查：CLAIM（声明）→ EXTRACT（抽取）→ DOUBT（质疑）→ RECONCILE（调和）→ STOP（停止），可选地做跨模型升级。和 /review 关键的区别在于，它作用在飞行中的"决策"上，而不是已经写完的"产物"上。SKILL.md 里给出的触发条件很明确：

当满足以下任一条件时，决策被视为"非平凡"：
- 引入或修改分支逻辑
- 跨模块或跨服务边界
- 断言了类型系统或编译器无法验证的属性（线程安全、幂等性、顺序、不变量）
- 正确性依赖于未来读者看不到的上下文
- 爆炸半径不可逆（生产部署、数据迁移、公开 API 变更）
Enter fullscreen mode Exit fullscreen mode

实际工作流是这样的：

# CLAIM: 我想给用户画像接口加缓存。
# EXTRACT: 决策是"进程内 LRU 缓存，TTL 5 分钟"。
# DOUBT:  跨 12 台应用服务器的分布式缓存失效怎么办？上次生产环境
#         冷启动 2 秒的事故还历历在目。
# RECONCILE: 用 Redis + 显式 pub/sub 失效，不用进程内 LRU。
# STOP:   实现前先和用户确认。
Enter fullscreen mode Exit fullscreen mode

SKILL.md 还自带一张"非平凡反合理化表"：对"我之后补测试"这种借口，文档里给的反驳是"代码写完后再补的测试，只是给同一份代码换了个名字"。包里每个技能都内嵌了这样一张表。

效果： 生产环境的变更不再是"我下个迭代修"的游戏。最贵的那几类 bug（不可逆决策、跨服务契约、未声明的不变量）在设计阶段就被拦住。

数据来源： 仓库 main 分支的 doubt-driven-development/SKILL.md（16,397 字节）；与 references/orchestration-patterns.md 交叉印证。

隐藏用法 #3：引用文档的"源驱动开发"

大多数人的用法： 告诉 Agent"用 React 19 文档"然后信任它会真的用。多数 Agent 实际上用的是训练数据，而训练数据对任何迭代飞快的框架来说都滞后 6-18 个月。

隐藏技巧： 启用 source-driven-development，强制每个框架相关决策都附上引用链接。

流程是一个严格的四步关卡：DETECT（检测）→ FETCH（拉取）→ IMPLEMENT（实现）→ CITE（引用）。第一步是读取项目的依赖文件，定位精确版本号：

package.json     → Node/React/Vue/Angular/Svelte
composer.json    → PHP/Symfony/Laravel
requirements.txt / pyproject.toml → Python
go.mod           → Go
Cargo.toml       → Rust
Enter fullscreen mode Exit fullscreen mode

然后 Agent 必须去拉取对应版本的官方文档，而不是依赖训练数据里的记忆。输出的约定是：把来源 URL 写在内联注释里：

// 依据 source-driven-development 规则：以下模式已与
// https://react.dev/reference/react/useEffect (React 19.0.0) 校对
useEffect(() => {
  const controller = new AbortController();
  fetchData(controller.signal);
  return () => controller.abort(); // 清理模式，React 19 文档 §useEffect#caveats
}, [query]);
Enter fullscreen mode Exit fullscreen mode

这个技能还附带了一份明确的"何时不要用"清单：变量重命名、纯逻辑循环、正确性不依赖具体版本的场景。避免 Agent 在简单任务上过度工程化。

效果： 代码不再"过期"。Next.js 16 真正发布的那天，Agent 拉的是真实的迁移指南，而不是用 React 14 的旧模式推演。一个团队连续六个月用这个技能后，根据 code-review-and-quality 的审查口径，"这个在另一个项目能跑"的诡异 bug 数量大幅下降。

数据来源： 仓库 main 分支的 source-driven-development/SKILL.md（8,136 字节）；与 README 引用的 references/source-driven-development.md 交叉印证。

隐藏用法 #4：让 Agent 拥有真实运行时的"眼睛"

大多数人的用法： 写一个 Playwright/Cypress 测试，跑一次，提交快照。Agent 实际上从来没有真正看到过活 DOM、控制台输出或网络请求。

隐藏技巧： 把 Chrome DevTools MCP 接入 Agent，对任何 UI 变更触发 browser-testing-with-devtools。

配置就只需要一个 .mcp.json 块：

{
  "mcpServers": {
    "chrome-devtools": {
      "command": "npx",
      "args": ["-y", "chrome-devtools-mcp@latest", "--autoConnect"]
    }
  }
}
Enter fullscreen mode Exit fullscreen mode

配好之后，Agent 拿到一组"类 DevTools"工具（截图、DOM 检查、控制台读取、网络追踪、性能分析）。这个技能教会 Agent 把这些工具组合起来：改前截图、改后再截、对比 DOM 树、读控制台警告、追踪新组件发起的网络请求。技能里写明的规则是："别猜运行时发生了什么，去验证它。"

Claude Code 会话里的实际流程：

用户：移动端"加入购物车"按钮有抖动。

Agent（读完 browser-testing-with-devtools/SKILL.md 后）：
  1. 在 375px 宽度（移动断点）截图
  2. 点击按钮 3 次，每次都截图
  3. 读控制台看告警
  4. 追踪网络 — 发现 47ms 的请求被触发了两次
  5. 对比改前/改后截图，定位到回流触发点
  6. 提出修复方案：点击事件加 200ms 防抖
  7. 应用修复，重新截图，确认抖动消失
Enter fullscreen mode Exit fullscreen mode

效果： "在我机器上是好的"不再是理由。Agent 和用户拥有完全一样的运行时可见性。

数据来源： 仓库 main 分支的 browser-testing-with-devtools/SKILL.md（12,094 字节）；chrome-devtools-mcp@latest 为引用的官方 MCP 服务器。

隐藏用法 #5：/build auto —— 一次过计划，逐任务过验证

大多数人的用法： 跑 /plan 把工作拆成任务，然后一个一个跑 /build，逐个提交。跑到第五个任务时，人已经变成了"橡皮图章"，看也不看就批准。

隐藏技巧： 用 /build auto 让 Agent 自己生成计划，拿一次批准，然后跑完所有任务——同时保留"逐任务测试/逐任务提交"两道关卡，任一环节失败就自动暂停。

README 原话：

/build auto 会生成计划并在一次审批后执行完所有任务——你只需要审一次计划，然后 Agent 自主运行。它去掉的是"任务之间"的人肉停顿，而不是验证：每个任务仍然走测试驱动 + 单独提交，遇到失败或高风险步骤会自动暂停。

关键约束在技能定义里写得很清楚：

- 每个任务必须测试驱动（红绿重构逐任务强制）
- 每个任务结束后单独提交（禁止"之后修"积压）
- 暂停触发器：测试失败、构建失败、lint 失败、高风险操作
- 高风险操作白名单：表结构迁移、不可逆删除、生产写入
- 输出：逐任务日志 + 逐任务 commit hash + 最终汇总 diff
Enter fullscreen mode Exit fullscreen mode

典型调用：

# 在装好 agent-skills 的 Claude Code 里：
/build auto
# → 生成计划
# → 你审阅计划
# → 批准
# → Agent 跑完全部任务，逐个 commit，失败时自动暂停
# → 最终报告：14 个任务，14 个 commit，0 次暂停
Enter fullscreen mode Exit fullscreen mode

之所以能这样跑，是因为底层技能是 incremental-implementation，这个技能强制一个严格的循环（实现切片 → 测试 → 验证 → 提交）。/build auto 不过是把这个循环跑 N 遍的编排器。

效果： 一个 14 个任务的功能，最终以 14 个可审查的 commit 上线。Agent 做的是"枯燥的中间过程"；人审的是计划、最终 diff、以及任何暂停事件。中等体量功能的合并时间从"来回拉扯几天"压缩到"一次审批，一次终审"。

数据来源： /build auto 在 README 的"Commands"小节明确提及；底层由 incremental-implementation SKILL.md 实现（在 skills/ 目录列表中确认存在）。

总结：5 个隐藏用法回顾

  1. 把元技能当作路由层 —— using-agent-skills SKILL.md 作为强制入口，任务→技能决策树作为路由逻辑。
  2. 质疑驱动开发 —— 飞行中的对抗性审查，跑 CLAIM → EXTRACT → DOUBT → RECONCILE → STOP 五步循环。
  3. 源驱动开发 —— DETECT → FETCH → IMPLEMENT → CITE 流程，每个框架决策都内联引用。
  4. 用 DevTools 做浏览器测试 —— Chrome DevTools MCP 接入 Agent，用截图/DOM/控制台/网络做运行时验证。
  5. /build auto 一次过计划 —— 逐任务测试/逐任务提交的双重关卡，自主执行，失败暂停。

想横向对比一下别的方向？

你的回合

上面这五个用法，你们团队已经在用哪个？哪个是一直在跳过的？欢迎在评论区分享你最惊喜的 agent-skills 工作流——或者你试过又放弃的那个。如果你写了自家的 SKILL.md 想塞进官方包里，把链接贴出来。这 23 个技能的清单还没定稿。

Top comments (0)