TLC Implement

When one agent is not enough

A long build runs out of context, and the two ways through it are not equivalent. Automatic compaction summarises the conversation and chooses for you what to drop, at whatever token boundary it happens to hit. A handoff to a fresh agent carries the artifact, at a boundary you chose. This skill is built for the second: the checklist plus the diff is a better briefing than a machine summary of a chat, which is the whole reason Landing rows are appended before the code that closes them rather than at the end.

The batch is whole slices, and you decide how many while writing the checklist. Slices come from the upstream task, one observable outcome each, and their checks are countable before any code exists - so the split is knowable in advance, which is the only reason it can be declared and argued with. Never split a slice: mid-slice is green but incomplete, and the next agent inherits half an outcome, which is the horizontal cut the whole pipeline exists to avoid.

Weigh the slices, do not count them. Slice size varies by a factor of three or more inside one task - the one holding all the doors is rarely the one with three trivial criteria - so a fixed number of slices per batch inherits all of that variance. Pack by the size on each slice heading: accumulate whole slices while the running total stays under 150k tokens, and hand off at the last slice that fits. Where two packings both fit, prefer the boundary at which the surface changes - where the next slice reads different code - because there the next agent had to read it anyway and nothing is paid twice.

A slice that alone exceeds the budget is a slice the upstream task cut too coarsely. Say so rather than splitting it here: cutting mid-outcome is the horizontal cut this whole pipeline exists to avoid, and the task is the place that can re-cut it vertically.

Why a token budget works where a check budget did not. What a check costs is a property of the repo - fourteen checks inside one service share their reading, fourteen across fourteen modules pay it in full - so a count travels badly between projects. A token does not: it means the same thing everywhere, and it is measurable from the files themselves. 150k is the default because it leaves the rest of a large window for the part no arithmetic reaches - failing tests, retries, a runner dumping two thousand lines. Where a project runs a different window, it says so: handoff: on, budget 90k. Do not fix the number of agents up front, though; that is still a boundary you would honour after it stopped making sense.

Write the intended split into the checklist while you are still writing it, under a ## Handoff heading, with the arithmetic that produced it - "S1-S3 = 118k, all in Warehouse; S4 enters Quantities at 140k, so hand off after S3". It costs a line, it is contestable before any code exists, and it is the only moment when anyone can say the batching is wrong cheaply. A number with its reason beside it can be argued with; a bare "hand off after slice 3" can only be trusted.

Handing off. Only on green, with every proof in the batch passing. The next agent reads the checklist and the diff of what has already landed - never a narrative summary of it. The diff is the state, and it carries the hundred reversible choices that sit below the Landing bar: naming, error shape, where the helper went. Those are exactly what drifts between agents, and they are exactly what no document records.

Then append three lines to ## Handoff. They go in the checklist rather than in the next agent's prompt: a briefing written into a prompt survives exactly one boundary, and the third agent needs the first one's.

• Where the boundary fell - the checks now closed and the commit that closed them. Scope then comes from the artifact instead of being reconstructed from a diff, which is the one inference the next agent would otherwise have to make before writing a line.
• What the user settled mid-build - every clarification and renegotiation that did not already become a Landing row or an edited check. This is the class that hurts most, because it exists only in a conversation the next agent cannot read, and re-deriving it means asking the user the same question twice or guessing, which every other part of this skill forbids.
• What was abandoned - tried, discarded, and why. The one thing neither the code nor the checklist preserves.

When compaction happens anyway, re-read the checklist and the diff before continuing. You cannot see the limit approaching - no reliable measure of your own context exists - but you can see that a compaction occurred, so build the recovery on the signal that exists rather than on predicting the one that does not.

That paragraph is the whole strategy under handoff: off, which a project sets when its harness has no sub-agent mechanism, or when one continuous session is simply easier to review. Off means one agent, compaction, and re-reading - so the checklist earns its keep more rather than less. Say at the start of a long build that handoff is off, and where the work is plainly too large for one context say that too, then let the user turn it back on for this feature.

Where the source is a ticket or a thread rather than a task with slices, there are no inherited boundaries, so cut on the surface you found yourself - the module the next checks move into. Say when that happens: a boundary you drew is weaker than one the upstream task drew, and the next agent should know that is what it inherited.

Verify

When the last commit lands, dispatch the Verifier automatically. See verify.md. The work is not done at the last commit; it is done when the Verifier's report accounts for every check.

"After the last commit" means the last one of the feature, not of your batch. With handoff on there are two different lasts, and collapsing them is the shortcut that looks like saving a hop: the agent closing the final batch tells its own sub-agent to verify on the way out. Even with a clean context that sub-agent is briefed by someone who only saw the final batch, so it verifies that slice's range and reports a pass that reads as if it covered the feature. And the verdict goes back to the author, who is then the one deciding what to do about it.

So a build agent finishes, reports, and stops. Verification is the orchestrator's step: it waits for the last batch, then dispatches one agent over <feature base>..HEAD with every check. If you find yourself writing "when you commit, dispatch the verifier" into a builder's prompt, that is the mistake with a friendly face.

Knowledge chain

In strict order: existing code and conventions, project docs, library documentation, web search, then flag as uncertain. Never invent an API, a flag or a behaviour. "I could not find documentation for this" always beats a plausible fabrication.

Output

Produce the artifact; do not narrate the phase. Lead with the verdict. State decisions definitively. Cut filler and hedging.

Examples

Example 1: Decided work, one feature

User says: "Implement this spec." Actions:

1. Read the source completely, then walk the code it touches.
2. Refuse vague claims. Sweep the nine unwritten requirements.
3. Read references/checklist-format.md and write .checks/<feature>.md.
4. Build from the checklist. Run each proof. Commit in coherent pieces.
5. After the last commit of the feature, dispatch a fresh Verifier with references/verify.md. Result: a checklist with named proofs, green proofs, and a Verifier report that accounts for every check.

Example 2: Nobody decided

User says: "Build a cache for the dashboard." Actions: Do not run this skill. There is no prior artifact to extract from. Result: hand off; no .checks/ file from this skill.

Example 3: Wrong skill

User says: "Should we add billing?" Actions: Do not run this skill. Nobody has decided what to build. Result: hand off; no checklist and no code from this skill.

Common failures

A proof that names a suite

Cause: Proof: npm test was treated as settling one claim. Solution: name a specific test. A suite going green says nothing about this claim.

The author verified their own work

Cause: the builder dispatched a child agent, or re-checked the diff themselves. Solution: a build agent finishes, reports, and stops. The orchestrator dispatches a fresh Verifier over the whole feature after the last batch.

A test written from the implementation

Cause: the assertion mirrors what the code happens to do. Solution: tests assert what the checklist says. If a check is wrong or impossible, stop and renegotiate rather than quietly adjusting it.