The Problem: AI Coding Tools Are Fragmented

Imagine you're building software with AI assistants. You've got Claude Code for orchestration, GPT for reasoning, Gemini for creativity. Each one is good at different things. But switching between them? Configuring workflows? Debugging when things break?

That's what Oh My OpenCode solves. It's a single plugin that turns a basic AI coding tool into a full AI development team.

One Word: ultrawork

When you type ultrawork (or just ulw), here's the chain reaction that fires off under the hood:

Under the Hood: A Plugin for OpenCode

Oh My OpenCode is a TypeScript plugin for OpenCode. When OpenCode starts, it loads the plugin, which injects agents, tools, and hooks into the system.

const OhMyOpenCodePlugin: Plugin = async (ctx) => {
  const pluginConfig = loadPluginConfig(ctx.directory, ctx)
  const managers = createManagers({ ctx, pluginConfig, ... })
  const toolsResult = await createTools({ ctx, pluginConfig, managers })
  const hooks = createHooks({ ctx, pluginConfig, ... })
  return { name: "oh-my-openagent", ...pluginInterface }
}
          

The Tech Stack at a Glance

Check Your Understanding

The Production Crew

Oh My OpenCode doesn't use one AI for everything. It runs a team of discipline agents, each cast for a specific role. Think of it like a film production crew.

Watch Them Work Together

Here is a realistic delegation sequence. Sisyphus receives a task, scouts the codebase, delegates the heavy lifting, and calls in an advisor when things go sideways.

How an Agent Is Born

Every agent is created by a factory function. Here is the real code that builds Sisyphus — the orchestrator that manages all other agents.

const MODE: AgentMode = "primary";

export function createSisyphusAgent(
  model, availableAgents, ...
): AgentConfig {
  const tools = categorizeTools(availableToolNames);
  const prompt = buildDynamicSisyphusPrompt(
    model, agents, tools, skills, ...
  );
  return {
    description: "Powerful AI orchestrator...",
    mode: MODE,
    model,
    prompt,
    ...
  };
}
          

Why Different Models for Different Agents?

Not every task needs the most expensive AI. The system matches each agent to the right model for its job — like casting the right actor for each role.

Check Your Understanding

The 911 Dispatch Center in Your Terminal

When you call 911, the operator doesn't fight fires or chase criminals. They ask one question: what kind of emergency is this? Then they route to fire, medical, or police. Sisyphus works the same way.

Every single message you send hits the Intent Gate before anything else happens. This is Phase 0 — the moment the agent decides how to think about your request.

The Five Types of Intent

Sisyphus follows an explicit ruleset to classify every incoming message. These aren't vague guidelines — they're deterministic rules baked into the system prompt.

### Step 1: Classify Request Type

Trivial (single file, known location)
  -> Direct tools only

Explicit (specific file/line, clear command)
  -> Execute directly

Exploratory ("How does X work?")
  -> Fire explore (1-3) + tools in parallel

Open-ended ("Improve", "Refactor")
  -> Assess codebase first

Ambiguous (unclear scope)
  -> Ask ONE clarifying question
          

Delegation by Category, Not by Model

Sisyphus never says "send this to GPT-5.4" or "use Claude Opus." Instead, it delegates by category — describing what kind of work needs doing. The system maps categories to models behind the scenes.

This is like a hospital where doctors order "imaging" not "use the Siemens MRI machine." The abstraction means you can swap models without rewriting any agent logic.

The Context-Completion Gate

Even after classification and delegation, there's one more checkpoint. Before any implementation begins, the Context-Completion Gate must be satisfied. Think of it as the surgical timeout — the pause before the first incision where the team confirms they have the right patient, right procedure, right site.

Check Your Understanding

A Surgeon's Instruments, Not a Sledgehammer

Think of a surgeon's operating room. They don't use one big tool for everything — they have scalpels, clamps, retractors, each designed for a specific job. One wrong instrument and the patient is in trouble.

OmO's agents work the same way. Each tool is purpose-built for a specific kind of code manipulation. The right tool for the right job means fewer mistakes and faster work.

Hashline Edit: The Breakthrough

Most AI coding failures aren't the model's fault — they're the harness's fault. The edit tool is usually the weak link. Here's the problem most tools have:

The result? Success rate jumped from 6.7% to 68.3% — just by changing the edit tool.

11#VK| function hello() {
22#XJ|   return "world";
33#MB| }
          

LSP: IDE Superpowers for Agents

When you use VS Code and right-click "Go to Definition" or "Rename Symbol" — that's LSP at work. OmO gives agents those exact same powers.

export const builtinTools: Record<string, ToolDefinition> = {
  lsp_goto_definition,
  lsp_find_references,
  lsp_symbols,
  lsp_diagnostics,
  lsp_prepare_rename,
  lsp_rename,
}
          

Background Agents & Task Delegation

Beyond the surgical tools, agents also have the power to spawn other agents. The background agent system lets Sisyphus fire up 5+ specialists at once, each working on a different part of the problem.

Check Your Understanding

An Invisible Army of Bodyguards

Imagine a skyscraper with motion sensors, fire alarms, and security cameras on every floor. You never notice them — until something goes wrong. Then they kick in instantly, preventing disaster.

OmO has 80+ hooks that work exactly like that. They intercept agent actions at every stage: before a message is sent, after a tool runs, when context gets too large, when an error occurs. The agent never sees most of them — they just silently make everything work better.

Three Layers of Protection

Hooks are organized into three categories, created by three factory functions in the code:

const core = createCoreHooks({
  ctx, pluginConfig, modelCacheState, isHookEnabled
})
const continuation = createContinuationHooks({
  ctx, pluginConfig, backgroundManager, sessionRecovery
})
const skill = createSkillHooks({
  ctx, pluginConfig, mergedSkills, availableSkills
})
          

The MVPs: Hooks That Save Your Project

You're in Control

Every hook can be disabled via your config file. The plugin reads a disabled_hooks list and skips any hook you don't want:

const disabledHooks = new Set(
  pluginConfig.disabled_hooks ?? []
)
const isHookEnabled = (hookName) =>
  !disabledHooks.has(hookName)
          

This gives you fine-grained control. Don't like the comment checker? Disable just that one hook. Everything else keeps working.

Check Your Understanding

The Full Map

Think of the entire system as a city. Each neighborhood has a purpose, roads connect them, and traffic lights (hooks) keep everything flowing safely. Let's see the whole city at once.

How the Code Is Organized

The monorepo has a clear hierarchy. Every directory has a single responsibility.

From Boot to Shutdown: The Full Lifecycle

The Design Philosophy

Now that you've seen every layer, here are the principles that hold everything together:

Final Check: Can You Navigate This Codebase?