---

 本文关键词: ["Claude Code Skills", "superpowers Claude Code", "Claude Code 开源", "AI 编程工作流", "Claude Code 技巧", "anthropics skills"] platform: "掘金 / 个人博客" source: "GitHub Trending + GitHub obra/superpowers + anthropics/skills"

---

我调 bug 有一段时间特别痛苦：试了五个方法，每次都以为找到了，改完之后还是出错。最后发现，问题出在我根本没有搞清楚根因，只是在猜。

这是一个思维方式的问题，不是工具问题。

然后我装了 systematic-debugging 这个 Skill，强制自己先走完四个分析阶段再动手改代码。第一次用，一个困扰了两天的问题在 20 分钟内解决了。

这让我开始认真翻开源社区的 Skills 仓库。翻完之后发现：最有价值的 Skills 不是功能扩展，而是方法论强制执行。它把"我知道应该这样做但执行起来总是偷懒"这件事，变成了"不走这个流程 Claude 就不继续"。

这篇文章精选的 10 个 Skills，来自两个最热门的开源仓库：

• **obra/superpowers**：121,691 ⭐，今日单日新增 2,292 stars，GitHub Trending 今日第一。核心是一套工程方法论——调试、TDD、规划、并行 Agent 协作。

• **anthropics/skills**：105,000 ⭐，11,600 forks。官方出品的能力扩展——文档处理、前端设计、MCP 构建。

---

先装好，再用

安装 superpowers（全部 14 个 Skills 一次装完）：

/plugin marketplace add obra/superpowers

安装 anthropics/skills（分 document-skills 和 example-skills 两包）：

/plugin install document-skills@anthropic-agent-skills
/plugin install example-skills@anthropic-agent-skills

装完后在 Claude Code 里输入 What skills are available?，确认能看到下面要介绍的 Skills。

---

Part 1：superpowers — 把方法论变成纪律

superpowers 的核心设计哲学是：把开发最佳实践变成 Claude 必须遵守的硬性流程，而不是"供参考的建议"。

这些 Skills 大多数设置了隐式的"HARD-GATE"——不完成当前阶段，不允许进入下一阶段。对付"AI 总是跳步骤"这个问题，这是最有效的解法。

---

Skill 1：systematic-debugging — 彻底消灭猜测式调试

这个 Skill 强制执行四阶段调试流程，核心原则只有一条：

“

"NO FIXES WITHOUT ROOT CAUSE INVESTIGATION FIRST"在找到根因之前，任何修复都不允许执行。

很多时候我们（包括 Claude）调 Bug 是这样的：看到错误 → 猜一个原因 → 改一行代码 → 还是错 → 再猜。这种模式可以耗掉 2-3 小时，而且越改越乱。

systematic-debugging 会强制按这四个阶段走：

flowchart TD
    A[发现 Bug] --> B[Phase 1: 根因调查\n仔细读错误信息\n稳定复现\n审查最近变更\n多组件时在边界加日志]
    B --> C[Phase 2: 模式分析\n找到代码库里的工作示例\n逐行对比 working vs broken\n不放过任何细节差异]
    C --> D[Phase 3: 假设验证\n提出一个具体假设\n用最小变更测试假设\n一次只改一个变量]
    D --> E[Phase 4: 实现修复\n先写失败测试\n修复代码通过测试\n验证没有回归]

    D -- 假设错误 --> B
    E -- 三次尝试都失败 --> F[质疑架构本身是否有缺陷]

图：systematic-debugging 四阶段调试流程

内置的预警机制：如果发现自己在提第三个修复方案，Skill 会强制要求停止并返回 Phase 1 重新调查——因为到了这一步，说明你搞错了问题所在，继续修只会越来越远。

根据 superpowers 的实测数据：系统化调试通常 15-30 分钟解决问题，而猜测式调试平均耗时 2-3 小时。

触发方式：遇到任何 Bug 或测试失败时，Skill 自动触发。也可以手动：

/systematic-debugging

或者直接描述问题，Claude 会自动加载这个 Skill：

