第 17 章：Skills 技能系统
第 16 章我们学习了 Plugins（插件）——它们是可打包发布的扩展单元，为 Claude Code 添加新工具和集成。本章要讲的 Skills（技能） 与插件密切相关却又本质不同：Skill 是一组可复用的指令模板，告诉 Claude"遇到某类任务时应该怎么做"。
你可以把 Plugin 理解为"给 Claude 安装了新工具"，而 Skill 则是"给 Claude 培训了新技能"。Skill 是 Superpowers 生态体系的核心，也是社区最活跃的贡献领域。学会使用 Skills，相当于让 Claude 具备了优秀工程师的工作方法论。
本章目标：理解 Skill 的本质和运作机制，掌握 Superpowers 体系核心 Skills 的使用场景和调用方式，能编写自己的 Skill 并组织个人 Skill 库。
17.1 什么是 Skill
定义：可复用的指令模板
Skill 本质上是一个 Markdown 文件，包含了针对特定任务的完整指令。当你调用一个 Skill 时，Claude Code 会将该 Skill 的完整指令加载到上下文中，Claude 随后严格按照这些指令执行。
这个机制的精妙之处在于：Skill 把顶尖工程师的工作流程固化成了可复用的模板。你不需要每次都跟 Claude 说"先做需求分析，再写设计文档，然后拆分成子任务……"，只需要调用 superpowers:brainstorming，Claude 就会自动按照经过社区打磨的最佳实践来引导你。
Skill 的调用方式
Skill 通过 Skill 工具来调用——你不需要手动输入，Claude 会在对话中判断何时需要使用某个 Skill 并自动调用。但你也可以直接要求 Claude：
帮我用 superpowers:brainstorming 来设计新功能
用 code-review:code-review 审查当前分支的代码当 Claude 的系统提示中列出了可用 Skills 时（就像 Claude Code 启动时显示的 Skill 列表），Claude 会收到明确的指示：对于匹配 Skill 描述的任务，必须调用 Skill 工具而非手动处理。这就是为什么系统提醒中说"You MUST use this before any creative work"——Skills 不是可选的建议，而是经过设计的工作流保障。
Skill vs Plugin：本质区别
| 维度 | Skill | Plugin |
|---|---|---|
| 本质 | 指令模板（Markdown 文件） | 可打包的扩展单元（含代码） |
| 能力 | 指导 Claude 如何使用现有工具 | 为 Claude 添加新工具和集成 |
| 分发方式 | 通过注册中心或文件共享 | 通过 npm / marketplace |
| 加载机制 | 按需加载到上下文 | 启动时加载工具定义 |
| 开发难度 | 低（纯 Markdown，会写提示词就能写） | 中高（需要 TypeScript/Node.js） |
| 代表例子 | superpowers:brainstorming | /plugin install superpowers-marketplace |
一个类比：Plugin 是给厨师买了新的厨具（比如一个搅拌机），Skill 是给厨师写了一份详细的菜谱（步骤、火候、配料顺序）。好的厨师（Claude）有了好菜谱（Skill）可以用现有工具做出精致的菜；但有些菜确实需要新厨具（Plugin）。
Skill vs Slash Command：粒度不同
| 维度 | Skill | Slash Command |
|---|---|---|
| 复杂度 | 多步骤工作流，可包含条件分支 | 通常是单步操作 |
| 上下文 | 加载完整指令模板 | 触发一个动作或命令 |
| 示例 | TDD 工作流（写测试→实现→重构→验证） | /commit（分析变更→创建提交） |
| 可否组合 | 可以（brainstorming → writing-plans → executing-plans） | 通常独立使用 |
Slash Command 适合"帮我做这一件事"，Skill 适合"按照这个方法论完成整个流程"。
什么时候用 Skill，什么时候直接问
应该用 Skill 的场景：
- 启动一个完整的开发工作流（从设计到实现）
- 需要进行系统性的代码审查或调试
- 任务有明确的行业最佳实践（如 TDD）
- 需要保证工作流的一致性和完整性
可以直接问的场景：
- 简单的一次性问题（"这个函数是干什么的？"）
- 不需要特定方法论的修改（"把这段代码改成 async/await"）
- 探索性、开放式的问题
判断原则：如果你知道自己要的是一个有方法论的完整流程，就找对应的 Skill；如果你要的只是一个具体的答案或修改，直接问就行。
Skill 工具的内部机制
从 Claude 的视角来看，Skill 工具是它可调用的工具之一。当 Claude 判断当前任务匹配某个 Skill 的描述时，它会调用 Skill 工具并传入 Skill 名称。Claude Code 的 Skill 系统随即：
- 查找 Skill 文件（从本地 Skills 目录或注册中心）
- 加载 完整指令到当前会话上下文
- 融入 Skill 指令到 Claude 的系统提示中
- 执行 Claude 按照 Skill 指令逐步完成
这个过程对用户来说基本透明——你只需要在合适的时候说"用 XX skill"，Claude 就会自动完成加载和执行。
17.2 内置 Skills 详解（Superpowers 体系）
Superpowers 是 Claude Code 社区中影响力最大的 Skill 套件，由 Claude Code 核心团队和社区共同维护。Superpowers 的设计理念是：将世界级工程师的工作方法论编码为可复用的 Skill，覆盖从需求分析到代码交付的完整开发流程。
Superpowers 使用 superpowers: 命名空间。下面按照开发流程的阶段，逐一介绍每个 Skill。
17.2.1 开发流程类
这些 Skills 覆盖了软件开发的完整生命周期：从头脑风暴到实现到交付。
superpowers:brainstorming
功能：在创意阶段通过协作式对话，将模糊的想法转化为清晰的设计方案。它是所有创造性工作的起点——没有经过充分讨论的需求，后续实现必然反复返工。
适用场景：
- 你有一个新功能的想法，但需求还不明确
- 需要设计系统架构，希望 Claude 提供专业意见
- 想要探索多种实现方案的利弊
系统提示关键指令："You MUST use this before any creative work - creating features, building components, adding functionality, or modifying behavior."
示例调用：
帮我想想怎么设计一个用户权限系统，用 superpowers:brainstorming当你调用这个 Skill 后，Claude 会主动探索你的需求、提出澄清问题、讨论设计取舍、最终产出一份结构化的设计文档。它不会直接开始写代码——这就是 brainstorming 和直接实现的关键区别。
superpowers:writing-plans
功能：将已有的设计规格转化为可执行的实现计划。当 brainstorming 产出了设计文档后，writing-plans 负责将设计拆分为具体的、可验证的步骤。
适用场景：
- 已经有明确的设计文档，需要制定实现计划
- 多步骤的复杂任务，需要分步执行
- 团队协作，需要清晰的实现路线图
系统提示关键指令："Use when you have a spec or requirements for a multi-step task, before touching code."
示例调用：
基于刚才的权限系统设计，用 superpowers:writing-plans 制定实现计划这个 Skill 会让你在动手写代码之前，先想清楚每一步做什么、依赖什么、怎么验证。
superpowers:executing-plans
功能：按照已制定的实现计划分步执行，每步之间设置审查检查点。这确保了实施过程不偏离计划，每个里程碑都经过验证。
适用场景：
- 已经有一个清晰的实现计划
- 需要在执行过程中保持代码质量
- 希望每一步完成后都有机会审查和调整
系统提示关键指令："Use when you have a written implementation plan to execute in a separate session with review checkpoints."
示例调用：
按照刚才的实现计划，用 superpowers:executing-plans 开始执行三大开发流程 Skill 的组合使用，构成了 Superpowers 最核心的工作流：
社区数据显示，遵循这个三步流程的项目返工率降低约 80%。
superpowers:subagent-driven-development
功能：为每个独立任务创建全新的子 Agent，采用两阶段审查（代码正确性 + 代码质量）。子 Agent 没有当前对话的历史包袱，能以全新的视角执行每个任务，确保每个任务的实现都是独立可验证的。
适用场景：
- 实现计划中包含多个相互独立的任务
- 需要并行处理多个模块
- 希望每个子任务都有独立的审查记录
系统提示关键指令："Use when executing implementation plans with independent tasks in the current session."
示例调用：
用 superpowers:subagent-driven-development 并行实现这三个独立模块与 executing-plans 的区别：executing-plans 在当前会话中逐步执行，适合有依赖关系的步骤链；subagent-driven-development 为每个任务开新的子 Agent，适合可以独立并行处理的模块。两者可以组合使用。
superpowers:test-driven-development
功能：严格执行 TDD 工作流——先写测试，确认测试失败，再写实现使测试通过，最后重构。这个 Skill 确保你不会跳过测试环节。
适用场景：
- 实现库函数、API 接口、工具类
- 后端逻辑层和数据处理层
- 任何"给定输入、期望输出"的纯逻辑代码
系统提示关键指令："Use when implementing any feature or bugfix, before writing implementation code."
示例调用：
用 superpowers:test-driven-development 实现这个用户名验证函数TDD Skill 对于后端和工具库开发尤其有价值——这些场景输入输出明确，测试编写成本低，收益高。
superpowers:systematic-debugging
功能：在提出任何修复之前，先系统性地调查 Bug 的根因。遵循结构化的调试方法论：复现问题 → 收集信息 → 提出假设 → 验证假设 → 定位根因 → 再写修复。
适用场景：
- 遇到任何 Bug、测试失败或意外行为时
- 问题原因不明确的故障排查
- 想在修复前确保真正理解了问题
系统提示关键指令："Use when encountering any bug, test failure, or unexpected behavior, before proposing fixes."
示例调用：
登录功能报 500 错误，用 superpowers:systematic-debugging 帮我排查这个 Skill 的价值在于：阻止你盲目修改代码。大多数开发者遇到 Bug 的第一反应是"改一下看看能不能好"——systematic-debugging 强制你先理解问题，再动手修复。
superpowers:verification-before-completion
功能：在声称任务完成、Bug 修复、测试通过之前，强制运行验证命令并确认输出。确保"口说无凭，要有证据"。
适用场景：
- 完成任务后、提交代码前
- 声称 Bug 修复后
- 创建 PR 之前
系统提示关键指令："Use when about to claim work is complete, fixed, or passing, before committing or creating PRs."
示例调用：
功能做完了，用 superpowers:verification-before-completion 验证一下这是 Superpowers 体系中最"简单"但也最容易被忽略的 Skill——但它的价值巨大：在 CI 报错之前，你自己先验证通过了。
superpowers:dispatching-parallel-agents
功能：当面对两个或更多互不依赖的独立任务时，将它们分派给并行子 Agent 同时处理，大幅缩短总执行时间。
适用场景：
- 同时需要修改前端和后端（无共享状态）
- 多个文件需要独立的重构
- 批量生成多个类似的文档或组件
示例调用：
前端的登录表单和后端的认证接口是两个独立任务，用 superpowers:dispatching-parallel-agents 并行处理superpowers:finishing-a-development-branch
功能：当功能实现完成、所有测试通过后，帮助决定如何集成已完成的工作——是直接合并、创建 PR、还是需要进一步处理。提供结构化的选项（merge / PR / cleanup）。
适用场景：
- 开发分支上的工作已经完成
- 不确定是该合并、发 PR、还是清理分支
- 需要处理 worktree 的清理
示例调用：
功能开发完成了，用 superpowers:finishing-a-development-branch 决定下一步superpowers:using-git-worktrees
功能：当启动需要隔离的功能开发时，确保通过 git worktree 创建隔离的工作空间。避免功能开发过程中的分支切换污染当前工作区。
适用场景：
- 开始一个新功能，需要独立的工作空间
- 执行实现计划前，需要隔离环境
示例调用：
用 superpowers:using-git-worktrees 创建隔离环境来开发这个新功能17.2.2 代码质量类
code-review:code-review
功能：对代码变更进行全面的代码审查。检查正确性（Bug）、可复用性、简化机会和效率问题。可以根据设置不同的审查强度（low / medium / high）。
适用场景：
- 完成一个功能或修复后，准备合并之前
- Review PR 中的代码变更
- 希望获得第二双"眼睛"来发现潜在问题
示例调用：
用 code-review:code-review 审查当前分支的变更也可以指定审查强度：
对当前 diff 做 high 强度的代码审查注意这个 Skill 来自 code-review 命名空间，不同于 Superpowers 套件，它是一个专注于代码质量的独立 Skill。
security-review
功能：对当前分支的变更进行安全漏洞扫描。检查常见的 OWASP 漏洞、注入风险、敏感信息泄露等安全问题。
适用场景：
- 涉及用户输入处理的代码变更
- 认证/授权相关的修改
- API 端点的新增或修改
- 合并到生产环境之前的最后检查
示例调用：
用 security-review 审查这次变更的安全性code-simplifier
功能：简化和优化代码，移除不必要的复杂度。专注于代码的可读性和可维护性提升。
适用场景：
- 代码通过了功能测试但结构复杂
- 重构遗留代码
- 减少嵌套层级和认知负担
示例调用：
用 code-simplifier 简化这段认证逻辑simplify
功能：审查变更代码的可复用性、简化机会和效率改进。与 code-simplifier 不同，它更侧重于检查变更中的重复代码和抽象机会。这个 Skill 只关注质量改进，不检查 Bug。
示例调用：
用 simplify 检查这次变更有没有可以复用的部分17.2.3 项目管理类
commit-commands:commit
功能：分析代码变更，生成信息丰富的提交信息，创建规范化的 git commit。
适用场景：
- 完成一个逻辑单元的工作后
- 需要生成符合项目规范的 commit 信息
示例调用：
用 commit-commands:commit 提交这些变更commit-commands:commit-push-pr
功能：将提交、推送、创建 PR 三个步骤合并为一个操作。分析变更 → 生成 commit → push → 自动创建 Pull Request。
适用场景：
- 功能开发完成，准备提交并请求审查
- 快速推送小型修复
示例调用：
用 commit-commands:commit-push-pr 一键提交并创建 PRcommit-commands:clean_gone
功能：清理所有远程已删除的本地分支（标记为 [gone] 的分支），同时清理关联的 worktree。保持本地仓库整洁。
适用场景：
- PR 合并后，远程分支已删除但本地还在
- 定期清理本地仓库中的陈旧分支
示例调用：
用 commit-commands:clean_gone 清理本地分支17.2.4 配置与自动化
init
功能：为新项目自动生成 CLAUDE.md 文件。分析项目结构、识别技术栈、提取常用命令，生成一份初始的项目文档。
适用场景：
- 新项目首次配置 Claude Code
- 从旧项目迁移，还没有 CLAUDE.md
示例调用：
用 init 为这个项目生成 CLAUDE.mdclaude-md-management:claude-md-improver
功能：审计并改进项目中的 CLAUDE.md 文件。扫描所有 CLAUDE.md，对照质量模板评估，输出质量报告，然后进行针对性改进。
适用场景：
- CLAUDE.md 写好了但想让 Claude 帮忙审查
- 项目演进后 CLAUDE.md 需要更新
- 定期维护项目文档
示例调用：
用 claude-md-management:claude-md-improver 审查并改进 CLAUDE.mdclaude-code-setup
功能：分析代码库，推荐应该启用的 Claude Code 自动化功能（Hooks、子 Agent、Skills、Plugins、MCP 服务器）。
适用场景：
- 新项目接入 Claude Code，想知道应该配置什么
- 项目发展后，重新评估 Claude Code 配置
示例调用：
用 claude-code-setup 分析项目并推荐自动化配置update-config
功能：管理 settings.json 配置文件。处理权限规则、环境变量、Hook 配置等所有 settings.json 相关的操作。
适用场景：
- 添加新的权限规则
- 设置环境变量
- 配置 Hook 或调试配置问题
示例调用：
用 update-config 添加对 pnpm 命令的 allow 权限fewer-permission-prompts
功能：扫描对话记录，识别常用的只读 Bash 和 MCP 工具调用，自动生成优先允许列表并添加到 settings.json，减少权限弹窗。
适用场景：
- 刚开始使用 Claude Code 时弹窗太多
- 希望自动分析并减少不必要的确认
示例调用：
用 fewer-permission-prompts 减少权限弹窗keybindings-help
功能：自定义键盘快捷键。支持按键重绑定、和弦快捷键（chord bindings）、修改 ~/.claude/keybindings.json。
适用场景：
- 想要自定义 Claude Code 的快捷键
- 习惯 Vim/Emacs 风格快捷键
示例调用：
用 keybindings-help 帮我设置 Ctrl+S 为提交快捷键17.2.5 其他内置 Skills
superpowers:requesting-code-review
功能：在完成任务、实现重要功能或合并之前，请求对工作进行全面验证。确保交付的代码符合要求。
示例调用：
功能做好了，用 superpowers:requesting-code-review 请求审查superpowers:receiving-code-review
功能：当收到代码审查反馈时，在采纳建议之前进行技术严谨性验证。特别适用于反馈看起来不清晰或技术上存疑的情况——要求技术严谨性和独立验证，而非表演性认同或盲目实现。
示例调用：
收到审查意见了，用 superpowers:receiving-code-review 分析这些反馈verify
功能：通过实际运行应用来验证代码变更是否真的有效。不仅仅是检查代码逻辑，而是确认运行时行为。
适用场景：
- 想确认 PR 的变更是否真的解决问题
- 测试一个修改是否在真实环境中生效
示例调用：
用 verify 确认这次修改在本地可以正常运行loop
功能：以固定间隔重复执行命令（如每 5 分钟检查部署状态）。适合需要持续监控的场景。
示例调用：
用 loop 每隔 5 分钟检查 CI 状态run
功能：启动并运行项目应用，验证变更在真实应用中的表现。会先查找是否有项目特定的启动 Skill，否则使用内置的项目类型检测来启动应用。
示例调用：
用 run 启动项目，确认新功能正常claude-api
功能：构建、调试和优化基于 Anthropic SDK 的应用。处理模型版本迁移（如 4.5 到 4.6）、prompt caching、thinking 模式等 API 层面的功能。
适用场景：
- 项目使用了
anthropic或@anthropic-ai/sdk - 需要添加或调优 prompt caching、tool use、batch 等 API 功能
- 模型版本升级迁移
示例调用：
用 claude-api 帮我给这个 SDK 调用添加 prompt cachingsuperpowers:using-superpowers
功能：Claude Code 会话的启动 Skill。建立如何查找和使用 Skills 的规范——要求在做出任何回复之前先调用 Skill 工具。这是所有 Superpowers 工作流的入口。
示例调用：
用 superpowers:using-superpowers 开始工作superpowers:writing-skills
功能：创建新 Skill、编辑已有 Skill、或在部署前验证 Skill 是否正常工作。这是构建和维护 Skill 生态的开发工具。
适用场景：
- 编写自定义 Skill
- 修改已有 Skill
- 验证 Skill 的有效性
示例调用：
用 superpowers:writing-skills 帮我写一个新的 Skill17.2.6 Skills 速查表
下表按使用频率整理，方便快速查阅：
| Skill | 命名空间 | 类型 | 一句话说明 |
|---|---|---|---|
| superpowers:brainstorming | superpowers | 开发流程 | 创造性工作前的需求分析 |
| superpowers:writing-plans | superpowers | 开发流程 | 设计规格转化为实现计划 |
| superpowers:executing-plans | superpowers | 开发流程 | 按计划分步执行+审查 |
| superpowers:subagent-driven-development | superpowers | 开发流程 | 独立任务的子Agent并行执行 |
| superpowers:test-driven-development | superpowers | 开发流程 | TDD：先写测试再实现 |
| superpowers:systematic-debugging | superpowers | 开发流程 | 系统化Bug排查方法论 |
| superpowers:verification-before-completion | superpowers | 开发流程 | 声称完成前强制验证 |
| superpowers:finishing-a-development-branch | superpowers | 开发流程 | 完成后的分支集成决策 |
| code-review:code-review | code-review | 代码质量 | 全面的代码审查 |
| security-review | — | 代码质量 | 安全漏洞扫描 |
| code-simplifier | — | 代码质量 | 简化和优化代码结构 |
| simplify | — | 代码质量 | 可复用性和效率检查 |
| commit-commands:commit | commit-commands | 项目管理 | 智能提交 |
| commit-commands:commit-push-pr | commit-commands | 项目管理 | 提交+推送+PR一键完成 |
| commit-commands:clean_gone | commit-commands | 项目管理 | 清理远程已删除的分支 |
| init | — | 配置 | 生成CLAUDE.md |
| claude-md-management:claude-md-improver | claude-md-management | 配置 | 审计改进CLAUDE.md |
| claude-code-setup | — | 配置 | 推荐项目自动化配置 |
| update-config | — | 配置 | 管理settings.json |
| fewer-permission-prompts | — | 配置 | 减少权限弹窗 |
17.3 自定义 Skill 编写
理解了社区 Skill 的运作方式后，下一步是学会编写自己的 Skill。
Skill 文件结构
一个 Skill 就是一个 Markdown 文件，包含 YAML 前置元数据（frontmatter）和 Markdown 正文（指令内容）：
---
name: my-custom-skill
description: 我的 React 组件创建流程
when_to_use: 当用户需要创建新的 React 组件时使用
---
## Instructions
When invoked, follow this workflow:
1. Ask the user what component they need and where it should live
2. Clarify props interface and state requirements
3. Generate the component file with TypeScript types and unit tests
4. Add the component to the barrel export (index.ts)
5. Verify the component renders correctly关键字段
| 字段 | 必填 | 说明 |
|---|---|---|
name | 是 | Skill 的唯一标识符。使用 namespace:skill-name 格式避免冲突 |
description | 是 | 简短描述 Skill 的功能，一行内完成 |
when_to_use | 推荐 | 明确说明在什么场景下使用这个 Skill，帮助 Claude 判断何时调用 |
| 正文 | 是 | 详细的指令内容，Claude 加载 Skill 后会严格遵循 |
Skill 命名规范
- 使用小写字母和短横线：
my-team:react-component-builder - 命名空间在前：
superpowers:brainstorming、code-review:code-review - 单段名称保留给全局通用 Skill：
init、security-review - 命名空间通常是你的团队名、组织名或功能领域
编写一个完整的示例 Skill
下面是一个更完整的自定义 Skill 示例，展示了一个 React 组件开发的完整工作流：
---
name: my-team:react-component
description: 按团队规范创建 React 组件及其测试和 Storybook 故事
when_to_use: 创建新的 React UI 组件或重构已有组件
---
## Instructions
你是一个遵循团队规范的 React 组件开发助手。
### 工作流程
1. **需求确认**
- 询问组件名称和用途
- 确认 props 接口（必填 vs 可选）
- 确认组件属于哪个模块（atoms / molecules / organisms）
2. **创建组件文件**
- 路径：`src/components/{module}/{ComponentName}/`
- 使用 TypeScript 严格模式
- 使用 FC 类型、明确的 props 类型定义
- 默认导出组件
3. **编写测试**
- 使用 vitest + @testing-library/react
- 覆盖：渲染测试、props 测试、交互测试、边界情况
- 测试文件命名：`{ComponentName}.test.tsx`
4. **编写 Storybook**
- 至少包含 Default、Loading、Error 三种状态
- 使用 CSF 3.0 格式
5. **导出**
- 在模块的 barrel export 中添加导出
- 组件和类型分别导出
### 代码风格
- 组件文件使用 PascalCase
- 不使用 default export（偏好 named export）
- 所有文本内容支持 i18n（使用 `useTranslation` hook）自定义 Skill 的存放位置
Skills 可以放在几个位置：
- 项目级 Skills：
.claude/skills/目录下。仅对当前项目生效，适合团队共享的开发规范。 - 用户级 Skills：
~/.claude/skills/目录下。对所有项目生效，适合个人工作流偏好。
项目目录/
├── .claude/
│ ├── settings.json
│ ├── skills/
│ │ └── my-team:react-component.md # 项目级 Skill
│ └── ...如何调用自定义 Skill
自定义 Skill 的调用方式和内置 Skill 完全一样：
帮我在 src/components/molecules/ 下创建一个 SearchBar 组件，用 my-team:react-componentClaude 会自动发现并加载你的 Skill 文件。
也可以用 superpowers:writing-skills 来辅助编写和验证 Skill：
用 superpowers:writing-skills 帮我写一个数据库迁移的 Skill17.4 组织个人 Skill 库
随着你使用的 Skill 越来越多，有意识地组织自己的 Skill 库会让你事半功倍。
按开发阶段分类
推荐的分类方式是按开发工作流的阶段来组织：
创建个人"常用 Skills"清单
不需要每种 Skill 都用到——根据你的日常开发场景，梳理出最常用的几个：
前端开发者：
superpowers:brainstorming— 设计新组件时superpowers:writing-plans— 大功能拆分时superpowers:subagent-driven-development— 并行开发多个组件code-review:code-review— 提交前审查superpowers:verification-before-completion— 声称完成时
后端/工具库开发者：
superpowers:brainstorming— API 设计时superpowers:test-driven-development— 实现核心逻辑superpowers:systematic-debugging— Bug 排查security-review— 安全审查commit-commands:commit-push-pr— 提交和发布
DevOps/基础设施：
init— 新项目初始化claude-md-management:claude-md-improver— 维护项目文档security-review— 配置变更的安全审查fewer-permission-prompts— 优化权限配置
什么时候写 Skill，什么时候写提示词
| 场景 | 建议 |
|---|---|
| 一次性任务 | 直接写提示词 |
| 重复 3 次以上的同类任务 | 值得写一个 Skill |
| 团队需要共享的开发规范 | 必须写 Skill |
| 复杂的多步骤工作流 | 写 Skill（即使只用一次，Skill 结构也能确保不遗漏步骤） |
| 简单的单步操作 | 适合写成 Slash Command（第 19 章） |
判断标准：如果你发现自己在重复说同样的话给 Claude——那就是一个 Skill 的信号。
团队共享 Skills
项目级的 Skill 文件放在 .claude/skills/ 下，可以通过 Git 随项目一起分发。这样团队新成员 clone 项目后，Claude Code 自动获得项目标准的开发规范。
建议在项目 README 或 CLAUDE.md 中注明项目有哪些自定义 Skill：
## 项目 Skills
在 `.claude/skills/` 下定义了以下项目专用 Skills：
- `my-team:react-component` — 按团队规范创建 React 组件
- `my-team:api-endpoint` — 按团队规范创建 API 端点
- `my-team:db-migration` — 数据库迁移脚本生成
运行 Claude Code 后，直接告诉 Claude 使用对应 Skill 即可。Skill 发现：持续扩展你的工具库
Skill 生态在快速发展，建议定期关注：
- Superpowers Marketplace：通过 Plugin 安装的 Skill 注册中心
- 社区推荐：Reddit、Discord、Twitter/X 上的 Claude Code 社区
- Claude Code 更新日志：新版本通常会包含新的内置 Skills
- 观察 Claude 的系统提示：启动 Claude Code 时显示的可用 Skills 列表是最完整的参考
17.5 Skills 最佳实践
经过社区的大量实践，以下七条原则经过了广泛验证。
1. 先理解再调用
在调用 Skill 之前，先阅读它的描述和 when_to_use 说明。确保这个 Skill 真的适合你当前的场景。错误的 Skill 调用不仅浪费时间，还可能把工作流引向错误的方向。
# 好：先理解
> 查看 superpowers:brainstorming 是做什么的
> 确认我的场景是"新功能设计"，匹配 → 调用
# 不好：盲目调用
> 用 superpowers:brainstorming 修这个 typo
（brainstorming 用于需求分析，修 typo 根本不需要任何 Skill）2. 按流程使用开发三件套
对于任何非 trivial 的功能开发，遵循这个流程：
brainstorming → writing-plans → executing-plans不要跳过 brainstorming 直接写代码——那是"先射箭再画靶子"。社区数据表明，使用完整三步流程的返工率比直接实现低约 80%。
3. 不要跳过 Skill 的系统提醒
当 Claude 的系统提示中列出了 Skill，并且声明了 "You MUST use this before..." 时，这不是建议而是要求。这些提醒的存在经过了大量工程实践验证——跳过它们意味着跳过最佳实践。
如果你确实不需要某个 Skill，明确告诉 Claude 原因：
这个改动很小，不需要 brainstorming，直接改就行4. TDD 适合后端和工具库
superpowers:test-driven-development 在以下场景效果最好：
- 函数库和工具方法（输入输出明确）
- API 接口（请求响应可预测）
- 数据转换逻辑（输入数据→输出数据）
在以下场景效果有限：
- UI 布局调整（视觉效果难以自动化断言）
- 快速原型开发（需求还在变化）
- 一次性脚本（用完就扔）
5. Review 不可省
无论功能多小，在合并之前使用 code-review:code-review 做一次全面的代码审查。自己写的代码自己很难发现所有问题——这就是 review 存在的原因。
# 最小化但完整的提交工作流
1. 实现功能
2. code-review:code-review（审查变更）
3. superpowers:verification-before-completion（验证通过）
4. commit-commands:commit-push-pr（提交并创建 PR）6. 验证再声称完成
人类和 AI 都容易犯的一个错误是：代码写完了就以为功能正确了。superpowers:verification-before-completion 强制你在声称"做完了"之前运行验证命令。
在任何声称完成之前，至少做以下之一：
- 运行相关的测试套件
- 在本地启动应用确认行为
- 运行
verifySkill
7. 组合使用，形成完整工作流
Skills 的价值在组合使用中最大化。以下是一个完整的开发工作流示例：
这个流程看起来很长，但每个环节都有明确的价值。实际使用中，并非每个项目都要走完所有步骤——根据项目规模和风险来选择。
17.6 本章小结
本章全面介绍了 Claude Code 的 Skills 系统。以下是核心要点：
Skill 是可复用的指令模板：本质是 Markdown 文件，指导 Claude 如何完成特定类型的任务。Skill 是"方法论"，Plugin 是"新工具"，两者互补而非替代。
Superpowers 是最重要的 Skill 套件：覆盖了从头脑风暴到分支集成的完整开发流程。核心的三步流程（brainstorming → writing-plans → executing-plans）能减少约 80% 的返工。
Skill 生态系统覆盖开发全流程：开发流程类（brainstorming、TDD、systematic-debugging 等）、代码质量类（code-review、security-review、simplify 等）、项目管理类（commit、clean_gone 等）、配置自动化类（init、claude-md-improver、update-config 等）。
编写自定义 Skill 很简单：一个 Markdown 文件 + YAML frontmatter，放在
.claude/skills/下即可。关键是写清楚description和when_to_use，让 Claude 知道何时调用。组织 Skill 库提高效率：按开发阶段分类（构思 → 计划 → 开发 → 质量 → 交付），根据角色场景挑选常用 Skill，通过 Git 与团队共享项目级 Skill。
七条最佳实践：先理解再调用、按流程使用三步法、不要跳过系统提醒、TDD 场景选择、Review 不可省、验证再声称完成、组合使用形成完整工作流。
Skills 系统是 Claude Code 从"工具"进化为"工作伙伴"的关键——它让 Claude 不仅仅是执行命令，而是按照经过验证的专业方法论来工作。在下一章，我们将学习 Hooks（钩子系统），它让你可以在 Claude Code 的各个生命周期节点插入自动化操作，与 Skills 形成强大的组合。