<!-- title: Claude Code Skill工程化深度实战 -->

## 概述

本教程面向已了解 Claude Code 基础操作、希望系统掌握 Skill 高级工程化实践的开发者。你将学会：SKILL.md 全部 Frontmatter 字段的精确语义与组合策略、Inline 与 Fork 两种执行上下文的抉择方法论、多文件 Skill 架构设计与渐进式上下文加载、Skill 调试诊断与评估测试闭环、以及从个人 Skill 到团队插件化分发的完整路径。适合训练营进阶阶段，预计教学时长 4-6 小时。

## 前置条件

- Claude Code ≥ 1.0.28 已安装并可用
- 理解 Markdown 与 YAML 基本语法
- 具备至少一个真实项目目录用于实战演练
- 了解 Claude Code 基本交互方式（对话、文件读写、Bash 执行）

---

## 一、Skill 架构全景：从一页纸到多文件体系

### 1.1 Skill 的三种形态

Claude Code 的 Skill 并非单一概念，而是覆盖了从简单指令到复杂工作流的光谱：

```
形态一：单文件 Skill（最常见）
├── SKILL.md

形态二：多文件 Skill（中等复杂度）
├── SKILL.md
├── references/
│   ├── api-patterns.md
│   └── troubleshooting.md
└── scripts/
    └── validate.py

形态三：编排型 Skill（最高复杂度）
├── SKILL.md（编排逻辑）
├── references/
│   ├── domain-a.md
│   ├── domain-b.md
│   └── domain-c.md
├── scripts/
│   ├── setup.sh
│   └── transform.py
└── templates/
    └── output-template.txt
```

选择哪种形态取决于 Skill 的**信息密度**，而非人为设定的行数上限。一个 600 行但每行都有用的 SKILL.md 远胜于一个 200 行但大量内容需要 Claude 去猜测的版本。

### 1.2 Skill 的三层加载机制

Claude Code 采用**渐进式上下文加载**（Progressive Disclosure）策略，Skill 内容分三个层级注入上下文：

| 层级 | 加载时机 | 大小估算 | 内容 |
|------|---------|---------|------|
| L1: 元数据 | 始终在上下文中 | ~100词 | `name` + `description` |
| L2: SKILL.md正文 | Skill被触发时 | 不限 | Markdown指令内容 |
| L3: 附属文件 | 按需读取 | 不限 | references、scripts、templates |

这意味着一个包含 20 个参考文档的 Skill 不会撑爆上下文——Claude 只在需要时才读取特定文件。

```mermaid
flowchart TD
    A[用户发送请求] --> B{Claude扫描所有Skill元数据}
    B -->|匹配description| C[加载L2: SKILL.md正文]
    B -->|不匹配| D[跳过该Skill]
    C --> E{正文引用了附属文件?}
    E -->|是| F[按需加载L3: references/scripts]
    E -->|否| G[直接执行指令]
    F --> G
```

---

## 二、Frontmatter 全字段深度解析

### 2.1 完整字段一览

SKILL.md 的 YAML Frontmatter 是控制 Skill 行为的核心"旋钮"。以下是截至 2026 年 6 月的全部有效字段：

```yaml
---
# === 身份与发现 ===
name: my-skill                    # 标识符。小写字母+数字+连字符，≤64字符
description: 做什么+何时用          # ★最关键字段。Claude凭此判断是否触发
argument-hint: "[issue-number]"   # 自动补全时显示的参数提示

# === 调用控制 ===
disable-model-invocation: true    # 禁止Claude自动调用，仅用户可/skill-name触发
user-invocable: false             # 从/菜单隐藏，仅Claude内部调用

# === 执行上下文 ===
context: fork                     # 在隔离子代理中运行
agent: Explore                    # context:fork时使用的子代理类型
model: sonnet                     # 激活时覆盖模型选择
effort: high                      # low|medium|high|max

# === 权限与工具 ===
allowed-tools: Read, Grep, Glob   # 工具白名单（省略=遵循用户权限设置）

# === 路径与钩子 ===
paths: "app/**/*.rb, spec/**/*.rb" # 自动激活的文件路径glob模式
hooks:                            # 生命周期钩子
  PreToolUse:
    - matcher: "Bash"
      hooks:
        - type: command
          command: "./scripts/check.sh"
shell: bash                       # bash|powershell
---
```

