The Top 1% Way to Use Claude Code: Drop Plan Mode and Use Verifiable Criteria to Boost Quality

For the past year, almost every piece of advice about using Claude Code has repeated the same line: start with plan mode. Even Boris Cherny, the creator of the feature, said early this year that he started most of his sessions in plan mode. But according to a Bilibili creator, two weeks ago Boris reversed course on Hacker News, saying "plan mode is no longer useful." In nine months, the way top users work has completely changed.

This video systematically lays out the ten practices the top 1% of users are using. The core logic can be summed up in one sentence: don't plan the process for the AI — give the AI a verifiable definition of done, then let it iterate on its own until it passes verification.

Why Plan Mode Was Abandoned

To understand this shift, you need to go back to what plan mode actually is. It never changed what Claude could do — it just appended a reminder to every message: you are in plan mode, please don't start writing code. Boris came up with the feature on a whim one Sunday night because he was tired of reminding Claude every time to plan before acting. In the Sonic 4.6 and early Opus era, models really did tend to jump straight into tasks, so plan mode compensated for the model's shortcomings.

But the new models have folded planning into the work process itself. Boris's current approach is: describe the task, describe the guardrails around the task, describe what "done" looks like (definition of done), then let the model solve the rest. Take the weekly client report as an example: the task is to export from the CRM and generate this week's report, the guardrails are not changing the template and not sending emails, and the definition of done is that every number matches the export. You no longer read an upfront plan — you check what it did after the task is finished.

For larger changes, Boris asks Claude to output a diagram or even an interactive demo. Claude has also recently built in the ability to generate live dashboards and animated explainers, making this kind of acceptance check more convenient. The whole model becomes: the user only writes a brief, Claude does the work, and returns the output plus a one-page explanation.

Don't Manually Control Thinking Depth

Last year a bunch of prompt tricks were popular: think, think hard, think harder, ultra think — each word could give Claude a larger thinking budget. Now Claude Code reads these words as ordinary text, and the real control is the effort level setting, which has a recommended value for each model. Opus 5.5 recommends medium, and Anthropic says that at the medium level it matches or even exceeds Opus 5's high level on coding and knowledge work.

The conclusion is simple: don't touch this setting for most tasks — leave it at the recommended level. The default configuration already accomplishes with fewer steps and tokens what you used to tune by hand.

Let Claude Prove the Task Is Done: Verification Is the Key to Triple the Quality

This is the most valuable part of the whole video. One point from Boris's post early this year still holds: giving Claude a way to verify its own work can raise the quality of the final result by 2 to 3 times. Anthropic's official guide now lists this as its first recommendation.

The key is that verification doesn't mean writing "please check again" in your prompt. The Opus 5 guide explicitly states that the model already self-checks, and that sentence only adds cost without improving results. What you need is to give Claude a set of criteria that can return pass or fail.

Specifically: turn the "definition of done" in your brief into checks Claude can execute. For example, write a check_report script that verifies every number matches the export and that every block of the template is filled in. When a check fails on the first run, Claude automatically goes back to fix it, re-runs the check, and only presents the output after it passes. The user reads the evidence instead of manually verifying the output.

These checks don't have to be code scripts. Brand tone documents and design specs can also serve as check criteria — it's just that the more deterministic the check, the more errors it can catch.

Verifiable definition of done is the core concept of this methodology: it means turning the vague judgment of "finished" into a machine-executable pass/fail determination. It usually takes the form of a script that returns an exit code or structured boolean result, a set of checklist-style assertions that can be checked item by item, or a spec document that can be compared line by line. Unlike "please check whether it's done" in an ordinary prompt, the key to a verifiable criterion is that there is a judgment source independent of the model's self-report: whether a number equals the source data, whether a template block is non-empty, whether lint reports zero errors — these are all objective facts that the model cannot circumvent with wording. This gives the iteration loop a clear stopping condition, and shifts the user's role from verifying output item by item to reviewing the evidence itself.

/goal: Let Claude Loop Continuously Until It Passes the Check

