Claude Code Skills 实战:从选装到自定义的完整指南

上周我在用 Claude Code 重构一个 React 项目,随口说了句"帮我审查一下这个组件"。Claude 没有像往常一样给我一段泛泛的建议,而是按照一份详细的检查清单,逐项扫了 props 类型、渲染性能、可访问性,最后给出了三个具体的重构建议。

区别在哪?我装了一个叫 frontend-code-review 的 Skill。

Skills 是 Anthropic 在 2025 年 10 月给 Claude Code 加的能力系统。简单说,就是一份 SKILL.md 文件,里面定义了某个领域的专业知识和操作流程。装好之后,Claude 会根据对话上下文自动判断要不要用——你不需要输入任何命令。

这篇文章不是又一份排行榜。我会从机制讲起,帮你搞清楚 Skills 到底怎么工作,然后告诉你哪些值得装、怎么装,最后教你写一个自己的 Skill。

Skills 的运行机制:为什么它比 Slash Commands 好用

先厘清一个常见的混淆:Skills 和 Slash Commands 不是一回事。

对比项Slash CommandsSkills
触发方式手动输入 /commitClaude 自动识别上下文
定义位置.claude/commands/.claude/skills/~/.claude/skills/
适用场景固定流程、一键执行领域知识、判断型任务
灵活度低,参数固定高,Claude 自行决定何时使用

Slash Commands 像快捷键,Skills 像肌肉记忆。你不会每次骑自行车都在脑子里默念"左脚踩、右脚踩",Skills 就是这个效果——Claude 内化了某个领域的专业能力,需要的时候自动调用。

一个 SKILL.md 文件的核心结构很简单:

# Skill 名称

## 触发条件
描述什么场景下应该激活这个 Skill

## 操作流程
1. 第一步做什么
2. 第二步做什么

## 检查清单
- [ ] 检查项 1
- [ ] 检查项 2

## 参考资料
相关文档链接

Claude 读到这个文件后,会把里面的知识融入自己的决策过程。当对话内容匹配触发条件时,它会按照操作流程执行,用检查清单做质量把关。

哪些 Skills 值得装:按场景推荐

GitHub 上的 Skills 生态已经有上百个项目了。我筛了一圈,按实际使用场景分成四类,每类推荐最值得装的。

日常开发工作流

这类 Skills 解决的是每天都会碰到的事:提 PR、审代码、重构组件。

create-pr 是目前社区热度最高的 Skill(GitHub 169k+ Stars)。它做的事情不复杂但很实用:自动创建 GitHub PR,格式化标题和描述,跑 CI 校验。省掉的是你每次手动填 PR 模板、检查 CI 状态的时间。

frontend-code-review 专门针对前端项目(tsx/ts/js),内置了一套检查清单。我用下来的感受是,它比通用的代码审查更懂前端的坑——比如它会检查 useEffect 的依赖数组、组件是否有不必要的重渲染。

component-refactoring 是 React 组件重构专用。当你的组件超过 300 行,或者 props 传了五六层,跟 Claude 说"帮我拆一下这个组件",它会按照安全重构的步骤来:先提取子组件,再调整 props 接口,最后验证功能不变。

AI 和 LLM 应用开发

如果你在做 AI 相关的项目,这几个能帮上忙。

cache-components-expert(137k+ Stars)解决的是 LLM 应用的缓存策略问题。调 API 贵,响应慢,合理的缓存能省不少钱。这个 Skill 会根据你的代码结构,建议哪些请求该缓存、用什么缓存策略、TTL 设多少。

context-engineeringmulti-agent-patterns 热度不算高(各 5.5k Stars),但内容质量不错。前者帮你优化 Prompt 设计,后者提供多 Agent 协作的架构模式。如果你在设计复杂的 AI 系统,这两个值得看看。

方法论类

obra/superpowers 是个有意思的项目。它在 2026 年 1 月冲上了 GitHub Trending 榜首,单日涨了 1800+ Stars。

它不是教 Claude 某个具体技术,而是教它一套开发方法论:强制 TDD(先写测试再写代码)、YAGNI(不写用不到的代码)、DRY(不重复自己)。装了之后,Claude 不会上来就写代码,而是先问你"你到底想实现什么?"然后按红-绿-重构的 TDD 流程走。

