Work

The software factory

A pipeline that carries an idea from issue to reviewed, merged pull request, with humans at the gates that matter.

Role
Sole engineer
Stack
shell · git worktrees · Playwright · multi-harness
Status
Shipped

Coding agents are good at writing code and bad at deciding what to write.

I got tired of babysitting them one prompt at a time, so I built a pipeline that treats them like contractors: a spec they can’t misread, an isolated workspace, a build gate before anything earns a pull request, and a reviewer that is never the agent that wrote the code.

The public implementation of that architecture is the factory behind box-box. Same ideas, readable, building a real app. Issue in, reviewed and merged pull request out, with humans only at the two decisions that should stay human.

Two human gates. Everything between them is unattended.

Grooming is an interrogation, not a summary. A grill persona and an architect lens seed questions into the issue until there is a ready spec written into the issue body, with effort and priority set on the project. Then a human reads that spec and flips the stage to Ready. That is the first gate: nothing starts until someone has accepted the work as worth doing.

The box-box software factory pipelineThree phases: Groom, Implement, Review. A grooming agent interrogates the issue into a spec; a human approves it; a harness implements it in an isolated worktree behind a build gate; a different harness reviews it; a human merges.01 · GROOM02 · IMPLEMENT03 · REVIEWGitHub issueStage: Icebox → Researchgrill persona + architect lensseeded interrogation, not summarizationReady spec written into issue bodyEffort + Priority set on the ProjectHUMAN GATEyou read the spec and flip Stage → Readydev implement <issue> --harnessStage → In Progressisolated git worktreeown branch, own workspace, no collisionsharness runs headless on the specone adapter function per toolBUILD GATEfails → no PR is ever openedrejected work never reaches a humanPR openedStage → In Reviewreview skill, a different harnessthe agent that wrote it does not grade ittests + Playwright visual capturechecked against the spec in the issue.review packet + PR commentfindings posted where the work livesHUMAN GATEyou mergeStage → Done43 of 44 pull requests mergedhuman gate: the two decisions that stay mineautomated gate: rejects before a human is involvedharnesses: claude · codex · opencode · cursor · piantigravity: disabled 2026-07-04, headless path unreliable
The pipeline behind box-box. Two human gates; everything between them is unattended.

Implementation opens an isolated git worktree (own branch, own workspace), runs a harness headless against the spec, and hits a build gate. If the gate fails, no pull request is opened. Rejected work never reaches a human. When the gate passes, a PR opens and a different harness reviews it: tests, Playwright visual capture checked against the spec, findings posted as a review packet on the PR. The second human gate is merge. The agent that wrote the code does not grade it.

One adapter function per tool. That is the only harness-specific code.

The .agents/ toolkit holds skills, personas, prompts, and shared library scripts in a portable layer every harness can read. Project context lives once and fans out to the files each tool expects. Below that sits a single adapter surface: one function per harness that takes a workdir and a prompt file, plus the shared gate runner.

Harness-agnostic agent toolkitCanonical skills, personas and prompts live in a portable layer. A single adapter function per tool is the only harness-specific code, so a new coding agent can be added or disabled without touching the workflows.PORTABLE · READ BY ANY AGENTAGENTS.md→ CLAUDE.md · GEMINI.md , the project context every harness reads.agents/skills/groomwrite-specimplement · reviewpersonas/grill.md, the base voicearchitect.md, a lensinterrogators, not helpersprompts/ready-spec.mdimplement.mdreview.mdlib/gh.sh: issues, Projectdispatch.sh: worktree,gate, PRthe only tool-specific code in the systemharnesses.shharness_<name> <workdir> <promptfile>: one function per tool, plus run_gateadding a coding agent is one function; removing one is deleting itclaudecodexcursoropencodepiantigravitydisabled, see note
Canonical skills and prompts above the line. One adapter function per tool below it.

Six harnesses plug in that way: claude, codex, cursor, opencode, pi, and antigravity. Adding a coding agent is writing one function. Removing one is deleting it. Antigravity is currently disabled, because when I tested its headless path it wasn’t reliable enough to trust with unattended work. That row stays in the table, with the date on it.

The factory is the argument, not a demo of a model.

What this setup defends is structural, not clever prompting. Humans keep the decisions that allocate attention (is this worth building, does this merge). Automation keeps the rest, including the quiet refusal to open a PR that would only waste a reviewer’s time.

The same pipeline is what box-box was built with, and the harness table on /agents is the living log of which tools still earn a seat. The factory does not care which model is fashionable this month. It cares that the work arrives as a spec, fails closed at the build gate, and is reviewed by something other than the thing that wrote it.

That last rule shows up again in how I route models: the thing that made the decision does not get to grade it. Grooming and implementation can share a vendor when that is the right call; review should not be a self-grade. The factory encodes that as structure so I do not have to remember it under deadline pressure.