分享一些我觉得很好用的Skill
先补一句背景说明：这篇文章里提到的很多 skill，其实都来自 superpowers 这一套。它本身不只是一个单独的 skill 仓库，更像是一整套配套工作流的入口：把需求澄清、写 spec、拆 plan、执行、测试、review 和收尾这些环节串起来，再通过一组 skill 去驱动整个过程。
分类
流程入口与思考
using-superpowers
这个 skill 更像总控层，不是直接帮你写代码、写文章，而是先判断这次任务应该走哪种工作流。适合所有新任务的起点，尤其是那种“看起来很简单，但其实一上来就容易做歪”的需求。
比如你给 agent 下任务：“帮我做一个订单管理后台。”
如果 agent 听完就直接上手改，你其实并不知道它会往哪个方向做。它可能花了半小时，把列表、筛选、详情都搭出来了，但最后做出来的东西和你真正想要的完全不是一回事。你以为重点在订单状态流转和退款处理，它却把时间都花在页面展示和交互细节上。这个 skill 的作用，就是先把任务的大致框架和重点捋清楚，避免 agent 一开始就朝着错误方向投入太多时间。
一个很常见的情况是：
你一开始以为需求只是“加个订单详情页”，结果梳理之后才发现里面还包含操作日志、售后记录、支付信息、发货状态这些内容。这个时候，先把整体框架想清楚，通常比立刻动手更重要。
brainstorming
这个 skill 适合所有“还在想，没开始做”的任务。它的核心不是多给点创意，而是把目标、边界和成功标准说清楚。
比如你说：“我想做一个优惠券系统。”
如果不先梳理，大部分人第一反应会是做一个发券和用券的功能。
但真往下聊，往往会发现你真正要解决的是：
- 优惠券是平台发还是商家发
- 是否支持满减、折扣、兑换码这几种类型
- 一张券能不能叠加使用
- 过期、退单、退款后的规则怎么处理
这时候 brainstorming 的价值就出来了，它会先把问题定义清楚，再去谈实现方案。
可以把这两个 skill 的位置理解成这样：
规划与执行
writing-plans
这个 skill 的强项是把一个“大概知道怎么做”的任务，拆成“具体”的计划。
比如你要做“商品搜索功能优化”。
如果只说一句“先改接口，再改前端，再联调”，看起来像计划，其实没法执行。
用这个 skill 的方式，会把它拆成更实的步骤，比如：
- 先梳理搜索条件和排序规则
- 再补后端查询逻辑和索引方案
- 再改接口返回结构
- 再补前端筛选和分页展示
- 每一步都带上测试和验证方式
我自己觉得，这个 skill 特别适合中等复杂度以上的任务，尤其是多 agent 协作，或者后面还要交给别的 agent 接手的时候。
executing-plans
如果说 writing-plans 负责把路画出来，那 executing-plans 就是按图走路。
它适合已经有明确方案的任务。
比如你已经写好了一份迁移计划，要把用户中心里的老接口逐步替换成新版接口。这时候最怕的是执行过程中“顺手把别的模块也改了”。这个 skill 的好处，就是让人按计划推进，不在中途跑偏。
举个简单例子：
- 第一步只是替换用户列表接口
- 第二步只是接入新的详情接口
- 第三步才是统一调整前端展示逻辑
不用这个 skill 时，如果提示词里没有明确约束，很多 agent 会在第一步就顺手把样式、状态管理甚至别的页面一并改掉，最后反而很难定位问题到底出在哪一层。
subagent-driven-development
这个 skill 比较适合长任务。思路是把一件大事拆成多个相对独立的小块，让不同子 agent 分别处理，再由主 agent 统一 review 和收口。
比如做一个后台权限系统时，可以这样拆：
- 一个 agent 处理角色和权限点的数据结构
- 一个 agent 处理菜单和路由的权限控制
- 一个 agent 处理页面上的按钮级权限展示
- 主 agent 负责最后集成和联调
它适合“能分块，但又不适合完全并行放飞”的项目。
dispatching-parallel-agents
这个 skill 和上面那个很像，但重点不同。
subagent-driven-development 更像分段施工。
dispatching-parallel-agents 更像并行处理多个独立问题。
比如你在工作时同时遇到这三件事：
- 订单列表接口偶尔超时
- 报表导出任务一直失败
- 后台某个页面切换分页后数据不刷新
如果确认这三件事彼此独立，就很适合并行派给不同 agent 去查。
这样效率会很高，但前提是问题真的独立。如果后来发现三件事都和同一个缓存服务异常有关，那就不该硬拆。
using-git-worktrees
这个 skill 的价值在于隔离环境。
比如工作时一边在修线上 bug，一边又在开发月底要上线的新功能。如果都放在同一个工作区里，很容易互相污染。这个 skill 会帮你把不同任务放进不同 worktree，避免“这个文件到底是修 bug 改的，还是做新功能改的”这种情况。
对有多 agent 切换需求的人来说，它尤其有用。因为 agent 本来就容易把上下文搅在一起，不隔离工作区的话，出错概率会更高。
质量、调试与审核
test-driven-development
这个 skill 用于新功能和 bug 修复。它最核心的一点就是：先写失败测试，再写实现。
比如你发现“用户修改收货地址后，订单确认页偶尔还是显示旧地址”。
如果让 agent 直接去修，大概率会直接改状态同步逻辑。
更稳的做法其实是先写好测试用例，把这个问题固定下来，再去修。这样你才能确定自己改的东西，真的解决了原来的问题，而不是碰巧让现象没出现。它可以明显减少那种“我以为修好了”的错觉。
systematic-debugging
这也是我很推荐的一个 skill。它的核心是：先找根因，不允许猜着修。
比如一个支付回调突然处理失败，有些人第一反应会是：
- 重启服务
- 重放消息
- 改一下超时时间试试
- 多打几行日志看看
这些动作不一定错，但如果没有先确认根因，很多时候只是把问题越搅越乱。
systematic-debugging 会要求先看报错、确认复现步骤、对比最近改动、顺着数据流定位到底是哪一层断了。
举个更具体的例子：
如果支付平台明明回调成功了，但订单状态一直没有更新，问题就不一定在支付逻辑本身，也可能在消息队列消费、签名校验、数据库事务或者状态机流转这一层。这个 skill 的价值，就是逼着你沿着链路一层层排查，而不是先凭感觉改代码。
verification-before-completion
这个 skill 解决的是“太早宣布结束”的问题。
很多任务不是做完，而是“看起来差不多做完了”。这时候如果直接说“好了”，很容易留下坑。
这个 skill 会要求先跑验证命令，看到真实结果，再下结论。
比如你修了一个导出报表失败的 bug，至少要确认：
- 对应测试确实通过了
- 没有引入新的失败
- 实际导出流程手动验证也正常
它的价值非常朴素，但真的真的很重要。团队里很多返工，其实都来自一句说早了的“已经好了”。
requesting-code-review
这个 skill 适合在工作快结束的时候切成“审稿模式”。
重点不是看风格，而是看风险。
比如你刚改完一个库存扣减逻辑，用这个 skill 来审，通常会重点看这些问题：
- 并发下会不会超卖
- 事务边界是不是清楚
- 异常回滚有没有覆盖到
- 失败场景和边界条件有没有测试
它很适合拿来做最后一轮质量把关。
receiving-code-review
这个 skill 的好处在于，它不会让你机械接受 review 建议。
比如 reviewer 说：“这里直接把缓存时间拉长就好了。”
表面看很合理，但如果你的问题是库存实时性或者价格同步，那缓存时间拉长可能反而会制造新问题。
这个 skill 会提醒你先验证：这条建议到底是不是适合当前上下文，而不是因为别人提了就照着改。
文档、图示、资料与表达
doc
这个 skill 可以用于处理 .docx 文档，尤其是那些对格式有要求的材料。
比如你要整理一份项目汇报，内容本身不复杂，但页面结构、标题层级、表格布局、截图位置都很重要。单纯把字写对不够，最终还得能直接发给老板、客户或者合作方，这就是它的价值。
一个常见场景是：
- 先在 markdown 里整理需求分析和方案说明
- 定稿后转成正式
.docx - 再用这个 skill 检查排版和结构有没有跑掉
plantuml
非常非常非常推荐！这个 skill 特别适合技术分享，因为很多东西只靠文字解释太累。还可以帮助快速理解和学习一个新的项目。
比如你要讲“下单后的订单处理流程”，只写一段说明会很绕；如果配一张图，别人一眼就明白了。它很适合画：
- 流程图
- 架构图
- 时序图
- ER 图
- 部署图
比如下面这种图，就很适合放在讲订单链路的文档里：
humanizer-zh
这个 skill 适合写中文文章、分享稿、口播稿时使用。它的重点不是“修得更华丽”，而是把那些很像 AI 写出来的句子，改回正常人会写的样子。
xxxxxx-docs
这个 skill 的优势是把某个框架、工具或者平台的官方文档直接提供给 AI，当成它做事时的参考依据。
比如有人问：
- 这个项目现在用的是 React 还是 Next.js 的新写法
- 某个框架的 API 有没有已经废弃的用法
- 某个工具目前推荐的最佳实践是什么
这类问题如果只靠模型记忆，很容易把旧版本的写法、已经废弃的特性，或者早就不推荐的实现方式继续用进去。这个 skill 的作用，就是把最新文档喂给 AI，让它尽量基于当前版本来实现，少踩弃用特性，也更接近官方推荐的最佳实践。
imagegen
这个 skill 更偏视觉生成。
如果你需要的是：
- 文章封面
- 视频缩略图
- 插画感概念图
- 带透明背景的素材
它就很适合。
举个例子，如果你写了一篇“电商后台重构复盘”，还想配一张封面图，比如一个后台大屏上同时展示订单、库存、商品和报表几个模块，这种图就很适合交给 imagegen。
插件生态
find-skills
这个 skill 适合在动手之前先查：有没有现成 skill 能解决问题。
比如你想做“自动生成接口变更说明”，如果不先查，很可能自己从零搭一套流程。可实际上，可能已经有现成 skill 处理这类工作了。
它的价值很简单：少造轮子。
skill-installer
这个 skill 很适合懒得自己手动装 skill 的人。
比如你在网上看到一个别人写好的 skill，觉得挺适合自己现在的工作流，但又不想自己去拷文件、配目录、处理安装细节。
- 这时候你只需要把 skill 的 URL 提供给 agent
- 剩下的安装动作就可以交给 agent 自己处理
它的好处很直接，就是省事。特别是看到合适的 skill 想顺手装一下的时候，不用再自己折腾安装过程，直接把地址给过去，agent 就能自己给自己装上。
skill-creator
当你发现一个动作自己已经重复做了很多次，就很适合考虑把它沉淀成 skill。
比如你每次接手一个老项目都会做这些事：
- 扫一遍目录结构
- 找入口模块
- 看启动命令
- 看测试方式
- 输出核心链路说明
那它其实就非常适合做成一个 repo-onboarding 类 skill。
skill-creator 就是帮助你把这种重复经验抽象出来。
writing-skills
这个 skill 更偏“写出来”。
如果说 skill-creator 是想清楚 skill 的边界和用途，那 writing-skills 就是在真正编写 skill 内容，并验证这份 skill 是否可执行。
一个常见例子是：
你已经想好了一个“新项目接手检查清单”类 skill，要包含环境检查、服务启动、数据库连接、核心接口验证，那么接下来就要靠这个 skill 把规则写扎实，不然最后只是一个看起来很完整、实际没人能稳定执行的文档。
plugin-creator
这个 skill 再往前一步，它适合那些已经不是单纯 prompt 或 skill 能搞定的场景，而是需要正式插件结构来承载能力。
比如你要做一个内部开发助手插件，它可能需要：
- 插件目录结构
- 配置文件
- 元数据
- 可加载的功能模块
这时候 skill 只是方法，插件才是载体。
这个 skill 的价值，就是帮你把载体搭起来。
交付与收尾
finishing-a-development-branch
很多人觉得代码写完就结束了，但实际上后面还有：
- 要不要再清一次分支
- 是直接合并还是先提 PR
- 有没有残留验证没做
- 这次交付到底算不算 ready
比如一个营销活动功能已经开发完成，但测试环境的数据还没走完一轮，这时候它就会提醒你，别因为“主要功能能跑了”就提前收尾。
yeet
这个 skill 适合明确要走完整提交流程的时候用。
比如你已经确认：
- 改动没问题
- 测试过了
- review 过了
- 可以交付了
那它就能把 stage、commit、push、开 PR 这些步骤串起来，一次做完。适合节奏快、但流程又不能漏的场景。
使用经验
我自己的使用习惯一直比较明确：skill 在精不在多。
装得太多，第一层问题是 token 成本会明显上升。模型幻觉也会提高。每次来一个新任务，你都得先想：
- 这次该用哪个
- 哪几个功能重叠
- 要不要先走流程 skill
- 会不会两个 skill 指令风格冲突
这样就本末倒置了，skill 本来是来提效的，最后反而会先消耗注意力。
第二层问题更实际，就是上下文会变脏。尤其是经常多个 agent 换着用的时候。A agent 装了一套，B agent 是另一套，C agent 甚至连 mcp 都不一样。切换几次之后，你很容易忘掉：
- 这个 agent 当前能不能调用某个 skill
- 这个环境是不是已经接了对应 mcp
- 这次输出为什么和刚才那个 agent 风格完全不一样
这种割裂感非常影响实际体验。
所以我自己的习惯，是把通用 skill 放到统一入口里集中管理，项目专用的 skill 则直接放在对应项目目录下。统一管理自己使用的是 cc-switch, 它可以把 skill 和 mcp 放到一个地方统一维护。对于经常多个 agent 轮着用的人来说，它的优势很明显：
- 配置不容易散
- agent 切换时体验更一致
- skill 和 mcp 的来源更清楚
- 出问题时更容易排查到底是哪一层出了问题
如果一定要给一个实际建议，我会这么配：
- 流程梳理：
using-superpowers、brainstorming - 规划执行：
writing-plans、executing-plans - 质量保障：
test-driven-development、systematic-debugging、verification-before-completion
其实这套工作流，核心就是围绕 spec 来转的。简要来说，它要把这几件事说清楚：
- 系统的外部行为
- 约束条件
- 边界与范围
- 可验证的标准
很多 AI 项目之所以越做越偏，不是执行能力不够，而是一开始就没有把 spec 说清楚。需求模糊的时候直接开工，agent 也只能按自己的理解往下做，最后很容易花了不少时间，做出来的东西却不是你真正想要的。先有 spec，再有 plan，再去执行和验证，整个过程会可控很多。