这个 API 请求一直返回 401，我已经检查过 token 了，应该是对的

---

Skill 2：brainstorming — 代码之前先设计，这是强制的

这个 Skill 解决一个工程里最常见的浪费：写了一半代码才发现方向不对。

它在任何实现开始前设置一个 HARD-GATE：必须完成设计对话，Claude 才会写代码。具体流程：

1. 探索项目上下文（读现有代码，理解架构）

2. 如果有帮助，提供可视化工具（在浏览器里显示 mockup）

3. 逐个提问（一次只问一个，不轰炸）

4. 提出 2-3 个方案，每个方案说清楚 tradeoff

5. 把讨论结果写成设计文档

6. 自我 review 设计文档的清晰度

7. 让用户 review 设计文档

8. 用户确认后，才调用 writing-plans 进入实现阶段

HARD-GATE 原文：

“

"ABSOLUTELY NO IMPLEMENTATION until design is presented and approved. This applies to EVERY project regardless of perceived simplicity."

说"这只是个小功能，不用设计"？不行，Skill 会拒绝直接进入实现。

触发方式：描述你要做什么，Skill 自动触发：

我想给这个接口加一个限流功能

---

Skill #3：test-driven-development — 强制 RED-GREEN-REFACTOR 不跳步

TDD 大家都知道，但执行起来总是"先写代码，之后再补测试"。test-driven-development Skill 让这件事没法偷懒。

它强制执行严格的 RED-GREEN-REFACTOR 循环：

RED（必须先做这步）：

• 写一个测试

• 运行测试，必须看到它失败（不是跳过，是真实失败）

• 如果测试没有失败，说明测试本身写错了

GREEN：

• 写最少量的代码让测试通过

• "最少量"是认真的——不允许写超出当前测试需要的代码

REFACTOR：

• 清理代码，消除重复，改进设计

• 测试必须依然通过

Skill 里还有一条明确规则：禁止在没有失败测试的情况下写任何实现代码。如果 Claude 发现自己在先写实现，会停下来告知用户并回到 RED 阶段。

触发方式：提到"实现某个功能"时自动触发，或手动：

/test-driven-development

---

Skill 4：writing-plans — 任务必须精确到"2-5分钟可完成"

这个 Skill 解决的问题是：AI 生成的实现计划经常太粗糙，充满"添加适当的错误处理"这类废话，实际执行起来根本不知道怎么做。

writing-plans 要求每个任务必须满足：

• 耗时 2-5 分钟（不是半天，不是一小时）

• 包含完整可执行的代码，不允许占位符（"similar to Task N" 是不允许的）

• 每个任务格式：写失败测试 → 确认失败 → 写最小实现 → 确认通过 → commit

被明确禁止的写法：

• ❌ "添加适当的错误处理"

• ❌ "与 Task 3 类似的实现"

• ❌ "实现相关功能"

• ✅ 必须写出具体的函数签名、参数类型、返回值

生成的计划可以通过两种方式执行：子 Agent 驱动（每个任务一个新的子 Agent 上下文）或内联执行（在当前 session 里逐步执行，带人工检查点）。

与 brainstorming 联动：brainstorming 设计完成后，直接把设计文档传给 writing-plans 生成实现计划。

/writing-plans

---

Skill 5：dispatching-parallel-agents — 让 AI 真正并行工作

这是 superpowers 里最"工程化"的 Skill，直接处理并发子 Agent 的编排问题。

它解决的问题：当一个任务可以分解为多个独立子任务时，不需要依次串行执行，而是同时启动多个 Agent 并行处理，最后汇总结果。

典型场景：

• 代码库分析：同时让多个 Agent 扫描不同模块

• 批量测试：多个 Agent 分别跑不同的测试套件

• 多语言版本：同时生成英文、中文、日文文档

graph LR
    A[主 Agent] -->|分解任务| B[子任务 1]
    A -->|分解任务| C[子任务 2]
    A -->|分解任务| D[子任务 3]
    B -->|结果汇报| E[汇总 Agent]
    C -->|结果汇报| E
    D -->|结果汇报| E
    E -->|整合报告| A

