Skill Creator

Create opencode skills that extend agent capabilities with specialized knowledge and workflows.

What Skills Provide

• •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

Skill Locations

• •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)

OpenCode walks up from cwd to git worktree root for project paths.

Skill Structure

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.md Format

---
name: skill-name
description: [Self-contained workflow summary — see guidelines below]
---
# Instructions here (markdown body)

Name: MUST be short, hyphen-case identifier. SHOULD be 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

The description field is the PRIMARY trigger mechanism.

Skills are SOPs/workflows, NOT agents. MUST 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):

---
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.

YAML SYNTAX: Multi-line descriptions with examples MUST use literal block scalar (|-). The hyphen strips the trailing newline. MUST NOT use plain YAML with unquoted colons or lists:

# WRONG - breaks YAML parsing
description: Handle plugins. Examples:
- user: "..." → action

# CORRECT - use |- for multi-line
description: |-
  Handle plugins.
  
  Examples:
  - user: "..." → action

---
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:

• •MUST start with action verb (NOT "You are" or "[Role] expert")
• •MUST list specific capabilities (vague "helps with X" = ignored)
• •MUST include "Use proactively when" trigger contexts
• •MUST provide 3-5 concrete user: "..." → ... examples
• •MUST use |- literal block scalar for multi-line descriptions
• •SHOULD be dense, LLM-parseable — description alone must justify loading
• •SHOULD NOT repeat description content in SKILL.md body

Bundled Resources

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.

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

Match Freedom to Fragility

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
   • •SHOULD focus on what the agent needs to do the work
3. •

   Bundled resources - Loaded on-demand by agent

   • •SHOULD 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.

Creation Process

Step 1: Understand

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?"

MAY skip only if usage patterns are already clear.

Step 2: Plan

For each use case, identify reusable resources:

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/

Step 3: Initialize

Create the skill directory and SKILL.md manually:

# Global skill (personal tools)
mkdir -p ~/.config/opencode/skill/my-skill

# Project skill (team-specific)
mkdir -p .opencode/skill/my-skill

Create SKILL.md with frontmatter:

---
name: my-skill
description: |-
  [Workflow/capabilities]. Use for [specific cases]. Use proactively when [contexts].
  
  Examples:
  - user: "query" → action
  - user: "query" → action
---
# [Skill Name]

[Instructions start here]

Add optional directories as needed:

cd my-skill
mkdir scripts references assets  # only create what you'll actually use

Step 4: Edit

Writing requirements:

• •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: MUST be lowercase-hyphen format, MUST match directory name exactly
• •description: MUST follow the format specified in <structure> above

Step 5: Validate

Verify the skill is discoverable:

1. •

   Check structure:

   • •SKILL.md MUST exist in skill directory
   • •Directory name MUST match name: in frontmatter exactly
   • •YAML frontmatter MUST be 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?

Skills are used directly from their directories. No packaging or installation step required.

Step 6: Iterate

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

Agent Permissions

Control skill access per-agent in agent config:

{
  "permission": {
    "skill": { "*": "deny", "my-skill": "allow" }
  }
}

Values: "allow", "deny", "ask". Use "*" as wildcard default.

Question Tool Usage

Batching: SHOULD use the question tool for 2+ related questions. Single questions → plain text.

Syntax: header MUST be ≤12 chars, label MUST be 1-5 words, SHOULD add "(Recommended)" to default.

When to ask: Ambiguous request, multiple skill patterns apply, or scope unclear.