Reuse a skill your team already wrote

In the last lesson you packaged feedmill’s add-a-feed procedure as a skill and watched OpenCode invoke it. But here’s the thing you probably already suspected while writing it: someone on your team wrote this exact procedure months ago. It’s sitting in another feedmill checkout — or a sibling service — as a Claude Code skill, or a Codex one, complete with the same “register the parser, add the source row, wire it into the poller” steps you just re-derived. Rewriting it as an OpenCode skill would be busywork, and worse, you’d now have two copies to keep in sync the moment the procedure changes.

You don’t have to. OpenCode reads the other tools’ skill folders directly. A skill authored for Claude Code or Codex generally works in OpenCode unchanged — the folder is the interface, and OpenCode already knows where the other tools put theirs.

OpenCode reads three skill roots, not one

When OpenCode looks for skills it doesn’t only check its own directory. It reads from all three of the standard locations, at both project and global scope:

  project:
    .opencode/skills/<name>/SKILL.md
    .claude/skills/<name>/SKILL.md     ← Claude Code's path
    .agents/skills/<name>/SKILL.md     ← the agents.md / Codex path

  global:
    ~/.config/opencode/skills/<name>/SKILL.md
    ~/.claude/skills/<name>/SKILL.md
    ~/.agents/skills/<name>/SKILL.md

So the colleague who wrote the add-a-feed skill under .claude/skills/add-feed/SKILL.md already wrote it somewhere OpenCode reads. You don’t move it, rename it, or convert it. You just open OpenCode in a checkout that has that folder, and the skill is there.

The discovery is the same git-rooted walk you saw with AGENTS.md: OpenCode walks up from your working directory to the git worktree, picking up every matching skills directory it passes. Open OpenCode three levels deep inside feedmill and a .claude/skills/ folder at the repo root is still found.

The global roots matter just as much for a team. If everyone keeps their personal, cross-project procedures in ~/.claude/skills/, those load in OpenCode too without anyone exporting or re-homing them. A skill you wrote once for Claude Code on this machine is available to OpenCode in every repo, for free.

Pull in the team’s skill and run it

Say a teammate’s add-a-feed skill lives in .claude/skills/add-feed/. You’ve cloned the repo and you open OpenCode. There’s no separate “list” step to run — OpenCode advertises every skill it discovered, including the ones under .claude/skills/, in the description of the built-in skill tool the agent already sees. (Each discovered skill also shows up in the TUI’s slash-command menu, suffixed :skill, so you can fire one by name too.) So the teammate’s add-feed skill is in front of the agent the moment you start, described exactly like a native OpenCode skill, because to OpenCode there’s no difference. You onboard a new source the same way you would have with your own skill, by describing the outcome and letting the agent reach for the procedure:

> onboard the Hacker News JSON feed as a new source

  | Skill  add-feed

  Following the add-feed procedure: I'll add a parser under
  internal/fetch for the HN JSON shape, register the source row, and
  wire it into the poller — respecting the rate-limit delay per the
  repo conventions.

  | Edit  internal/fetch/hn.go

The agent saw add-feed in its skill list, decided this task matched the description, and called the skill tool to load the body on demand — the same invocation path a native OpenCode skill uses. The procedure your team already proved out is now driving an OpenCode run, and you wrote none of it.

Why tool-specific frontmatter doesn’t break it

The reason this works unchanged is worth understanding, because it tells you what will and won’t carry over. A Claude Code SKILL.md often carries frontmatter keys that are Claude-specific — things like allowed-tools or disable-model-invocation, knobs OpenCode has no concept of. OpenCode doesn’t choke on them and it doesn’t try to honor them. Unknown frontmatter fields are simply ignored.

What OpenCode actually reads from the frontmatter is a small, shared core: name (which must match the directory) and description are the required pair, with license, compatibility, and metadata recognized as optional. Everything else in the block is inert. That’s the whole compatibility story: the part of the format that matters — name, description, and the Markdown procedure in the body — is the open Agent Skills standard (originally developed by Anthropic and released as an open spec) that Claude Code, Codex, and OpenCode all share, and the tool-specific extras each tool layers on top are skipped by the tools that don’t recognize them.

The practical consequence: the behavior a Claude-specific key was buying you doesn’t transfer. If your teammate used disable-model-invocation to stop Claude Code from auto-running the skill, OpenCode ignores that key, so it won’t suppress invocation the same way — OpenCode controls that through its own agent and permission model, which is the next lesson’s subject. The procedure travels; the tool-specific gating does not. That’s the seam to watch when you reuse a skill across tools: it’ll run, but any access rules baked into another tool’s frontmatter are yours to re-establish on the OpenCode side.

That re-establishing is exactly what comes next: now that a shared skill can run in OpenCode, you’ll want to decide which agents are allowed to reach for it. Next: control which agents can run a skill.