### 2.2 description：Skill 触发的生死线

`description` 是 Claude 决定是否使用你的 Skill 的**唯一依据**。写得差，Skill 就是隐形的。

**反模式：模糊描述**

```yaml
# ❌ Claude无法判断何时该用
description: Helps with documents
```

**最佳实践：具体+触发词**

```yaml
# ✅ 明确做什么+列举触发场景
description: |
  从PDF提取文本和表格、填充表单、合并文档。
  当用户处理PDF文件，或提到PDF、表单、文档提取时使用。
  即使没有明确说"PDF"，只要涉及文档处理就应考虑此Skill。
```

关键技巧：Claude 存在**欠触发**（undertrigger）倾向——宁可不用也不误用。应对方法是在 description 中适度"推销"你的 Skill，明确列举触发场景。

### 2.3 调用控制矩阵

| Frontmatter 组合 | 用户可调用 | Claude可自动调用 | 子代理可用 |
|-----------------|----------|----------------|----------|
| 默认（都不设） | ✅ | ✅ | ❌（内联运行） |
| `context: fork` | ✅ | ✅ | ✅ |
| `disable-model-invocation: true` | ✅ | ❌ | ❌ |
| `context: fork` + `disable-model-invocation: true` | ✅ | ❌ | ✅（被显式委派时） |
| `user-invocable: false` | ❌ | ✅ | 取决于context |

**何时用哪种组合：**

- **公开工具型 Skill**（如代码审查、文档生成）：默认配置即可
- **工作流编排型**（如多步骤部署流水线）：`disable-model-invocation: true`，只在你明确输入 `/deploy-pipeline` 时触发
- **后台知识型**（如编码规范、架构决策）：`user-invocable: false`，让 Claude 在相关场景自动引用
- **可被其他 Skill 调用的专家型**：`context: fork`，使其成为可被编排的子代理

### 2.4 allowed-tools：权限沙箱

`allowed-tools` 限制 Skill 激活时 Claude 可用的工具集。**注意：省略此字段并不意味着无限制——而是遵循用户的正常权限设置。**

```yaml
# 只读审查Skill——不修改任何文件
allowed-tools: Read, Grep, Glob

# 数据分析Skill——只操作表格
allowed-tools: Read, Write, Bash

# 完全无限制——使用用户的全局权限
# （不设allowed-tools字段）
```

**实践建议**：大多数情况下不要设 `allowed-tools`。只在以下场景使用：

1. 安全敏感的工作流（如只读审查）
2. 明确限定范围的自动化（如只操作特定文件类型）
3. 防止 Skill 意外越权的防护栏

---

## 三、Inline vs Fork：Skill 架构的核心决策

### 3.1 两种执行上下文

这是设计 Skill 时**最重要的架构决策**，选错会导致 Skill 静默失败。

**Inline（默认）**：Skill 指令注入主对话上下文，Claude 在当前会话中直接执行。

```yaml
# 默认行为，不需要显式声明
---
name: code-conventions
description: 本项目编码规范参考
---
```

**Fork（context: fork）**：Skill 在独立的子代理中运行，拥有隔离的上下文。

```yaml
---
name: deep-research
description: 使用多源检索深度调研指定主题
context: fork
agent: Explore
---
```

### 3.2 关键约束：子代理不能嵌套

**子代理不能产生其他子代理。** 一个使用 `context: fork` 运行的 Skill **不能**：

- 使用 Task 工具启动并行探索代理
- 使用 Skill 工具调用其他 Skill
- 执行任何多代理编排工作流

### 3.3 决策矩阵

| 你的 Skill 需要... | 选择 | 原因 |
|-------------------|------|------|
| 编排并行代理（Task工具） | **Inline** | 子代理不能产生子代理 |
| 调用其他Skill（Skill工具） | **Inline** | 子代理不能调用Skill |
| 运行Bash命令操作外部CLI | **Inline** | 主上下文有完整工具访问 |
| 执行单一聚焦任务（研究、分析） | **Fork** | 隔离上下文，干净执行 |
| 提供参考知识（编码规范） | **Inline** | 指导性内容丰富主对话 |
| 需要被其他Skill调用 | **Fork** | 必须是子代理才能被产生 |

