# Claude Code Agent Skills 使用与开发实战指南

（面向有 Prompt 经验的 LLM 开发者）

***

## 0. 面向谁 \& 要解决什么问题

本指南面向已经熟悉「写系统 Prompt / 模板 Prompt 来驱动大模型」的工程师，重点回答三个问题：

1. **从 Prompt 到 Skill 的本质差异是什么？**
2. **在 Claude Code / Agent SDK 里，Skill 实际是怎么被发现、触发和执行的？**
3. **如何把现有的 Prompt 工作流系统性迁移为 Skill，并做好工程化维护？**

全文会大量对比 Prompt vs Skill，突出 Skill 在「可复用、可维护、可组合」上的优势，并给出面向工程实践的设计建议。

***

## 1. 核心概念：什么是 Agent Skill？

从官方定义出发，**Skill = 指令包（Markdown）+ 元数据（YAML）+ 可选脚本/资源文件**，用于给 Claude 注入特定领域的专业能力，并在需要时**按需加载（progressive disclosure）**。

可以粗略理解为：
> 从「一次性 Prompt」升级为「可发现、可触发、可共享的领域专家插件」。

### 1.1 Skill 的组成

典型 Skill 目录结构（Claude Code / Agent SDK 默认形式）如下：

```text
my-skill/
├── SKILL.md          # 必须，有 YAML frontmatter + 主指令
├── reference.md      # 可选，详细文档/规范，按需加载
├── examples.md       # 可选，用法示例
└── scripts/          # 可选，可执行脚本（Python/JS/bash 等）
    └── helper.py
```

其中：

- **SKILL.md**
    - 顶部 `---` 之间为 YAML frontmatter：
        - `name`: Skill 名（唯一标识）
        - `description`: Skill 做什么 \& 何时使用（触发判断关键信号）
    - 下方为 Markdown 正文：指令、步骤、示例、链接到其它文件等
- **其他 Markdown 文件**
    - 延伸文档、规范、API 说明、更多示例
    - Skill 激活后才按需加载，避免一开始就占满上下文
