claude-helpers

It started with me asking Claude, by hand, "what would Uncle Bob think of this?" I'd write a plan, have it reviewed as one persona, fix what came back, and ask again as another. I kept adding voices, and the hand-typed prompts turned into the toolkit I work out of every day. Some of it predates the repo, which started around October 2025.

This page is for anyone using Claude Code for real work who wants to see how one person's setup fits together and why. I use it on everything I write code for: this site, lotl, the BedtimeStories app, and more.

Blind-first review

/expert-review runs a diff past a panel of 28 named reviewers, each with a narrow concern (security, type safety, concurrency, dead code, and so on). The first pass is blind: a reviewer sees the diff and nothing else.

Why: if I tell a reviewer why I did something, it takes my reason and runs with it. Human reviewers do the same thing. So the first pass never sees my justification. The blindness is enforced by isolation, not instruction: each reviewer is its own subagent that can't see my reasoning or the other reviewers' output. Asking a model to ignore something it can see doesn't work well. Not handing it the information does.

When one comes back with "why is this done this way?", that's a better question than any answer I'd have handed it. A second pass then re-reads each finding with the business context and keeps, downgrades, or withdraws it.

One reviewer is deliberately not blind. Contrarian Carl runs last, reads everything the panel found, and looks somewhere else: what haven't I asked? Most of his findings get rejected. The ones that stick are usually ones nobody else would have raised. He's my favorite.

Sizing and finishing a review

A full panel on every diff is slow and expensive. So a router sends each reviewer only the parts of the diff it cares about, and an effort ladder from 1 to 5 scales a run from six cheap scouts up to everyone. Left unset, a heuristic picks the level from diff size and risk keywords. Review subagents were the largest item in my token spend, so the default leans small.

The run ends in triage, not a report. The panel got good enough that reading its output became the expensive part, so every finding is sorted into one of four buckets: doing it, needs you, needs measurement, deferred. "Needs you" is kept short on purpose.

Expert planning

/expert-plan builds an implementation plan from a ticket. Three experts contribute in isolation, Carl looks for what they all missed, and a synthesis step merges the contributions and checks that every requirement and decision landed in a step. A higher effort level adds an independent auditor.

Why this shape: the first version let decisions drift between steps because nothing checked consistency; the second fixed that at three times the cost. This one keeps the consistency check without the cost, with a cheaper model orchestrating and the expensive model doing the judgment steps.

Implementing with cheap models

/implement-with-haiku splits a plan into independent units and gives each to a Haiku agent in its own worktree. Each hands back a diff. The orchestrator (Sonnet) applies them, builds and type-checks, then scans for tampering: touched test files, || true, it.skip, stubs, functions nothing calls. Then a second Haiku writes tests from the plan alone, without reading the implementation, because tests written from the implementation just encode the implementer's assumptions.

Why: Haiku does the mechanical work and the expensive model is kept for judgment. The scan exists because the implementer's own report of success isn't trusted.

The rest

• Hardening. /expert-harden-types, -contracts, and -tests switch a review persona to edit mode: tighten types, document preconditions, write property-based tests.
• Pre-mortem. /expert-pre-mortem is Fragile Feynman alone, scanning a diff for ten kinds of fragility and writing the fictional post-mortem for each.
• Shipping. /track-and-start makes an issue, branch, and worktree. /shipit runs local CI, commits, and opens the PR. /queued-merge merges one PR at a time against the exact base it lands on. /cleanup removes the worktree.
• Project context. A .claude/project.yaml tells the reviewers your stack and ADRs. At work, a team sharing the same reviewers gets consistent PRs without anyone arguing for it.

Why it's public

I was talking to a few people and they were interested. The idea is that you pull the repo and build your own practices on it, not adopt it as is. I'm constantly working on it and changing it, and the git history shows that. The README says to fork it and not merge back. Nearly every commit in the public repo went through the panel itself.

What I learned

• Telling a reviewer your reason makes it run with your reason. Withhold it on the first pass.
• Isolation beats instruction. A fresh subagent can only see what it's handed, and that's the only kind of blindness that holds.
• They catch me all the time. Open any PR, even a recent one, and Uncle Bob is flagging something that isn't DRY or isn't clean code. The open question is when I should stop asking for improvements.