Skills 已经成为 Claude Code 中最常用的扩展点之一。它们灵活、易于创建，也便于分发。
但这种灵活性也带来了另一个问题：很难判断什么才是最有效的做法。什么类型的 skill 值得做？写好一个 skill 的秘诀是什么？又该在什么时机分享给别人？
在 Anthropic，我们已经在 Claude Code 里大规模使用 skills，活跃使用中的有数百个。下面是我们在使用 skills 加速开发过程中总结出的经验。
什么是 Skills？
如果你刚接触 skills，我建议先看一下官方文档，或者观看我们最新的 Skilljar Agent Skills 课程。本文默认你已经对 skills 有一定了解。
我们经常听到一个关于 skills 的误解：它们“只是 markdown 文件”。但 skills 最有趣的地方，恰恰在于它们不只是文本文件。它们是文件夹，可以包含脚本、资源、数据等，agent 能发现、探索并操作这些内容。
在 Claude Code 中，skills 还有丰富的配置选项，包括注册动态 hooks。
我们发现，Claude Code 里最有意思的一些 skills，正是创造性地利用了这些配置选项和文件夹结构。
Skills 的类型
在梳理所有 skills 后，我们发现它们通常会聚类到几个反复出现的类别里。最好的 skill 往往能清晰归入某一类；更容易让人困惑的 skill 往往跨了好几类。这不是一个“唯一正确”的分类清单，但它很适合拿来思考你的组织里是否遗漏了某些能力。
1. 库与 API 参考
这类 skill 用来说明如何正确使用某个库、CLI 或 SDK。既可以面向内部库，也可以面向 Claude Code 偶尔会用不好的常见库。这类 skill 往往会附带参考代码片段目录，以及一份 Claude 在写脚本时要避免的坑点清单。
示例：
- billing-lib —— 你的内部计费库：边界情况、易踩坑点等
- internal-platform-cli —— 你的内部 CLI 封装里每个子命令的说明，以及何时使用的示例
- frontend-design —— 让 Claude 更好地遵循你的设计系统
2. 产品验证
这类 skill 用来描述如何测试或验证代码是否正常工作。它们通常会搭配 playwright、tmux 等外部工具来完成验证。
验证类 skill 对确保 Claude 输出正确非常有价值。让一位工程师花一周时间专门把验证类 skills 打磨到优秀，通常很值得。
可以考虑一些技巧，比如让 Claude 录制自己输出结果的视频，便于你精确看到它测了什么；或者在每一步对状态施加强制的程序化断言。这通常通过在 skill 中加入各类脚本来实现。
示例：
- signup-flow-driver —— 在无头浏览器里跑通 signup → email verify → onboarding，并在每一步通过 hooks 断言状态
- checkout-verifier —— 用 Stripe 测试卡驱动结账 UI，验证发票是否真的落在正确状态
- tmux-cli-driver —— 用于交互式 CLI 测试，适合被验证对象需要 TTY 的场景
3. 数据获取与分析
这类 skill 用于连接你的数据与监控体系。它们可能包含带凭据的数据获取库、特定 dashboard id，以及常见工作流或取数方式的说明。
示例：
- funnel-query —— “要看 signup → activation → paid，需要关联哪些事件”，以及真正存放 canonical user_id 的那张表
- cohort-compare —— 对比两个 cohort 的留存或转化，标记统计显著的差异，并链接到 segment 定义
- grafana —— datasource UID、集群名、问题 → dashboard 的映射表
4. 业务流程与团队自动化
这类 skill 把重复性流程自动化成一条命令。它们通常是相对简单的指令，但可能依赖其他 skills 或 MCP。对于这类 skill，把历史结果写入日志文件，能帮助模型保持一致性，并回顾此前执行过的流程。
示例：
- standup-post —— 聚合工单系统、GitHub 活动、过往 Slack 内容，输出格式化 standup，仅展示增量
- create-
-ticket —— 强制工单 schema（有效枚举值、必填字段），并执行建单后的流程（@ reviewer、在 Slack 贴链接） - weekly-recap —— 合并的 PR + 已关闭工单 + 部署记录 → 格式化周报
5. 代码脚手架与模板
这类 skill 为代码库中特定功能生成框架样板。你可以把它们和可组合的脚本配合使用。特别是当你的脚手架需求包含纯代码难以覆盖的自然语言约束时，它们会非常有用。
示例：
- new-
-workflow —— 按你的注解规范为新 service/workflow/handler 生成脚手架 - new-migration —— 你的 migration 文件模板及常见坑点
- create-app —— 创建带有预接线 auth、logging、deploy 配置的新内部应用
6. 代码质量与评审
这类 skill 用于在组织内部落实代码质量并辅助评审。它们可以包含确定性的脚本或工具，以获得更高稳健性。你也可以把这些 skill 自动运行在 hooks 或 GitHub Action 中。
- adversarial-review —— 拉起“新鲜视角”子 agent 做批判性评审，实施修复并迭代，直到问题退化为吹毛求疵
- code-style —— 强制代码风格，尤其是 Claude 默认做得不好的风格约束
- testing-practices —— 如何写测试、该测什么的指导
7. CI/CD 与部署
这类 skill 帮助你在代码库内拉取、提交与部署代码。它们可能会引用其他 skill 来收集数据。
示例：
- babysit-pr —— 监控 PR → 重试 flaky CI → 解决合并冲突 → 打开 auto-merge
- deploy-
—— build → smoke test → 渐进式流量发布并比较错误率 → 回归时自动回滚 - cherry-pick-prod —— 隔离 worktree → cherry-pick → 解决冲突 → 用模板创建 PR
8. Runbook
这类 skill 从某个症状出发（如 Slack 线程、告警或错误特征），走完多工具排查流程，并产出结构化报告。
示例：
-debugging —— 为高流量服务建立“症状 → 工具 → 查询模式”映射 - oncall-runner —— 拉取告警 → 检查常见嫌疑项 → 输出结论
- log-correlator —— 给定 request ID，从所有可能触达该请求的系统里拉取匹配日志
9. 基础设施运维
这类 skill 用于执行常规维护和运维流程，其中有些可能涉及破坏性操作，因此需要护栏。它们能让工程师在关键操作中更容易遵循最佳实践。
示例：
-orphans —— 查找孤儿 pods/volumes → 发到 Slack → 观察期 → 用户确认 → 级联清理 - dependency-management —— 你们组织的依赖审批流程
- cost-investigation —— “为什么存储/出口账单突然上涨了”，并附上具体 bucket 和查询模式 Skills 编写技巧
确定要做哪个 skill 后，具体该怎么写？以下是我们总结的一些最佳实践、技巧和窍门。
我们最近还发布了 Skill Creator，让在 Claude Code 中创建 skills 更容易。
不要陈述显而易见的事
Claude Code 对你的代码库已有很多认知，Claude 本身对编码也有很多默认“偏好”。如果你要发布的是知识型 skill，重点应该放在能把 Claude 从常规思路中“推出来”的信息。
frontend design skill 是个很好的例子——它由 Anthropic 一位工程师在与客户反复迭代中构建，目标是提升 Claude 的设计品味，避免 Inter 字体和紫色渐变这类经典套路。
建立 Gotchas（坑点）章节
任何 skill 里信号密度最高的内容，通常就是 Gotchas 章节。这些章节应从 Claude 使用该 skill 时的常见失败点逐步沉淀而来。理想情况下，你会随着时间不断更新 skill，把新出现的坑补进去。
利用文件系统与渐进式披露
正如前面所说，skill 是一个文件夹，而不只是 markdown 文件。你可以把整个文件系统都当作上下文工程与渐进式披露的一部分。告诉 Claude 你的 skill 里有哪些文件，它会在合适的时候读取它们。
渐进式披露最简单的形式，是把 Claude 引导到其他 markdown 文件。例如，你可以把详细函数签名与使用示例拆到 references/api.md。
再比如：如果最终输出是一个 markdown 文件，你可以在 assets/ 里放一个模板文件供复制使用。
你可以准备 references、scripts、examples 等目录，帮助 Claude 更高效地工作。
避免把 Claude 绑死在流程里
Claude 通常会尽量遵循你的指令。由于 skill 的可复用性很强，你要小心指令过于具体。给 Claude 足够的信息即可，也要给它根据实际情况调整的空间。比如：
把初始化流程想清楚
某些 skill 可能需要从用户那里获取上下文才能完成初始化。比如你在做一个把 standup 发到 Slack 的 skill，就可能需要 Claude 先询问要发到哪个 Slack channel。
一个常见好模式是把这类初始化信息存到 skill 目录里的 config.json（如上例）。如果配置还没准备好，agent 就可以向用户发问补齐信息。
如果你希望 agent 以结构化的多选问题方式提问，可以指示 Claude 使用 AskUserQuestion 工具。
Description 字段是写给模型看的
Claude Code 启动会话时，会构建一个包含所有可用 skill 及其 description 的列表。Claude 正是扫描这个列表来判断“这个请求是否有对应 skill”。这意味着 description 字段不是摘要，而是“这个 PR 在什么情况下应触发”的说明。
Memory 与数据存储
某些 skill 可以通过在目录内存数据来实现某种“记忆”。这可以简单到追加文本日志或 JSON 文件，也可以复杂到 SQLite 数据库。
例如，standup-post skill 可以维护一个 standups.log，记录每次生成的内容。这样下次运行时，Claude 能读取自己的历史，判断相对昨天有哪些变化。
存放在 skill 目录里的数据，在升级 skill 时可能被删除。因此建议放到稳定目录；截至目前，我们提供 ${CLAUDE_PLUGIN_DATA} 作为每个 plugin 的稳定数据目录。
存脚本，让 Claude 生成代码
你能给 Claude 的最强工具之一就是代码本身。提供脚本与库后，Claude 可以把轮次更多花在“组合与决策下一步”，而不是重复拼装样板代码。
例如，在你的数据科学 skill 里，你可以提供一套从事件源拉取数据的函数库。为了让 Claude 做复杂分析，可以给它类似下面的一组 helper 函数：
这样，Claude 就能在运行时动态生成脚本，组合这些能力，去回答类似“周二发生了什么？”的更高级分析请求。
按需 Hooks
skill 可以包含仅在被调用时激活、并持续整个会话的 hooks。对于那些“平时不该一直开，但在特定场景极其有用”的强约束 hooks，这很适合。
例如：
- /careful —— 通过 Bash 的 PreToolUse matcher 阻止 rm -rf、DROP TABLE、force-push、kubectl delete。你只会在明确操作生产环境时才想开它——一直开会把人逼疯
- /freeze —— 阻止任何不在指定目录内的 Edit/Write。很适合
- 调试时：“我想加日志，但总是手滑‘修复’了不相关内容” 分发 Skills
Skills 的一大优势是可以与团队共享。
你有两种方式把 skill 分享给他人：
- 把 skill 提交到你的 repo（放在 ./.claude/skills）
- 做成 plugin，并建设 Claude Code Plugin marketplace，让用户上传和安装插件（更多见文档） 对于跨 repo 数量不多的小团队，把 skills 直接放进 repo 往往就够用了。但每个提交进 repo 的 skill 都会给模型上下文增加一点负担。规模变大后，内部 plugin marketplace 能帮助你分发 skills，并让团队自行决定安装哪些。
管理 Marketplace
如何决定哪些 skill 放进 marketplace？大家又如何提交？
我们没有一个集中团队来统一拍板；我们更倾向于让最有价值的 skill 自然涌现。如果你有一个想让大家试用的 skill，可以先传到 GitHub 的 sandbox 目录，再在 Slack 或其他渠道分享。
当一个 skill 获得一定采用（阈值由 skill owner 自定）后，再提 PR 把它移入 marketplace。
也提醒一句：做出“差”或“重复”的 skill 非常容易，所以在发布前确保有一定的策展/筛选机制很重要。
组合 Skills
你可能需要让 skills 相互依赖。比如有一个文件上传 skill 负责上传文件，另一个 CSV 生成 skill 负责生成 CSV 再上传。此类依赖管理目前在 marketplace 或 skills 里还没有原生支持，但你可以直接通过名称引用其他 skill；只要已安装，模型就会调用它们。
衡量 Skills 效果
为了理解 skill 的表现，我们使用 PreToolUse hook 来记录公司内部的 skill 使用情况（示例代码见此）。这样我们就能识别哪些 skill 很受欢迎，或哪些 skill 相比预期触发不足。
结语
Skills 是 agent 的强大且灵活的工具，但这个领域仍很早期，我们都还在摸索最佳实践。
与其把本文当成定论，不如把它看作一组经过验证、可直接拿来试的经验。理解 skills 最好的方式，就是马上动手、持续实验，观察哪些方法对你有效。我们的大多数 skill 也都是从几行内容和一个 gotcha 起步，然后随着 Claude 遇到新边界情况，被持续补充和打磨出来的。
希望这篇内容有帮助，如果你有任何问题，欢迎告诉我。