什么是 Skill

在与大模型协作的语境中，Skill（技能）本质上是一段被工程化封装的提示词（prompt）。它的主体仍然是自然语言指令——通常以一个 Markdown 文件（SKILL.md）的形式存在——描述"在某类任务中应当如何行事"。但与随手写下、用完即弃的临时提示词不同，Skill 在这段指令之外附加了三层结构，使其从"一次性的表达"升级为"可沉淀、可复用的能力单元"。

一、可路由的触发机制

每个 Skill 在文件头部（frontmatter）声明一段 description，用以说明"此技能适用于何种场景"。这段描述并非给人看的注释，而是模型进行任务路由的依据：只有当用户的意图与描述相匹配时，Skill 的正文才会被加载进模型的上下文。

这带来一个关键区别。若将所有约定统统写入常驻的全局配置（如 CLAUDE.md），它们会持续占用有限的上下文窗口，无论当前任务是否相关；而 Skill 采用**按需加载（progressive disclosure）**的策略——平时不占用上下文，命中场景时才被"导入"。这与软件工程中"惰性加载模块"的思想一致。

二、可复用与可版本化

Skill 以文件形式独立存在，因而天然具备工程化资产的属性：它可以纳入版本控制、随代码库在团队间共享、通过名称被显式调用（如 /new-dashboard）。一次性提示词的价值随对话结束而消散，Skill 则将某类任务的最佳实践固化下来，使其可被反复调用、持续演进。

三、可捆绑依赖资源

Skill 承载的不止是文本指令。在其目录下,还可以附带模板文件、示例代码乃至可执行脚本,并在真正需要时才被读取。换言之,一个 Skill 可以是"指令 + 资源"的完整封装,而非孤立的一段话。

一个类比

若以工程师熟悉的概念作比:随手写的提示词，如同每次都手写一段 SQL；而 Skill，则像是将其固化为一个存储过程。 其中，description 相当于函数签名——决定它在何时被调用；正文相当于函数体——定义具体行为；附带的资源，则相当于它所引用的表与依赖。

因此,一句话概括:Skill 是一段带有触发条件、可复用、并可携带依赖的提示词。 它的内核仍是提示工程,但通过路由、复用与封装三重机制,让"如何做好一类任务"的知识,从个人的临场表达,变成了可积累、可传承的团队资产。

name: commit-msg
description: 生成符合团队规范的 Git 提交信息。当用户要求"写 commit / 生成提交信息 / 帮我提交"时使用。

生成 Git 提交信息

按以下规范撰写提交信息：

1. 首行格式：<类型>: <简述>，不超过 50 字。
   类型取值：feat / fix / docs / refactor / test / chore。
2. 首行只说"做了什么"，空一行后再用要点说明"为什么"。
3. 使用祈使语气（“新增"而非"新增了”）。

示例：

feat: 新增标签使用看板

- 用户需要按周查看标签调用量的分布
- 数据口径对齐 ads 层日更分区

结构上只有两部分：

• frontmatter（— 之间）：name 是调用标识，description 是路由依据——模型据此判断"何时该加载这段技能"。这是 Skill 区别于普通文本的关键。
• 正文：即真正注入上下文的提示词，描述"如何完成这类任务"。

将它保存为 .claude/skills/commit-msg/SKILL.md，此后当你说"帮我写个提交信息"，这段指令便会被自动调用；也可通过 /commit-msg 显式触发。一个仅十余行的文件，就把"如何写好提交信息"这一约定，固化成了可复用、可共享的能力单元。