- **scripts/**
    - 放可执行脚本，由 Claude 通过 code execution / bash 调用，结果再由模型解释


### 1.2 Skill 在系统里的位置

在 Agent SDK / Claude Code 中，Skill 被作为一种特殊的「工具」存在（工具名通常为 `Skill`），出现在工具列表中，与 `Read` / `Write` / `Bash` 等并列。

但它和传统工具最大的区别是：

- 传统工具：**执行动作 → 返回结果**
- Skill：**注入指令/上下文 → 修改后续推理环境**

换句话说，Skill 更像是**上下文工程 (context engineering) 的模块化单元**，通过：

- 在对话历史中插入系统/用户级指令
- 动态调整可用工具、模型、思考 token 限制等

***

## 2. Prompt vs Skill：从 Prompt 工程师视角的系统性对比

为了方便有 Prompt 经验的读者，先用表格给出高层对比。

### 2.1 Prompt / Slash Command / Skill / MCP / Subagent 对比

| 维度 | 普通 Prompt | Slash Command (`/xxx`) | Skill (Agent Skill) | MCP 工具 | Subagent |
| :-- | :-- | :-- | :-- | :-- | :-- |
| 触发方式 | 用户临时输入 | 用户显式输入命令 | 模型根据描述自动触发（可带确认） | 模型显式选择调用 | 用户或模型显式切换 |
| 存储形态 | 文本片段 / 模板 | 单一 `.md` 文件 | 目录 + `SKILL.md` + 资源文件/脚本 | 外部服务 / 进程 | 独立 agent 配置文件 |
| 作用范围 | 当前对话 | 当前项目或用户 | 全局（用户级）+ 项目级 | 任意集成的应用 | 子上下文 |
| 核心能力 | 影响一次或一段对话行为 | 复用一段 Prompt | 封装**可重用工作流 + 资源 + 可执行逻辑** | 访问外部数据/服务 | 长期专职 agent，独立上下文 |
| 上下文成本 | 每次要重新输入或粘贴 | 命令内容一次性进入上下文 | 先只加载 metadata，触发后再加载全文（progressive disclosure） | 按调用次数计入提示 | 独立 context window |
| 发现机制 | 人脑记忆/文档 | 人主动记命令名 | 模型基于 `description` 自动匹配任务 | 调用逻辑通常在 app 代码里 | 由 orchestrator 决定何时委派 |
| 脚本支持 | 需要外部 pipeline | 支持有限（多数为文本） | 可绑定脚本并在 code execution 环境中运行 | 自己就是代码 | 可使用一组工具 |
| 复用 \& 版本管理 | 很难系统管理 | 可以通过 Git 管理单文件 | 自然地通过 Git / 目录版本化、共享 | 依赖微服务/Git | 类似 micro-service 配置 |

从 Prompt 工程师角度，可以总结为：

> **Prompt 是「指令文本」，Skill 是「指令系统」**
> Prompt 强在「灵活，快速试验」，Skill 强在「标准化，可复制，可演化」。

### 2.2 Skill 相比纯 Prompt 的关键优势

1. **发现 \& 自动触发**
    - 不需要用户记住「要贴哪段 Prompt」，模型通过 Skill 的 `description` 判断当前请求是否适配，然后请求使用该 Skill。
    - 对于团队内部知识，极大降低使用门槛（只要「说人话描述任务」即可）。
2. **进阶的上下文工程**
    - Progressive disclosure：启动时只加载 metadata；触发 Skill 时再读 `SKILL.md` 和相关文件，既省 token 又避免污染通用对话。
    - 能把长文档、规范、脚本拆分到多个文件，按需加载，而不是一次性塞进系统 Prompt。
3. **与可执行代码融合**
    - 可在 `scripts/` 里放好经过验证的 Python/JS/Bash 脚本，Skill 中只写「何时、如何调用脚本、如何解释输出」。
    - 把「确定性处理」（解析文件、复杂计算、格式转换）迁到脚本，「不确定性决策」留给模型。
4. **工程化与团队协作**
    - Skill 目录可以直接纳入 Git 仓库，与代码、文档同一生命周期进行评审、测试、发布。
    - 可以在个人级 (`~/.claude/skills/`) 和项目级 (`.claude/skills/`) 间共享和组合。
5. **跨界面统一复用**
    - 同一个 Skill 可同时在 Claude App / Claude Code / API / 支持 Skills 的 IDE 插件中使用。
    - 你在本地为团队开发的 Skill，理论上可以作为「统一的工作流组件」在多个入口使用。

***

## 3. Skill 的运行机制：发现 → 触发 → 执行

理解运行机制，有助于更好地做「技能触发设计」和「上下文工程」。

### 3.1 Discovery：启动时的轻量加载

当 Agent 启动（Claude Code、SDK 程序、支持 Skill 的 app）时，会做：

1. 扫描 `~/.claude/skills/` 和当前工程 `.claude/skills/` 中的子目录。
2. 对每个目录，只读取 `SKILL.md` 的 YAML frontmatter（`name` + `description` 等）。
3. 把这些 metadata 以文本形式加入 Skill 工具的描述中，出现在模型能看到的 system 提示中。

**此时模型只知道：**
> 「有哪些技能、叫啥名字、干什么、什么时候用」，
> 但还没有看到真正的长指令和资源内容。

### 3.2 Activation：根据自然语言请求触发

当用户输入任务（例如「帮我生成一份符合公司品牌规范的 PPT」），流程大致是：

1. 模型在看到当前用户消息 + Skill 列表描述后，**根据语义匹配**，判断有哪些 Skill 适用。
2. 如果判断某个 Skill 合适，会通过 `Skill` 工具发起一次调用，内部携带 `command`/`name` 等信息。
3. 前端/SDK 通常会给用户一个「是否使用某某 Skill」的确认提示（尤其在 Claude Code/Claude App 中）。

匹配质量高度依赖：

- `description` 里是否写清楚**任务类型、输入形式、关键关键词**；
- 是否给出类似「当用户说 X/Y/Z 时，使用本 Skill」的语句。


### 3.3 Execution：加载指令、脚本与资源

Skill 激活后，系统会做：

1. 通过 `Bash` / 文件访问工具读取 `SKILL.md` 正文内容，插入到对话上下文中（通常以用户可见 + 隐藏两条消息注入）。
2. 如果 `SKILL.md` 里引用了其他 Markdown 文件（如 `reference.md` / `examples.md`），则在需要时再读取对应内容，进一步注入上下文。
3. 若指令中包含像「运行 `scripts/analyzer.py` 并解析输出」的步骤，Claude 会：
    - 使用 code execution / bash 工具执行脚本；
    - 读取输出文件（比如 JSON/CSV），再进行解释和总结。
4. 在整个 Skill 激活期内，可以调整：
    - 可用工具的白名单/黑名单（例如只读文件、不允许 Bash 修改文件）；
    - 使用的模型（例如对某 Skill 固定使用 Sonnet / Opus）；
    - 思考 token 等参数，使复杂任务能更稳定完成。

Skill 完成任务后，可以自然退出，其指令虽然已在对话里，但后续模型可根据上下文判断是否继续遵循，或在需要时再次触发其它 Skill。

***

## 4. Skill 目录结构与 `SKILL.md` 设计详解

### 4.1 `SKILL.md` 最小可用示例

以一个「解释代码」的 Skill 为例（官方文档类似示例）：

```markdown
---
name: explaining-code
description: Explain source code in clear, structured language; use when users ask you to explain or understand code.
---

# Explaining Code

## Goal
When this skill is active, you explain the given code in a way that is:
- Clear and concise
- Structured with headings and bullet points where helpful
- Focused on behavior, design decisions, and potential issues

## Instructions

1. First, identify the language, framework, and main purpose of the code.
2. Then, explain:
   - What the code does step by step
   - How key functions, classes, and modules interact
   - Any assumptions or implicit behaviors
3. Highlight:
   - Potential bugs or edge cases
   - Performance concerns
   - Security considerations
4. Provide suggestions for improvement if relevant.

## Examples

### Example 1: Small function

_User request_: "Explain what this JavaScript function does and if there are any issues."

...
```

要点：

- **YAML frontmatter 必须有 `name` \& `description`**；模型就是靠这两个字段判断何时使用该 Skill。
- 正文建议包含：
    - 明确的目标（Goal）
    - 详细的步骤（Instructions）
    - 若干典型示例（Examples）
- Skill 是给「另一实例的 Claude」看的文档，写法应面向模型：步骤清晰、可执行、少模糊语义。


### 4.2 推荐的正文结构模板

对于多数工程类 Skill，可以采用固定骨架：

```markdown
# <Skill 名称（人类友好标题）>

## 1. 适用场景（When to use this Skill）
- 当用户...
- 当输入包含...
- 不要在以下情况使用...

## 2. 输入与输出约定
- 输入可以是：
  - ...
- 输出必须包括：
  - ...
- 对输出格式的要求（如 JSON schema / Markdown 结构）

## 3. 工作流步骤
1. ...
2. ...
3. ...

## 4. 参考规范 / 约束
- 引用 `style-guide.md` / `api-reference.md` 等
- 明确必须遵守的约束（安全/隐私/合规）

## 5. 示例
### 示例 1
_用户..._
_期望输出..._

## 6. 常见错误与修正
- 如果出现 X，则...
```

这样设计有几个好处：

- 方便未来的 Claude 实例按「When to use」部分进行自我检查；
- 输入输出约定可以和脚本/下游系统严格对齐；
- 工作流步骤使 Skill 更像一份 SOP（标准作业流程），可复用性强。


### 4.3 多文件 Skill 的组织方式

多文件 Skill 适合复杂领域，例如：

- 公司级代码规范/安全规范；
- 复杂文档模板（产品需求文档、设计文档、测试计划）；
- 大型 API / 数据仓库查询规范。

典型做法是：

```text
code-review/
├── SKILL.md          # Overview + 导航
├── SECURITY.md       # 安全审计检查表
├── PERFORMANCE.md    # 性能审查要点
├── STYLE.md          # 代码风格规范
└── scripts/
    └── run-linters.sh
```

在 `SKILL.md` 中：

- 先给出总体工作流；
- 再指示 Claude 在特定步骤「按需打开 SECURITY.md / PERFORMANCE.md」等文件。

这天然支持 progressive disclosure：仅在安全相关检查时才加载 `SECURITY.md`，避免所有规范一次性进入上下文。

***

## 5. 在 Claude Code / Agent SDK / App 中使用 Skill

### 5.1 Claude Code 中的使用路径

在 Claude Code（VS Code / 其他 IDE 集成）中，Skill 的使用大致包括：

1. **安装/放置位置**
    - 全局：`~/.claude/skills/<skill-name>/SKILL.md`
    - 项目级：`<project>/.claude/skills/<skill-name>/SKILL.md`
      项目级具备更高优先级，更适合项目特定约束。
2. **启用 Skill 工具**
    - Agent SDK 或 Claude Code 的配置中，需要将 `Skill` 工具加入 `allowedTools` / `allowed_tools` 才能使用 Skill。
3. **交互方式**
    - **自然语言触发**：直接按业务语言提需求，只要和 `description` 匹配，模型就会尝试触发 Skill。
    - **显式指定技能名**：如「使用 `explaining-code` 这个技能帮我…」，可提高触发概率。
    - **列出可用 Skill**（在 IDE 中）：例如通过命令面板或直接问 Claude 「列出当前可用的 Skills」，方便调试加载是否成功。
4. **结合 Subagent 使用**
    - 在 Subagent 的配置里可以指定 `skills: skill1, skill2`，让某个 Subagent 启动时自动加载对应技能。
    - 典型用法：创建 `code-reviewer` Subagent，并为其加载 `code-review` Skill，包括安全/性能/风格规范。

### 5.2 在 Claude App / Web / 桌面端中的使用

技能同样在 web/桌面端可用：

- 在设置中的「Skills」部分可以：
    - 启用内置官方技能（Excel/Word/PPT/PDF 等）；
    - 上传自定义 Skill（打包成 zip 或按要求目录）；
- 对话中，当 Claude 自动使用 Skill 时，会有明显标记（例如「已使用某某 Skill」），便于观察和调试；
- 「Skill Creator」技能可以辅助用自然语言生成新的 Skill 初稿（对 prompt 工程师尤其友好）。


### 5.3 在 API / Agent SDK 中使用

在 Agent SDK 或直接使用 Claude Messages API 时：

- 在 agent 配置中声明开启 Skills，并允许 `Skill` 工具。
- 上下文中会自动注入已安装技能的 metadata，后续与 Claude Code 的逻辑一致。
- 某些环境还支持在 API 调用中显式指定要使用的 Skill 名称，以更强约束模型行为。

***

## 6. 从 Prompt 到 Skill：一个系统化迁移方法论

假设你已经有一批在日常工作中频繁使用的 Prompt（代码审查模板、文档模板、业务流程模板等），可以按如下步骤逐步迁移为 Skill。

### 6.1 Step 1：挑选适合作为 Skill 的场景

优先选择具备以下特征的 Prompt：

- **任务稳定、重复频率高**
  例如「生成符合公司模板的周报」、「按照固定格式写 PRD」、「执行特定框架的代码审查」。
- **指令较长，粘贴成本高**
  每次要粘贴 100+ 行 Prompt 才能用的流程。
- **有明确可复用工作流**
  如「先收集需求 → 再分析约束 → 再生成文档 → 再生成测试用例」。
- **需要结合外部资源 / 规范**
  如品牌规范 PDF、API 文档、现有脚本。

这类场景用 Skill 迁移后收益最大。

### 6.2 Step 2：抽象为「领域工作流」

把原 Prompt 拆成几个维度：

1. **适用场景 / 不适用场景**（写入 `description` 和正文「When to use」部分）
2. **输入输出契约**（类型、格式、字段）
3. **步骤化工作流**（尽量写成 numbered list）
4. **引用的外部知识/规范**
5. **可交给脚本完成的确定性操作**

再决定：

- 哪些应该留在 `SKILL.md` 主体中；
- 哪些应拆出到 `reference.md` / `examples.md`；
- 哪些迁移到 `scripts/` 中由代码执行。


### 6.3 Step 3：创建目录与 `SKILL.md`，写好 frontmatter

在本地或项目中创建目录：

```bash
mkdir -p ~/.claude/skills/my-weekly-report
```

然后新建 `SKILL.md`，至少包含：

```yaml
---
name: weekly-report
description: Create structured weekly status reports following our team's format, tone, and content guidelines. Use when users want to draft, revise, or polish weekly reports.
---
```

描述里建议同时包含：

- **任务类型**（create / review / analyze…）
- **对象类型**（weekly report / PRD / code / log…）
- **关键触发词**（weekly report, 周报, 状态更新 等）

有实践表明，过于抽象的描述会导致触发不稳定，描述应「贴近用户会说的话」。

### 6.4 Step 4：迁移 Prompt 内容为结构化指令

把原来的大段 Prompt 迁移到 `SKILL.md` 正文里：

- 按前文推荐的「适用场景 / 输入输出 / 工作流 / 规范 / 示例」骨架重构；
- 适当拆分为多个 Markdown 文件，通过链接组织；
- 将那些「给人看的摆设性说明」删减，把关键的决策规则和格式要求留下。

此时建议使用官方的 `skill-creator` Skill 做一次「反向审阅」：让 Claude 作为「Skill 审查专家」检查你的 `SKILL.md` 是否清晰、可执行。

### 6.5 Step 5：引入脚本（可选）

对于涉及复杂文件处理、数据转换的 Skill：

- 在 `scripts/` 目录中放置脚本（如 `scripts/generate_charts.py`）；
- 在 `SKILL.md` 中写明：
    - 何时触发该脚本；
    - 调用方式（命令行参数、输入输出文件）；
    - 如何基于脚本输出继续生成响应。

示例片段：

```markdown
### Step 3: Generate metrics

1. Run `python {baseDir}/scripts/metrics.py --input "{INPUT_PATH}" --output "metrics.json"`.
2. Read `metrics.json` and:
   - Summarize key metrics
   - Highlight anomalies
   - Propose follow-up actions
```

这样可以让 Skill 在执行时自动落地可靠、可测试的脚本逻辑。

### 6.6 Step 6：测试、迭代与版本管理

- 在 Claude Code 中打开工程，触发 Skill 相关任务，观察：
    - Skill 是否被正确检测与加载；
    - 输出是否稳定、可预期；
    - 是否存在错误触发或遗漏触发的情况。
- 把 Skill 目录纳入 Git：
    - 对 `SKILL.md` 和脚本做 code review；
    - 用单元测试或 golden test 验证脚本输出与模型输出模式；
    - 给 Skill 加上版本号和 changelog，避免团队混乱。

***

## 7. 与其它能力的关系：Prompt / Slash Commands / MCP / Subagents

### 7.1 与 Slash Commands 的关系

官方文档已经明确给出对比：

- **Slash Commands 更适合：**
    - 简单、单文件的快捷 Prompt 片段；
    - 用户显式调用的「动作」（如 `/review`、`/optimize`）。
- **Skills 更适合：**
    - 多步骤、复杂工作流；
    - 需要脚本/多个文档支持的能力；
    - 希望由模型自动发现与触发的能力。

一个现实做法是：

- 将「一两句话就能说清楚的常用命令」做成 Slash Command；
- 将「背后有 SOP/规范/脚本组合」的能力做成 Skill。


### 7.2 与 MCP（Model Context Protocol）工具的关系

MCP 工具解决的是「对接外部服务和数据源」的问题，而 Skill 解决的是「**如何使用这些工具与数据完成任务**」的问题。

常见组合方式：

- MCP 提供：
    - 数据库查询；
    - 外部 API 调用；
    - 文件存储与检索。
- Skill 提供：
    - 如何根据业务规则选择查询；
    - 如何解释结果并组装报告；
    - 如何处理失败/重试逻辑（在指令层面）。

可以理解为：

> MCP = 手里的工具箱
> Skill = 用这些工具完成某项工程的施工手册

### 7.3 与 Subagents 的关系

Subagent 是具备独立系统 Prompt / 上下文 / 工具集合的「子代理」：

- 适合：
    - 长期运行的专职角色（如「安全审核专家」「数据科学家」）；
    - 需要独立上下文，避免主对话污染。
- 而 Skill 本身不创建新上下文，只是在当前 agent 环境里注入额外知识与流程。

两者可以协同：

- Subagent 的系统 Prompt 里定义角色；
- 为该 Subagent 配置一组 Skills（通过 `skills:` 字段自动加载），让其在子上下文中运用这些技能处理任务。

***

## 8. Skill 设计与实现的最佳实践（结合 Prompt 工程经验）

从 Prompt 工程到 Skill 工程，有几条实践尤为关键：

### 8.1 面向「触发」写 description，而不是面向人写标题

- 不要只写「Brand style enforcement skill」；
- 应写「Enforce our company's brand style when generating documents, slides, and emails; use when users request brand-compliant content or mention brand guidelines.」

要点：

- 包含**动词 + 对象 + 触发语句**；
- 尽量覆盖用户实际会说的关键词（包括中英文同义词）；
- 明确排除场景（可写在正文里）。


### 8.2 把 Skill 当「SOP + Playground」而不是「单次提示」

- SOP：用 numbered steps 描述必须遵守的流程；
- Playground：在示例部分给出多个「现实场景 -> 标准输出」的例子，帮助模型对齐风格。

对比传统 Prompt，把「元层说明」（你是谁、你要怎么做）抽象到稳定 SOPS；把一次性的上下文保留在对话中。

### 8.3 严格区分「模型擅长」和「脚本擅长」的部分

- 让脚本做：
    - 复杂解析（PDF/Excel/日志）；
    - 一致性要求高的格式转换；
    - 算法类计算、指标统计。
- 让模型做：
    - 决策、总结、解释；
    - 文本生成、风格迁移；
    - 多步推理。

Skill 文本中应明确告诉 Claude 什么时候「先运行脚本再思考」，减轻 hallucination 风险。

### 8.4 使用 progressive disclosure 优化上下文

- 把大型规范/文档拆分为多个文件；
- 在 `SKILL.md` 中通过「当执行到某步时，再读取某文件」的方式引用；
- 避免在 Skill 中「一上来就复制粘贴整本手册」。

这样不仅省 token，还减少上下文「噪音」，提高任务对齐度。

### 8.5 将测试和迭代流程制度化

- 为关键 Skill 设计一组「golden prompts + expected patterns」；
- 每次改动 `SKILL.md` 或脚本后，跑一遍回归验证；
- 把「Skill 使用问题」回溯到：
    - description 不清；
    - 指令歧义；
    - 示例不足；
    - 或脚本行为与说明不一致。

社区和官方仓库里的 Skill（如 `skill-creator`）是很好的参考和基准，可以从中抽取通用结构和写法。

***

## 9. 常见坑与排错思路

结合官方文档与社区经验，总结几个典型问题及解决方向：

1. **Skill 明明写好了，但从未触发**
    - 检查：
        - 目录名是否正确，`SKILL.md` 是否位于根目录；
        - frontmatter 是否合法 YAML，`name`/`description` 是否存在；
        - 是否在 agent 配置中启用了 `Skill` 工具；
        - `description` 是否过于抽象、不含实际触发关键词。
2. **Skill 误触发或过度触发**
    - 现象：稍有相关就被加载，导致上下文被早早塞满。
    - 解决：
        - 在 description 中更明确限定任务范围；
        - 在正文「When NOT to use」部分增加自检指令，让 Claude 自我约束；
        - 将多个任务拆成多个更细粒度的 Skill。
3. **Skill 行为不一致，时好时坏**
    - 可能原因：
        - 工作流步骤过于模糊，缺少关键约束；
        - 示例不足，导致风格漂移；
        - 依赖的脚本无单测或输出不稳定。
    - 建议：
        - 增加「负例」示例，说明不应该产生的输出；
        - 对关键决策处增加明确的「思考检查清单」。
4. **多 Skill 并用时出现冲突**
    - 例如：多个文档生成 Skill 都认为自己适用。
    - 治理方式：
        - 在 description 中加入更具体的触发条件（如特定文件类型、特定领域关键词）；
        - 在 Skill 正文中加入互斥说明：如「如果 X 更匹配另一个 Skill，则不要使用本 Skill」。

***

## 10. 总结：从 Prompt 工程到 Skill 工程

从体系化视角看：

- **Prompt 工程**解决的是：
  「如何构造一次性上下文，让模型在当前会话表现良好」。
- **Skill 工程**解决的是：
  「如何以模块化方式封装知识与流程，让模型在不同场景、长期、多人协作下都表现一致」。

对于已经有成熟 Prompt 经验的开发者，下一步的升级路径可以概括为：

1. 把高频、高价值 Prompt 抽象成可重用工作流（SOP）；
2. 迁移为 Skill：写好 `SKILL.md` 的 frontmatter 与结构化正文；
3. 将领域知识与脚本一起封装，利用 progressive disclosure 和 code execution 提升稳定性与效率；
4. 通过 Git + 测试 + 版本管理，把 Skill 纳入工程资产；
5. 结合 MCP 和 Subagent，把 Skill 作为「领域 Playbook」，构建真正可运营的 AI agent 体系。

在 Claude Code / Agent SDK 生态下，Skill 已经成为官方推荐的「中间层抽象」：
与 MCP 工具、Subagent、Projects 等能力一起，构成从 Prompt 工程到 Agent 工程的关键桥梁。

如果后续希望，可以进一步围绕你的具体场景（例如代码库结构、文档模板、数据分析流程）给出一份「定制 Skill 设计蓝图」，直接从现有 Prompt 资产出发设计目录和 `SKILL.md` 模板。