The Coding Pipeline

One-shot code generation produces one-shot quality. The pipeline exists because real development is iterative, plan, build, review, fix, polish, and because iteration only works when each pass knows what the previous passes did. This page covers how tasks flow through, where output lands, and how to get the most out of it.

Queueing a Task

A task is a file in work/coding/queue/, and everything that can write a file can queue work: ask the master agent to build something and it writes the task for you, Impulse queues builds it deems worth making, and you can drop a file in the queue yourself. The task describes what to build the way you would brief a developer, context, requirements, constraints. The pipeline node ticks on its own schedule, picks up the next task, and works it to completion before taking another.

The first line of a task file can set a role: type:<agenttype> loads that agent type's role instructions for the run. The default is devteam, the generic development role, and its step files plus your coding standards in memory/system steer how every pass works, which means the pipeline writes code the way your shop writes code.

The Passes

Plan and build comes first: the session reads the task, plans the approach, and writes the implementation. Review and fix runs at least twice: the same session steps back, reads what was built with a critical eye, finds the bugs, gaps, and rough edges, and fixes them, then does it again. Cleanup finishes: dead code goes, naming gets consistent, the loose ends from iteration are tied off.

The continuous session is what makes the passes compound rather than repeat. The first step creates one AI session and every later step resumes it, so the second review pass knows what the first one fixed and why, and the cleanup pass knows the full history of decisions. The output reads like one careful engineer's work because, in terms of context, it is.

Where Output Lands

Fresh work goes to projectfiles/ by default, or to the project path you configure per task or per project. Existing git projects get the full courtesy treatment: a pre-flight check confirms the working tree is clean before the pipeline touches anything, so your uncommitted work is never mixed with the machine's, and each cycle auto-commits, leaving a readable history of what each pass changed. Reviewing a pipeline run on a git project is as pleasant as reviewing a colleague's branch, read the commits in order and you see the build, the review fixes, and the cleanup as separate steps.

Model and Schedule

The pipeline has its own card in the Config tab's Models panel: its model key and tick rate, independent of every agent. This is the seat where strong models earn their keep, the difference between a mid-tier and a top-tier model shows directly in the code, and the effort-level keys (claude-opus-high through claude-opus-max, or the codex-5.5 ladder) exist for exactly this kind of work. The default 15-minute tick just controls how quickly the queue is checked; each task runs as long as it needs.

For interactive use, the same machinery is available as a one-shot tool launchable from the UI, the multi-pass discipline without the queue, when you want a result while you watch.

Working With It Well

Brief it like a senior contractor. The task file is your leverage: name the files or project it should work in, state constraints explicitly, and say what done means. Keep your coding standards file honest, every pass reads it, so a one-line standard ("prefer plain functions over classes for utilities") quietly improves every future task. And let the memory bank work: pipeline runs save what they learn, the patterns of your codebase, the gotchas of your stack, so the tenth task on a project goes noticeably smoother than the first. Everything the pipeline does streams to the activity feed, and the work directory keeps each task's artifacts inspectable.