boondoggling.ai · Practice Guide
Anyone can use Claude code. Boondogglers conduct it — with structure, precision, and the five supervisory capacities that no model can replace.
March 30, 2026
A moderately complex website — six routes, a hybrid filesystem/database architecture, an admin dashboard, a community upload pipeline, a sandboxed iframe viewer, and a full prompt library — went from idea to live in roughly three hours.
Two hours of conversation. One hour of Claude Code. Nearly all the time was spent talking.
Every prompt worked. Not because the prompts were magic. Because the conversation that produced them was structured. That is boondoggling.
The mental model comes from the movie. Gru does not build the rocket. Gru designs the mission, assigns the minions, checks their work, decides what the mission IS, and takes responsibility for the outcome.
The minions are excellent. They are enthusiastic. They will execute exactly what they understood you to mean.
Give them a vague prompt and they will produce a confident, plausible, wrong answer. Give them a complete specification — with context inline, output format named, negative constraints stated, and a testable handoff condition — and they will produce exactly what you needed.
Your job is not to type less. Your job is to be Gru.
Anthropic's Claude interface has a gift for anyone who works with AI: a collection of words for what Claude is doing while it thinks. They are not progress indicators. They are tiny moments of delight.
Boondoggling makes five supervisory capacities explicit. These are not skills you develop. They are roles you exercise at specific moments in a build.
Hearing the wrong note before you recompute it. Knowing an output is wrong because of what you know about the domain — not because you checked. This is the capacity that catches confabulation. Claude cannot do this for itself.
Deciding what the mission is before Claude sees it. Not reframing after — before. The quality of the output is determined here, before any prompt is written.
Choosing which Claude task, in what order, with what context, and how to verify it. Deciding when to trust the output and when to run another check. This turns a collection of prompts into a build sequence.
Supplying meaning, accountability, and domain reality to Claude's output. Deciding which of Claude's variations is correct for this context. Signing your name to the decision. Claude cannot be accountable for what it produces. You can.
Holding all four simultaneously toward a unified goal. Recognizing when one Claude output requires another task to re-engage. Knowing when the build is done.
After a Software Design Document is complete, /claude generates the Boondoggle Score — a conductor's score with two simultaneous parts: the Minion Part and the Gru Part.
Every Claude task has context required, a complete copy-pasteable prompt, an expected output, and a handoff condition. Every human task has a supervisory capacity label and a specific action.
The handoff condition is the most important element. A minion who does not know when to stop will stop at the wrong place or not stop at all.
The handoff condition is the conductor's downbeat.
Version one is not the product. Version one is the thing you learn from. The real world will test the site. Users will find paths you did not design for.
The process for frick-fracking is lighter than the full SDD build:
Name what needs to change and why (one sentence).
Check whether the change contradicts anything in the SDD (one minute).
Write the prompt — precise, context inline, handoff condition named.
Verify the output.
Ship.
The SDD is what makes frick-fracking safe. Because the architecture is documented, small changes do not accidentally become large ones.
Noodling is dreaming. It has no deliverable. It is the lightest touch — a thought that something could be interesting, a feature that might exist, a direction the platform could go. Noodling is where the next SDD begins.
The discipline is knowing which noodle is worth developing and which is a gallivant — an appealing direction that does not serve the person the site is built for. Every noodle that survives the "what problem does this solve for whom?" test becomes a candidate for the next build cycle.
Boondoggling is not a tool. It is a practice.
Before Claude sees the problem, you decide what the problem is. Before Claude produces output, you specify what done looks like. After Claude produces output, you verify it against domain reality before the next step begins.
You are not saving time by skipping those steps. You are borrowing it, at interest, from the moment when the wrong thing ships and has to be unwound.
The minions are excellent. The mission is yours.
Built with Gru. Documented with the methodology it teaches. · boondoggling.ai