ultracode

Claude Code-style dynamic workflows on iii, with the kanban board as the task manager. Give Ultracode a goal: it breaks the goal into tickets, gives each ticket a lead that runs it through its phases with its own sub-agents, runs the leads in parallel in bounded waves, and loops in bounded rounds until the goal is done, nothing is left, progress stalls, rounds run out or the budget is spent.

A goal that changes code in a git repository gets the superpowers flow: you approve the design and the plan, every code ticket (ultracode-impl) is built test-first in a git worktree with one commit, an independent verifier and a code reviewer check every commit, the whole branch is reviewed, and you choose how it finishes. Reading and research tickets (ultracode-worker) in the same run are done and verified without a commit.

Profile	Role	Model
ultracode	the orchestrator you talk to; the only writer of ticket fields	yours (the session's)
ultracode-lead (hidden)	runs one ticket through its phases and reports back	pin a fast, cheap model
ultracode-worker (hidden)	the work phase: research, reading, analysis	set one, or inherit
ultracode-impl (hidden)	the tests and code phases: failing test, least code, commit	pin a strong model
ultracode-verifier (hidden)	judge (one per model), critic and branch review; base of the check tiers	none (nor on Default): judges pick per spawn
ultracode-qa (hidden)	verify and code review in each check (the default verifier)	pin a mid-tier model

No workflow worker, code runner or fp pipeline: just harness, state, kanban and ide (the shell and file functions the tiers preload).

Install

iii trigger directory::download-kit kit=iii/ultracode apply=true --timeout-ms 1200000

apply=true installs at once when the plan has no warnings, blocks or pending decisions (for example, a profile with the same id already exists). Otherwise the reply is a plan: review and apply it in the ADE (Directory → Kits), or run iii trigger directory::kits::apply plan_id= --timeout-ms 1200000. Applying adds or updates workers through Compose and can take minutes; if the command still times out, the apply keeps running: check Directory → Kits instead of re-running it.

Once it is applied, pin the models of the tiers. The kit ships them without model because it cannot know your providers. Edit agents/ultracode-lead.md, agents/ultracode-impl.md and agents/ultracode-qa.md (and ultracode-worker.md if you like) and add model: , e.g. model: anthropic::claude-opus-5-5. Use the provider::model form: it pins the provider and lets reasoning_effort reach it. An unpinned lead runs on the orchestrator's model, and it takes a turn per phase. A tier without its own model inherits one set on Default (agents/default.md, which the Directory editor writes), and that beats both the orchestrator's model and the judge models; with judges= the run refuses to start if ultracode-verifier resolves a model. Editing an installed kit file is fine; a kit update merges your edits.

Run it

From the console: pick Ultracode and type the goal, optionally followed by an args: line:

Add per-user rate limits to the login route.
args: max_rounds=2 concurrency=4 budget_usd=5

Arg	Default	Meaning
flow	auto	dev (the superpowers flow) when the goal changes code or files in a git repository, else plain; set dev or plain to force one
approve	on	the dev flow waits for you on the design, the plan and the finish; off runs straight through and keeps the branch
max_rounds	3	retry cycles over the queue
attempts	2	code (or work) attempts a lead makes per round; a rejected attempt goes back to the same code session with the reasons
concurrency	8	leads per wave (max 8). Every ticket whose Depends on tickets are done starts in parallel; a dependent ticket waits for a later wave (a Depends on: KAN-12 line on a card you add counts too). In the dev flow, tickets that share a file or test target never share a wave
verify	on	run each ticket's check step
verifier	ultracode-qa	tier for verify and review (ultracode-qa* or ultracode-verifier*)
judges	–	comma-separated model ids (at most 7 in the dev flow, 8 in the plain one): one ultracode-verifier per model in each check, majority wins
deadline_min	20	per-phase deadline: each phase sub-agent gets it from its own start. A lead may run 3 × attempts phases for a dev ticket, 2 × attempts with a check in the plain flow (or without one in the dev flow), attempts for work alone, each with two minutes of slack; its wave closes one minute after that
critic	on	one completeness critic when the queue runs dry; in the dev flow it is the branch review: full test suite, linter and a review of the whole diff
max_items	5 × K	cap on tickets the run creates; K = leads per wave = min(concurrency, 8)
budget_usd	–	soft cap: checked with harness::metrics before each wave and at each round close; no new wave starts once it is reached. When a model has no catalog pricing or usage is missing, the cost is a lower bound (marked incomplete when the harness total is null; one generation without usage is left out silently), so the cap can be overshot
notify	–	a function id called with the final report (e.g. a Slack or email send)
project	–	an existing kanban project (id or name) to file the run under. Without it, Ultracode creates one project per run (ultracode: · ) (the repository rule set allows a create whose lead is ultracode, see Prerequisites), so the board's Project filter shows just that run; subtasks you add join it when their round starts
release	–	an existing kanban release (id or name), the same way. Agents can't create releases: make them in the console first

With hard caps: console runs have only the soft budget_usd. For a hard ceiling, start the run from the CLI (or any non-agent client):

iii trigger harness::send --json '{"message":"<goal + args>","model":"<provider::model>","options":{"agent":"ultracode","max_cost_usd":5,"max_total_tokens":2000000}}'

model is required because the profile sets none. Every model used in a capped run, every tier and judge included, needs catalog pricing. The dev flow's design, plan and finish questions appear in that session in the console; pass approve=off to run without them.

The dev flow

1. Design. Ultracode reads the repository (git status, the tree) and asks you what the code can't settle, one question card at a time, with two or three approaches and its recommendation first.
2. Plan. The design goes into the run ticket's description and each task becomes a subtask with a test-first card: Files:, Test first:, Implement:, Verify:, Commit:. A task is two to five minutes of work. You get one card: Start, Stop, or type your changes. A change rewrites the design on the run ticket first, then the affected subtasks (new ones are added, dropped ones are canceled with a comment), and the card comes back.
3. Worktree. git worktree add .worktrees/ -b ultracode/ (the slug ends with part of the session id, so runs never share a branch); run Ultracode from the repository's top folder. .worktrees/ is excluded locally (.git/info/exclude), so your files stay untouched. The test suite runs once for a baseline.
4. Per code ticket (ultracode-impl; a research ticket runs work then verify, without tests or a commit), its lead runs tests (write the failing test, see it fail for the right reason), code (the least change that passes it, then one commit ()), then verify (re-runs the Verify lines) and review (reads the commit, checks the test files are unchanged and nothing outside Files: moved) at the same time. A rejection goes back to the same code session with the reasons; a reason about the test reruns the tests phase. Tickets that touch the same file never run in the same wave: they share the worktree.
5. Branch review. When the queue runs dry, one reviewer runs the full suite and the linter and reviews git diff .... Findings become tickets for the next round.
6. Finish. A card: merge into your branch (then the worktree is removed), push and open a PR, keep the branch, or discard it. Ultracode does only what you pick; it never pushes, merges or deletes on its own.

Sub-agents never push, merge, rebase, reset, switch, stash or clean, and they work inside the worktree: their filesystem_root anchors every relative path there, and a stack whose filesystem boundary is workspace also refuses writes outside it. Loose ends a sub-agent notices but the goal doesn't need become Backlog subtasks labelled pending.

The board

• The run ticket is titled ultracode: with the label uc:run. Every run item is one of its subtasks: its page lists them with a done/total progress bar, and each round adds a summary comment with the cost. Filter the board by the run ticket to see only the run.
• The run's subtasks in To do, in board order, are the queue. In progress means its lead is running; the session tree shows each lead as ·