图：dispatching-parallel-agents 的 Agent 编排模型

Skill 里包含了并行 Agent 工作的完整协议：如何分解任务确保独立性、如何传递上下文、如何处理子 Agent 失败、如何汇总结果。

触发方式：描述可以并行的工作时自动触发，或：

/dispatching-parallel-agents

---

Part 2：Claude Code 内置精选

Skill 6：/batch — 一次迁移整个代码库

superpowers 的 dispatching-parallel-agents 是通用的并行编排，而内置的 /batch 是专门为代码库级别的批量操作设计的——它自动创建 Git worktree 隔离，每个子任务结束后各自提 PR。

/batch 把 src/ 目录下所有 Class 组件迁移到 React Hooks，保留现有测试

会自动：分析仓库 → 拆分 5-30 个独立任务 → 各自建 worktree → 并行执行 → 各自提 PR。

它和 dispatching-parallel-agents 的区别：/batch 是代码操作专用，有 Git 集成；dispatching-parallel-agents 是通用的任务并发框架。

---

Skill 7：/simplify — 代码写完自动做三角质量审查

写完代码跑 /simplify，它同时启动三个并行 review Agent，分别从代码复用、质量、效率三个维度审查，汇总后直接修复，不只是给建议。

/simplify
/simplify focus on unnecessary re-renders

---

Part 3：anthropics/skills — 官方出品的能力扩展

anthropics/skills 和 superpowers 的定位完全不同：superpowers 是方法论，anthropics/skills 是能力扩展——它给 Claude 增加了本来没有的技能（生成 PPT、构建 MCP 服务器、生成算法艺术等）。

---

Skill 8：frontend-design — 直接产出生产级 UI

这是我用过的最惊喜的 Skill 之一。描述一个界面，它会给出真正有区分度的设计，而不是千篇一律的 Bootstrap 样式。

Skill 内部包含了：排版系统、颜色理论、组件模式、响应式原则，以及"怎样让界面看起来不像模板"的具体准则。

/frontend-design 设计一个任务管理看板，支持拖拽排序，暗色主题

产出是可以直接用的完整代码，不是样式建议。

---

Skill 9：mcp-builder — 从零构建 MCP 服务器的完整指南

如果你想给 Claude Code 接一个新的外部工具（自己公司的 API、数据库、内部系统），需要构建一个 MCP 服务器。mcp-builder 把这个过程标准化了。

Skill 覆盖：MCP 协议规范、工具定义格式、认证处理、错误处理模式、测试方法。

/mcp-builder
我想给 Claude Code 接入公司内部的 Confluence API，让它能直接读写 wiki 页面

---

Skill #10：pdf + pptx — 文档生成直接输出文件

这两个 Skill 让 Claude 能真正生成二进制文件，不是文本描述。

**pdf**：

/pdf
把这份技术规范整理成格式规范的 PDF，带封面页、目录、代码高亮

**pptx**：

/pptx
把这次 Sprint 的总结做成 PPT，10 页，科技风格，包含数据图表

两者都需要先安装 document-skills@anthropic-agent-skills。这两个 Skill 会在本地生成实际的 .pdf 和 .pptx 文件，直接可以打开用。

---

怎么组合用最顺手

“

🖼️ [配图占位]10 个 Skills 在开发工作流中的触发时机图

提示词： 横向时间轴，展示一个完整开发周期从需求到上线的各阶段，每个阶段标注对应触发的 Skill 名称，用图标区分 superpowers（紫色）和 anthropics（蓝色）两个来源，深色背景，现代信息图表风格

替换为 ![Skills 在开发工作流中的触发时机](skills-workflow-timing.png)

把这 10 个 Skills 放进开发流程里，触发时机是：

