zeaslity/ProjectAGiPrompt
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
0d511d9a03c659e1b73169590ed1158f4c096a6b
ProjectAGiPrompt/98-AgentSkills/3-Agent Skills 使用与开发实战指南-p.md
zeaslity 631cce9e1e RMDC系统设计文档 整体转换为SKILL
2026-01-21 16:15:49 +08:00

25 KiB
Raw Blame History

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 默认形式）如下：

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 为例（官方文档类似示例）：

---
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，可以采用固定骨架：

# <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 / 数据仓库查询规范。

典型做法是：

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

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

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

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

---
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 中写明：
    • 何时触发该脚本；
    • 调用方式（命令行参数、输入输出文件）；
    • 如何基于脚本输出继续生成响应。

示例片段：

### 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 模板。