Break coding goals into verified multi-agent task plans
Turns one goal into an editable plan of coding-agent tasks, each with its own runner and model, then runs and verifies them by completion marker.
0.7.2Add to Favorites
Why it matters
Turn a single development goal into an ordered, editable plan where each task is assigned the right coding agent, model, and execution mode, then execute and verify completion with evidence-based checks rather than AI opinion.
Outcomes
What it gets done
Research your codebase read-only and ask clarifying questions before committing to a plan
Assign different models and runners per task based on complexity and requirements
Execute tasks with completion verified by unique markers in output, not exit codes
Edit plans inline-change models, add tasks, rewire dependencies-without losing completed work
Source
Get it from source
Spark does not host a copy of it.
Open sourceReports
Agent outcome reports
No reports yet
Overview
An orchestrator with a read-only planner and a plan you edit before running. Each task gets its own runner, model, effort and mode, and finishes only when its marker appears. Use for multi-step goals across several coding agents. The TUI needs tmux, and there is no browser dashboard yet.
What it does
Ordewell turns one goal into an ordered plan of coding-agent tasks, each with its own runner, model and mode, then executes and verifies it. You give a goal, and the plan is a file you can rewrite before anything runs. Every task carries its runner, model, thinking effort and mode. You can change any of them, add and remove tasks and rewire dependencies, completed work survives, and nothing runs until you say go. It is Apache-2.0 licensed, with the name and logos excluded from the license.
Its core design choices:
- One runner and model per task, all visible at once. A security refactor and a README update do not deserve the same model, so the planner assigns across the whole plan and shows every assignment first.
- A task is done only when its completion marker appears in the runner's output. Exit code is kept as diagnostic evidence, no model grades its own work, and a task that ends without its marker fails visibly.
- The planner is read-only and conversational. It researches the repo, asks when the goal is vague, and its final message is the plan. Reads run in parallel, anything reaching outside the workspace asks once, and commands that would write are refused outright.
- No extra API key is required. Claude Code, Codex or OpenCode can act as the planner, strictly read-only, on the subscription you already hold.
- Multi-runner by design. Claude Code, Codex and OpenCode ship built in, and any other CLI such as Aider is added through a plugin manifest and not a code change.
When to use - and when NOT to
Use it for goals that span several steps and would benefit from different models and modes, where you want to review and edit the plan before spending anything, and where you want verified completion. Manual steps become checklists inside the plan.
It has requirements to note. It needs Node.js 20 or newer, and the terminal UI needs tmux on every platform because tmux backs each task's live terminal. On Windows the TUI runs under WSL, while the CLI, API server and VS Code extension work natively, and Git for Windows should stay installed because the planner runs research commands in its POSIX shell. There is no browser dashboard yet: the web command serves a local JSON and WebSocket API on port 3742 that the CLI and TUI use as clients.
Inputs and outputs
The flow has five steps. Describe a goal in plain prose. The planner researches your workspace read-only and interleaves questions with research in one persistent conversation. A plan appears, which you can edit inline or reprompt to reshape without losing completed work. Execution spawns a real coding-agent session per AI task, respecting the dependency graph and passing each task its predecessors' results. Finally, the verdict engine completes a task only once its marker appears, and sessions auto-save to a local folder.
The CLI mirrors every slash command. Plan and run are one line: plan with a goal, then run. Related commands reassign a task's runner, model and dependencies, show status for a session, and toggle skills: grilling makes the planner interrogate your goal with at least three probing questions, prd writes a full PRD, and tdd adds red-green-refactor instructions to tasks. Independent tasks run in parallel, with a default of three concurrent sessions, adjustable from 1 to 5.
For planning without a coding-agent subscription, twenty-five providers are recognised through their own API key variables, including OpenRouter, Anthropic, OpenAI, Gemini, xAI, Groq, DeepSeek and Mistral, and any OpenAI-compatible endpoint can be set through a base URL variable. The default planner model is a budget model, since the planner never writes code.
Integrations
Three surfaces share one core: a VS Code extension with a streaming timeline and task cards, a terminal UI with a chat pane and plan pane, and the CLI. Plugins install from https repositories on GitHub, GitLab, Bitbucket and Codeberg, or from a local directory. The architecture splits into a pure TypeScript core, the CLI, the VS Code extension and a Hono-based local server, with a pure-reducer TUI design documented in the project's decision records.
Configuration centers on four settings. One provider key is the only required setting, and the provider is auto-detected from whichever key is set, or forced with AI_PROVIDER. The planner model defaults to a budget model, deepseek/deepseek-v4-flash, set through ORCHESTRATOR_MODEL or the model command, and with a coding-agent planner it must be one of that agent's own model IDs. ORDEWELL_PLANNER_EFFORT sets thinking effort for a coding-agent planner and is ignored by vendor planners. ORDEWELL_MAX_PARALLEL defaults to 3. The TUI is driven by single keys, such as f to start, E to run all, m to toggle done, R for runner and o for model, and the mouse wheel scrolls whichever pane the pointer is over, with a mouse-off command to restore drag-to-select.
How to install
Install globally with npm and start the TUI, where first run asks for a planner and runner from inside, with no restart or up-front key needed. The package also runs through npx and ships scoped as a CLI package, and the VS Code extension carries its own core.
npm install -g ordewell
Who it's for
Developers who use several coding agents and want a reviewable, editable, verified plan instead of one long unsupervised session. The planning skills are adapted from Matt Pocock's MIT-licensed skills.
Source README

