gsd-opencode ports a spec-driven Claude Code workflow to OpenCode, and its author recommends the original

What GSD is, and what the port changes

gsd-opencode is a port of GSD, the meta-prompting, context engineering and spec-driven development system that the README attributes to TACHES, originally built for Claude Code and adapted for OpenCode by rokicool and other contributors. The upstream repository is glittercowboy/get-shit-done, and this port is based on TACHES v1.38.5 dated 2026-04-25.

The pitch for GSD is worth repeating because it explains what the port is for. The author's complaint about other spec-driven tools is that they add ceremony, with sprint ceremonies, story points, stakeholder syncs, retrospectives and Jira workflows, or that they lack an understanding of what is being built. The claim is that the complexity belongs in the system rather than in your workflow: behind the scenes there is context engineering, XML prompt formatting, subagent orchestration and state management, and what you see is a few commands that work.

The port exists because the original added OpenCode support and the maintainer found a lot of roughnesses in it. The README says that despite being a direct port with straightforward code adaptation, specific features were added, and the credit for the initial version and the idea of the profile system goes to dpearson2699.

The repository layout tells you how the work is organised. There is a gsd-opencode/ directory for the port itself, an original/ directory that holds the upstream version, assets/ for configuration such as the translation rules, local/ and reports/ for generated output, a .planning/ directory, an opencode.json at the root, a DISTRIBUTION-MANAGER.md, a CHANGELOG.md and a .gitmodules file for the upstream.

Installation is npx, and the tool writes into your project

The install is a single command, and the README gives two forms of it.

npx gsd-opencode

To force the newest published version, the second form is used.

npx gsd-opencode@latest

It works on Mac, Windows and Linux, and the package is published on npm as gsd-opencode with an MIT licence badge pointing at the LICENSE file in the repository.

What the installation does is not fully spelled out in the visible part of the README, but the repository layout implies it: the presence of opencode.json at the root and a gsd-opencode/ directory with the port's contents suggests the tool installs its commands, skills and configuration into the project you run it in. The .planning/ directory, the reports/ directory and the local/ directory are the kind of directories a workflow tool creates to hold its own state, and the README refers to a distribution system and to a DISTRIBUTION-MANAGER.md at the root, which suggests the port carries a mechanism for pushing its files into a project and keeping them in step with upstream.

The chapter list in the README points the same way, with entries for Why I Built This, Distribution System, How It Works, Commands and a second Why It Works section about the mechanics rather than the motivation.

The profile system had to be rewritten, not translated

The clearest example of a port that is not a port is the model profile system, introduced in version 1.20.3.

The author says he had to give up on supporting the original GSD model profile system, because Claude Code uses three different models, Opus, Sonnet and Haiku, while in OpenCode there are dozens of providers and hundreds of models, so the original system is not suitable.

So it was redesigned with three named levels, simple, smart and genius, and the hope expressed is that it will solve unexpected stops. The three commands that follow from that are worth noting, because their behaviour is unusual. The /gsd-settings command no longer makes any changes to the model-agent assignment at all: it asks about the model profile and then does nothing, and you have to run /gsd-set-profile yourself. The /gsd-check-profile command checks the gsd-opencode config files and reports any issues. And /gsd-set-profile is where the actual assignment happens.

That is a real design difference rather than a naming change. In Claude Code, the three models are a fixed property of the tool, so the mapping can be implicit. In OpenCode, where the model is chosen per provider, the profile has to be set explicitly, and the author split the query from the action to avoid a setting that silently does nothing.

Agent calls had to be rewritten for OpenCode's syntax

The second substantive change is the translation layer, and version 1.33.2 shows how mechanical it had to be.

That release added support for translating Agent() background task calls into the OpenCode-compatible @gsd-<agent> shorthand syntax. The new translation rule 21 lives in assets/configs/remove-task.json, and it dynamically extracts agent names from skill="gsd-<agent>" patterns and converts them to the OpenCode format. The release note says this fixes two Agent() calls in the autonomous.md workflow, for the plan and execute phase dispatch, and ensures full OpenCode compatibility.

