Adopt an environment: take a bespoke CLI integration out-of-tree as an EoS host plugin

[trek-e]

The ask

We're looking for people to adopt one of GSD's bespoke environment integrations and maintain it out-of-tree, as an EoS host plugin they own.

Every environment except Claude Code, Codex, and OpenCode is in scope. If you're a heavy user of Qwen Code, Cursor, Windsurf, Cline, Copilot, Kilo, pi, Trae, Hermes, Kimi, Antigravity, Augment, CodeBuddy, ZCode, or Kimi Code — this is an invitation to take that integration, put it under your own repo and your own release cadence, and stop waiting on us.

We'd de-scope it from core, list your plugin in the EoS Registry, and keep supporting the engine underneath it.

---

Why we're doing this

Honestly: eighteen environments move at eighteen different speeds.

Each one ships its own breaking changes on its own schedule — a new hook surface here, a renamed config directory there, a slash-command format that quietly changes shape. Every one of those is a bug report against gsd-core, a triage cycle, a fix, a release. Meanwhile the thing that actually makes GSD GSD — the orchestration loop, the planning model, the phase lifecycle, the state contracts — competes for attention with "Windsurf moved its config path again."

That's a bad trade, and it gets worse with every environment we add. We'd rather be excellent at the core and let the people who actually live in a given CLI own the last mile of it.

This isn't us dropping support in frustration. It's a structural fix that only became possible recently.

---

What changed: EoS

ADR-1239 (accepted, shipped through v1.7.0) inverted the model.

GSD used to be a standalone installer that projected onto a host — which meant every host's quirks lived in our source tree. EoS makes GSD an embeddable orchestration engine that a host loads through a stable, negotiated interface. In the ADR's own framing: "turn the CLIs into Capabilities like we did for the loop."

The contract is six interface points — command, dispatch, model, hooks, state, artifact — negotiated across nine declared axes (embeddingMode, commandSurface, dispatch, modelMode, hookBus, stateIO, transport, runtime, effortSurface). Protocol version 1. Where a host lacks a primitive, the interface degrades on a defined ladder rather than breaking.

The important part for you: all eighteen first-party CLIs are already migrated onto it. There are no runtime-literal branches left in the dispatch paths — a runtime's behavior is data, not code.

---

What you'd actually be taking on

This is the part people assume is huge, and it isn't. You start from a working integration, not a blank page.

Your environment already has a complete, declared descriptor in-tree at capabilities/<runtime>/capability.json — roughly 100–125 lines covering its axes, hook surface, install paths, artifact layout, and branding rewrites. That file is the integration. You lift it as-is.

Everything generic stays generic and comes from the published SDK (host-integration-sdk):

• negotiateHostCapabilities, profileOf, degradationFor — capability negotiation
• createImperativeAdapter / createDeclarativeAdapter, createModelAdapter, createHookBus, createStateIO — the five engine adapters
• buildHandshakeRequest / handleHandshakeRequest — serialized handshake for out-of-process hosts

What you'd own on day one is mostly packaging: an install/uninstall entry point and a release. If your host's artifact dialect drifts from the generic converters, you'd own one converter per artifact family — and that's the ceiling, not the floor.

Per the authoring guide, binding a host requires no gsd-core source change. That's the whole point of the design.

Start here:

• docs/how-to/author-a-host-plugin.md — the five-step procedure
• docs/reference/host-integration-interface.md — full axis + adapter vocabulary
• docs/reference/host-integration-capability-matrix.md — every runtime's declared axes, including yours
• docs/tutorials/embed-gsd-in-a-new-host.md — end-to-end walkthrough

---

Why this is better for you, not just for us

You ship fixes the day the CLI breaks. Right now the path is: notice breakage → file an issue → wait for triage → wait for a fix → wait for a gsd-core release that bundles it. Out-of-tree, you notice it and you cut a release. No queue, no maintainer bandwidth in the middle.

You set the cadence. Your host's release rhythm is probably nothing like ours. Stop forcing them to rhyme.

You can go deeper than we ever would. We integrate to a common denominator across eighteen hosts. You can exploit the one host you actually care about — its native extension API, its specific isolation model, its bespoke surfaces. gsd-omp does exactly this against Oh My Pi's native ExtensionAPI.

You own the roadmap. Features we'd decline as too host-specific are yours to just build.

No fork, no drift. You're consuming a versioned protocol, not maintaining a patch set against our tree. Engine improvements flow to you without a rebase.

---

How we keep supporting you

De-scoping the integration is not walking away from you.

• The EoS Registry (docs/registries/eos.json → generated eos-registry.md) is the discovery surface. Your plugin is listed as the way to run GSD in that environment — users find it from our docs.
• The protocol is versioned and stable. protocolVersion: 1, enginesGsd: ">=1.7.0". Breaking the interface is our problem to manage, not something we do casually.
• The engine keeps getting better — orchestration, planning, phase lifecycle, state contracts. That's where our effort goes, and you inherit all of it.
• We help with the migration itself. Descriptor handoff, wiring questions, review of your first entry.
• You get a thread in this category for your entry, so users have somewhere to report and discuss.

Standard registry caveat, stated plainly: listing means a maintainer merged a PR pointing at your repo. It's a discovery index, not an endorsement or an audit.

Submission is one entry, one PR — append to eos.json, run npm run gen:registry, use the registry-entry PR template, and put your thread's URL in the entry's discussion field.

---

In scope

Any of these fifteen:

antigravity · augment · cline · codebuddy · copilot · cursor · hermes · kilo · kimi · kimi-code · pi · qwen · trae · windsurf · zcode

Claude Code, Codex, and OpenCode stay first-party — they're our reference hosts for the interface itself, and we dogfood the protocol against them.

Groups are very welcome. If two or three people who all use the same CLI want to co-maintain one plugin, that's a better outcome than a single maintainer, and we'll happily coordinate it.

---

It's already happening

Two out-of-tree EoS entries exist today:

• GSD for Oh My Pi (gsd-omp, by @tchivs) — a full six-interface-point embed via OMP's native extension API, on Bun. This is what a complete port looks like.
• GSD Cursor Model Profiles (gsd-cursor, by @clezcoding) — a narrower entry touching model + state, adding Cursor tier maps and model profiles without modifying gsd-core.

Note that second one: you don't have to start with a full port. A narrow entry that scratches your own itch is a completely legitimate first step, and it can grow into full ownership later.

---

Raise your hand

If you want to take one of these — or want to talk through what it'd involve before committing — come to the GSD Core Discord:

Post in #gsd-core-chat and tag @trekkie0.
Please don't DM — no PMs. Keep it in the channel so others working on the same environment can find each other and team up.

Say which environment you're interested in and roughly how you use it. We'll coordinate the de-scope and migration from there — descriptor handoff, timing, registry entry, and a deprecation note in core pointing users at your plugin.

Questions, doubts, and "this seems like a lot, is it really?" are all fair game in the thread below.