Ordewell turns a goal into a plan you can read and change before anything runs. A planner researches your repository and asks about whatever you left vague. It then hands back a dependency graph of tasks, and each task names the coding agent, model and thinking effort it will use. Independent tasks run in parallel, each in its own git worktree. A task only counts as done when the agent reports it done - through Ordewell's own tool on the structured transport, or its completion marker in the output as the fallback - and nothing reaches your branch until you have reviewed the result.
Claude Code, Codex and OpenCode are supported out of the box, and can be mixed freely within one plan.
Features
- An editable plan. Change any task's prompt, runner, model, effort or mode, add or remove tasks, and rewire dependencies without another round trip to the model.
- The right model for each task. A security refactor and a README update get different models, and you see every assignment before a token is spent.
- Isolated execution. Every task that changes code works on its own branch. Passing work lands on one integration branch in plan order, and you choose when to merge it.
- Operations in the right place and order. A deploy, a cloud CLI call or a push runs as an ops task in your own checkout, and waits until the change it depends on is merged into your branch.
- Verdicts from evidence. Completion is decided by the runner's own done signal - a tool call on the structured transport, or its completion marker as the fallback - never by a model's opinion of its own work.
- A planner that cannot write. It reads, asks, and plans. Commands that would change your repository are refused.
- No extra API key. A coding agent you already pay for can be the planner. An API key from any of 25 providers works too.
- Use it where you work. A terminal UI, a VS Code extension, a CLI for scripts and a local API, all sharing one core.
Installation
npm install -g ordewell
For VS Code, install Ordewell from the Marketplace
or run code --install-extension ordewell.ordewell. The extension bundles its own
core and needs nothing from npm.
Requirements: Node.js 20 or newer, at least one of Claude Code, Codex or
OpenCode, and git for task isolation. tmux is optional: only the terminal
transport (/transport terminal) uses it, to give each task a terminal window
you can open. On Windows, run the terminal UI under WSL.
Quick start
Run ordewell in your project to open the terminal UI, then type a goal. The first
run lets you pick a planner and runners with /planner and /runners.
The same workflow is available from the command line:
export AI_PROVIDER=claude-code # plan with Claude Code, Codex or OpenCode
ordewell plan --goal "Add rate limiting to the public API"
ordewell run
ordewell handoff review # read the diff
ordewell handoff merge # bring it onto your branch
Between plan and run, the plan is yours to edit:
ordewell task-runner 2 opencode # move a task to another agent
ordewell task-model 3 sonnet # or just change its model
ordewell task-deps 3 1,2 # make it wait for tasks 1 and 2
How it works
- Plan. The planner explores your workspace without modifying it, asks clarifying questions, and produces an ordered list of tasks with dependencies.
- Execute. Each task starts a fresh coding agent session - in its own worktree, or in your checkout for an ops task - given the results of the tasks it depends on. Independent tasks run concurrently, three at a time by default.
- Verify. A task passes when the agent reports it done - through Ordewell's own tool on the structured transport, or its unique completion marker in the output as the fallback. The exit code is kept as supporting evidence.
- Land. A passing task is merged into the run's integration branch. If the merge conflicts, the task gets a chance to resolve it; if that fails, it waits for you with the conflicting files named.
- Hand off. When the run finishes, review the diff, then merge it, discard it, or clean up its worktrees.
Folders containing several repositories are handled as one workspace: each task gets a worktree of every repository and lands in all of them or none. See isolation and handoff for details.
Documentation
The documentation covers the planner options, skills, commands, configuration and platform notes. Design decisions, including the options that were rejected, are recorded as architecture decision records, and CONTEXT.md defines the project's vocabulary.
Where it's going
- Now: take-over, opening a structured task in its runner's own terminal UI (#58). The structured transport is the default and tmux is optional (#61).
- Next: the planner keeps watching a run after you approve it, and suggests fixes when a task fails or gets stuck.
- Later: the planner supervises a run on its own, within limits you set in advance.
The full roadmap, and where to help, is in #21.
FAQ
Common questions
Discussion
Questions & comments · 0
Sign In Sign in to leave a comment.