The short version
Most Claude advice is prompt wording. Almost none of it survives contact with a real project. I ran 50 of them properly. Forty six were fine but forgettable. Four changed my defaults permanently, and all four are about structure, not phrasing: who reviews the work, what can physically stop a bad action, where the work runs, and how many versions of it you keep.
Read Tier 1 today. Skim the rest when you want them.
How this is ranked
Tier 1 is the four from the video. Those are the ones I would fight to keep.
Tiers 2 to 7 descend from there. Everything in this guide is something I actually use, but the tips near number 50 are habits, not turning points. Nothing here is filler I added to reach a round number, and I have said plainly where a tip is a preference rather than a rule.
Tier 1 · The four that changed how I work
01 Never let the same Claude review its own work
The Claude that wrote your code is the worst possible reviewer of it. It is carrying every assumption that produced the bug in the first place, plus a few hundred lines of its own reasoning telling it the work is correct. Ask it to check, and it checks its logic against itself. It passes.
Hand the work to a Claude that has never seen the conversation. No history, no reasoning trail, no memory of what the plan was. Just the code and a question.
Two ways to get one:
/clear then reopen the files and ask for a cold review
/agents create a reviewer subagent with its own context window
The subagent version is better because it is repeatable. A reviewer subagent gets its own context window and its own tool set, so it can read the diff and the tests and nothing else. It is not persuaded by the plan, because it never saw the plan.
The tell that this is working: your fresh reviewer starts disagreeing with your writer. That argument is the entire value of the tip.
02 A rule in your instructions file is a suggestion. A hook is a wall.
Your CLAUDE.md is context, and context is weighted, not obeyed. Ten rules and Claude follows all ten. Forty rules and it starts quietly dropping the ones that feel least relevant to the task in front of it. It is not being lazy. You gave it forty competing priorities and asked it to hold all of them while solving something hard.
A hook is different in kind. It is not context at all. It is code that runs before the tool call executes, and it can refuse.
A PreToolUse hook in your settings sees the tool and its input before anything happens. Exit with code 2 and the call is blocked, and whatever you wrote to stderr is handed back to Claude as the reason. It cannot be skipped, because Claude never gets a vote.
The move is to sort your instructions file honestly. Anything that is style or preference stays as prose. Anything you would be genuinely upset about becomes a hook:
PreToolUse block edits to .env, secrets, migrations, prod config
PreToolUse block git push to main
PostToolUse run the formatter and linter after every edit
UserPromptSubmit inject the branch and failing tests into every prompt
The side effect is that your CLAUDE.md gets shorter, which makes the rules still in it more likely to be followed. You get both halves of the win.
03 Let it run completely wild, inside a box it cannot escape
Most people run Claude carefully because the blast radius is their actual machine. So they approve every action, stay in the loop, and get a fraction of the value out of a tool that is at its best when it can try things.
Change the box instead of changing the caution. Give it a container with your repo mounted and nothing else reachable. Inside that container it can install packages, rewrite files, delete things, run the whole test suite in a loop, and be completely wrong, and none of it touches your real files, because it has no path to them.
The Claude Code docs ship a reference devcontainer built for exactly this. That is the version I use. Inside it, skipping permission prompts is reasonable. Outside it, it never is.
The lighter version, if a container is too much setup today: a git worktree on a throwaway branch. It is a separate directory with a separate checkout. It cannot reach into your main working copy, and deleting it costs you nothing.
The thing to notice is how differently you work once nothing it does can hurt you. You stop supervising and start reviewing outcomes, which is the job you actually wanted.
04 Fork the conversation instead of arguing with it
When Claude takes an approach you are not sure about, the instinct is to argue: no, do it the other way. That throws away a working attempt to gamble on an idea neither of you has tested.
Run both. Two git worktrees, two Claude sessions, same task, one approach each. They cannot collide, because they are separate checkouts. Twenty minutes later you have two finished implementations to compare instead of one opinion to defend.
Then diff them and keep the one that actually worked. Delete the other without ceremony. The loser was never a loss, it was the control group.
There is a cheaper fork too. Press Escape twice to jump back to an earlier checkpoint in the session, and take the other road from the same starting point. Same idea, no extra setup, and it beats trying to talk a session out of a direction it has already committed to.
This is the one I underestimated longest. It feels wasteful and it is the opposite. Most of the time I spent arguing with Claude was time spent guessing which approach was better, and guessing is exactly the thing running both removes.
Free, for your email
Get the full setup steps + the copy-paste setup prompt
The rest of this guide (8 more sections) opens right here. The setup prompt, one paste into Claude that sets it all up, comes by email only. Use your real address.
Unlocks: Tier 2 · Context and memory · Tier 3 · Guardrails · Tier 4 · Speed and cost · Tier 5 · Reviewing and shipping · Tier 6 · Workflow and automation · +3 more
50,000+ follow where these guides come from. No spam, reply “unsubscribe” any time.