The verification mechanism only makes sense if Claude can keep iterating; otherwise you still have to manually type "continue." The slash command /goal solves this: it presses the continue key for you, letting Claude loop until the goal is met.

There's an important pitfall here. After each round, a separate small model (such as Haiku) reads your goal and judges whether the condition is met. But this judge doesn't execute commands or read files — it only looks at the conversation and output. If your goal is vaguely defined — for example, "the report is done" — it will judge completion too early.

Anthropic's criteria for a good goal: it has only one terminal state, it explains how to prove the terminal state was reached, it explains what must not change, and it sets a round limit to prevent infinite loops. Example: /goal the check_report script passes and displays the output, the template stays unchanged, stop after 15 rounds.

Judge model is the decision component in an automated loop, usually played by a lower-cost, smaller-context model. It has no execution environment privileges — it can't run scripts or read the file system — and judges whether the goal is met only based on the visible conversation history and command output. This design lowers the cost of each round's judgment, but it also means its judgment quality depends entirely on whether the goal's wording can be observed on the surface. Therefore, the goal description must write "how to prove it" in a form the judge can directly see in the conversation — for example, "the check_report script outputs PASS and displays the report content" — rather than relying on internal states the judge cannot verify. The round limit is a safety valve that prevents the loop from running indefinitely when the judge keeps misjudging.

CLAUDE.md Should Be a Table of Contents, Not a Manual

When Opus 5 was released, Anthropic did something radical: it deleted more than 80% of Claude Code's own instructions, because most of them were patching the flaws of old models. The official docs recommend keeping CLAUDE.md under 200 lines; longer files cost more and are followed less.

A more practical mental model is to treat CLAUDE.md as the table-of-contents page of your workspace, keeping only four kinds of content: tools and commands Claude can't guess; places where you differ from the usual practice; pitfalls that repeatedly cause errors; and boundary rules (such as drafting emails but never sending them). Everything else becomes a pointer to another file.

The pointers themselves have three rules. First, reference files with paths rather than import syntax — the @ symbol loads the entire file into every session, whereas a backtick path plus a timing for opening it (such as "read the client email before doing client work") enables on-demand loading. Second, all files should be pointed to directly from CLAUDE.md; nested references only get the first 100 lines previewed. Third, add a table of contents at the top of any file over 100 lines, because every read likewise only gets the first 100 lines as a preview — this rule was originally for skill files but applies to all indexed files.

You can make these changes manually, or use /doctor prompt audit to audit automatically: it checks CLAUDE.md, skills, and rules for instructions aimed at old models, broken paths, and contradictory files, and makes no changes without your confirmation.

Context window and on-demand loading are the premise for understanding the principle of keeping CLAUDE.md lean. Claude Code injects the full text of CLAUDE.md into the context at every session, so the longer the file, the more fixed budget it takes up, the less reasoning space is left for the actual task, and the more diluted the model's attention to any single instruction — which is exactly why the official recommendation is to keep it under 200 lines and delete most old instructions. The problem with the @ import syntax is that it loads the referenced file recursively in full, effectively stuffing the entire file tree into every session; whereas a backtick path plus a timing for opening it only leaves a textual clue, and the model actively reads that file only when performing the relevant task. Similarly, automatic reading of indexed files often only provides the first 100 lines as a preview, so long files need a table of contents at the top, letting the model know where the full content lives and decide whether to read deeper.

A Skill Is Not a Process Manual but an Error-Correction Checklist

A common mistake is: plan the process in your head, then have Claude generate a skill before it has ever tried the task. Anthropic's skill guide requires doing the opposite — first complete the task without a skill, run it on real tasks, record the points that actually went wrong, and then write the corrections into a skill. Skills solve real problems, not imagined ones.

This also explains why the Anthropic team's own best skills are often just a few lines and one gotcha. The desktop app now also supports recording skills: observing you perform a task and recording it automatically. According to the creator, when he tested Instagram DM automation, the recorded skill was surprisingly small, because it only recorded the parts Claude couldn't do out of the box.

