skill-creator

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Skill Creator

Skill 创建指南

Create opencode skills that extend agent capabilities with specialized knowledge and workflows.
<overview>
创建可通过专业知识和工作流扩展Agent能力的OpenCode Skill。
<overview>

What Skills Provide

Skill能提供什么

  • Specialized workflows - Multi-step procedures for specific domains
  • Tool integrations - Instructions for file formats, APIs, libraries
  • Domain expertise - Company-specific knowledge, schemas, business logic
  • Bundled resources - Reusable scripts, references, and assets
  • 专业工作流 - 针对特定领域的多步骤流程
  • 工具集成 - 关于文件格式、API、库的使用说明
  • 领域专业知识 - 企业专属知识、Schema、业务逻辑
  • 捆绑资源 - 可复用的脚本、参考资料和资产

Skill Locations

Skill存储位置

ScopePath
Project
.opencode/skill/<name>/SKILL.md
Global
~/.config/opencode/skill/<name>/SKILL.md
  • Project skills: Team-shared, repo-specific (e.g.,
    our-api-patterns
    ,
    project-deploy
    )
  • Global skills: Personal tools for all projects (e.g.,
    pdf-editor
    ,
    commit-helper
    )
For project paths, OpenCode walks up from cwd to git worktree root.
</overview> <structure>
范围路径
项目级
.opencode/skill/<name>/SKILL.md
全局级
~/.config/opencode/skill/<name>/SKILL.md
  • 项目级Skill:团队共享、针对特定仓库(例如:
    our-api-patterns
    project-deploy
  • 全局级Skill:适用于所有项目的个人工具(例如:
    pdf-editor
    commit-helper
对于项目级路径,OpenCode会从当前工作目录向上遍历到Git工作区根目录。
</overview> <structure>

Skill Structure

Skill结构

skill-name/
├── SKILL.md              # Required - frontmatter + instructions
├── scripts/              # Optional - executable code (Python/Bash)
├── references/           # Optional - docs loaded on-demand
└── assets/               # Optional - templates, images, fonts
skill-name/
├── SKILL.md              # 必填 - 前置元数据 + 使用说明
├── scripts/              # 可选 - 可执行代码(Python/Bash)
├── references/           # 可选 - 按需加载的文档
└── assets/               # 可选 - 模板、图片、字体

SKILL.md Format

SKILL.md格式

yaml
---
name: skill-name
description: [Self-contained workflow summary — see guidelines below]
---
yaml
---
name: skill-name
description: [自包含的工作流摘要 — 请遵循下方指南]
---

Instructions here (markdown body)

此处为说明内容(Markdown格式)


**Name**: Short, hyphen-case identifier. Should be descriptive but concise (max 64 chars).

**Description**: Agent sees this + the name before loading. Must be self-contained with:
- What workflow/capabilities it provides
- "Use proactively when" trigger contexts
- 3-5 concrete examples


**CRITICAL: The `description` field is the primary trigger mechanism.**

Skills are **SOPs/workflows**, NOT agents. DO NOT use role descriptions like "You are a..." or "[Role] expert."

Before loading, the agent sees only the **name** and **description** in `<available_skills>`:
<available_skills> <skill> <name>skill-name</name> <description>...</description> </skill> </available_skills>

The description must be self-contained — agents won't load a skill just to "see what it does."

**Name + description should work together:**
- **Name**: Short, hyphen-case identifier (e.g., `typescript-advanced`)
- **Description**: Self-contained workflow summary with capabilities, triggers, and examples

**Description pattern (LLM-optimized):**
```yaml
---
name: skill-name
description: |-
  [Action verb/capabilities]. Use for [specific cases]. Use proactively when [contexts].
  
  Examples:
  - user: "query" → action
  - user: "query" → action
---
Dense, machine-parseable, specific. Avoid prose.
CRITICAL YAML SYNTAX: Multi-line descriptions with examples MUST use literal block scalar (
|-
). The hyphen strips the trailing newline. Do NOT use plain YAML with unquoted colons or lists:
yaml
undefined

**Name**:简短的连字符分隔标识符。需兼具描述性和简洁性(最多64个字符)。

**Description**:Agent在加载Skill前会看到该内容和Name字段。必须包含以下自包含信息:
- 该Skill提供的工作流/能力
- 「主动使用场景」触发上下文
- 3-5个具体示例


**关键提示:`description`字段是主要的触发机制。**

Skill是**标准操作流程/工作流**,而非Agent。请勿使用角色描述,例如“你是一个...”或“[角色]专家”。

加载前,Agent只会在`<available_skills>`中看到**Name**和**Description**:
<available_skills> <skill> <name>skill-name</name> <description>...</description> </skill> </available_skills>

描述必须自包含 — Agent不会仅仅为了“看看它能做什么”而加载Skill。

**Name + Description需协同工作:**
- **Name**:简短的连字符分隔标识符(例如:`typescript-advanced`)
- **Description**:包含能力、触发场景和示例的自包含工作流摘要

**针对LLM优化的描述模板:**
```yaml
---
name: skill-name
description: |-
  [动作动词/能力范围]。用于[特定场景]。在[上下文场景]下主动使用。
  
  示例:
  - user: "查询内容" → 执行操作
  - user: "查询内容" → 执行操作
---
内容需简洁、可被机器解析、具体。避免冗长的散文式描述。
关键YAML语法: 包含示例的多行描述必须使用文字块标量(
|-
)。连字符会去除末尾的换行符。请勿使用未加引号的冒号或列表的普通YAML格式:
yaml
undefined

❌ WRONG - breaks YAML parsing

❌ 错误 - 会破坏YAML解析

description: Handle plugins. Examples:
  • user: "..." → action
description: 处理插件。示例:
  • user: "..." → 操作

✅ CORRECT - use |- for multi-line

✅ 正确 - 对多行内容使用 |-

description: |- Handle plugins.
Examples:
  • user: "..." → action

**Example:**
```yaml
---
name: typescript-advanced
description: |-
  Handle TypeScript 5.9 advanced typing, generics, strict configs, type errors, migrations,
  erasable syntax compliance, and test writing. Use proactively for complex generics,
  conditional types, utility types, TS compiler config, or test authoring.
  
  Examples:
  - user: "Create a type-safe event emitter" → implement with generics and mapped types
  - user: "Migrate to strict TypeScript" → add discriminated unions, exhaustive checks
  - user: "Build typed API client from OpenAPI" → generate request/response types with inference
  - user: "Write unit tests" → create strict, typed tests with realistic fixtures
---
Requirements:
  • Start with action verb (NOT "You are" or "[Role] expert")
  • List specific capabilities (vague "helps with X" = ignored)
  • Include "Use proactively when" trigger contexts
  • Provide 3-5 concrete
    user: "..." → ...
    examples
  • Use
    |-
    literal block scalar for multi-line descriptions (plain YAML with lists/colons breaks parsing)
  • Dense, LLM-parseable — description alone must justify loading
Reduce redundancy: Don't repeat description content in SKILL.md body.
description: |- 处理插件。
示例:
  • user: "..." → 操作

**示例:**
```yaml
---
name: typescript-advanced
description: |-
  处理TypeScript 5.9的高级类型、泛型、严格配置、类型错误、迁移、
  可擦除语法合规性和测试编写。在处理复杂泛型、条件类型、工具类型、TS编译器配置或测试编写时主动使用。
  
  示例:
  - user: "创建类型安全的事件发射器" → 使用泛型和映射类型实现
  - user: "迁移到严格模式TypeScript" → 添加区分联合类型、穷尽检查
  - user: "从OpenAPI构建类型化API客户端" → 通过推断生成请求/响应类型
  - user: "编写单元测试" → 使用真实测试数据创建严格的类型化测试
---
要求:
  • 以动作动词开头(请勿使用“你是”或“[角色]专家”)
  • 列出具体能力(模糊的“帮助处理X”会被忽略)
  • 包含「在...场景下主动使用」的触发上下文
  • 提供3-5个具体的
    user: "..." → ...
    示例
  • 对多行描述使用
    |-
    文字块标量(包含列表/冒号的普通YAML会导致解析失败)
  • 内容简洁、可被LLM解析 — 仅靠描述就必须能证明加载该Skill的合理性
减少冗余: 请勿在SKILL.md正文中重复描述字段的内容。

Bundled Resources

捆绑资源

DirectoryPurposeWhen to use
scripts/
Reusable Python/Bash codeSame code rewritten repeatedly
references/
Docs, schemas, API specsInfo agent needs while working
assets/
Templates, images, fontsFiles used in output (not loaded)
MUST NOT include: README.md, CHANGELOG.md, INSTALLATION_GUIDE.md, or other auxiliary docs. Skills contain only what the agent needs to do the job.
</structure> <principles>
目录用途使用场景
scripts/
可复用的Python/Bash代码重复编写相同代码时
references/
文档、Schema、API规范Agent工作时需要参考的信息
assets/
模板、图片、字体输出时使用的文件(不会被加载)
禁止包含:README.md、CHANGELOG.md、INSTALLATION_GUIDE.md或其他辅助文档。Skill仅包含Agent完成工作所需的内容。
</structure> <principles>

Core Principles

核心原则

Be Concise

保持简洁

The context window is shared. Only add info the agent doesn't already have.
  • Challenge each paragraph: "Does this justify its token cost?"
  • Prefer examples over explanations
  • SHOULD keep SKILL.md under 500 lines
上下文窗口是共享资源。仅添加Agent不具备的信息。
  • 对每个段落进行审视:“它的token成本是否合理?”
  • 优先使用示例而非解释
  • SKILL.md内容应控制在500行以内

Match Freedom to Fragility

根据场景灵活选择格式

Freedom LevelFormatUse When
HighText instructionsMultiple valid approaches
MediumPseudocode/parameterized scriptsPreferred pattern exists
LowSpecific scriptsFragile ops, consistency critical
自由度等级格式使用场景
文字说明存在多种有效实现方式时
伪代码/参数化脚本存在首选实现模式时
特定脚本操作流程敏感、一致性要求高时

Progressive Disclosure

渐进式披露

  1. Metadata (name + description) - Always loaded (~100 words)
    • The
      description
      is the PRIMARY discovery mechanism
    • Agents see this and decide whether to load the skill
    • If description is vague, the skill will never be used
  2. SKILL.md body - Loaded when skill triggers
    • Core workflow and detailed instructions
    • Keep focused on what the agent needs to do the work
  3. Bundled resources - Loaded on-demand by agent
    • Move variant-specific details to
      references/
Keep core workflow in SKILL.md. Move variant-specific details to
references/
.
Example structure:
cloud-deploy/
├── SKILL.md (workflow + provider selection)
└── references/
    ├── aws.md
    ├── gcp.md
    └── azure.md
Agent loads only the relevant provider file.
</principles> <workflow>
  1. 元数据(Name + Description)- 始终会被加载(约100词)
    • description
      是主要的发现机制
    • Agent会根据这些内容决定是否加载Skill
    • 如果描述模糊,Skill将永远不会被使用
  2. SKILL.md正文 - Skill触发时加载
    • 核心工作流和详细说明
    • 内容需聚焦于Agent完成工作所需的信息
  3. 捆绑资源 - Agent按需加载
    • 将变体相关细节移至
      references/
      目录
将核心工作流保留在SKILL.md中。将变体相关细节移至
references/
目录。
示例结构:
cloud-deploy/
├── SKILL.md (工作流 + 云服务商选择)
└── references/
    ├── aws.md
    ├── gcp.md
    └── azure.md
Agent只会加载相关的云服务商文档。
</principles> <workflow>

Creation Process

创建流程

  1. Understand → Gather concrete usage examples
  2. Plan → Identify reusable scripts/references/assets
  3. Initialize → Create directory and SKILL.md manually
  4. Edit → Write SKILL.md frontmatter + body, add resources
  5. Validate → Verify the skill loads and triggers correctly
  6. Iterate → Test, improve, repeat
  1. 需求梳理 → 收集具体的使用示例
  2. 规划 → 确定可复用的脚本/参考资料/资产
  3. 初始化 → 手动创建目录和SKILL.md文件
  4. 编辑 → 编写SKILL.md的前置元数据和正文,添加资源
  5. 验证 → 验证Skill能否正常加载和触发
  6. 迭代 → 测试、改进、重复

Step 1: Understand

步骤1:需求梳理

Gather concrete examples of how the skill will be used. Ask:
  • "What should this skill do?"
  • "What requests should trigger it?"
  • "Can you give example user queries?"
Skip only if usage patterns are already clear.
收集Skill的具体使用示例。思考以下问题:
  • “这个Skill应该做什么?”
  • “哪些请求应该触发它?”
  • “能否给出用户查询的示例?”
仅当使用模式已明确时可跳过此步骤。

Step 2: Plan

步骤2:规划

For each use case, identify reusable resources:
If you find yourself...Add to...
Rewriting same code
scripts/
Re-discovering schemas/docs
references/
Copying same templates
assets/
Examples:
  • pdf-editor
    : "Rotate this PDF" →
    scripts/rotate_pdf.py
  • bigquery
    : "How many users today?" →
    references/schema.md
  • frontend-builder
    : "Build me a todo app" →
    assets/react-template/
针对每个使用场景,确定可复用的资源:
当你发现自己在...添加到...
重复编写相同代码
scripts/
反复查找Schema/文档
references/
复制相同模板
assets/
示例:
  • pdf-editor
    :“旋转这个PDF” →
    scripts/rotate_pdf.py
  • bigquery
    :“今天有多少用户?” →
    references/schema.md
  • frontend-builder
    :“帮我构建一个待办事项应用” →
    assets/react-template/

Step 3: Initialize

步骤3:初始化

Create the skill directory and SKILL.md manually:
bash
undefined
手动创建Skill目录和SKILL.md文件:
bash
undefined

Global skill (personal tools)

全局级Skill(个人工具)

mkdir -p ~/.config/opencode/skill/my-skill
mkdir -p ~/.config/opencode/skill/my-skill

Project skill (team-specific)

项目级Skill(团队专属)

mkdir -p .opencode/skill/my-skill

Create `SKILL.md` with frontmatter:

```yaml
---
name: my-skill
description: |-
  [Workflow/capabilities]. Use for [specific cases]. Use proactively when [contexts].
  
  Examples:
  - user: "query" → action
  - user: "query" → action
---
mkdir -p .opencode/skill/my-skill

创建包含前置元数据的`SKILL.md`:

```yaml
---
name: my-skill
description: |-
  [工作流/能力范围]。用于[特定场景]。在[上下文场景]下主动使用。
  
  示例:
  - user: "查询内容" → 执行操作
  - user: "查询内容" → 执行操作
---

[Skill Name]

[Skill名称]

[Instructions start here]

**Description template example:**
```yaml
---
name: typescript-advanced
description: |-
  Handle TypeScript 5.9 advanced typing, generics, strict configs, type errors, migrations,
  and test writing. Use proactively for complex generics, conditional types, utility types, TS compiler
config, or test authoring.

Examples:
- user: "Create a type-safe event emitter" → implement with generics and mapped types
- user: "Migrate to strict TypeScript" → add discriminated unions, exhaustive checks
- user: "Build typed API client from OpenAPI" → generate request/response types with inference
- user: "Write unit tests" → create strict, typed tests with realistic fixtures
---
Add optional directories as needed:
bash
cd my-skill
mkdir scripts references assets  # only create what you'll actually use
[说明内容从此处开始]

**描述模板示例:**
```yaml
---
name: typescript-advanced
description: |-
  处理TypeScript 5.9的高级类型、泛型、严格配置、类型错误、迁移、
  和测试编写。在处理复杂泛型、条件类型、工具类型、TS编译器
配置或测试编写时主动使用。

示例:
- user: "创建类型安全的事件发射器" → 使用泛型和映射类型实现
- user: "迁移到严格模式TypeScript" → 添加区分联合类型、穷尽检查
- user: "从OpenAPI构建类型化API客户端" → 通过推断生成请求/响应类型
- user: "编写单元测试" → 使用真实测试数据创建严格的类型化测试
---
根据需要添加可选目录:
bash
cd my-skill
mkdir scripts references assets  # 仅创建实际会用到的目录

Step 4: Edit

步骤4:编辑

Writing guidelines:
  • MUST use imperative form ("Run the script", not "You should run")
  • SHOULD use bullet points over prose
  • SHOULD link to references for detailed info
  • MUST test all scripts before including
Frontmatter requirements:
  • name
    : lowercase-hyphen format, must match directory name exactly
  • description
    : CRITICAL — follow the format specified in <structure> above. This is how agents discover your skill.
编写指南:
  • 必须使用祈使句(“运行脚本”,而非“你应该运行”)
  • 优先使用项目符号而非散文式描述
  • 应链接到参考资料获取详细信息
  • 必须在包含前测试所有脚本
前置元数据要求:
  • name
    :小写连字符格式,必须与目录名称完全匹配
  • description
    :关键内容 — 遵循<structure>部分指定的格式。这是Agent发现你的Skill的方式。

Step 5: Validate

步骤5:验证

Verify the skill is discoverable:
  1. Check structure:
    • SKILL.md
      exists in skill directory
    • Directory name matches
      name:
      in frontmatter exactly
    • YAML frontmatter is valid
  2. Test discovery:
    • The skill should appear in agent's
      <available_skills>
      section
    • Description should be specific enough to match relevant queries
  3. Verify triggers:
    • Read your description — would you know when to use this skill based solely on it?
    • Do the examples cover the main use cases?
Note: Skills are used directly from their directories. No packaging or installation step required.
验证Skill是否可被发现:
  1. 检查结构:
    • 技能目录中存在
      SKILL.md
    • 目录名称与前置元数据中的
      name:
      完全匹配
    • YAML前置元数据格式有效
  2. 测试发现机制:
    • Skill应出现在Agent的
      <available_skills>
      部分
    • 描述应足够具体,以匹配相关查询
  3. 验证触发逻辑:
    • 阅读你的描述 — 仅靠描述你能知道何时使用这个Skill吗?
    • 示例是否覆盖了主要使用场景?
注意: Skill直接从其目录中使用,无需打包或安装步骤。

Step 6: Iterate

步骤6:迭代

After real usage:
  1. Notice where the skill fails to trigger or provides unclear guidance
  2. Update the
    description
    to include missing trigger contexts
  3. Add more examples to the description or SKILL.md body
  4. Re-validate discovery and triggers
</workflow> <permissions>
实际使用后:
  1. 注意Skill未能触发或提供模糊指导的场景
  2. 更新
    description
    以添加缺失的触发上下文
  3. 在描述或SKILL.md正文中添加更多示例
  4. 重新验证发现机制和触发逻辑
</workflow> <permissions>

Agent Permissions

Agent权限

Control skill access per-agent in agent config:
json
{
  "permission": {
    "skill": { "*": "deny", "my-skill": "allow" }
  }
}
Values:
"allow"
,
"deny"
,
"ask"
. Use
"*"
as wildcard default.
</permissions>
<question_tool>
Batching: Use the
question
tool for 2+ related questions. Single questions → plain text.
Syntax:
header
≤12 chars,
label
1-5 words, add "(Recommended)" to default.
When to ask: Ambiguous request, multiple skill patterns apply, or scope unclear.
</question_tool>
在Agent配置中按Agent控制Skill访问权限:
json
{
  "permission": {
    "skill": { "*": "deny", "my-skill": "allow" }
  }
}
权限值:
"allow"
"deny"
"ask"
。使用
"*"
作为通配符默认值。
</permissions>
<question_tool>
批量提问: 当有2个及以上相关问题时,使用
question
工具。单个问题直接使用纯文本。
语法:
header
不超过12个字符,
label
为1-5个单词,默认选项添加“(推荐)”。
提问场景:请求模糊、存在多个Skill模式适用、或范围不明确时。
</question_tool>