Give Claude a check it can run: tests, a build, a screenshot to compare. It's the difference between a session you watch and one you walk away from. Anthropic — Claude Code best practices
Claude stops when work looks done. Without a check it can run itself, you are the verification loop — and you become the bottleneck in your own build.
Boris Cherny, who runs Claude Code, calls verification loops his single biggest recommendation: "give Claude a way to verify its work… 2–3× the quality."
You made 2,001 preview-eval and screenshot calls in two weeks. You wrote "prefer-deployed-url" into your own memory. You ask Claude to prove things. This is genuinely your standout habit and I want to be clear that the rest of this chapter is not telling you to start verifying — it's telling you to stop doing it by hand.
| Level | Mechanism | Use when |
|---|---|---|
| Prompt | "…run the tests after implementing" | Any task, today |
| Session | /goal all tests in test/auth pass and lint is clean | A multi-turn grind |
| Deterministic | A Stop hook runs your script and blocks the turn from ending | An invariant that must always hold |
| Second opinion | /code-review, or a verification subagent in a fresh context | Before shipping |
And always demand evidence, not assertion: "show me the test output, the command you ran, the screenshot" — never accept "I've verified it works."
Delete these. Several of them are things you may still be typing out of habit, and two of them actively make output worse on current models.
In Claude Code, only the literal keyword ultrathink is recognised. "Think", "think hard", "think carefully", "reason step by step" are now passed through as ordinary prose. They do nothing at all.
The replacement is the /effort dial. If reasoning looks shallow, raise the effort — don't prompt around it.
budget_tokens extended thinking → returns a 400 error on Opus 4.7+, Fable 5, Mythos 5. Replaced by adaptive thinking plus an effort setting.| Level | Use for |
|---|---|
low | Short, scoped, latency-sensitive work |
medium | Cost-sensitive work |
high | The minimum for anything intelligence-sensitive |
xhigh | "The best setting for most coding and agentic use cases." Start here. |
max | Toughest debugging. Can overthink; diminishing returns |
ultracode | xhigh + auto-orchestrated dynamic workflows |
Effort is likely to be more important for this model than for any prior Opus, so experiment with it actively. Anthropic — prompting Claude Opus 4.8
It follows instructions literally and does not generalise them. It "does not silently generalise an instruction from one item to another." If you want a rule applied everywhere, you must say "apply this to every section, not just the first."
It favours reasoning over tool calls. If it isn't reading or searching enough, raise the effort — that's the lever that increases tool use, not more nagging.
Opus 4.8 has a persistent default aesthetic: cream and off-white backgrounds (~#F4F1EA), serif display faces (Georgia, Fraunces, Playfair), italic accents, terracotta and amber. Lovely for editorial and hospitality. Wrong for dashboards, dev tools, and fintech — which is most of what you build.
And here's the trap: generic pushback doesn't fix it. "Make it cleaner," "don't use cream," "it's ugly" just swap one fixed palette for another fixed palette. This is exactly the loop you got stuck in on Noor and on Core 2.0 — you described the problem in adjectives and got a different set of defaults back.
Two things reliably work:
That second prompt replaces what temperature used to do for design variety — and temperature now returns a 400 error, so this is the only lever you have left.
Hard rule: keep it under 200 lines. "Bloated CLAUDE.md files cause Claude to ignore your actual instructions."
The test for every single line: "Would removing this cause Claude to make a mistake?" If no, cut it.
| ✅ Include | ❌ Exclude |
|---|---|
| Bash commands Claude can't guess | Anything Claude can learn by reading the code |
| Style rules that differ from defaults | Standard language conventions |
| Test runner and how to run it | API docs (link instead) |
| Repo etiquette — branch and PR conventions | Info that changes frequently |
| Architectural decisions specific to this project | File-by-file codebase descriptions |
| Environment quirks, required env vars | "Write clean code" |
| Non-obvious gotchas | Long tutorials |
/doctor now trims your CLAUDE.md for you
It strips the things Claude can derive (directory layouts, dependency lists, architecture overviews) and keeps the pitfalls, rationale, and non-default conventions. Run it on every active project.
Put conventions in .claude/rules/ with a paths: frontmatter, and they load only when Claude touches matching files:
---
paths:
- "src/**/*.{ts,tsx}"
---
# React conventions
- Function components only; no class components
- Co-locate tests as *.test.tsxThat's real context savings versus @imports, which load in full at launch whether they're relevant or not.
CLAUDE.md is injected as a user message. It is context, not enforcement. If a rule must hold every time — no exceptions — make it a hook, not a memory line. A hook is code. A CLAUDE.md line is a suggestion that Claude is very likely to follow.
Every rule you've had to repeat is a rule that wanted to be a hook.
When to build one: you've pasted the same playbook into chat three times, or a CLAUDE.md section has turned into a procedure rather than a fact.
Why skills are nearly free: progressive disclosure. Only the name and description sit in the system prompt at startup. The full SKILL.md loads when invoked. Reference files and scripts load only if referenced. Which means "the amount of context that can be bundled into a skill is effectively unbounded."
---
name: ship
description: Build, typecheck, deploy to Cloudflare Pages, verify the live URL.
Use when the user says deploy / ship / push live.
disable-model-invocation: true # only I can trigger it — it has side effects
allowed-tools: Bash(npm run build) Bash(npx wrangler *) # no permission prompts
effort: xhigh # per-skill effort override
context: fork # run it in an isolated subagent
---Backtick-bang syntax — !`command` — runs a command before Claude sees the skill and inlines the output into the prompt:
## PR context
- Diff: !`gh pr diff`
- Comments: !`gh pr view --comments`
Summarise this PR...Claude never runs those commands — it simply receives the fully-rendered prompt. Enormous savings in both context and latency versus letting Claude shell out itself.
SKILL.md under 500 lines. Push detail into referenced files.disable-model-invocation: true costs zero context until you type /name. Use it for anything with side effects..claude/commands/ship.md and .claude/skills/ship/SKILL.md both give you /ship.Agents use ~4× the tokens of chat. Multi-agent systems use ~15×. And "token usage by itself explains 80% of the variance" in performance — parallelisation mostly works by brute-force token scaling, not architectural elegance. Know what you're buying.
Fan out when: exploration is breadth-first, the information exceeds one context window, workstreams are genuinely independent, or you're testing competing hypotheses.
Don't fan out when: work is sequential, edits touch the same files, or tasks share heavy dependencies. Anthropic is blunt about this: "Most coding tasks involve fewer truly parallelisable tasks than research."
A reviewer in a fresh context sees only the diff — not the reasoning that produced it. "A fresh context improves code review since Claude won't be biased toward code it just wrote."
But constrain it, or it will invent work: "A reviewer prompted to find gaps will usually report some, even when the work is sound. Chasing every finding leads to over-engineering." Tell it: "Report gaps, not style preferences."
Agent Teams (experimental) run 3–5 peers. The killer pattern, straight from the docs: "Spawn 5 teammates to investigate different hypotheses. Have them talk to each other to try to disprove each other's theories, like a scientific debate." That defeats anchoring — which is precisely what makes sequential debugging fail.
The physics: context rot. Models have a finite attention budget, and the transformer's pairwise relationships stretch thin as tokens accumulate. More context makes things worse past a point, not better.
Aim for "the minimal set of information that fully outlines your expected behaviour."
/clear between unrelated tasks. Non-negotiable./compact focus on the API changes — directed compaction beats the automatic guess./btw — ask a side question; the answer lands in a dismissible overlay and never enters your history. Perfect for "wait, what does this flag do?"/context — a live breakdown of what's eating your window.Two failed corrections = /clear.
"A clean session with a better prompt almost always outperforms a long session with accumulated corrections."
Your Core 2.0 and Noor design loops ran for dozens of turns of "still not faithful yet." At correction number two, the right move was to stop, clear, and write a better prompt with a named token and a screenshot. You even sensed this yourself — you asked, mid-loop, whether you should "create a new session, and dedicate it ENTIRELY to importing the Figma project." The answer was yes.
(From public interviews — directional, not official policy.)
I don't prompt Claude anymore. I have loops running that prompt Claude… My job is to write loops.Boris Cherny, Head of Claude Code
/clear between unrelated tasks./clear and rewrite the prompt./doctor in each active project. Get every CLAUDE.md under 200 lines./effort xhigh as your default for build sessions..worktreeinclude with .dev.vars and .env to every Cloudflare project — this is the thing that makes worktrees actually usable for your stack.disable-model-invocation: true — deploy, and release.PostToolUse hook that runs tsc --noEmit after edits. Just ask Claude to write it for you./clear → implement → /code-review./clear. Make it a reflex.Sources. Claude Code best practices · Prompting best practices & Prompting Claude Opus 4.8 · Effective context engineering for AI agents · Equipping agents for the real world with Agent Skills · Building a multi-agent research system · How Anthropic teams use Claude Code · Claude Code docs (memory, skills, sub-agents, agent teams, workflows, hooks, worktrees, output styles, model config) · public interviews with Boris Cherny (unofficial, treat as directional).