You and the model settle the plan in a file before any code. Then it builds one small step at a time and stops after each one — waiting for you to read the diff and approve before anything is committed. Its one law: vibe to execute, never vibe to decide.
Most AI-assisted work swings between two poles. Full autonomy takes you off the thinking — the artifact comes back and your job was to audit it. Vibing fuses deciding and executing, so the model converges on a shape before you chose it and you spend the day cleaning up behind the flood. Both destroy the scarce resource: your attention. PlumbBob is the third mode — you stay the author, the machine does the labor, and a boundary keeps the execution stream from overrunning your judgment.
The whole goal is settled on paper first — the Frame, the Decisions (each with its because), and every numbered Step. The unit of work is a decision resolved, not a diff generated.
The loop does a step's labor, pulls up to the line, and waits. Nothing is locked and nothing refuses you — the boundary between deciding and executing is a pause you advance, not a wall that fights you. Re-firing /pb-build is the clock tick.
A mid-build "ooh, what if…" never derails the step. /pb-park captures it in one line; /pb-harvest judges it cold at the next boundary. Most ideas are still good ten minutes later — the ones that weren't cost you nothing.
A typo earns no session; just fix it. The loop pays for itself from "contained bug" up to "feature touching a few modules." Above that, reach for full autonomy. Ceremony destroys attention too — knowing how much process a task deserves is the skill.
Everything the model must stay true to lives in one file — the build's intent.md, written before any code. Then each step is built, checked, self-reviewed against the plan, and committed as its own checkpoint only once you approve. A wrong turn costs one step, not the afternoon.
On your OK it commits the step as a checkpoint, marks it done, and returns to the boundary. Fire /pb-build again for the next step. You are the clock.
/pb-build is the default engine, not the only one. Implement a step by hand — or vibe it in another session, or in another harness entirely — and run /pb-verify instead: same checks, same pause, same checkpoint.
That mechanical half is what PlumbBob adds under the skills. Five deterministic edges, enforced by the CLI and git rather than by the model's goodwill. The planning surface is the on-ramp; these five are the floor under it.
A headless skill-eval harness sweeps the loop — prose-only baseline vs. the shipped latch, N=5 per contract, every assertion a mechanical read of git state — and commits each receipt to the repo. The route the latch owns: no checkpoint over a red check, under adversarial pressure.
You drive the whole loop from your IDE — no step numbers to remember, no raw CLI to type. Every skill is disable-model-invocation, so you fire every move, and /pb-status always names your next one. Most sessions need only the four on the happy path.
| SKILL | group | does |
|---|---|---|
| {{ row.name }} | {{ row.group }} | {{ row.does }} |
A user-authored agent is anything executable that speaks one small JSON envelope — a twelve-line bash script is a complete agent. Drop it under .plumbbob/agents/, bind it to a step's before / build / after slot, and PlumbBob runs it through the same pause — with no way for it to advance the loop. The check gate still gates; you're still the clock.
The agent contract →Add the marketplace, install the plugin, and the twelve /pb-* skills are in your IDE — no npm, no CLI to learn. Then, inside any git repo with a clean tree, fire /pb-plan and go.
An attention-first build loop for Claude Code. Guidance on the work, a latch on the record — the human owns every decision, the model owns the labor.