You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Thanks for filing this — it turned up a real bug, and the answer is more interesting than "not supported yet."
The skill already works in opencode today. opencode searches ~/.agents/skills/<name>/SKILL.md, which is exactly where basecamp skill install has always written. If you've run that, basecamp is already available to opencode with nothing else to do.
What was broken is the wizard.basecamp skill offered "OpenCode (Global)" and "OpenCode (Project)" pointing at skill/ — singular. opencode reads skills/. So choosing OpenCode in the picker wrote a file opencode would never load and then reported success, and the auto-refresh-on-upgrade loop skipped opencode installs for the same reason. #624 fixes both.
The open question is how far "support" should go. Codex got more than a skill in #550 — it got a plugin manifest and lifecycle hooks. The equivalent for opencode is a different mechanism from either manifest this repo already ships: JS/TS plugin modules in .opencode/plugins/, or an npm package named in opencode.json. That's a new artifact for us to build, version-stamp and release, so it wants a deliberate decision rather than a quiet yes.
So: with #624 merged, does this issue do what you wanted, or is it the hooks/plugin parity you're after? If it's the latter, what would you actually use the hooks for — that shapes whether it's worth the new build artifact.
Correction to my earlier comment — I got a load-bearing detail wrong, and you should have the accurate version.
I said the wizard's OpenCode entries pointed at a directory opencode never reads. That was wrong. opencode takes an optional plural throughout; its own shipped docs table (checked against the 1.18.4 binary rather than the docs site) reads:
the same agent(s)/command(s) form it uses elsewhere. So the singular paths worked, and #624 moved the install target from one working path to another rather than repairing a break.
Worse, #624 introduced one: that list is also the auto-refresh set, so anyone who had installed to the singular path kept a skill opencode loads but that no longer updates on upgrade. #627 fixes that by refreshing both spellings.
What this means for you: if you installed the skill through basecamp skill at any point, it already worked in opencode, and after #627 it stays current wherever it landed. ~/.agents/skills/basecamp/SKILL.md — what basecamp skill install writes — is auto-loaded by opencode too, so that route was always fine. That part of what I said holds.
The open question is unchanged and still yours: is a skill all you wanted here, or is it the hooks/plugin parity Codex got in #550? If the latter, what would you use the hooks for?
Activity
jeremy commentedon Aug 5, 2026
Thanks for filing this — it turned up a real bug, and the answer is more interesting than "not supported yet."
The skill already works in opencode today. opencode searches
~/.agents/skills/<name>/SKILL.md, which is exactly wherebasecamp skill installhas always written. If you've run that,basecampis already available to opencode with nothing else to do.What was broken is the wizard.
basecamp skilloffered "OpenCode (Global)" and "OpenCode (Project)" pointing atskill/— singular. opencode readsskills/. So choosing OpenCode in the picker wrote a file opencode would never load and then reported success, and the auto-refresh-on-upgrade loop skipped opencode installs for the same reason. #624 fixes both.The open question is how far "support" should go. Codex got more than a skill in #550 — it got a plugin manifest and lifecycle hooks. The equivalent for opencode is a different mechanism from either manifest this repo already ships: JS/TS plugin modules in
.opencode/plugins/, or an npm package named inopencode.json. That's a new artifact for us to build, version-stamp and release, so it wants a deliberate decision rather than a quiet yes.So: with #624 merged, does this issue do what you wanted, or is it the hooks/plugin parity you're after? If it's the latter, what would you actually use the hooks for — that shapes whether it's worth the new build artifact.
jeremy commentedon Aug 5, 2026
Correction to my earlier comment — I got a load-bearing detail wrong, and you should have the accurate version.
I said the wizard's OpenCode entries pointed at a directory opencode never reads. That was wrong. opencode takes an optional plural throughout; its own shipped docs table (checked against the 1.18.4 binary rather than the docs site) reads:
the same
agent(s)/command(s)form it uses elsewhere. So the singular paths worked, and #624 moved the install target from one working path to another rather than repairing a break.Worse, #624 introduced one: that list is also the auto-refresh set, so anyone who had installed to the singular path kept a skill opencode loads but that no longer updates on upgrade. #627 fixes that by refreshing both spellings.
What this means for you: if you installed the skill through
basecamp skillat any point, it already worked in opencode, and after #627 it stays current wherever it landed.~/.agents/skills/basecamp/SKILL.md— whatbasecamp skill installwrites — is auto-loaded by opencode too, so that route was always fine. That part of what I said holds.The open question is unchanged and still yours: is a skill all you wanted here, or is it the hooks/plugin parity Codex got in #550? If the latter, what would you use the hooks for?