flowchart LR
    A[新需求] -->|自动触发| B[brainstorming\n设计对话]
    B -->|设计完成| C[writing-plans\n生成精确任务]
    C -->|开始实现| D[test-driven-development\n RED-GREEN-REFACTOR]
    D -->|遇到 Bug| E[systematic-debugging\n四阶段根因分析]
    E -->|Bug 修复| D
    D -->|功能完成| F[simplify\n三角质量审查]
    F -->|需要大量并行任务| G[dispatching-parallel-agents 或 /batch]
    G -->|代码库迁移| H[PR 提交]
    D -->|UI 任务| I[frontend-design]
    D -->|需要接外部工具| J[mcp-builder]
    H -->|交付文档| K[pdf / pptx]

图：10 个 Skills 在开发工作流中的触发位置

superpowers 的 Skills 之间有设计上的依赖关系：brainstorming → writing-plans → test-driven-development 是官方推荐的串联顺序。不需要手动串联，Skills 之间会互相调用。

---

踩坑记录

坑一：superpowers Skills 有时会让 Claude 变得"太慢"

brainstorming 的 HARD-GATE 意味着一个简单的修改（比如改个变量名）也会被要求先走设计对话流程，很烦。

解决方法：对于明显是单行改动的任务，明确告诉 Claude "这是个小修改，不需要走 brainstorming 流程"。superpowers 允许用户主动跳过，但需要你明确说出来。

坑二：writing-plans 生成的计划太细，任务量爆炸

"每个任务 2-5 分钟"意味着一个中等功能可能被拆成 30+ 个任务。看到任务列表会很崩溃。

实际上这不是问题——你不需要手动一个个确认，告诉 Claude "用子 Agent 执行所有任务，有疑问再问我"，它会自动跑完。

坑三：document-skills 里的 pdf 和 pptx 依赖本地环境

这两个 Skill 需要特定的本地依赖（Python 或特定库）。如果生成失败，先看报错里缺什么库，通常 pip install python-docx weasyprint 就能解决。

坑四：两套 Skills 的优先级冲突

superpowers 和 anthropics/skills 都安装了之后，如果同名 Skill 冲突（目前没有，但未来可能有），Claude Code 的优先级是：项目级 > 个人级 > 插件级。可以通过这个规则来覆盖。

---

常见问题

Q：superpowers 和 Claude Code 官方内置的 Skills 有什么本质区别？

A：内置 Skills（/batch、/simplify 等）是 Anthropic 用代码实现的固定逻辑，比如 /batch 会真正创建 Git worktree 并管理生命周期。superpowers 的 Skills 是纯 prompt 工程——通过详细的指令让 Claude 遵循特定方法论。两者互补：内置 Skills 有更强的工具集成，superpowers 的方法论 Skills 更灵活、可定制。

Q：这些 Skills 会不会拖慢我的开发速度？

A：superpowers 的调试类和规划类 Skills 短期内确实会让单个任务更慢（设计对话要时间、调试要系统化分析）。但从一周或一个月的维度看，"不走弯路"节省的时间远超"多花的流程时间"。特别是 systematic-debugging，15-30 分钟解决问题 vs 2-3 小时乱猜，这个数据是真实的。

Q：anthropics/skills 的 frontend-design 会被 Cursor 的设计能力替代吗？

A：两者聚焦不同。Cursor 擅长在已有代码基础上做编辑；frontend-design Skill 更擅长从零到一生成有设计感的界面。后者内置了更多的设计理论（排版、颜色、组件模式），产出的 UI 质量更高。如果你同时用 Claude Code 和 Cursor，建议用 frontend-design 生成初版，用 Cursor 做后续调整。

Q：能自己写 Skills 然后贡献到 superpowers 或 anthropics/skills 吗？

A：可以。两个仓库都接受 PR。superpowers 有一个 writing-skills Skill，专门指导你如何写出高质量的 Skill（按照它定义的标准，不是随便写一个）。贡献新 Skill 之前，建议先用 /writing-skills 让 Claude 帮你评审。

---

这 10 个 Skills 里，今天就能产生价值的是 systematic-debugging 和 /simplify——下次遇到 Bug 或写完一个功能，直接用，感受一下差别。

方法论类的 Skills（brainstorming、test-driven-development）需要养成习惯，但一旦习惯了，你会发现之前写代码的方式有多随意。

关注我，解锁更多硬核 AI 编程实战技巧