### 3.4 实战案例：编排者-专家模式

最强大的组合模式是**编排者（Inline）调用专家（Fork）**：

```
product-analysis（Inline，编排者）
  ├─ Task agents 并行探索
  ├─ Skill('competitors-analysis', 'X') → Fork子代理
  └─ 综合所有结果

competitors-analysis（Fork，专家）
  └─ 单一聚焦任务：分析一个竞品代码库
```

编排者 Skill 的 SKILL.md：

```yaml
---
name: product-analysis
description: |
  多路径并行产品分析，综合竞品调研、技术评估和用户反馈。
  当用户要求产品分析、竞品对比、市场调研时使用。
---

# 产品分析编排器

## 执行流程

1. 检测可用工具（`which codex` 等）
2. 启动 3-5 个 Task 代理并行探索
3. 可选调用 /competitors-analysis via Skill 工具
4. 综合所有结果生成报告
```

专家 Skill 的 SKILL.md：

```yaml
---
name: competitors-analysis
description: 深度分析指定竞品的技术架构与产品策略
context: fork
agent: Explore
---

# 竞品分析专家

## 执行流程

1. 使用 Glob 和 Grep 搜索相关文件
2. 读取并分析代码结构
3. 按模块输出分析结果，附具体文件引用
```

```mermaid
flowchart LR
    subgraph 主上下文
        A[product-analysis<br/>Inline编排者] --> B[Task Agent 1]
        A --> C[Task Agent 2]
        A --> D[Skill: competitors-analysis]
    end

    subgraph 隔离子代理
        D --> E[Explore子代理<br/>Fork模式]
        E --> F[Glob/Grep/Read]
    end

    B --> G[综合报告]
    C --> G
    F --> G
```

---

## 四、变量替换与动态上下文

### 4.1 内置变量

Skill 正文中可以使用以下变量，在执行时被替换为实际值：

| 变量 | 说明 | 示例值 |
|------|------|-------|
| `$ARGUMENTS` | 用户传入的全部参数 | `quantum computing` |
| `$ARGUMENTS[0]` / `$0` | 第一个位置参数 | `quantum` |
| `$ARGUMENTS[1]` / `$1` | 第二个位置参数 | `computing` |
| `${CLAUDE_SESSION_ID}` | 当前会话ID | `abc123` |
| `${CLAUDE_SKILL_DIR}` | SKILL.md所在目录 | `/home/user/.claude/skills/my-skill` |

**实战：带参数的搜索 Skill**

```yaml
---
name: issue-fixer
description: 根据GitHub issue编号自动定位并修复问题
argument-hint: "[issue-number]"
---

# Issue 修复器

## 执行步骤

1. 运行 `gh issue view $ARGUMENTS[0]` 获取issue详情
2. 分析issue描述，定位相关代码文件
3. 实施修复并运行相关测试
4. 创建PR：`git commit -m "fix: resolve #$ARGUMENTS[0]"`
```

用户输入 `/issue-fixer 1234` 时，`$ARGUMENTS[0]` 被替换为 `1234`。

### 4.2 自动检测优于手动标记

**永远不要为可自动检测的能力添加手动标记。** 与其要求用户传 `--with-docker`，不如在 Skill 内部检测：

```markdown
## Step 0: 检测环境能力
- `which docker` → 如果存在，启用容器化执行
- `ls package.json` → 如果存在，针对Node.js项目优化
- `which python3` → 如果存在，使用Python脚本辅助
```

原则：**能力自动检测，用户决定范围。**

---

## 五、Skill 调试诊断全流程

### 5.1 常见故障与排查

**故障一：Claude 不使用我的 Skill**

这是最常见的问题。排查清单：

```bash
# 1. 检查文件路径是否正确
# 个人Skill
ls ~/.claude/skills/my-skill/SKILL.md
# 项目Skill
ls .claude/skills/my-skill/SKILL.md

# 2. 检查YAML语法
cat SKILL.md | head -15
# 确保：第一行是---、关闭---在Markdown之前、无Tab缩进

# 3. 启动调试模式
claude --debug
# 观察Skill加载日志，查找错误信息
```

**故障二：Skill 加载但行为异常**

```bash
# 检查脚本权限
chmod +x .claude/skills/my-skill/scripts/*.py

# 检查路径格式（必须用正斜杠）
# ✅ scripts/helper.py
# ❌ scripts\helper.py
```

