Agent Skills, which first originated in Anthropic’s Claude Code, are now widespread to all major coding agents including OpenCode and are even somewhat standardized. This allows various skill aggregation platforms to provide agent-agnostic skills, which is great for sharing knowledge and avoiding unnecessary fragmentation. There is, however, one subtle distinction between Claude Code and OpenCode which makes verbatim-copied skills not fully equivalent between them.
Why skills don’t translate verbatim
OpenCode makes the explicit distinction between visible and callable by agents skills - actual Agent Skills, and skills that are intended only for manual triggering by users - what they call Commands.
In Claude Code a similar behavior is controlled by the disable-model-invocation and user-invocable flags, which have no effect in OpenCode.
Moreover, Claude Code supports some additional flags such as effort, allowed-tools, etc. that tweak skill behavior even further and make interoperability even less smooth.
In practice, however, it is rare that any of these distinctions are truly decisive and skill sharing in general works pretty well.
Decisive or not, I am still not comfortable with blindly installing third-party skills and hoping they will do what I want (and perhaps more importantly won’t do what I don’t want). I believe in personalizing development tools and with coding agents this is literally as easy as writing plain English. Or maybe I just want everything to work my way and am ready to invest time into that.
Adapting Matt Pocock’s skills
In the rest of this post I will explain how I adapted a popular collection of skills from Matt Pocock (author of /grill-me) for OpenCode and personally for me.
From reading through his skills it was immediately clear that:
- Skills are written for Claude Code
- Some skills are intended for manual use only and so should really be Commands in OpenCode
- Some of the skills are too specific to be useful for me
- Even the ones that look promising often seem a tad over-engineered and could be split
There were, however, several ideas and principles I really liked there:
/grill-meitself is so simple and useful for building own understanding and uncovering hidden problems./zoom-outis another simple skill for quickly getting a birds-eye view of the local architecture, especially useful for unfamiliar codebases./diagnosedescribes a systematic way for cracking hard bugs.- Writing and using a CONTEXT.md file that establishes a single domain language for your project, which helps the agent and your colleagues to be more concise and precise in meaning, facilitate consistent naming across the codebase, and avoid misunderstandings and subtle bugs. This file should ideally be loaded into the context at all times together with AGENTS.md.
- Writing architecture decision records (ADR) to document for future reference which possibilities were considered during development and why they were rejected. This is tremendously useful for any newcomers to the codebase and helps to avoid any repeated discussions, while at the same time costing nothing in context.
Interestingly, the last two points were not independent, but instead just sub-files of the /grill-with-docs skill, even though other skills often referenced them.
After that I decided that /grill-me and /zoom-out should never be called by an agent and therefore should go into Commands.
For the rest of the skills the agent should be able to decide itself when it is time to add a new term to the vocabulary, add a new ADR, or bring the big guns to bug fixing.
In the end I converted several of Matt’s multi-file skills into 2 single-file Commands and 3 single-file Skills. I am glad I took time to simplify them and decide when and how they should trigger - hopefully, this will make OpenCode’s behavior more predictable. Note, however, that I don’t think all skills need this explicit treatment - if a skill just describes how to do some specific action (like converting a PDF) then it is perfectly fine to leave it as is.