The lot method: one measurable objective per agent session

Why an agent drifts

A coding agent receives a request, understands part of it, then fills the gaps with its own assumptions. On a small task, that does not matter. On a real task, assumptions pile up: the agent delivers something that compiles, passes its own tests, and is not what you wanted.

The second problem is memory. A long session grows heavy and the agent forgets early decisions; a fresh session starts from scratch and you explain everything again. The lot method answers both: scoping before coding, and a document that keeps the thread from one session to the next.

Scope before coding

It all starts with a short interview. The scoping skill, grill-me, asks its questions in rounds: what to deliver, for whom, what is out of scope, how we will know it is done. It stops as soon as the important decisions are made, then summarises; you confirm or correct.

The result is written down, not kept in memory: the intent of the task goes into its roadmap, and each step becomes a lot with its own document. Nothing that was decided depends on what a session remembers.

A lot: one branch, one session, one objective

A lot is the smallest useful delivery: one branch, one agent session, one objective. Its document holds the objective in one line, the scope and what it excludes, measurable completion criteria, the steps, the risks, then a log kept during the work.

A completion criterion is checked by a command or an observation: “the test suite exits without error and the page shows a single main heading”, not “the page is well made”. That is what lets the agent know it is done, and lets you check it without rereading all the code.

At launch, lab launch rebuilds the objective from the document and hands it to the agent: nothing to copy, nothing to type, and no truncation on the way.

Splitting a task well

A good lot can be delivered on its own: once merged, it leaves the project in a consistent state, even if the following lots never come. It fits in one agent session without its context overflowing, and its completion criteria are checked in a few commands.

The first lots lay down what the others depend on; the last one makes the result ready to try. When a lot reveals a surprise, the order of the next ones changes in the roadmap, not in the agent’s head: the next session reads the updated version.

An oversized lot is easy to spot: an objective that takes several sentences, criteria that start with “and also”, a log that grows without evidence. Better to cut it in two than to let the agent improvise the end.

Run: test, log, prove

During the lot, the agent moves in small steps, each with its test. For every bug fix, it writes the test first and watches it fail: a test never seen red proves nothing.

It keeps a short log in the document: what is proven, with the command and its result, what remains, what it decided not to do and why. Measurements and screenshots go into a proof report stored with the lot, which the document cites instead of copying.

$lab status project-2SLUG=feature-4BRANCH=feat/admin-overridesBATCH=lot-03-admin-overridesBATCH_STATE=in progressLANE_PHASE=workLAST_BATCH=yes$lab next project-2 feature-4lab: Last planned batch — a check together will follow.$lab plan project-1lab: 3 lanesLane              Presence   Done/total   Current batchfeature-1         alive      1/2          lot-02-search-results-page · Search…feature-2         alive      0/1          lot-01-feature-2 · Export orders as…feature-3         alive      1/1          —

Resume without explaining again

When the context grows heavy, the agent does not wait to saturate. It writes the handoff: where it stands, what remains, the next action. lab next then opens a fresh session in the same tab, starting from the document rather than from scratch.

The same command works between lots: it reads where the task stands and starts what is needed, running or resuming the lot, opening the next one after a delivery, or preparing your final trial. It neither merges nor deletes anything.

Close: independent review and real checks

A lot closes only after your repository’s checks: tests, style and types green. Then an agent that did not write the code reviews the diff against the document, as an independent review, and reports only correctness or scope gaps.

Finally, each completion criterion is proven by a real run, and the listed screens are checked in a real browser. Only then does lab merge deliver the lot, after checking the report and the pull request’s checks.

The method does not guarantee defect-free code: it makes missing evidence visible, before it goes missing on your side.

Claude Code and Codex: the same method

The method ships as identical skills and agents for both tools. Claude Code calls them with a slash command, Codex by their name preceded by a dollar sign; the content is the same. Each worktree keeps the agent chosen at its creation, and lab next relaunches it.

Codex asks you to approve the hooks once through /hooks; lab doctor checks that they are active. Treelab is an independent product: Claude Code and Codex are named with no affiliation.

To see each command in action, read the features page. To isolate each task, the guide to worktrees; to keep the decisions yours, the one on staying in control.