有开发者反馈说,用了 Superpowers 之后 Claude 可以自主编程两小时以上不跑偏。这个说法我没法验证,但我自己的体验是:它确实让 Claude 的输出更有章法,不会东一榔头西一棒子。

平台专用类

cloudflare-skill 把整个 Cloudflare 平台(60+ 产品)的知识打包成了一个 SKILL.md。Workers 还是 Pages?Durable Objects 还是 Workflows?Bindings 怎么配?这些问题它都能答。如果你是 Cloudflare 重度用户,这个 Skill 能省掉大量翻文档的时间。

electron-chromium-upgrade(119k+ Stars)专门处理 Electron 应用的 Chromium 版本升级。做过 Electron 开发的都知道,升级 Chromium 是个苦差事,这个 Skill 把迁移步骤和常见坑都整理好了。

三种安装方式

Skills 的安装方式取决于它的发布形态。

方式一:Plugin 安装(技能集合包)

Superpowers、awesome-claude-skills 这类包含多个 Skills 的项目,以 Plugin 形式发布:

claude /install-plugin obra/superpowers

一条命令搞定,所有子 Skills 自动就位。

方式二:手动复制 SKILL.md

单个 Skill 文件,直接复制到对应目录:

# 项目级(仅当前项目可用)
mkdir -p your-project/.claude/skills/
cp skill-name/SKILL.md your-project/.claude/skills/skill-name/

# 个人级(所有项目可用)
mkdir -p ~/.claude/skills/
cp skill-name/SKILL.md ~/.claude/skills/skill-name/

项目级和个人级的区别:项目级的 Skill 只在当前项目生效,适合团队统一规范;个人级的全局可用,适合你自己的通用习惯。

方式三:SkillPort(第三方包管理器)

pip install skillport
skillport search code-review
skillport install skill-name

SkillPort 还比较新(229 Stars),但思路是对的——给 Skills 做一个类似 npm 的包管理器。

写一个自己的 Skill

社区的 Skills 覆盖不了所有场景。比如你团队有自己的代码规范、特定的部署流程、或者某个内部框架的使用约定——这些只能自己写。

一个实用的 SKILL.md 不需要很长。以"Git 提交规范"为例:

# Git Commit Convention

## 触发条件
当用户要求提交代码、创建 commit 时激活。

## 提交格式
类型(范围): 简短描述

类型必须是以下之一:
- feat: 新功能
- fix: 修复 bug
- refactor: 重构(不改功能)
- docs: 文档变更
- test: 测试相关
- chore: 构建/工具变更

## 规则
1. 标题不超过 50 字符
2. 正文每行不超过 72 字符
3. 用中文写描述,类型用英文
4. 如果改动涉及多个模块,拆成多个 commit

## 示例
feat(auth): 添加 OAuth2 登录支持
fix(api): 修复分页参数未校验的问题

写好后放到 .claude/skills/git-convention/SKILL.md,下次你说"帮我提交一下",Claude 就会按这个规范来。

写 Skill 的几个要点:

  • 触发条件要具体,别写"当用户需要帮助时"这种废话
  • 操作流程按步骤写,Claude 是按顺序执行的
  • 加上反面示例(什么不该做),比正面示例更有效
  • 保持精简,一个 Skill 只解决一个问题

如果你想系统地学写 Skill,社区有两个工具可以帮忙:skill-writer(96k Stars)帮你生成高质量的 SKILL.md 模板,skill-creator(38.5k Stars)提供从零开始的创建向导。

我的装机清单

如果你刚开始用 Claude Code Skills,不用全装,按需来:

你的需求推荐安装
先把基础搞好anthropics/skills(官方文档处理套件)
日常开发提效create-pr + frontend-code-review
想让 Claude 更靠谱obra/superpowers
做 AI/LLM 项目cache-components-expert
找更多 Skillsskill-lookup 或逛 awesome-claude-skills
写自己的 Skillskill-writer

Skills 生态还在早期,每周都有新项目冒出来。与其追热度,不如想清楚自己的工作流里哪个环节最痛,然后找(或写)一个 Skill 来解决它。工具的价值不在于装了多少,在于用对了几个。