Topping Out

Let AI coding agents work through your tickets for hours, even overnight, without drifting: every job starts fresh from files, a cheap model does the heavy coding, and your Claude Code limit lasts far longer.

Each job ends with evidence you can check: what was asked, what was built, what was tested, and what reviewers found.

The problem: one agent plans, builds and then tells you it's done, so it marks its own homework. After an hour or two it drifts from the plan, and the expensive model burns your usage on typing.

What Topping Out does: splits the work. A foreman plans each job in a fresh session and never writes code, a cheaper builder does the typing, inspectors from another model family check it, and you give the word for what matters.

Even a very cheap builder works. The weaker the builder, the tighter the foreman writes the work orders: one checkable outcome each, every decision already settled (builder profiles).

Site: toppingout.dev · Repo: github.com/kaithoughtarchitect/toppingout

The project board (synthetic example): the head is what the product must do, every rib is one job. Solid is merged, yellow is next, dotted is blocked.

Try it in 2 minutes

1. git clone https://github.com/kaithoughtarchitect/toppingout
2. In Claude Code, in the repo that will hold your records, say: Read <path to toppingout>/skills/f-setup/SKILL.md and follow it
3. Give the foreman one small ticket. It walks the site, then asks for your "go".

What a finished job looks like

One real job, run on its own from ticket to merge (an autonomous run; the project's name and feature are left out):

ticket      one feature, one branch, one PR
plan check  5 findings from a cross-family reader, 4 applied before building
build       work orders written by the foreman, built test-first by a cheaper model
inspect 1   lens inspection: 18 fixes found and accepted
inspect 2   independent review (another model family): no findings
review      Greptile 5/5
tests       831 -> 848 passing; no test red at head that was green at base
probes      18 of 18 mutation probes caught (each removes a guard; the tests must fail)
merge       merged tree identical to the reviewed tree
spend       at most 1.34 USD in paid calls, against a 3 USD cap
record      acceptance ledger, both inspections, base-vs-head runs, lessons saved as cards

The smallest loop:

1. a foreman session reads the ticket and the code, and writes exact work orders;
2. a builder session implements each one and reports, with its test output;
3. the foreman checks the work on disk, and inspectors (fresh review sessions, one of them from another model family) review it and only report;
4. you, the owner, give the word for the acts RULES.md reserves for you: merging, pushes, messages, migrations and the rest.

Work orders reach the builder as a one-line pointer: you paste it, or the foreman sends it over a pane link. With an autonomous-run goal (/goal autonomous run: …), or a night shift of them, a job runs to the merge without you (with the pane link carrying the pointers), inside the grants RULES.md ("The one exception") lists. Any other standing goal grants nothing.

The name comes from the building site: the ceremony held when the last beam goes on. The roles follow the site too, and the skill names start with f-, for foreman, the role that runs them. It has been used on real codebases since September 2026.

How to start: in the repo that will hold your records, start a session and say Read <path to this folder>/skills/f-setup/SKILL.md and follow it (SETUP.md). Then run one job (below). You don't need the whole flow first: the foreman follows METHOD.md, and you answer when it asks.

Tested on Windows with Claude Code as the foreman. macOS and Linux are expected to work (the scripts are Node, Python and Bash) but aren't verified yet: SETUP.md, "Tested setup".

One job, from your side

1. Give the foreman a ticket: a tracker link, or a short TICKET-<nn>.md (/f-sketch helps write one).
2. It walks the site, then asks for your "go".
3. It writes work orders; you paste each pointer into the builder (or the pane link does it), until the build, the two inspections and the acceptance ledger are done.
4. On your word ("open the PR") it opens the PR, and on "greploop" runs up to three Greptile rounds. You say "merge" when the evidence satisfies you.
5. It closes the job, saves the lessons, and proposes the next ticket for you to confirm.

Start here

The idea in seven lines

1. One ticket = one job = one branch = one PR.
2. The foreman never writes product code; the builder never makes design decisions.
3. Everything goes through files. Work orders are files, reports are files, reviews are files. The builder gets a one-line pointer (from the owner, or sent over a pane link by the foreman), never pasted text.
4. Disk before words. After every builder step, the foreman checks commits, captures and files on disk before it reads the builder's report.
5. Every claim carries its evidence: a command and its output, a commit hash, a test name. A claim without evidence counts as not done.
6. Some acts need the owner's word. These are approval boundaries, not all of them irreversible: merging and pushes, tracker transitions, messages, branch and worktree deletion, edits outside the ticket's files, migrations, and the "greploop" grant for at most three Greptile rounds on one PR. The full list, and the exceptions (the job's own cleanup and records push after a verified merge, an autonomous run's grants), are in RULES.md.
7. Every reply ends with the 5-line status block (templates/J-STATUS.md).

The flow at a glance

Before any job, a big plan is cut into tickets: /f-survey → /f-blueprint → /f-plancheck (cold cross-family read) → /f-schedule (project, one ticket per job, the project board). Each job below builds one ticket (METHOD.md §13).

 SHIFT HANDOVER + OPENER ──> SITE WALK ──> [owner: "go"]
                                          │
          BUILDER PRE-FLIGHT (read-only env check) ── READY / BLOCKED
                                          │
 WORK ORDER 1  setup + baseline (worktree, job file, t0 captures) ── no code
                                          │
 WORK ORDER 2  form A (default): "plan in force + T1" (the foreman wrote and validated the plan)
          form B (an audition): the builder writes the plan as plain steps (WORK-ORDER-2-PLAN.txt)
                                          │
 GATE 1   form A: /f-plancheck on the foreman's own plan (cold seats, other families; before work order 2)
          form B: the foreman reviews the builder's plan ──> findings
                                          │
 WORK ORDER 3..N  one decision-complete task per work order, test-first, one commit each
      │  after EACH: disk check → work order review (re-probe, verify test-first, switch-rule line)
      │  next work orders drafted while the current one runs
                                          │
 BASE-VS-HEAD  builder work order; any red-at-head-only = STOP, foreman characterises
 GATE 2   foreman reviews every commit + runs its own base-vs-head
 LENS INSP.    foreman runs /f-inspect in its own session (fresh lens agents) ──> checks each finding ──> repair work orders (QUICK: skipped)
                                          │
 CROSS-MODEL   foreman /pack-review (checks its own brief) ──> fresh session of another
               family runs /xreview ──> foreman /adjudicate ──> repair work orders
 FINAL RE-RUN  all captures, probes, both base-vs-head again at the final head
 ACCEPTANCE LEDGER  no FAIL/UNTESTED/INCONCLUSIVE to open the PR; every row PASS (the foreman's own run done) to merge
                                          │
 PR opened (owner watches it in the browser) ──> [owner: "greploop"] /f-greploop: ≤3 Greptile rounds
      (adjudicate → builder repairs → tests + both base-vs-head + ledger re-run → push) ──> PR description check
                                          │
 [owner: "merge"]
                                          │
 /f-signoff (+ Logbook cards) ──> dev report ──> next-ticket decision ──> you confirm ──> /f-board close ──> handover + opener ──> records push
                                          │
 when every job on the board is done: TOP OUT: close the last job ──> topout (board frozen as the record) ──> topping out report ──> candidate next heads
                                          │
 [owner picks a head] ──> /f-survey ──> /f-blueprint ──> /f-plancheck ──> /f-schedule ──> a new board, and the loop starts again

Topping out is where the name comes from: when a board reaches its head (every job merged or resolved), the end game freezes it as the project's record, writes what was built and what's carried over, and offers three to five candidate next heads. You pick one, whenever you're ready, and the cycle starts again on a new board (METHOD.md §11b). Work found while testing a product goes on an iteration board instead: no blueprint, small jobs added as you find them.

Folder map

Precedence

When two sources disagree: the owner's own words → RULES.md → METHOD.md → OVERRIDES.md → BUILDER-PROFILES.md / SETUP.md → Foreman-Playbook.md (the why behind the foreman rules in RULES.md) / Builder-Playbook.md → templates/ → the bundled skills/ and agents/. The bundled skills and agents are general; OVERRIDES.md lists exactly where the method beats them.

What it is not

• Not autonomous by default. By default you give the word for every push, PR, review round and merge (except the job's own cleanup and records push after a verified merge): the owner is the one piece a confident report can't talk round. Autonomy comes only from an explicit grant: an autonomous run (/goal autonomous run: <path to the job's opener>) or a night shift covers exactly the acts RULES.md ("The one exception") lists, for the jobs it names, and repairs what goes red and stops only on the conditions RULES.md ("The one exception") lists. A standing goal never covers the other gated acts.
• Not a second judge on top of the foreman. Reviews are layered by independence (a fresh session, a different reader), not by stacking graders. Separate reviewers reduce some failure modes; they don't guarantee correct code.
• Not tied to one builder. Any agent that can read a file, run a shell and write a report can build. How much the work order has to spell out depends on the builder (see BUILDER-PROFILES.md).

What software enforces, and what is only instructed

Most of the method is instructions the agents follow; a few checks are scripts that refuse. Know which is which:

If this saves you a babysitting session, a star helps others find it.

Licence

MIT. See LICENSE.