**故障三：多个 Skill 冲突**

当两个 Skill 的 description 重叠时，Claude 可能选错。解决方法是用**不同的触发词**区分：

```yaml
# Skill A - 明确限定范围
description: 分析Excel电子表格、创建数据透视表和图表。当处理Excel文件、电子表格、.xlsx格式数据时使用。

# Skill B - 与A完全不同的触发词
description: 分析系统日志文件和性能指标数据。用于性能监控、故障排查、系统诊断。
```

### 5.2 调试工作流

```mermaid
flowchart TD
    A[Claude未使用Skill] --> B{文件路径正确?}
    B -->|否| C[修正路径<br/>~/.claude/skills/ 或 .claude/skills/]
    B -->|是| D{YAML语法有效?}
    D -->|否| E[修复Frontmatter<br/>检查---分隔符和缩进]
    D -->|是| F{description足够具体?}
    F -->|否| G[增加触发词<br/>列举使用场景和关键词]
    F -->|是| H{与其他Skill冲突?}
    H -->|是| I[差异化description<br/>使用不重叠的触发词]
    H -->|否| J[用--debug启动<br/>查看加载日志]
```

---

## 六、Skill 评估测试（Eval）实战

### 6.1 为什么需要 Eval

Skill 写完了不等于写好了。没有测试的 Skill 就像没有 CI 的代码——在你电脑上能用，换个场景就可能崩。

评估分两个维度：

| 维度 | 方法 | 适用场景 |
|------|------|---------|
| **定性评估** | 人工审查输出质量 | 写作风格、设计类Skill |
| **定量评估** | 自动化测试用例 | 代码生成、数据提取、文件转换 |

### 6.2 构建测试用例

使用 `skill-creator` 工具链的推荐流程：

**Step 1：编写测试提示词**

创建 5-10 个覆盖 Skill 核心场景的测试提示：

```json
{
  "test_cases": [
    {
      "prompt": "帮我审查 src/auth.ts 的安全性",
      "expected_contains": ["SQL注入", "XSS", "输入验证"],
      "expected_not_contains": ["TODO", "不确定"]
    },
    {
      "prompt": "检查最近的commit有没有安全问题",
      "expected_contains": ["敏感信息", "硬编码"],
      "expected_not_contains": ["看起来没问题"]
    }
  ]
}
```

**Step 2：批量运行**

```bash
# 使用Claude Code非交互模式批量测试
claude -p "使用 /security-review 审查 src/auth.ts" --allowedTools "Read,Grep,Glob" 2>&1 | tee results/test1.log
claude -p "使用 /security-review 检查最近的commit" --allowedTools "Read,Grep,Glob,Bash" 2>&1 | tee results/test2.log
```

**Step 3：量化评分**

对每个测试结果打分：

| 指标 | 权重 | 评分方法 |
|------|------|---------|
| 触发准确率 | 30% | Skill是否在应当触发时被激活 |
| 输出完整度 | 30% | 是否覆盖expected_contains中的关键点 |
| 误触发率 | 20% | 是否在不相关场景被错误激活 |
| 执行效率 | 20% | Token消耗和执行轮次是否合理 |

### 6.3 迭代优化循环

```mermaid
flowchart LR
    A[编写测试用例] --> B[批量运行测试]
    B --> C[量化评分]
    C --> D{得分≥阈值?}
    D -->|是| E[✅ Skill可发布]
    D -->|否| F[分析失败案例]
    F --> G[修改SKILL.md]
    G --> B
```

每次修改 SKILL.md 后重新运行全部测试，确保改动没有引入回归。

---

## 七、多文件 Skill 架构设计

### 7.1 何时拆分为多文件

**拆分信号**：

- SKILL.md 超过 400 行且每节都在"赚"它的位置
- Skill 支持多个框架/平台（AWS/GCP/Azure）
- 有大量参考资料只在特定场景需要

**不拆分信号**：

- SKILL.md 虽长但内容高度相关
- 拆分后每个文件只有几十行
- 参考内容在大多数场景都会用到

### 7.2 实战：多云部署 Skill

