Everything Is a Plugin: The Sprint Engine Studio Module System

Most tools treat extensibility as a sidebar: a marketplace of add-ons bolted onto a fixed core. We took the opposite bet. In SE Studio the core is small, and almost everything you think of as a feature is a plugin filling a typed slot.

Slots, not a sidebar

The SE Studio host knows how to do a few durable things: open a repo, run terminals, manage worktrees, persist state under .multi-code/, and show you what is happening. Everything above that is contributed through slots. A slot is a typed extension point with a contract, so the host can load, validate, and combine plugins without knowing what any specific one does.

Because the slots are typed, the things you would expect to be hard-coded are not. They are contributions:

• Workspace types — a new way of working, such as a design lab or a Switchboard-style intake board.
• Roles and teams — specialist agents like strategist, architect, security reviewer, or one you define.
• CLI providers — the runtime an agent runs on, from Claude Code to a custom local harness.
• Skills and MCPs — capabilities and tool servers an agent can reach for during a task.

Two ways to fill a slot

The first way is the marketplace. The intent is that a team can install a vetted workspace type or a role pack the same way they would add an editor extension, and have it show up as a first-class option in the product surface.

The second way is to build your own. Plugins are not a separate, lesser API. The built-in roles and workspace types are written against the same contracts you get, which keeps the platform honest: if we needed an escape hatch to build a feature, you would have it too.

Agent-native APIs

Agent-native means the extension points are shaped for how agents actually work — sessions, tasks, evidence, worktrees, and review — rather than a generic UI plugin API with agents bolted on. A plugin declares what it contributes, and the host wires it into the workflow.

// multicode.plugin.ts
export default definePlugin({
  id: "acme.design-review",
  contributes: {
    workspaceTypes: [designLab],   // a new way of working
    roles: [designReviewer],       // a new specialist agent
    skills: [figmaExport],         // a capability it can use
  },
})

Once that plugin is installed, designLab appears in the new-workspace picker, designReviewer can be added to a team, and figmaExport is available to agents in that workspace — without touching the host.

Why modular matters

Teams already have local scripts, security policies, review habits, and tools they trust. A monolithic product forces those teams to adapt to its one workflow. A modular one adapts to them. The environment should bend to your way of working, not the other way around — and a marketplace means the best modules can come from outside our team entirely.

Keep the host small and opinionated about workflow. Keep everything else replaceable.