Claude Code 技能系统：把你的工作流知识变成代理能力

使用 AI 编码助手最贵的部分，是一遍遍解释同样的上下文。

你的代码库有规范，CI 流程有特殊之处，部署流程有一些从代码里看不出来的步骤。每次会话你都要解释其中一部分，每次会话代理从零开始，因为会话结束之后，这一切就消失了。

Claude Code 的技能系统解决这件事：把代理需要知道的东西写下来一次，之后自动生效。

技能就是一个文件，没有任何魔法

技能是一个带有 SKILL.md 文件的目录。YAML 前置数据告诉 Claude 这个技能叫什么、什么时候用、谁能调用；Markdown 正文是具体指令。

最简单的例子：

---
name: fix-issue
description: 修复 GitHub issue。被要求修 bug 或实现 issue 功能时使用。
---

按照我们的代码规范修复 GitHub issue $ARGUMENTS。

1. 先读 issue 描述，动代码之前搞清楚背景
2. 找相关文件，先看测试来理解预期行为
3. 用能解决问题的最小改动来实现修复
4. 写一个能提前发现这个 bug 的测试
5. 按 conventional commit 格式提交

存到 ~/.claude/skills/fix-issue/SKILL.md 就完成了。之后你说"修复 issue 247"，Claude 考虑这个技能是否适用；也可以用 /fix-issue 247 直接调用。

这套指令从此成为所有相关对话的一部分，不需要每次重新粘贴。

三种触发模式，应对不同场景

Claude 自动判断是默认行为，适合背景知识类技能：API 规范、测试风格指南、只要相关对话开始就应该生效的那些。

只有你显式调用才跑：在前置数据里加 disable-model-invocation: true。对部署、提交、有副作用的操作应该这样设置，避免代理在不该的时候自动触发。

始终在后台生效，但不出现在命令菜单：user-invocable: false。适合应该持续影响代理行为（比如公司写作风格指南）但不需要被显式调用的上下文。

写技能的时候，真正要回答的问题：这个技能应该自动运行、按需运行，还是一直在后台起作用？

context: fork：让代理并行工作，你的对话不被打断

技能加上 context: fork，就在独立的子代理里运行，你的会话继续，子代理在后台处理任务，互不干扰。

Claude Code 自带三个展示这个模式的内置技能：

/simplify 审查最近改动并清理。它并行启动三个审查代理：一个检查代码复用，一个检查质量，一个检查性能，各自独立运行，返回结果，Claude 综合后应用改动。

/batch 接受大任务描述，拆成独立单元，每个单元给一个代理在独立 git 工作树里并行跑，各自产出独立 PR。一个巨大的顺序改动变成多个可以独立审查的并行改动。

/loop 在会话开着时按间隔重复跑一个提示：每五分钟检查一次部署，等某个测试变绿，轮询 API 状态变化。

这三个都是普通技能文件，写法和你自己写的完全一样，可以看源码、fork、改、参考来做类似的事。

动态注入：技能让代理在工作开始时就有真实数据

技能文件里的 !command 语法，在 Claude 看到指令之前先执行 shell 命令，把输出插入提示词。

PR 审查技能注入实际的 diff，让指令和被审查的代码同时到达。部署技能注入当前环境状态。调试技能注入最近的日志行。代理拿到的是真实的当前信息，可以直接开始工作。

技能存在哪里，谁能用

~/.claude/skills/ 下的技能对你所有项目有效，.claude/skills/ 放在项目根目录里只对这个项目有效，企业部署可以通过托管配置统一推给所有人。同名技能存在多个层级时，项目级覆盖个人级，企业级覆盖所有。

在 monorepo 里，Claude Code 向上遍历目录树找技能：编辑 packages/api/src/ 里的文件时，它会找 packages/api/.claude/skills/、packages/.claude/skills/ 和根目录的 .claude/skills/，子包可以有自己的技能，不需要改全局配置。

技能把工作流知识沉淀成代理的持续能力

写下一个关于项目部署流程的技能，捕捉的是原本只存在于某人脑子里或入职文档里没人看的那种知识。新成员拉代码就能用到这套知识，代理在代码库里做的判断和有经验的开发者一样，不需要额外告知，技能随项目成长，和代码一起做版本控制。

大多数开发者把 AI 助手当成一个需要不断解释上下文的工具。技能把这个关系翻过来：解释一次，解释清楚，代理从这里持续工作，知识每次都在上一次的基础上推进。