Anthropic rewrote its Claude prompting guidance for newer models. Here's what changed, why old habits backfire, and how to fix your prompts.
How should you prompt Claude in 2026? #
Prompt Claude with clear intent instead of rigid steps: state what to do (not what to avoid), explain why an instruction matters, and define what “done” looks like instead of prescribing a sequence. Anthropic’s newer models already self-check their work, follow shorter instructions better than long rule lists, and infer edge cases from justification rather than exhaustive rules. Habits that were considered best practice a year ago, like telling Claude to double-check its own output, now actively slow it down and often make results worse.
TL;DR #
- Verification instructions are now counterproductive because newer Claude models already verify their own work internally, so telling them to “double-check” adds a slower, redundant second pass that can contradict the first.
- Negative instructions confuse the model more than positive ones, so replace “don’t use bullet points” with a direct instruction like “write it as a flowing paragraph.”
- Justification beats prescription , meaning a rule like “never use ellipses because this will be read by a text-to-speech engine” generalizes better than a bare command, since the model uses the reasoning to catch cases you didn’t think to specify.
- Anthropic’s “golden rule” for prompts is to ask whether a colleague with zero context could follow the prompt without confusion. If they’d struggle, Claude probably will too.
- Long, exhaustive master prompts now hurt performance , since newer models follow short, clear instructions better than sprawling rule lists, and a broken rule usually means the file is too long, not that the rule needs repeating.
- Claude’s
/goalcommand lets sessions run autonomously by having a separate model check after each turn whether a measurable, verifiable end state has been met. - Projects should be split by workstream , kept brief, and ideally built by letting Claude interview you for instructions rather than writing them yourself from scratch.
Remy is new. The platform isn't. #
Remy is the latest expression of years of platform work. Not a hastily wrapped LLM.
Why did Anthropic’s prompting advice change? #
Anthropic periodically rewrites its official prompting documentation to match how its newest models actually behave, and the guidance tied to Claude 5-generation models marks one of the bigger shifts. Older models needed more explicit hand-holding: step-by-step instructions, verification requests, and long lists of dos and don’ts. Newer models have more built-in judgment. They self-verify by default, they infer intent from context, and they tend to over-trigger on instructions that used to be necessary but are now redundant.
That’s the core problem with carrying old prompts forward unchanged. A line like “before you finish, double check every number against the spreadsheet” used to add a useful safety net. On current models, Anthropic’s own Opus guidance now lists that kind of explicit verification instruction under habits to drop, because the model already runs an internal check. Adding another one on top just means a slower, more expensive response that can second-guess and contradict the first pass.
What should you actually put in a Claude prompt now? #
Four habits form the core of the updated guidance.
Say what to do, not what to avoid. Negative instructions (“don’t use bullet points”) force the model to hold a negative constraint in mind while still figuring out what you actually want. A positive instruction (“write it as a flowing paragraph”) gives it a direct target instead.
Explain the reasoning behind a rule. Anthropic’s prompting documentation recommends attaching a justification to instructions rather than issuing a bare command. “Never use ellipses in your response” works, but “never use ellipses in your response because this will be read aloud by a text-to-speech engine and it can’t interpret ellipses” works better. The justification gives the model a broader principle to reason from, so it can catch related issues you never explicitly listed, like other punctuation or formatting that a speech engine also can’t handle.
Apply the golden rule. Anthropic frames it simply: if you showed the prompt to a colleague with zero context and they’d be confused about what to do or why, Claude will likely be confused too. Overly prescriptive, ordered steps without explanation are the main offender here. The model may assume the order itself is meaningful even when it isn’t, and it has no sense of why it’s doing any given step.
Use a lightweight template instead of a rulebook. Rather than a long set of instructions, structure a prompt around three things: a brief description of the larger task and who it’s for, the underlying need or outcome the work is meant to enable, and a clear definition of done. Cut anything that reads like a forced procedure (“follow this process exactly,” “this is important”) since newer models tend to overreact to urgency language and already handle much of that behavior by default.
Is Claude’s /goal command worth using? #
One coffee. One working app. #
You bring the idea. Remy manages the project.
For anyone running longer, semi-autonomous sessions, yes. The /goal command changes how a work session ends. Instead of Claude working until it decides it’s finished (or looping indefinitely without a clear stopping point), you give it a specific, measurable end state and a way to prove it’s been reached. After each turn, a separate, faster model reads the conversation and returns one of three verdicts: not yet met, met, or (with a turn limit set) stopped. If the criteria aren’t met, Claude takes that feedback as guidance for the next turn rather than starting over blind.
The key design detail is that the model doing the work and the model checking the work are different models. That separation is what prevents Claude from simply deciding on its own that it’s done. A basic template for this looks like:
/goal [measurable end state]
Prove it by: [verification criteria, show the output]
Constraints: stop after [n] turns
This is most useful for repetitive, well-defined build tasks where “done” can be checked mechanically, such as confirming a tool works end to end at a live URL, rather than open-ended creative work where “done” is subjective. Running this way still requires operating in a mode that bypasses manual permission prompts, since babysitting each step defeats the purpose of an autonomous run.
How should Claude Projects be structured? #
Three rules from Anthropic’s guidance apply here:
One project per workstream, not one project for everything. A project bundles instructions, reference files, memory, and any scheduled tasks together. Mixing unrelated work, like client deliverables and personal writing, in a single project creates ambiguity about which context applies to which task.
Keep project instructions short. The old approach of building one exhaustive master prompt with hundreds of lines covering every possible preference no longer holds up. Newer models follow short, clear instructions more reliably than long rule lists. If Claude keeps breaking a rule inside a project, the more likely cause is that the instruction file has grown too long and diluted, not that the rule itself needs to be repeated or emphasized more strongly.
Let Claude interview you instead of writing instructions from scratch. Using a feature that prompts Claude to ask you questions about your role, the project’s purpose, the intended audience, your voice, and any standard operating procedures produces a more usable instruction set than trying to draft it all yourself. Voice and tone guidance in particular is often better kept as a separate reference file rather than folded into the main instructions.
Frequently Asked Questions #
Should I still ask Claude to double-check its work?
Generally no, for current-generation models. Anthropic’s guidance now lists explicit verification instructions as a habit to drop, since these models already run an internal check. Adding your own “double-check this” instruction on top typically just adds a slower, more expensive second pass.
Why do negative instructions (“don’t do X”) work worse than positive ones?
Telling Claude what not to do requires it to hold a constraint in mind while still inferring what you actually want instead. Telling it what to do directly, such as specifying the desired format, gives it a concrete target and produces more consistent results.
What is Anthropic’s “golden rule” for prompt writing?
If you showed the prompt to a colleague with no background on the task and they’d be confused about what to do or why, Claude is likely to be confused too. It’s a check against prompts that are overly prescriptive or missing the reasoning behind an instruction.
Are long, detailed master prompts still a good idea?
No. Anthropic’s current guidance favors short, clear instructions over exhaustive rule lists. Newer models handle brief instructions with justification better than long files, and a rule that keeps getting ignored is often a sign the instruction file is too long, not that the rule needs more repetition.
What is the /goal command used for?
It lets a Claude session run with less supervision by defining a measurable end state and verification criteria up front. A separate model checks progress after each turn and reports whether the goal has been met, letting Claude continue working autonomously until it has or until a set turn limit is reached.