```
cloud-deploy/
├── SKILL.md              # 工作流入口 + 平台选择逻辑
├── references/
│   ├── aws.md            # AWS部署详细步骤
│   ├── gcp.md            # GCP部署详细步骤
│   └── azure.md          # Azure部署详细步骤
├── scripts/
│   ├── preflight.sh      # 部署前检查脚本
│   └── rollback.sh       # 回滚脚本
└── templates/
    ├── dockerfile.tmpl   # Dockerfile模板
    └── ci-config.tmpl    # CI配置模板
```

SKILL.md 中的引用方式：

```markdown
# 云部署 Skill

## 平台选择

根据项目配置自动选择目标平台：
- 存在 `aws.tf` → 读取 [AWS部署指南](references/aws.md)
- 存在 `cloudbuild.yaml` → 读取 [GCP部署指南](references/gcp.md)
- 存在 `azure-pipelines.yml` → 读取 [Azure部署指南](references/azure.md)

## 预检查

运行部署前检查：
```bash
bash scripts/preflight.sh
```
```

Claude 只在检测到对应平台标识文件时才读取具体的参考文档，避免无谓的上下文消耗。

---

## 八、Skill 分发：从个人到团队

### 8.1 三级分发路径

| 路径 | 范围 | 方式 | 适用场景 |
|------|------|------|---------|
| 个人目录 | 仅自己 | `~/.claude/skills/` | 个人生产力工具 |
| 项目仓库 | 团队 | `.claude/skills/` + git | 项目特定工作流 |
| 插件市场 | 社区 | Plugin打包发布 | 通用工具分享 |

### 8.2 项目级分发

```bash
# 1. 在项目中创建Skill
mkdir -p .claude/skills/team-code-review
cat > .claude/skills/team-code-review/SKILL.md << 'EOF'
---
name: team-code-review
description: |
  按团队编码规范审查代码变更。
  当用户请求代码审查、PR审查、检查代码质量时使用。
---

# 团队代码审查

## 审查清单
1. 命名规范（camelCase for JS, snake_case for Python）
2. 错误处理（不允许裸catch）
3. 测试覆盖率（新增代码必须有测试）
4. 安全检查（无硬编码密钥、无SQL拼接）
EOF

# 2. 提交到git
git add .claude/skills/
git commit -m "Add team code review skill"
git push

# 3. 团队成员pull后自动可用
git pull
claude  # Skill立即可用
```

### 8.3 插件级分发

对于需要跨项目、跨团队分享的 Skill，打包为 Plugin 是推荐方式：

```bash
# 使用skill-creator打包
# 在Claude Code中执行：
/create-skill  # 按引导创建并打包

# 或手动构建插件结构
my-plugin/
├── plugin.json
├── skills/
│   └── my-skill/
│       └── SKILL.md
└── README.md
```

安装方式：

```bash
# 从GitHub安装
claude plugin marketplace add https://github.com/user/my-plugin
claude plugin install my-skill@my-plugin
```

---

## 九、实战案例：从零构建一个生产级代码审查 Skill

### 9.1 需求分析

构建一个覆盖安全、性能、可维护性三个维度的代码审查 Skill：

- 自动检测变更文件
- 按维度输出结构化审查报告
- 支持自定义规则扩展
- 只读操作，不修改代码

### 9.2 架构设计

```
security-review/
├── SKILL.md
├── references/
│   ├── security-checklist.md
│   ├── performance-patterns.md
│   └── maintainability-guide.md
└── scripts/
    └── diff-analyzer.py
```

### 9.3 完整实现

**SKILL.md：**

```yaml
---
name: security-review
description: |
  多维度代码安全审查：安全漏洞、性能瓶颈、可维护性问题。
  当用户请求代码审查、安全检查、PR审查、代码质量分析时使用。
  即使用户只说"看看这段代码"，也应考虑使用此Skill。
allowed-tools: Read, Grep, Glob, Bash
---
```

