Start with a task you can recognize

A useful skill begins with a repeatable job. “Help with development” is too broad to evaluate. “Review Docker Compose files and explain risky service configuration” gives you a task, a context, and an output to inspect.

Before drafting, write down a few real requests you would use the skill for. Add a few neighboring tasks that should stay outside its scope. These examples become the beginning of your evaluation set, and they make it easier to spot a description that promises too much.

Install the workflow

For OpenCode V2, run the global installer, then restart OpenCode:

Terminal
npx opencode-skill-creator install --global

The installer adds the package to the V2 plugins array while preserving existing entries. Supported OpenCode V1 versions ≥ 1.18.29 require manual registration under the singular plugin key. Use the documentation for your runtime rather than copying both forms into your configuration.

Give the agent a concrete brief

Tell OpenCode what the skill should do, what it should leave alone, and what you want to see in the result. A short, bounded brief is more useful than a list of abstract adjectives.

Example prompt
Use opencode-skill-creator to create a Docker Compose review skill.

Use it when I ask for a review of a Compose file. Explain risky configuration and suggest focused changes. Do not rewrite unrelated application code. Include examples that should and should not trigger it.

Keep the draft in a temporary staging directory outside the working repository. A separate evaluation workspace prevents generated runs and reports from mixing with your source files. On Windows, use an appropriate directory under %TEMP% instead of the Unix paths shown in the docs.

Read the draft before you expand it

The workflow produces a SKILL.md file and any supporting material the task needs. Read the description first: does it explain when the agent should select the skill? Then read the instructions: do they make the intended result and boundaries clear?

Use skill_validate to check structure and frontmatter. That check is useful, but a structurally valid skill can still contain vague or incorrect guidance. Compare the draft with the examples you wrote before asking for more features.

Check selection and output separately

Run positive and negative trigger cases with skill_eval. Include near misses, such as explaining a Compose concept without reviewing a file. Investigate both false positives and false negatives.

Then inspect the actual work. Compare output produced with the skill against a baseline without it. Does the skill improve the review, preserve the task boundary, and explain its recommendations? A good trigger result does not answer those questions for you.

Install the version you chose

After reviewing the candidate, install the finished skill into the project or global skills directory appropriate to its use. Keep the draft, evaluation cases, and comparison evidence so a later revision can be judged against the same work.

You do not need a large skill to begin. A small skill with a clear job and a useful test set gives you something concrete to improve.