One Claude Code Tip a Day: Draft the Plan in /ultraplan Before the Patch

This post is part of the “One Claude Code Tip a Day” series — a daily guide to using Claude Code more effectively.

The failure: the first patch is too convincing

The dangerous Claude Code session is not the one where Claude is obviously confused. It is the one where it sounds organized, edits three files, and hands you a green-looking explanation before anyone has decided what would actually prove the work. I see this most often in medium-sized changes: adding a billing flag, replacing a cache layer, or moving a frontend flow from local state to a server action. The request is not huge, but it crosses enough files that a normal 'please implement this' prompt turns into a patch before the architecture has been challenged.

Today’s habit is to use `/ultraplan` before the patch when the work has more than one moving part. Treat it as a planning room, not as a fancier way to ask for code. The goal is to make Claude Code draft a plan that can be reviewed, attacked, and sliced before it touches your working tree.

Use /ultraplan as a separate planning room

Start from the repository that can prove the change, then open the plan with a prompt that forbids implementation. For example:

`/ultraplan We need to add organization-level invite limits to the SaaS dashboard. Do not edit code. Read the relevant auth, billing, and invite paths. Produce a plan that names files, data model assumptions, migration risk, tests, and the smallest first slice we can verify locally.`

That prompt does two useful things. First, it tells Claude the task is cross-cutting, so it should inspect before optimizing for speed. Second, it asks for evidence categories: files, assumptions, tests, and a first slice. A good plan is not a paragraph of intentions. It is a map of where the change will be proven.

What to inspect before you accept the plan

When the plan comes back, do not skim it like project-management prose. Read it like a code review. I usually ask three questions. Did Claude name the actual files and runtime paths, or did it invent generic layers such as 'billing service' and 'user controller'? Did it separate reversible UI work from schema or migration work? Did it include a verification path that runs on your machine, not only a statement that tests should be added?

A useful follow-up is direct and slightly adversarial:

`Before I let you edit, critique this plan. Which assumption is most likely wrong? Which file did you not inspect deeply enough? Which test would fail if the invite limit is enforced in the wrong layer? Return a revised plan with one first patch only.`

This is where `/ultraplan` earns its keep. You are buying a second pass before the repo changes. Claude may discover that the limit belongs in the server action, not the React form. It may notice that existing tests mock the billing state and would never catch the real failure. That correction is much cheaper while the work is still a plan.

Bring back only the first verifiable slice

The mistake is to approve the entire beautiful plan at once. Instead, bring back the smallest slice that can survive inspection. In the invite-limit example, the first slice might be: read the organization plan from the server-side invite path, reject invites above the limit, and add one focused test around that path. Do not redesign the settings UI, write a migration, and update docs in the same pass unless those are required to prove the behavior.

Your execution prompt can be boring on purpose:

`Implement only slice 1 from the reviewed /ultraplan: enforce the invite limit in the existing server-side invite path and add the narrowest test that proves over-limit invites are rejected. Do not change the billing UI or migration files. After editing, show git diff and run the focused test.`

Verification and the second pass

After Claude edits, make the verification match the plan. If the plan promised a focused test, run that exact test. If it promised that the UI would continue to submit through the same server action, inspect the diff for accidental client-side-only enforcement. If the test fails, resist the urge to say 'fix it' immediately. Ask Claude to connect the failure to the plan:

`The focused test failed. Before patching again, explain whether the plan was wrong, the test was wrong, or the implementation missed the planned layer. Then make one correction and rerun the same test.`

This second-pass correction is the difference between using Claude Code as a patch generator and using it as an engineering partner. The plan is not sacred. It is a hypothesis. The test, logs, browser check, and git diff decide whether the hypothesis survived contact with the codebase.

Failure modes

Do not reach for `/ultraplan` for every typo or one-file cleanup. It adds overhead when the answer is obvious and the proof is local. Use it when there are multiple subsystems, ambiguous ownership, migrations, deployment risk, or a change that will tempt Claude to edit broadly. Also watch for plans that sound impressive but have no stop condition. If Claude cannot name the first verifiable slice, the plan is still too large.

Another failure mode is letting the planning session become a substitute for reading the diff. A reviewed plan does not guarantee a safe patch. It only gives you a sharper checklist for reviewing the patch. You still need `git diff`, focused tests, and sometimes a browser or log check before the work is done.

Rule of thumb

Use `/ultraplan` when you would hesitate before handing the task to a junior developer without a design review. Ask it to read, plan, critique itself, and return one verifiable first slice. Then make Claude Code earn the next slice with evidence: a clean diff, a passing focused check, and an explanation of what changed from the original plan. Planning before editing is not slower when the alternative is three confident patches in the wrong layer.