Four habits for working with Claude Code — a checklist · Resource

Keep this open and run it against every Claude Code session. Out of the box the tool is tuned to make you feel productive, not to produce good results. These four habits close that gap. Tick the items as you go.

1. Stop hearing only "yes"

The model wants you to like it, so it agrees with whatever you propose. Take it out of agreement mode before it commits to anything.

[ ] Before it builds, make it argue against the plan — play devil's advocate and hunt for the reasons your idea fails, not the reasons it's clever.
[ ] For a real decision, run a critic council, each persona as its own sub-agent with one job: a contrarian finding the fatal flaw, an expansionist finding the biggest upside, a first-principles thinker reasoning from scratch, a researcher pulling real market and pricing data, a buyer who role-plays your customer and says whether they'd pay.
[ ] Have a separate judge read the council and return one verdict: green-light, reshape, or kill.
[ ] Demand the cheapest test you could run in the next 48 hours to find out whether the idea is worth pursuing at all.
[ ] Never let the thing that proposed an idea be the only voice that approves it.

2. "Looks done" is not "works"

The model can sound certain about work it never checked, and even report a task complete that it didn't finish. Make it prove the result.

[ ] Write an explicit definition of done up front: the objective conditions the work must meet before it can stop.
[ ] Make it verify its work as it builds, not in one pass at the end.
[ ] After it reports "done," make it stress-test the result against bad inputs and edge cases — the odd values a real person or a real client would hit.
[ ] Require evidence, not assertions: screenshots, click-throughs, a re-run of the failing case after each fix.
[ ] Keep going until the definition of done is met in full: every check passes, no visible errors, bad input handled.

3. Manage your context

A longer conversation makes the model duller and slower, well before the window is full. Handle context deliberately before it quietly wrecks your output.

[ ] Check /context to see what's filling the window: which files, tools, and instructions are loaded, and what each costs.
[ ] Prefer /clear and a fresh start over leaning on /compact, which is slow and lossy.
[ ] Before you clear, write a structured handoff — what you're on, the key files, the decisions you've locked, the open questions, and exactly where to resume — then paste it into the clean session.
[ ] Use the most capable model the task warrants; an under-powered model makes everything downstream worse.

4. Stop being the bottleneck

You can only point the model in one direction at a time, which makes you the limit. Spread the work and let it run.

[ ] Split anything that can be done independently and in parallel into its own sub-agent.
[ ] Give each sub-agent its own clean context, so none of them hits the context wall.
[ ] Set a goal loop: define a measurable finish condition and let the model work turn after turn until it's met. Make the bar objective ("all six files exist and none is empty"), never "make it good."
[ ] Judge "done" with a separate evaluator — a second model whose only job is to grade each turn. The worker never declares itself finished.

Run these and your own role shifts. You stop being the builder and become the decision-maker, the reviewer, the judge — the place where the leverage actually is.

Definition-of-done template: Done when [objective condition 1], [condition 2], [condition 3] — each verifiable, no "looks good."

Session handoff skeleton:

Working on: <task>
Key files: <paths>
Locked decisions: <what's settled, don't relitigate>
Open questions: <what's undecided>
Resume at: <the exact next step>