```markdown
# 安全代码审查

## 执行流程

### Step 1: 获取变更范围
```bash
# 如果在git仓库中，获取最近的变更
git diff --name-only HEAD~1 2>/dev/null || echo "非git仓库"
```

### Step 2: 三维度审查

对每个变更文件，按以下三个维度审查：

#### 安全维度（参考 [security-checklist.md](references/security-checklist.md)）
- SQL注入风险
- XSS攻击面
- 硬编码凭证
- 不安全的反序列化

#### 性能维度（参考 [performance-patterns.md](references/performance-patterns.md)）
- N+1查询
- 内存泄漏风险
- 不必要的同步操作
- 缺失的缓存策略

#### 可维护性维度（参考 [maintainability-guide.md](references/maintainability-guide.md)）
- 函数复杂度
- 命名一致性
- 注释完整性
- 测试覆盖

### Step 3: 输出报告

按以下格式输出：

| 维度 | 文件 | 行号 | 严重性 | 描述 | 建议 |
|------|------|------|--------|------|------|

严重性等级：🔴 严重 | 🟡 警告 | 🔵 建议
```

**references/security-checklist.md（示例）：**

```markdown
# 安全检查清单

## 注入攻击
- [ ] SQL参数化查询检查
- [ ] 命令注入防护
- [ ] LDAP注入防护
- [ ] 模板注入检查

## 认证与授权
- [ ] 密码存储方式（bcrypt/argon2）
- [ ] Session管理
- [ ] JWT验证完整性
- [ ] CORS配置合理性
```

### 9.4 测试验证

```bash
# 创建测试环境
mkdir -p /tmp/skill-test && cd /tmp/skill-test
git init

# 创建一个故意有安全问题的文件
cat > auth.ts << 'EOF'
const password = "admin123"; // 硬编码密码
const query = "SELECT * FROM users WHERE name = '" + userName + "'"; // SQL注入
eval(userInput); // 代码注入
EOF

git add . && git commit -m "add auth"

# 在Claude Code中测试
claude -p "帮我审查 auth.ts 的安全性"
```

预期输出应包含三个维度的发现，其中安全维度应识别出硬编码密码、SQL注入和代码注入三个问题。

---

## 十、高级模式与最佳实践

### 10.1 正交设计原则

每个 Skill 应只关注一个领域。需要跨领域协作时，通过组合而非堆叠：

```
❌ 错误：一个巨型Skill处理所有事情
code-review-all-in-one（安全+性能+风格+测试+部署）

✅ 正确：多个正交Skill按需组合
security-review  ← 安全维度
perf-review      ← 性能维度  
style-review     ← 代码风格
test-coverage    ← 测试覆盖
deploy-check     ← 部署前检查
```

### 10.2 Pipeline 手接模式

Skill 可以形成顺序管道——一个的输出是下一个的输入。在 SKILL.md 末尾添加"下一步建议"：

```markdown
## Next Step

审查完成后，建议下一步：

> 代码审查已完成。是否需要：
> A) /security-review — 对发现的安全问题深入分析（推荐）
> B) /fix-security — 自动修复发现的安全问题
> C) 结束 — 当前输出已足够
```

**管道示例**：

```
youtube-downloader → asr-transcribe → transcript-fixer → meeting-minutes → pdf-creator
```

### 10.3 版本管理

在 SKILL.md 中记录版本历史，帮助团队追踪变更：

```markdown
## Version History
- v2.0.0 (2026-05-01): 新增多维度审查，breaking change
- v1.1.0 (2026-04-15): 增加性能检查维度
- v1.0.0 (2026-04-01): 初始版本，仅安全审查
```

### 10.4 不要使用的无效字段

以下字段不被 Claude Code 识别，写入 Frontmatter 只会浪费上下文 Token：

- `license` — 不是 Frontmatter 字段
- `compatibility` — 不是 Frontmatter 字段
- `metadata`、`author`、`version` — 不是 Frontmatter 字段

如需记录这些信息，放在 Markdown 正文中，不要放在 Frontmatter。

---

## 完整工作流总览

```mermaid
flowchart TD
    A[需求分析] --> B[Prior Art调研<br/>8通道检索]
    B --> C{已有成熟工具?}
    C -->|是| D[采纳/扩展]
    C -->|否| E[从零构建]
    D --> F[设计架构<br/>Inline vs Fork]
    E --> F
    F --> G[编写SKILL.md<br/>+ 附属文件]
    G --> H[编写测试用例]
    H --> I[批量运行测试]
    I --> J{量化评分通过?}
    J -->|否| K[分析失败+修改]
    K --> I
    J -->|是| L[选择分发路径]
    L --> M[个人: ~/.claude/skills/]
    L --> N[团队: .claude/skills/ + git]
    L --> O[社区: Plugin打包发布]
```

