👆 上下滑动阅读 · 左右滑动翻页 · 键盘方向键同理
🛠️
Claude Skills
完整构建指南Anthropic 官方手册 · 注释版
一个 SKILL.md 文件 · 三层渐进披露 · 让 Claude 按你的工作流办事
—— Anthropic 团队的 32 页官方权威指南，从零开始构建你的第一个 Skill
resources.anthropic.com · 2026 年 1 月 26 日发布
含 52 个术语注释 + 6 个原理过程解析
蓝色虚线 = 技术工具（点击查看解释）
绿色虚线 = 产品/平台
橙色虚线 = 概念/方法论
紫色虚线 = AI模型
点击带虚线下划线的术语查看注释
什么是 Skill
WHAT IS A SKILL · CHAPTER 1 FUNDAMENTALS
本页要点
一个 Skill 本质上就是一个文件夹——里面装着教 Claude 如何处理特定任务或工作流的指令集。它让你只需要教 Claude 一次，之后每次对话都能直接受益，而不必反复在每个会话里解释你的偏好、流程和领域知识。
Anthropic
Skill 是一个文件夹，包含：
• SKILL.md（必需）：带 YAML frontmatter 的 Markdown 指令
• scripts/（可选）：Python、Bash 等可执行代码
• references/（可选）：按需加载的文档
• assets/（可选）：模板、字体、图标等输出物
编辑注
这个定义里最重要的不是「文件夹」，而是「教一次、永远受益」。Skill 是 Anthropic 给「重复性工作流」开出的标准答案——当你发现自己在多个会话里反复粘贴相同的偏好或流程时，就该把它沉淀成一个 Skill。它和 MCP 的关系是：MCP 给 Claude 工具访问权限，Skill 教 Claude 怎么用这些工具。
核心设计原则：渐进披露
PROGRESSIVE DISCLOSURE
本页要点
Skill 用三层加载机制最小化 token 消耗，同时保留特化能力：YAML 元信息常驻系统提示、SKILL.md 主体按需加载、链接文件最深层探索。这就是 渐进披露 的精髓。
Anthropic
第一层（YAML frontmatter）：始终加载到 Claude 的系统提示中。提供刚好够用的信息，让 Claude 知道每个 skill 应该在何时被使用，无需把全部内容塞进上下文。
第二层（SKILL.md 主体）：当 Claude 判断这个 skill 与当前任务相关时才加载。包含完整的指令和指引。
第三层（链接文件）：捆绑在 skill 目录内的额外文件，Claude 可以按需自主导航和发现。
编辑注
三层渐进披露的本质是「按需付费」——让 Claude 只为正在用的能力付出 token 成本。这就是为什么 YAML frontmatter 是整个 Skill 系统中最关键的部分：它是唯一始终常驻系统提示的内容，决定了 Claude 是否会在合适时机激活你的 skill。
可组合性与可移植性
COMPOSABILITY & PORTABILITY
本页要点
Claude 可以同时加载多个 skill。你写的 skill 必须能与其他 skill 共存，而不能假设自己是唯一的能力。同时，同一个 skill 应该能在 Claude.ai、Claude Code 和 API 之间无缝迁移。
Anthropic
Composability：Claude 可以同时加载多个 skill。你的 skill 应该与其他 skill 良好协作，而不假设自己是唯一可用的能力。
Portability：Skill 在 Claude.ai、Claude Code 和 API 之间表现一致。一次创建、处处可用——前提是运行环境支持 skill 所需的依赖。
编辑注
这两个原则约束了 skill 的设计哲学：不要写大而全的 skill，要写小而专的 skill。一个 skill 解决一个具体工作流，多个 skill 通过组合解决复杂任务。这与 Unix 哲学一脉相承——「Do one thing and do it well」。可移植性则保证了你今天在 Claude.ai 里写的 skill，明天可以原封不动放到 Claude Code 里跑。
Skills × MCP：厨房与菜谱
THE KITCHEN ANALOGY
本页要点
如果你已经有一个能跑的 MCP server，最难的部分已经做完了。Skill 是建在它之上的知识层——把你已经掌握的工作流和最佳实践沉淀下来，让 Claude 能稳定复用。
Anthropic
想象一个专业厨房：
MCP 提供的是厨房——访问工具、食材、设备的能力。
Skill 提供的是菜谱——一步一步教你如何把这些原料变成有价值的成品。
两者结合，用户才能完成复杂任务，而不必自己摸索每一步。
编辑注
这是整份指南里最精炼的概念定位。MCP 解决「Claude 能做什么」（连接性），Skill 解决「Claude 应该怎么做」（知识）。一个建好 Notion MCP 的团队还会经常被问「我连接了 Notion 但不知道下一步该做什么」，正是因为缺了 Skill 这一层。Anthropic 用厨房比喻来说服 MCP 开发者：你的 connector 已经有了，再加一份 skill 等于免费增加了一层差异化。
为何 MCP 用户需要 Skill
WITHOUT VS WITH SKILLS
本页要点
没有 skill 时，用户连接了你的 MCP 但不知道下一步、每次会话都要从零开始、结果不一致；有了 skill 后，预制工作流自动激活、工具调用稳定、最佳实践内嵌在每一次交互中。
- 没有 skill：用户连接 MCP 后不知道下一步该做什么
- 没有 skill：support 工单全是「怎么用你的集成做 X」
- 没有 skill：每次对话都从零开始，提示词五花八门
- 没有 skill：用户把 MCP 集成的锅扣在 connector 头上，其实是工作流引导缺失
- 有 skill：预制工作流在需要时自动激活
- 有 skill：工具调用一致、可靠、可预测
- 有 skill：最佳实践嵌入在每一次交互中
- 有 skill：用户上手集成的学习曲线显著降低
编辑注
这一节是写给 MCP 服务商看的「商业价值文案」。Anthropic 想传递的信息很明确：没有 skill 的 MCP 是半成品。当用户在比较多个 connector 时，附带 skill 的那个会因为「上手快、结果稳」而胜出。所以从产品竞争角度，skill 是 MCP 厂商的差异化武器。
从用例出发
START WITH USE CASES · CHAPTER 2 PLANNING
本页要点
在写任何代码之前，先列出 2-3 个具体的用例。一个好的用例定义包含触发条件、执行步骤和预期结果三要素。模糊的用例只会产出模糊的 skill。
Anthropic
问问自己这四个问题：
1. 用户想完成什么？
2. 这需要哪些多步骤工作流？
3. 需要哪些工具（内置还是 MCP）？
4. 应该嵌入哪些领域知识或最佳实践？
用例：项目 Sprint 规划
触发：用户说「帮我规划这个 sprint」或「创建 sprint 任务」
步骤：
1. 通过 MCP 从 Linear 拉取当前项目状态
2. 分析团队速度和容量
3. 建议任务优先级
4. 在 Linear 中创建任务，附带正确的标签和估算
结果：完整规划好的 sprint，任务已创建
编辑注
「先用例后代码」是 Anthropic 反复强调的一条铁律。它和软件工程里的「先写 spec 再写实现」是同一个道理——你必须先在脑子里跑一遍这个 skill 的完整使用过程，才能写出有用的指令。如果你连 2-3 个具体用例都列不出来，说明这件事还不值得做成 skill。
三类常见 Skill 用例
COMMON USE CASE CATEGORIES
本页要点
Anthropic 内部观察到三大类典型 skill：文档与资产创建、工作流自动化、MCP 增强。每一类都有对应的官方示例和典型技巧。
Anthropic
类别 1：Document & Asset Creation
用于：创造一致、高质量的产出——文档、演示、应用、设计、代码等。代表案例：frontend-design skill，以及 docx、pptx、xlsx 等系列。
类别 2：Workflow Automation
用于：受益于一致方法论的多步骤流程，包括跨多个 MCP 服务器的协调。代表案例：skill-creator。
类别 3：MCP Enhancement
用于：在 MCP 服务器提供的工具访问之上叠加工作流引导。代表案例：sentry-code-review。
编辑注
这三类用例对应了 skill 的三种心智模型：第一类是「创造者」，关注产出物的质量；第二类是「编排者」，关注流程的可重复性；第三类是「桥梁」，把工具能力翻译成业务能力。在动手之前先想清楚自己要做的属于哪一类，能让你少走弯路。
定义成功标准
DEFINE SUCCESS CRITERIA
本页要点
如何知道你的 skill 有效？指南给出量化和定性两组指标。这些是「理想目标」而非精确阈值——评估总会有一定「凭感觉」的成分，但仍要尽量用数据说话。
- 量化指标 1：在 90% 的相关查询上能被自动触发
- 量化指标 2：完成工作流所需的工具调用次数（与不用 skill 相比）
- 量化指标 3：每次工作流的失败 API 调用次数为 0
- 定性指标 1：用户不需要提示 Claude 下一步做什么
- 定性指标 2：工作流无需人工纠正即可完成
- 定性指标 3：跨会话结果保持一致
Anthropic
运行 10-20 个本应触发你 skill 的测试查询，统计自动加载的次数 vs 需要显式调用的次数。把开启 skill 和不开 skill 的相同任务对比一次——数一数工具调用数和总 token 消耗，差距就是你的价值。
编辑注
Anthropic 坦率地承认这套度量体系还在演进中——他们目前的态度是「rigorous but vibes-based」（追求严谨但接受感觉成分）。这反映了 skill 工程的真实状态：它不是确定性的代码工程，而更像「提示词工程」与「领域建模」的结合体。
文件结构与命名规则
FILE STRUCTURE & CRITICAL RULES
本页要点
Skill 文件结构很简单，但有几条不可违反的硬性规则：SKILL.md 名字必须精确（区分大小写）、文件夹必须用 kebab-case、不得放 README.md。
your-skill-name/
├── SKILL.md # 必需 - 主文件
├── scripts/ # 可选 - 可执行代码
│ ├── process_data.py
│ └── validate.sh
├── references/ # 可选 - 文档
│ ├── api-guide.md
│ └── examples/
└── assets/ # 可选 - 模板等
└── report-template.md
- SKILL.md 命名：必须精确为 SKILL.md（区分大小写），SKILL.MD、skill.md 都不接受
- 文件夹命名：notion-project-setup ✅；Notion Project Setup ❌；notion_project_setup ❌；NotionProjectSetup ❌
- 禁止 README.md：所有文档放在 SKILL.md 或 references/ 里。GitHub 上的 repo 级 README 是给人看的，与 skill 文件夹分开
编辑注
这些规则看起来死板，但都有原因。SKILL.md 大小写敏感是因为底层加载器用精确字符串匹配；kebab-case 强制是为了保证跨平台兼容（Windows 不区分大小写、Linux 区分）；禁止 README.md 是为了避免 Claude 误把它当成 skill 内容加载。每一条都是踩过坑后的产物。
YAML Frontmatter：最关键的部分
THE MOST IMPORTANT PART
本页要点
YAML frontmatter 是 Claude 决定是否加载你 skill 的依据。它是渐进披露的第一层，常驻系统提示。把它写好就成功了一半。
---
name: your-skill-name
description: What it does. Use when user asks to [specific phrases].
---
Anthropic
name 字段（必需）：仅 kebab-case；不允许空格或大写；应与文件夹同名。
description 字段（必需）：必须同时包含「做什么」和「何时使用」（触发条件）；上限 1024 字符；不得包含 XML 尖括号；包含用户可能说的具体短语；如果相关，提到文件类型。
禁止：包含「claude」或「anthropic」的 skill 名称是保留命名；XML 尖括号会被注入安全过滤拒绝。
编辑注
禁止 XML 尖括号是个有意思的安全限制——因为 frontmatter 会被插入到 Claude 的系统提示中，恶意的 XML 标签可能注入指令，影响 Claude 的行为。这是一道提示注入防线。同样，「claude」「anthropic」前缀被保留是为了防止冒充官方 skill。
Description 字段：好与坏的对比
WRITING EFFECTIVE DESCRIPTIONS
本页要点
Description 的黄金结构：[做什么] + [何时使用] + [关键能力]。坏的 description 要么太泛、要么没有触发词、要么只写技术不写场景。
好例子
包含触发短语：
"Manages Linear project workflows including sprint planning, task creation, and status tracking. Use when user mentions 'sprint', 'Linear tasks', 'project planning', or asks to 'create tickets'."
清晰的价值主张：
"End-to-end customer onboarding workflow for PayFlow. Handles account creation, payment setup, and subscription management. Use when user says 'onboard new customer', 'set up subscription', or 'create PayFlow account'."
坏例子
太泛："Helps with projects."
缺触发词："Creates sophisticated multi-page documentation systems."
太技术、无用户触发："Implements the Project entity model with hierarchical relationships."
编辑注
差异的核心在「触发短语」。Claude 在选择 skill 时其实是在做语义匹配——你 description 里写的词越接近用户真实会说的话，匹配率就越高。所以写 description 时不要用工程师的视角描述功能，要用用户的口吻写「他们会怎么提问」。
主体指令：具体、可执行、有错误处理
WRITING THE INSTRUCTIONS
本页要点
Frontmatter 之后是 Markdown 主体。最佳实践三条：具体且可执行、包含错误处理、清晰引用打包资源。模糊的「请验证数据」毫无意义；具体的「运行 validate.py，常见错误是 X 和 Y」才是好指令。
好的指令示例
Run python scripts/validate.py --input {filename} to check data format.
If validation fails, common issues include:
- Missing required fields (add them to the CSV)
- Invalid date formats (use YYYY-MM-DD)
坏的指令示例
Validate the data before proceeding.
编辑注
Anthropic 还提到一条进阶技巧：对关键校验不要靠语言指令，要绑定脚本——「Code is deterministic; language interpretation isn't.」这一点和 Office skills 用 Python 脚本做格式校验的做法一致。指令告诉 Claude「应该做什么」，但实际验证应该交给确定性的代码完成。
三类测试：触发 / 功能 / 性能对比
TESTING APPROACH · CHAPTER 3
本页要点
Skill 测试有三个层级：在 Claude.ai 里手动测、在 Claude Code 里写脚本测、用 skills API 做程序化评估套件。不论哪种深度，都要覆盖触发测试、功能测试、性能对比三大类。
Anthropic
1. 触发测试：在显然该触发的查询上必须触发；在改写过的查询上仍能触发；在无关话题上绝不触发。
2. 功能测试：产出有效；API 调用成功；错误处理生效；边界情况覆盖。
3. 性能对比：用「成功标准」一节定义的指标，对比开/关 skill 时的表现差异。
Pro Tip
最有效的 skill 创作者都遵循同一条经验：先在一个有挑战性的具体任务上反复迭代直到 Claude 成功，再把成功的方法提炼成 skill。这利用了 Claude 的in-context learning，比一开始就做大范围测试反馈更快。
编辑注
「先做单点 → 再扩展覆盖」是一种典型的「最小可行 skill」迭代法。它的好处是先验证核心价值，再投入打磨。这个建议反面就是常见的反模式：上来就想覆盖 10 种情况，结果每种都做得半生不熟。
用 skill-creator 自举与迭代
SKILL-CREATOR & FEEDBACK LOOPS
本页要点
Anthropic 自己出品了一个用来创建 skill 的 skill——skill-creator。它能从自然语言生成 skill，建议触发短语，flag 常见问题。如果你已经有 MCP 服务器，配合 skill-creator 通常 15-30 分钟能交付一个能跑的 skill。
Anthropic
迭代信号有三类：
欠触发（Undertriggering）：skill 在该用时没加载、用户手动启用、support 问「什么时候用」——解决方案：在 description 里加入更多细节和关键词。
过触发（Overtriggering）：skill 在无关查询上加载、用户禁用、对用途困惑——解决方案：加负向触发、写得更具体。
执行问题：结果不稳、API 调用失败、需要人工纠正——解决方案：改进指令、增加错误处理。
编辑注
「用 skill 来造 skill」是 Anthropic 的一个有趣自举：他们自己用 skill-creator 设计新的 skill，遇到边界 case 后再把案例反喂给 skill-creator 来改进。这种recursive bootstrapping是评估 skill 本身有效性的最好证据——能造出更多 skill 的 skill 才是好 skill。
分发与共享
DISTRIBUTION · CHAPTER 4
本页要点
2026 年 1 月的分发模式：个人用户从 GitHub 下载 zip 后上传到 Claude.ai；组织管理员可以全 workspace 部署（2025-12-18 上线）。Anthropic 已经把 Agent Skills 发布为开放标准，希望它像 MCP 一样跨平台可移植。
Anthropic
个人用户安装方式：
1. 下载 skill 文件夹
2. 打成 zip
3. 在 Claude.ai 通过 Settings > Capabilities > Skills 上传
4. 或放到 Claude Code 的 skills 目录
组织级部署：
• 管理员可以 workspace-wide 部署
• 自动更新
• 中心化管理
API 集成
对程序化应用——构建 agent、自动化工作流——可以通过 API 直接管理 skill：
• /v1/skills 端点用于列出与管理
• Messages API 通过 container.skills 参数挂载
• 通过 Claude Console 做版本管理
• 与 Claude Agent SDK 协同
注意：API 用法需要 Code Execution Tool beta。
编辑注
把 Agent Skills 做成开放标准是个战略选择——和 MCP 走的是同一条路：用开放标准换生态，而非锁定单一厂商。这意味着你今天写的 skill 理论上可以被其他 AI 平台复用，前提是它们采用同一标准。这种「模型可换、生态共享」的设计哲学正是 Anthropic 在 AI 中间件层的核心打法。
模式 1 & 2：顺序工作流 / 多 MCP 协同
PATTERNS · CHAPTER 5
本页要点
指南总结了五种实战模式。前两种是最常见的：顺序工作流编排处理需要严格顺序的多步骤流程；多 MCP 协同把跨服务的工作流拆成清晰阶段。
模式 1：Sequential Workflow
何时使用：用户需要按特定顺序执行的多步骤流程。
核心技巧：明确的步骤顺序；步骤之间的依赖；每个阶段的校验；失败时的回滚指令。
典型场景：客户上线流程——创建账户 → 配置支付 → 创建订阅 → 发送欢迎邮件，每一步依赖前一步的产出。
模式 2：Multi-MCP Coordination
何时使用：工作流跨越多个服务。
核心技巧：清晰的阶段分隔；MCP 之间的数据传递；进入下一阶段前的校验；中心化的错误处理。
典型场景：设计到开发的交接——Figma 导出资产 → Drive 存储 → Linear 创建任务 → Slack 通知工程团队，每个阶段属于不同 MCP。
模式 3 / 4 / 5：迭代 · 上下文 · 领域
REFINEMENT · CONTEXT · DOMAIN INTELLIGENCE
本页要点
后三种模式偏向「让 skill 拥有判断力」：迭代精炼用质量循环逼近高质量产出；上下文感知根据情境选择不同工具；领域智能把专业知识嵌入决策逻辑。
模式 3：Iterative Refinement
输出质量随迭代提升的场景。流程：初稿 → 质量检查 → 精炼循环 → 终稿。关键技巧：明确的质量标准、迭代改进、校验脚本、知道何时停止。典型场景是报告生成。
模式 4：Context-aware Tool Selection
同一目的、不同情境用不同工具。例如智能文件存储——根据文件类型和大小选择目标：大文件走云存储 MCP、协作文档走 Notion/Docs MCP、代码文件走 GitHub MCP、临时文件走本地。关键技巧：清晰的决策树、回退方案、对用户透明的选择理由。
模式 5：Domain-specific Intelligence
skill 不只是调用工具，还嵌入了专业领域知识。例如金融合规——支付前检查制裁名单、司法管辖权、风险等级、记录合规决策。这类 skill 把domain expertise 作为核心价值，工具调用只是执行层。
故障排查：四类常见问题
TROUBLESHOOTING
本页要点
Skill 出问题通常落在四个篮子里：无法上传、不触发、过度触发、指令未被遵循。每一类都有具体解法。
- 无法上传：检查 SKILL.md 大小写、YAML 是否有
--- 分隔符、name 是否 kebab-case
- 不触发：description 是否太泛？是否包含用户真会说的触发词？是否提到了文件类型？
- 调试技巧：直接问 Claude「你什么时候会用 [skill name] 这个 skill？」Claude 会把 description 复述出来——根据缺失的内容反向调整
- 过度触发：加负向触发词、写得更具体、明确范围（不要把 PayFlow 写成「金融查询」，而要写成「电商支付工作流」）
- 指令未被遵循：指令太啰嗦？关键指令被埋在中间？语言太模糊？
- 解决「指令被埋」：把关键指令放最上面、用 ## Important / ## Critical 标题、必要时重复
- 大上下文问题：把详细文档移到 references/、SKILL.md 控制在 5000 词内、避免同时启用 20-50 个以上的 skill
编辑注
最实用的一条调试技巧：问 Claude「你什么时候会用这个 skill？」。这是 Anthropic 在指南里悄悄塞的一个「元提问」技巧——通过让模型反向叙述自己的触发逻辑，你能发现 description 中真正起作用的部分和被忽略的部分。比任何文档都直接。
原理注释：渐进披露与 MCP 共生
PRINCIPLES EXPLAINED · PART 1
补充 1. 渐进披露的本质是 token 经济学
为什么 Anthropic 要设计三层加载机制？答案是 token 成本。Claude 的系统提示是每次对话都要消耗的固定成本——如果把每个 skill 的完整指令都塞进系统提示，启用 50 个 skill 就要先付出几十万 token 的开销。渐进披露 把这个开销分摊到「相关时才付费」：YAML 元信息（仅几行）常驻，主体内容（几千词）按需加载，深层文件（任意大小）只在 Claude 主动探索时才进上下文。这套机制让 skill 系统在理论上可以无限扩展。
补充 2. MCP 与 Skill 的分工不对称
厨房比喻很形象，但有一层更深的不对称值得讲清楚：MCP 是能力契约，Skill 是使用规范。MCP 描述「这台机器有什么按钮、按下去会发生什么」，Skill 描述「在什么场景下应该按哪些按钮、按什么顺序、按完后该检查什么」。MCP 是确定性的（输入 → 输出），Skill 是策略性的（情境 → 决策 → 执行）。这就是为什么同一个 MCP 可以配套多个不同的 skill——一个 Linear MCP 可以同时配 sprint 规划 skill、bug triage skill、roadmap 报告 skill。
补充 3. 「问 Claude 自己什么时候用」是个核心调试范式
指南里的这个调试技巧值得单独拎出来。它的本质是元提问：让模型成为自己行为的解释者。这比看文档、读源码都直接，因为模型告诉你的就是它实际依据的判断逻辑。同样的范式可以推广到所有 AI 系统调试：当你不确定为什么 AI 没按预期行事时，与其翻文档，不如直接问它「你为什么这么做？你看到什么提示让你做这个决定？」——它会非常诚实地把自己的依据复述出来。
原理注释：触发器、开放标准、自举
PRINCIPLES EXPLAINED · PART 2
补充 4. 触发器调优：从工程师视角到用户视角
触发短语设计是 skill 工程的核心难点。新手常犯的错是「用工程师视角描述功能」——比如写「Implements the Project entity model」。但 Claude 在做触发判断时是基于用户实际会说的话做语义匹配。所以正确做法是：召集 5 个目标用户，问他们「如果你想做 X，你会对 Claude 说什么？」把这些话原封不动塞进 description。这与提示词工程的核心原则一致——站在调用方而非实现方的角度写。
补充 5. Agent Skills 作为开放标准的战略意义
把 Agent Skills 做成开放标准而非 Anthropic 私有特性，是延续了 MCP 的成功路径。这种「基础设施开放、模型差异化」的策略让 Anthropic 处于一个有利位置：你写的 skill 可以理论上跨平台运行，但 Anthropic 的模型在执行 skill 时质量最好——开发者迁移到其他平台的成本低（避免锁定恐惧），但实际使用 Anthropic 的动机强（最好用就够了）。这是「以开放赢生态、以质量赢使用」的典型操作。
补充 6. 自举循环：用 skill 造 skill 是 skill 系统成熟度的标志
skill-creator 的存在不只是个便捷工具——它是 skill 系统达到自给自足的标志事件。一个能够「用自己造自己」的工具系统说明了几件事：1）抽象层足够清晰，可以被自己描述；2）反馈循环够紧密，问题能被快速暴露和修复；3）用户和创作者的边界已经模糊。这与编程语言的self-hosting 编译器有异曲同工之妙——能编译自己的编译器才是成熟的语言实现，能造 skill 的 skill 才是成熟的 skill 平台。
关键洞察回顾
- Skill 是个文件夹——SKILL.md 是必需，scripts/references/assets 都是可选
- 渐进披露三层：YAML 常驻系统提示 / 主体按需 / 链接文件深探
- Composability：写小而专的 skill，让多个 skill 协作完成复杂任务
- Portability：一次写好，Claude.ai / Claude Code / API 通用
- MCP 是厨房，Skill 是菜谱——MCP 给能力，Skill 给方法
- 动手前先列 2-3 个具体用例，不能就别做 skill
- 三类典型用例：文档创作、工作流自动化、MCP 增强
- 文件夹必须 kebab-case，SKILL.md 大小写敏感，禁止 README.md
- YAML frontmatter 是最关键的部分——决定 skill 何时被激活
- description 的黄金结构：[做什么] + [何时使用] + [关键能力]
- 禁止 XML 尖括号（防注入）、禁止 claude/anthropic 前缀（保留命名）
- 指令要具体可执行：比起「请验证」更要写「跑 validate.py，常见错误是 X」
- 三类测试：触发 / 功能 / 性能对比；先做单点再扩展
- 欠/过/执行问题——三种迭代信号都有对应解法
- skill-creator：用 skill 来造 skill，15-30 分钟首个可用
- Agent Skills 是开放标准，希望像 MCP 一样跨平台
- 五种实战模式：顺序 / 多 MCP / 迭代 / 上下文 / 领域智能
- 调试金句：直接问 Claude「你什么时候会用这个 skill？」
本文涵盖 52 个术语注释及 6 个原理过程补充解析。
点击任何虚线下划线的术语了解详细解释。
原文来源：resources.anthropic.com
下期再见