executor

Implementation agent that writes code, runs tests, and commits changes from a concrete plan.

The executor agent is the workhorse of an OMX workflow. Hand it a concrete, file-level plan and it sees the whole thing through to a verified result: writing the code, running diagnostics, fixing what breaks, and closing out tasks as they land. Partial progress doesn't count. It keeps going until the task is genuinely resolved.

When invoked

Situation	How it's triggered
Execution phase in `$autopilot`, `$ralph`, `$team`, and `$ralplan`	Automatic
When `planner` completes a plan with target files and expected outcomes	Automatic
When `build-fixer` or `debugger` has narrowed down the root cause and repair strategy	Delegated from parent agent
Handling independent task branches in a `$ultrawork` parallel pipeline	Automatic

Example prompts

"Implement based on the files listed in this plan"
"Translate the approved auth refactor into actual code"
"Finish this failing plan step through to completion"

Task classification

Class	Criteria
trivial	Single file, clearly scoped change
scoped	2–5 files, boundaries are clear but verification is needed
complex	Touches multiple systems, full verification is critical

This classification determines the depth of exploration and verification.

Work process

Confirm target files and expected outcomes from the plan
Explore the repository first if needed to understand existing patterns
Implement with a small diff
Run diagnostics on every modified file
Run tests and build to confirm they actually pass
Reflect results in state and commit

Small and precise to completion takes priority over large and clever.

Verification criteria

Before claiming completion, confirm at minimum:

Zero diagnostic errors on modified files
Relevant tests and build actually pass
No debug code or temporary TODOs remain
No significant deviation from existing codebase patterns

Inputs

A plan document from planner or ralplan (tasks, target files, expected outcomes)
Active .omx/state/ session context indicating which tasks are pending
Optional: LSP diagnostics output, test failure logs, or prior explore results

Outputs

Code changes across the files named in the plan
Inline verification evidence such as passing tests and clean LSP diagnostics
One or more descriptive git commits
Updated .omx/state/ entries marking completed tasks

Limits

Works from a plan — does not improvise system architecture or introduce unrequested abstractions
Does not skip tests or force-push branches under any circumstances
Does not claim completion without showing fresh build, diagnostic, or test output as evidence

planner — produces the task plan that executor consumes
verifier — independently confirms that the executor's output meets acceptance criteria
build-fixer — handles stubborn build or type errors that block the executor
debugger — performs root-cause analysis when executor hits an unexpected failure

On this page