---

## 延伸阅读

- [Claude Code Skills 官方文档](https://code.claude.com/docs/en/skills) — Anthropic 官方 Skills 指南，包含创建、管理和分享
- [Agent Skills 概述](https://docs.claude.com/en/docs/agents-and-tools/agent-skills/overview) — Skills 工作原理的深层解释
- [Skills Best Practices](https://docs.claude.com/en/docs/agents-and-tools/agent-skills/best-practices) — Anthropic 官方 Skill 编写最佳实践
- [Equipping Agents for the Real World](https://www.anthropic.com/engineering/equipping-agents-for-the-real-world-with-agent-skills) — Anthropic 工程博客，Agent Skills 架构设计理念
- [Claude Code Frontmatter Reference](https://github.com/ThibautBaissac/rails_ai_agents/blob/main/docs/claude-code-frontmatter-reference.md) — 社区维护的完整 Frontmatter 字段参考

## 训练营适用性评估

| 训练营类型 | 适配度 | 说明 |
|-----------|--------|------|
| AI工具入门营 | ⭐⭐ | 需先完成基础Skill创建教程 |
| **前端/后端开发营** | ⭐⭐⭐⭐⭐ | 直接可用，代码审查Skill即学即用 |
| **DevOps/SRE营** | ⭐⭐⭐⭐⭐ | 多云部署Skill高度匹配 |
| 安全训练营 | ⭐⭐⭐⭐ | 安全审查Skill可作为实战项目 |
| **AI Agent开发营** | ⭐⭐⭐⭐⭐ | 编排者-专家模式是Agent架构核心模式 |

**预计教学时长**：4-6小时（含实战演练）

**推荐教学路径**：基础Skill创建（1h）→ Frontmatter字段实验（1h）→ Inline/Fork架构对比（1h）→ 多文件Skill实战（1-2h）→ 评估测试闭环（1h）

## 参考来源

1. [Extend Claude with skills - Claude Code Docs](https://code.claude.com/docs/en/skills) — Anthropic 官方 Skills 完整文档，包含创建、测试、分享全流程
2. [Claude Code Frontmatter Reference - GitHub](https://github.com/ThibautBaissac/rails_ai_agents/blob/main/docs/claude-code-frontmatter-reference.md) — 社区维护的完整 YAML Frontmatter 字段参考，覆盖 Agent/Skill/Command/Rules 四类文件
3. [Claude Code Skills Marketplace - GitHub](https://github.com/daymade/claude-code-skills) — 生产级 Skill 市场仓库，包含 53 个可直接安装的 Skill 和增强版 skill-creator
4. [CLAUDE_CODE_SKILL_TUTORIAL.md - GitHub](https://github.com/StrayDragon/my-claude-skills/blob/main/CLAUDE_CODE_SKILL_TUTORIAL.md) — 开源 Skill 教程，涵盖创建、使用、管理全生命周期
5. [How to Build Claude Code Skills - dev.to](https://dev.to/whoffagents/how-to-build-claude-code-skills-custom-slash-commands-that-actually-work-1nje) — 实战导向的 Skill 构建指南，侧重于"真正可用"的 Skill 设计

> [!tip] 51学通信知识星球
> **星主：爱卫生**（微信：gprshome201101）——公众号「51学通信」创办者，19 年通信行业运维与讲师经验，著有《GPRS网络信令实例详解》《EPC原理与实践》《5G核心网原理与实践》三本纸质书（各大电商平台有售）。
> **星球定位**：深耕 5G 核心网、IMS、NFV/AI、云原生等 ICT 领域，主打运维岗位与信令分析。
> **当前规模**：5200 篇主题 / 990 个回答，198 元/年。
> **加入福利**：加入星球后请加爱卫生微信，拉您进知识星球年度陪伴与答疑群——不限量回复您的各种问题，另有群内分享。
> **AI 加持**：51学通信知识星球已作为 skill 接入 WorkBuddy，使用 deepseek-4-flash 在海量星球帖子中精准找贴、找视频、找 FAQ 和案例，做总结、找文档和 PPT 等场景全覆盖。

![51学通信知识星球海报-扫码加入](https://wiki.500nian.com/images/zhixingqiu_qrcode.png)