Wariness of popular skill packs is equally necessary. According to the creator, a developer tested 9 high-star skill packs, running them 450 times on Opus 5.5, and only 2 performed better than "writing the entire process into a placeholder file." More than 70% of skill packs bring only extra token overhead. Claude Code's built-in claude plugin eval can compare scores with and without a skill; the same score means the skill is purely decorative. First use /skill doctor to see each skill's cost and usage frequency, delete the ones never used, then run eval on the rest.

Use Hooks Instead of Capital Letters and Exclamation Marks

Writing "important," "must," or all caps in rules is basically ineffective on current models. Behavior that needs an absolute guarantee should be written as a hook: a small script that executes deterministically at a time you define, such as before every tool use by Claude. Hooks don't consume AI tokens and execute no matter what the model thinks.

Go through every all-caps emphasis in CLAUDE.md: either it's something Claude would do anyway, so delete it; or it's something that must never happen, so rewrite it as a hook. In the client report example, the rule "never email the client" should be replaced with a hook that blocks any client email from being sent.

The essential difference between a hook and a prompt constraint is the executing entity. A rule written in CLAUDE.md or a prompt is a "suggestion" to the model, which follows it probabilistically — and compliance drops as the context grows longer and the task becomes more complex. A hook, by contrast, is a deterministic script executed directly by the Claude Code runtime at predetermined lifecycle points (such as before a tool call, after a file write, or at session end); its trigger does not go through model decision-making and does not consume token budget. Typical scenarios that can be intercepted include blocking emails to specific addresses, prohibiting writes to production config directories, and forcing format checks before commits. Design hooks to fail fast and return a clear reason so the model can adjust its behavior accordingly, rather than just silently aborting — the latter would cause the model to repeatedly retry the same rejected operation.

Sub-agents: Let Claude Decide, You Only Set the Limit

Building an agent team in the early days required hand-writing an orchestrator, agent files, and routing, with a main agent coordinating multiple sub-agents. The Opus 5 guide says it delegates work to sub-agents more proactively than any previous model, but doing so for small tasks only multiplies cost and time.

The division of labor now is: Claude decides for itself how many helpers it needs and how to assign tasks; you set the team size limit and boundaries to prevent over-expansion on simple tasks. There is one exception — when you build a skill that contains a large-scale research step or a step connecting to MCP, you should explicitly require that part to run in a sub-agent, keeping the main conversation context clean.

Unattended: Projects, Scheduled Tasks, and Event Triggers

The last piece of the puzzle is making work happen while you're away. Claude Code projects are now persistent conversations that can start their own threads, and combined with scheduled tasks or event triggers — a new to-do item, a new CRM lead, a contact form submission — they can form a workflow that requires no human intervention. The creator says his Instagram carousels and short videos are produced with this mechanism; he only needs to click approve in his own UI. Codex recently also announced plugin MCP events, where connected apps can trigger a run when a specific event occurs.

Behind all these practices is the same principle: let Claude do the work first, and add infrastructure after something goes wrong. CLAUDE.md is workspace information that is always true, skills are error-correction sets for a single process, hooks are boundaries that must be absolutely enforced, and verification scripts are the closed loop of quality assurance.

One-line Summary

Drop plan mode; give Claude a verifiable definition of done and a verification loop so it iterates on its own until it passes.

Paragraph Summary

The article lays out ten practices of the top 1% of Claude Code users, whose core shift is from planning the process for the AI to giving a verifiable definition of done and letting the model iterate on its own. Plan mode lost its value because new models plan as they work; the replacement is to describe the task, guardrails, and definition of done, then check the output afterward. The key to quality is the verification mechanism: giving Claude executable check scripts can raise result quality 2 to 3 times, and what really works is criteria that return pass/fail, not "check again" in the prompt. /goal drives a loop through a judge model until the goal is met, but the goal must have a single terminal state and a round limit. In addition, CLAUDE.md should be trimmed to a table-of-contents page with on-demand path pointers; skills should come from real corrections rather than preset processes; absolute rules should be rewritten as hooks; sub-agents should only have a limit set; and scheduled and event triggers enable unattended operation.