Version 1.33.0 went further in the opposite direction: the task() calls were removed, since they are not supported by OpenCode, and replaced with a direct call to an agent.

Version 1.30.0 records the awkward middle, where a controversial solution was used to support the skill(skill='command-name') syntax, with everything else expected to be fully functional. Version 1.22.1 added a mode: subagent property to all custom agents, which should not affect any GSD functionality but should remove unnecessary agents from the list available by Tab.

The pattern across these entries is worth naming: the port is a series of small translations of Claude Code idioms into OpenCode ones, each recorded in the changelog with the reason. The version numbers 1.38.0, 1.35.0 and 1.33.0 exist to keep pace with the original GSDv1 releases, and the README notes that the upstream changelog between v1.20.5 and v1.22.4 is where the original author's changes are listed.

The maintainer recommends the original now

The most important paragraph in this README is the breaking news note dated 2026-05-16, and it is a recommendation against the project it appears in.

Roman writes that he gave the original get-shit-done-cc for OpenCode a try and it looks solid, while still thinking the /gsd-oc-set-profile command of this port is much better. Going forward, he says, he is going to slow down on gsd-opencode upgrades and recommends everyone start using the original get-shit-done. He thanks people for the support, the ideas, and for catching the bugs along the way.

An earlier note from 2026-04-13 is more ambivalent still. It says the original GSDv1 started supporting OpenCode about three months ago, that the author found a lot of roughnesses in the original for OpenCode and decided to continue working on the port, and then, in the same message, that he is not going to give up on the project yet but that it makes less and less sense.

The release history is consistent with that. The last three tags are v1.38.5 on 2026-04-28, v1.38.4 and v1.38.3 on 2026-04-27, and the last push to the repository was on 2026-05-16, the date of the note recommending the original.

For anyone evaluating this, that note is the most useful document in the repository. It tells you the maintainer's own view of the project, and it is the sort of disclosure that is rare and worth reading before you install anything.

Where gsd-opencode is the wrong choice

Three situations rule it out.

The first is a team that wants a supported upstream. The original project exists, it is the one the maintainer now points at, and it has its own release stream with versions such as v1.38.5 and v1.22.4. A port that exists to fill a gap which the upstream has since closed is a dependency on someone else's backlog, and the maintainer has just said he is slowing down.

The second is a team that already has its own workflow. The whole value here is the system doing the work behind a few commands, which means adopting a set of commands, skills, profiles and a state directory. If your project already has a convention for how the assistant is invoked, or an existing spec process, this adds a second opinion rather than removing friction.

The third is a shared or production repository where generated directories are unwelcome. The tool writes into your working tree, and the repository carries .planning/, reports/ and local/ directories, which are the kind of artefacts that need a decision about what gets committed and what gets ignored. The .bg-shell/ directory at the root and the .gitmodules file suggest the same thing about how the port manages its own files.

The honest framing is that gsd-opencode was a useful contribution at a moment when the original did not support OpenCode well. That moment has been superseded by the maintainer's own recommendation, and the project is best read now as a documented case of how a Claude Code workflow was translated to another agent runtime.

Editorial conclusion

gsd-opencode fits an OpenCode user who wants a structured, spec driven workflow with subagent orchestration and state management rather than a bare prompt loop, since the port reimplements the parts that do not carry over. It is the wrong choice if you want a project with an active roadmap, because the maintainer said in May 2026 that upgrades would slow and recommended the original GSD instead, and the last release is v1.38.5 from 2026-04-28. Before adopting it, read the Breaking news note and the model profile section, run npx gsd-opencode in a scratch directory, and check the .planning/ and reports/ directories afterwards to see what it wrote into your project.

Frequently asked questions

Official sources

1. Issues
2. README
3. Releases
4. rokicool/gsd-opencode on GitHub