🍱Agent Skills 生态深度盘点
约 4730 字大约 16 分钟
AgentSkillsWorkflowSuperpowers
2026-06-20
AI 写代码越来越快，但"写什么"这件事从未被认真解决过。 需求活在聊天记录里，AI 靠猜，人靠纠正，反复拉扯。2026 年 4 月，mattpocock/skills 仅凭 21 个 markdown 文件登顶 GitHub Trending #1，obra/superpowers 累计 224k stars，OpenSpec 在 20+ AI 工具中跑通——三股力量同时指向同一件事：把 prompt 调教这件事，搬到工程化的桌面上。
核心仓库
引子：三个项目，同一个方向
2026 年 4 月 27 日，AlphaSignal AI 在 X 上贴出一张截图：mattpocock/skills 在两天内从 18,700 stars 涨到 28,000+，登顶 GitHub Trending 第一。没有 SDK，没有 framework， 没有 application code——21 个 markdown 文件，每个 < 200 行。
同期，obra/superpowers 累计 224k stars，被 Anthropic 接入官方 Plugin Marketplace；Fission-AI/OpenSpec 用 5 个 slash command 在 OpenCode / Cursor / Claude Code / Codex / Antigravity 之间无缝穿梭。
三个项目的共同点很明确：它们都不再相信"调 prompt 就能写出好代码"。 它们用结构化的 SKILL.md、可重用的 workflow、强制性的 TDD 门控，把 "AI 编程"从聊天框搬到了工程看板。
为什么 Prompt Engineering 不够用了
上下文不稳定
长对话是 LLM 的天敌。当一个工程任务跨过 20 轮交互，模型会开始遗忘前文约束、混淆变量语义、把"刚才说不要用 jQuery"和"刚才说要支持 IE11"揉在一起。prompt 写在聊天框里是一次性燃料——窗口一关就烧完。
可复用性差
一个老手花两周调出一套"写 Go 服务时如何分层"的 prompt，塞在 Notion 角落里。组里新同学不知道这个 prompt 存在；知道的人会改两个词就把它弄坏；改了的人不会回头同步。prompt 没有版本控制、没有 lint、没有 review。
团队无法共享
当 prompt 躺在个人聊天记录里，它就是私人的工程记忆。当工程师离职，他的 prompt 经验就跟着走。这跟 2010 年代大家写 wiki 一个道理——知识不沉淀，团队就永远在原地踏步。
Skill Engineering 的出现
Skill Engineering 是一次范式切换：把"写在聊天框里的 prompt"升级为"写在仓库里的 SKILL.md"。每个 skill 有名字、有触发条件、有 step-by-step 的工作流、有版本号、 可以被 fork、可以被 review。当一个 skill 进了 .agents/skills/ 目录，它就成了团队资产。
具体落地方式：
- 能力模块化：一个 skill 只解决一个问题（写 TDD、debug、写 PRD、code review）
- 工作流标准化：skill 之间能像函数一样组合（grill-me → to-prd → to-issues → tdd）
- 团队经验沉淀：SKILL.md 是 Markdown，可以 review、可以 lint、可以归档
一个典型 skill 长什么样
---
name: tdd
description: 强制 red-green-refactor，禁止一次写完所有测试
triggers:
- "写测试"
- "加单元测试"
- "TDD"
---
# TDD Skill
## 规则
1. 先写一个失败的测试（红）
2. 跑测试，确认它**因为正确的原因失败**
3. 写最少的实现让测试通过（绿）
4. 重构，保持测试通过
5. 重复YAML frontmatter 告诉 agent 何时该调用，Markdown body 告诉 agent 该怎么做。当 agent 看到 prompt 命中 triggers，它就自动加载这个 skill 并按规则执行。
三大流派：Workflow / Spec / Capability
2026 年的 Agent Skills 生态，基本可以归为三个流派。
| 流派 | 代表项目 | 核心思想 | 工作流刚性 | Token 消耗 |
|---|---|---|---|---|
| Workflow First | Superpowers | 先流程后代码 | 强（强制 TDD） | 高 |
| Spec First | OpenSpec | 先 spec 后实现 | 中（spec 必备） | 中 |
| Capability First | Matt Pocock Skills | 只增强不限制 | 弱（按需加载） | 低 |
- Workflow First：把整套开发流程钉死。Superpowers 的 brainstorming → writing-plans → executing-plans → test-driven-development 是一条不归路—— 你不写 spec，agent 拒绝写代码；你不写失败测试，agent 拒绝实现。
- Spec First：在意图和实现之间插入一层 spec。OpenSpec 的 proposal → specs → design → tasks 把"为什么、改什么、怎么改"切成四个文件， AI 按文件实现，错了可以回滚。
- Capability First：只给 agent 增强能力，不限制流程。Matt Pocock Skills 的 21 个 skill 是"工具箱"——你需要 grill-me 就调 grill-me， 需要 tdd 就调 tdd，没人逼你走完整条链。
三种流派不互斥。严肃工程团队常把 Superpowers 的 TDD 门控和 OpenSpec 的 spec 工作流结合，再加上 Matt Pocock 的 grill-me 做需求起点。下面逐一拆解。
Superpowers 深度拆解
项目定位
Superpowers 是 Jesse Vincent（obra）的作品，224k stars，2026 年最被认可的 agentic skills framework。它的 README 写得很直接：
Superpowers is a complete software development methodology for your coding agents, built on top of a set of composable skills and some initial instructions that make sure your agent uses them.
它是一套给 AI 编程代理的开发方法论，由一组可组合的 skills 和初始指令组成。适配 8 个 harness：Claude Code（通过 Anthropic 官方 plugin marketplace）、Codex CLI / App、 Cursor、Factory Droid、Gemini CLI、OpenCode、GitHub Copilot CLI、Kimi Code、Pi。
核心工作流
brainstorming → writing-plans → executing-plans
↓
test-driven-development
systematic-debugging
using-git-worktreesbrainstorming：需求起点，agent 跟人对话把"想做什么"问穿；writing-plans：把 brainstorm 出来的需求写成可执行的实施计划，每个 task 必须列出"改哪个文件、写什么代码、怎么测"；executing-plans：agent 按 plan 逐项实现。
核心 Skills
- brainstorming——需求探索的 skill，强制 agent 不断追问"为什么"、"给个例子"、"边界在哪"
- writing-plans——产出 implementation plan，每个 task 可独立验证
- executing-plans——按 plan 执行，遇到 ambiguity 必须暂停回问
- test-driven-development——红绿重构门控，禁止写完代码再补测试
- systematic-debugging——5 步法定位 bug 根因
- using-git-worktrees——隔离工作区，每个 task 一个 worktree
- subagent-driven-development（特色）——为每个 task 起 fresh context 的 subagent，完成后做两阶段 review：先 spec compliance，再 code quality
Skill 架构图
Skill 业务场景对照
| Skill | 使用对象 | 触发时机 | 业务 / Coding 例子 |
|---|---|---|---|
brainstorming | 全员（PM / 工程师） | 新需求刚提、技术选型 | "做语音输入？" → 强制追问"目标用户是谁、为什么不做快捷键、ROI 怎么算" |
writing-plans | 工程师 | brainstorming 之后、写代码前 | "支持深色模式" → 拆 5 个 task，每个 task 写明改哪个 CSS 文件、加哪个 toggle、怎么测 |
executing-plans | 工程师 | 计划落地阶段 | agent 逐 task 实现，遇到计划没说清的细节就暂停（不靠猜） |
test-driven-development | 工程师 | 写实现代码之前 | 单元 / 集成 / 端到端都红绿重构，先看到测试失败才写实现 |
systematic-debugging | 工程师 | 出现 bug、性能问题 | CI 报红 / 线上崩溃 / 内存泄漏 → 5 步法定位根因（不乱试） |
using-git-worktrees | 工程师 | 多任务并行 | "同时修 bug + 加新 feature" → 各自一个 worktree，互不污染 |
subagent-driven-development | Tech Lead | 大型 PR review | "这个 PR 改了 30 个文件" → fresh context subagent + 两轮 review（spec → code quality） |
适合什么团队
- 6 人以上严肃工程团队，对 TDD / spec compliance 有硬要求
- 想要"代码评审"前置到 AI 写代码那一瞬间
- 愿意为流程刚性付出 token 成本（Superpowers 是三大流派里最费 token 的）
OpenSpec 深度拆解
项目定位
OpenSpec（opsx）是 Fission-AI 出品的 Spec 驱动开发框架。它的 README 写得很朴素：
OpenSpec adds a lightweight spec layer so you agree on what to build before any code is written.
它轻量、portable、跨 20+ AI 工具——Antigravity、Cursor、Claude Code、Codex、OpenCode 都能跑。和 GitHub Spec Kit、AWS Kiro 形成对比：Spec Kit 偏重、Kiro 绑自家 IDE，OpenSpec 走"轻 + 跨工具"路线。
核心工作流
explore → propose → apply → sync → archive这是核心 5 步。还有扩展开关（openspec config profile=expanded）：
- /opsx:new
<feature-name>——创建变更目录 - /opsx:continue——继续未完成的变更
- /opsx:ff——fast-forward，一次性生成 proposal / specs / design / tasks
- /opsx:apply——AI 按 tasks.md 逐项实现
- /opsx:verify——验证实现是否符合 spec
- /opsx:onboard——沉淀领域 schema 到 openspec/ 目录
- /opsx:bulk-archive——批量归档
变更目录的 4 类 artifact
每个变更一个目录，目录里有 4 类文件：
- proposal.md——为什么做、改什么
- specs/——需求与场景，delta 形式（不是覆盖，是描述"从 X 变到 Y"）
- design.md——技术方案
- tasks.md——实现清单，AI 逐项执行
/opsx:ff 是最常用的入口——一次性生成 4 个 artifact，跳过逐步确认的繁琐。每个变更 archived 后会 merge 进主 spec，不污染主 spec 的历史。
Skill 架构图
Skill 业务场景对照
| 命令 | 使用对象 | 触发时机 | 业务 / Coding 例子 |
|---|---|---|---|
/opsx:new | PM / 工程师 | 任何变更的起点 | /opsx:new user-2fa → 建变更目录，4 个 artifact 占位 |
/opsx:ff | 工程师 | 变更范围明确、想跳过逐步确认 | 5 分钟出活——一次性生成 proposal / specs / design / tasks 4 文件 |
/opsx:continue | 工程师 | 中断后继续 | 跨 session 不丢上下文，上次写到哪这次接着写 |
/opsx:apply | 工程师 | spec 评审通过 | agent 按 tasks.md 逐项实现，完成一项 check 一项 |
/opsx:verify | QA / Tech Lead | 实现完成后 | 检查实现是否真的满足 spec，发现偏离就回滚 |
/opsx:onboard | 新成员 | 加入新项目 | 沉淀领域 schema 到 openspec/specs/，新人读 spec 就懂业务 |
/opsx:sync | Tech Lead | 变更要 merge | 把 delta 同步进主 spec，spec 永远反映真实状态 |
/opsx:archive | Tech Lead | 变更 merge 后 | 历史变更归档，主 spec 不被旧变更污染 |
适合什么团队
- "AI 写代码太快，但写什么永远没对齐"的团队
- 多分支并行开发、需求变更频繁
- 想要把"需求追踪"做进工具链，而不是丢在聊天框里
Matt Pocock Skills 深度拆解
为什么突然爆火
mattpocock/skills 在 2026 年 4 月 27 日登顶 GitHub Trending 第一，不是 因为有 SDK / framework / 跑得快，而是因为它"足够小"——21 个 markdown 文件，每个 < 200 行，可以一个一个读，一个一个装。
AlphaSignal AI 在 X 上的原话：
A folder of 21 markdown files just hit #1 on GitHub trending. mattpocock/skills crossed 28,000+ stars on April 27, up from 18,700 two days earlier. No SDK. No framework. No application code. Each skill is a SKILL.md file under 200 lines, with YAML frontmatter that tells the agent when to use it.
Matt Pocock 本人是 TypeScript 布道师、AI Hero 创始人，YouTube 上 27 万订阅。他的 "5 Agent Skills I Use Every Day" 视频 41 万播放——用真人 demo 跑通 5 个 skill 的真实链路，这是它爆火的关键。
三段式技能地图
Matt Pocock 把 21 个 skill 分成三段：
Product Skills（需求段）
- grill-me——不写一行代码，先把需求问穿。一个一个提问，每个问题都带"我推荐的回答"
- grill-with-docs——基于仓库已有文档追问，避免重新发明领域语言
- to-prd——把 grill-me 沉淀的对话整理成 Product Requirements Document
Planning Skills（规划段）
- to-issues——把 PRD 切成 vertical slice，每个 issue 可独立 merge
- design-an-interface——从 PRD 反推 API shape
Engineering Skills（实现段）
- review——PR 提交前的自查 checklist
- qa——端到端测试设计
- tdd——红绿重构门控
- diagnose——5 步法定位 bug
- improve-codebase-architecture——找 shallow module 深化，固定 8 词字典
- improve-repository-structure——仓库目录结构审计
- handoff——交接上下文，让下一个 session 快速上手
最值得抄的实现
grill-me：不写代码先写需求。它会一个一个问问题，每个问题都带"我推荐的回答"+ "为什么这样推荐"。这跟普通 chat 不一样——普通 chat 是"你说啥 agent 就答啥"，grill-me 是"agent 主动拷问"。
to-prd：把聊天记录沉淀成 GitHub issue，每条 PRD 都带可追溯的对话链接。当 AI 三个月后忘了为什么这么设计，issue 评论里能找回。
to-issues：把 PRD 切成 vertical slice（端到端可 demo 的最小切片），不是 horizontal layer（先把所有 model 写完再写所有 view）。vertical slice 的好处是 24 小时内能 ship 第一个 slice，horizontal layer 经常卡 3 周。
improve-codebase-architecture：固定 8 词字典描述"shallow module"——比如 "leaky abstraction" / "tangled concern" / "missing seam"。这把主观判断变成可枚举的 checklist。
Skill 架构图
Skill 业务场景对照
| Skill | 使用对象 | 触发时机 | 业务 / Coding 例子 |
|---|---|---|---|
grill-me | PM / 独立开发者 | 需求起点，不写一行代码 | "做个 AI 简历筛选工具" → 主动问"目标用户、付费意愿、vs BOSS 直聘的差异点" |
grill-with-docs | 加入新项目的工程师 | 看 README 也看不懂业务时 | 绑定仓库 docs/ 目录追问，让 AI 帮你读懂领域语言 |
to-prd | PM / 工程师 | grill-me 聊完 | 沉淀成 GitHub issue，每条对话带可追溯链接 |
to-issues | Tech Lead | PRD 写完、准备进 sprint | 把"AI 简历筛选"切成 5 个 vertical slice（每个端到端可 demo） |
design-an-interface | 工程师 | 写代码前 | 从 PRD 反推 API shape，先定 contract 再写实现 |
review | 工程师 | PR 提交前 | 自查 checklist：测试覆盖、命名规范、breaking change、文档同步 |
qa | QA / 工程师 | review 后、merge 前 | 端到端测试设计：登录流、支付流、错误流、异常流 |
tdd | 工程师 | 写实现前 | 单元测试先红再绿，禁止写完再补测试 |
diagnose | 工程师 | 出 bug | 5 步法：复现 → 定位 → 假设 → 验证 → 修复 |
improve-codebase-architecture | 工程师 | code review 时 | 用 8 词字典找 shallow module（leaky abstraction / tangled concern / ...） |
improve-repository-structure | 工程师 | 仓库混乱 | 目录结构审计，职责清晰比代码优雅更重要 |
handoff | 工程师 | 跨 session / 跨人交接 | 上下文打包，下一个 session 30 秒上手 |
适合什么团队
- 独立开发者 / 2-3 人小团队
- 想要"轻量级 prompt 工程化"的
- 不愿被 rigid workflow 绑死——只挑需要的 skill 装
三大体系横向对比
| 维度 | Superpowers | OpenSpec | Matt Pocock Skills |
|---|---|---|---|
| Skill 数量 | ~15 | ~10 命令 | 21 |
| 工作流控制 | 强（必须 TDD） | 中（spec 必备） | 弱（按需） |
| Token 消耗 | 高 | 中 | 低 |
| OpenCode 适配 | ✅ | ✅ | ✅（npx skills add） |
| Claude Code 适配 | ✅ | ✅ | ✅ |
| Codex 适配 | ✅ | ✅ | ✅ |
| Cursor 适配 | ✅ | ✅ | ✅ |
| 学习曲线 | 陡 | 中 | 平 |
| 适合规模 | 中大型 | 任意 | 小团队 / 个人 |
| 核心思想 | 流程钉死 | spec 优先 | 能力即插即用 |
| 入门成本 | 1 天 | 半天 | 1 小时 |
如果你只装 10 个 Skills
覆盖 80%+ 开发场景的最小集：
- writing-plans（Superpowers）—— 出活之前先写计划，避免 agent 跑偏
- review（mattpocock）—— PR 提交前自查
- to-prd（mattpocock）—— 把聊天记录变成可追溯的 PRD
- to-issues（mattpocock）—— 把 PRD 切成 vertical slice
- brainstorming（Superpowers）—— 需求起点，把"想做什么"问穿
- tdd（mattpocock）—— 红绿重构门控
- diagnose（mattpocock）—— bug 调试 5 步法
- handoff（mattpocock）—— 上下文交接，让新 session 快速上手
- grill-me（mattpocock）—— 把需求问穿，避免"AI 靠猜"
- apply（OpenSpec opsx:apply）—— 按 tasks.md 逐项实现
这一套已经覆盖：
- 需求（brainstorming + grill-me + to-prd）
- 规划（writing-plans + to-issues）
- 实现（tdd + apply）
- 验证（review + diagnose）
- 维护（handoff）
怎么装
# Superpowers
claude plugin marketplace add obra/superpowers-marketplace
# OpenSpec
npm install -g @fission-ai/openspec@latest
# Matt Pocock Skills
npx skills@latest add mattpocock/skills未来趋势：从 Prompt 到 Agent OS
四个阶段的演进：
Prompt Engineering → Workflow Engineering → Skill Engineering → Agent Operating System- Prompt Engineering（2023-2024）：单点调教，prompt 是聊天框里的一次性燃料
- Workflow Engineering（2025）：流程钉死，LangChain / LlamaIndex 时代
- Skill Engineering（2026）：能力模块化，SKILL.md 是新通货
- Agent Operating System（2027-）：把 skill + tools + memory + hooks 装成 OS
关键判断
2027 年之前，"哪个 agent 跑得更聪明"不重要——所有 frontier model 的 SWE-bench 分数都卷到 60+。"哪个 agent 的 skill 生态更厚"决定胜负。
三个落地信号：
- Anthropic Plugin Marketplace——Superpowers 进了官方市场，这是 Claude Code 的 App Store 化
- OpenCode Marketplace——
/plugin install命令把 skill 装到工程目录 - Kimi Code Plugins——
/plugins install命令同样模式
skill 不再是 agent 的内部实现，而是 agent 之间的可移植资产。一个 skill 写好，Claude Code 能用、Codex 能用、OpenCode 能用、Cursor 能用。这跟 Linux package manager 的演化如出一辙——未来 2 年，"npm install skill" 跟 "npm install package" 一样自然。
2026 年的工程师该学什么
- 会写 SKILL.md——跟会写 README 一样基础
- 会挑 skill——三个流派按团队规模各取所需
- 会组合 skill——把 grill-me + to-prd + to-issues + tdd 串成 pipeline
- 会 review skill——SKILL.md 也要 code review，坏 skill 比坏 prompt 更危险