Add and ship OpenCode support for one Claude Code plugin at a time. Includes core migration to a reviewable `opencode-plugin/` adapter, maintainer-facing docs, and follow-up CI/versioning setup for package publishing or skill-copy drift checks.
92
92%
Does it follow best practices?
Impact
97%
1.25xAverage score across 2 eval scenarios
Passed
No known issues
Use this when a repo has .claude/commands/, .claude/agents/, or the user asks to migrate commands or agents.
Existing Claude commands and agents are migration input. Do not generate new .claude/commands/ or .claude/agents/ as part of OpenCode support.
Default generated shared locations:
.agents/commands/<name>.md or the repo's established shared convention..agents/agents/<name>.md or the repo's established shared convention.OpenCode-specific wrappers belong under .opencode/commands/ or .opencode/agents/ only when the user explicitly wants project-local OpenCode config. These are active OpenCode config files, not neutral package output.
OpenCode command wrappers should start with frontmatter. Without frontmatter, wrappers may not load or may load without useful metadata.
Minimal OpenCode command wrapper:
---
description: Enforce code discipline checklist
agent: build
---
@.claude/commands/enforce-code-disciplines.mdUse wrapper references when the goal is to keep existing Claude command files intact. If creating a new shared command, prefer .agents/commands/ rather than a wrapper around .claude/.
OpenCode agent wrappers should also start with frontmatter and can point at an existing prompt file.
Minimal OpenCode agent wrapper:
---
description: Senior code reviewer
mode: subagent
prompt: "{file:~/.claude/agents/senior-code-reviewer.md}"
---Use wrappers when preserving an existing Claude prompt as the source is the user's explicit goal. If creating a new shared agent, prefer .agents/agents/.
OpenCode has supported singular and plural config folder names in some versions. Do not rely on this for generated output.
.agents/skills, .agents/commands, .agents/agents, .agents/rules.Symlinks can be useful for personal migration or local dogfooding, but they are not the default for reusable OSS/package support.
Prefer explicit .agents/ shared assets and opencode-plugin/ package code. Avoid symlinks in package contents unless intentionally tested across platforms.
After generating wrappers or shared assets, verify the relevant user-facing surfaces:
opencode debug skill lists expected skills./ palette shows expected commands.@ picker shows expected agents.