Goal: Bring OpenCode to feature parity with Claude Code as a first-class skill runtime for the framework — a maintainer who has only OpenCode installed should be able to run the framework end-to-end. Grounds: RFC-AI-0004 Principle 3 — Vendor neutrality across LLM backends and the agent-harness axis of docs/vendor-neutrality.md, which already lists OpenCode as a recognised harness.
Current state — the substrate half is already done. Unlike the sibling feat(adapter/*) runtimes, OpenCode already has genuine, tested support in every harness-integrating substrate tool:
As a result the agent-harness axis of the vendor-neutrality score reads OpenCode = 5/5 substrate tools (100%). What remains is the skill-runtime half — making the skills themselves run under OpenCode.
What "parity" means (the remaining work):
- Skills under
.claude/skills/<name>/SKILL.md are invokable from OpenCode directly — OpenCode reads the AGENTS.md standard and a shared skills home natively, so the mapping should be light
- The
tools/* CLI bridges (gh, jira, gmail, ponymail, vulnogram, cve-org, …) are language-agnostic invocations and should port directly
- HITL primitives: OpenCode's
permission model (ask / allow / deny, with per-pattern bash rules) maps to the framework's confirm-before-acting posture — verify and document the wiring (RFC-AI-0004 Principle 1)
- Sandbox parity: the
setup-isolated-* bubblewrap + egress model already launches OpenCode via opencode-iso; document the end-to-end setup
Suggested approach:
- Map
SKILL.md → OpenCode's skill/agent discovery (AGENTS.md); document how a maintainer runs (e.g.) security-issue-triage end-to-end under OpenCode
- Wire the shipped OpenCode plugin (
tools/agent-guard/opencode/plugin.js) and a safe opencode.json permission baseline into the setup skills so an OpenCode-only adopter gets the guards + isolation by default
- Extend
/magpie-setup and the setup-isolated-* skills to install the OpenCode plugin + opencode.json alongside the existing Claude wiring
Reference:
Goal: Bring OpenCode to feature parity with Claude Code as a first-class skill runtime for the framework — a maintainer who has only OpenCode installed should be able to run the framework end-to-end. Grounds: RFC-AI-0004 Principle 3 — Vendor neutrality across LLM backends and the agent-harness axis of
docs/vendor-neutrality.md, which already lists OpenCode as a recognised harness.Current state — the substrate half is already done. Unlike the sibling
feat(adapter/*)runtimes, OpenCode already has genuine, tested support in every harness-integrating substrate tool:agent-guard— an OpenCodetool.execute.beforeplugin over the shared guard core (feat(agent-guard): OpenCode harness adapter — closes a Claude-coupled harness gap #686)agent-isolation— anopencode-isoclean-env launcher (the renamedagent-iso.sh) (feat(harness): OpenCode support for spec-loop + agent-isolation; rename to agent-iso.sh #687)spec-loop— anopencode runheadless invocation path (feat(harness): OpenCode support for spec-loop + agent-isolation; rename to agent-iso.sh #687)permission-audit—audit-opencodeforopencode.jsonpermission policies (feat(harness): OpenCode support for permission-audit + sandbox-lint — agent-harness 100% #688)sandbox-lint—--opencodepermission-policy invariants (feat(harness): OpenCode support for permission-audit + sandbox-lint — agent-harness 100% #688)As a result the agent-harness axis of the vendor-neutrality score reads OpenCode = 5/5 substrate tools (100%). What remains is the skill-runtime half — making the skills themselves run under OpenCode.
What "parity" means (the remaining work):
.claude/skills/<name>/SKILL.mdare invokable from OpenCode directly — OpenCode reads theAGENTS.mdstandard and a shared skills home natively, so the mapping should be lighttools/*CLI bridges (gh, jira, gmail, ponymail, vulnogram, cve-org, …) are language-agnostic invocations and should port directlypermissionmodel (ask/allow/deny, with per-patternbashrules) maps to the framework's confirm-before-acting posture — verify and document the wiring (RFC-AI-0004 Principle 1)setup-isolated-*bubblewrap + egress model already launches OpenCode viaopencode-iso; document the end-to-end setupSuggested approach:
SKILL.md→ OpenCode's skill/agent discovery (AGENTS.md); document how a maintainer runs (e.g.)security-issue-triageend-to-end under OpenCodetools/agent-guard/opencode/plugin.js) and a safeopencode.jsonpermission baseline into the setup skills so an OpenCode-only adopter gets the guards + isolation by default/magpie-setupand thesetup-isolated-*skills to install the OpenCode plugin +opencode.jsonalongside the existing Claude wiringReference:
docs/vendor-neutrality.mddocs/rfcs/RFC-AI-0004.mdAGENTS.mdconvention: https://agents.md/