6 New Rules for Using Claude Code

Anthropic just admitted they were wrong

Anthropic published a guide this summer on how it prompts its own newest models, Opus 5 and Fable 5.

They admitting their pompting rules are now constrain Claude Code.

Researches deleted more than 80% of Claude Code's system prompt for these newer models. System prompt means the instructions Claude Code reads before you start a conversation.

If you're prompting Claude for anything — planning a launch, drafting a client update, building out a workflow — this matters to you, not just to people writing code.

The same over-constraining habit shows up in a bloated custom instructions field, a Claude Project stuffed with every document you own, or a prompt that tries to cover every edge case up front.

Step 1: Stop writing strict rules. Tell it the outcome

Emphasize the end outcome, instead of tuffing your prompts with do not's.

Rules like that exist to prevent a worst-case outcome, but they're wrong often enough that they start producing bad results of their own.

Anthropic's old system prompt told Claude things like "never write multi-line comments" and "don't create planning documents unless asked."

Newer models can think for themselves and come up with a solution, if you let them.

What this looks like in a real workday:

• Instead of "always use bullet points, never write more than 3 sentences per paragraph, don't use the word 'leverage'" — try "match the tone of the last status update I sent you" and attach it.

• Instead of a 12-line list of formatting rules for a deck outline, say what the deck needs to accomplish and who's reading it.

Caution: This doesn't mean drop guardrails. Still protect against damage.

If there's a genuine worst-case outcome — omitting a word, or type of data — keep that rule explicit.

Step 2: Stop describing what you want — show it

The old habit was writing out a spec: a paragraph or bullet list describing the outcome. Anthropic found Claude performs better working from a real reference — a mockup, a working file, an actual example — than from a description of one.

What this looks like in a real workday:

• Instead of describing your deck's layout in a paragraph, attach a previous deck you liked and say "match this."

• Instead of writing three sentences about your ideal email tone, paste an actual email you sent and say "write like this."

Caution: A reference file only helps if it's actually representative of what you want. A messy or outdated example will anchor Claude just as strongly as a good one. Choose it deliberately.

Step 3: Stop putting everything upfront, hand it what's relevant, when it's relevant

Anthropic used to load Claude Code's system prompt with detailed instructions for code review and verification, used or not, every single time.

The same logic applies outside of code. If you've built a giant reference document you expect Claude to read in full on every request, you're overloading the model.

What this looks like in a real workday:

• Break one long "everything about how I work" doc into smaller files by topic — client communication style, meeting notes format, project status template — and only attach the one relevant to the task at hand.

• In a Claude Project, resist the pull to upload every document you have. Add what the current task needs.

Caution: Don't swing to the other extreme and give Claude too little context to work with. The goal is relevant, not minimal. Cut what doesn't apply to this task, not everything you have.

Step 4: Stop repeating yourself. Say it once, in the right place

Older models sometimes needed the same instruction stated twice to actually register it. It found that repetition is no longer necessary. Newer models catch it the first time, as long as it's placed where it's actually used.

What this looks like in a real workday:

• If your custom instructions and your project knowledge both say the same thing in different words, that's redundant weight, not reinforcement. Say it once, in the doc that's actually relevant to it.

• Put formatting or tone guidance directly where the output happens — in the project's custom instructions — rather than restating it in every single prompt.

Caution: Don't confuse repetition with reminders for genuinely unusual asks. If you're asking for something Claude wouldn't default to, restating it once at the point of the request is still worth doing.

Step 5: Stop manually managing memory. Let it build automatically

Anthropic used to tell users to explicitly save things to CLAUDE.md. Now Claude saves what's relevant to the work on its own, without being told.

There's a section called "Memory" within Claude that has this shows the cumulated memory over time.

What this looks like in a real workday:

• Stop maintaining a running "remember this" doc you paste in every time. Let ongoing context accumulate on its own, and check in on what's been retained instead of manually feeding it.

• If you're still writing a fresh context recap at the start of every session, test how much Claude already carries forward before you rebuild it from scratch.

Caution: Automatic memory isn't a replacement for verifying accuracy. If a decision genuinely needs to be on record — a client sign-off, a budget number — confirm it's actually been retained correctly rather than assuming it has.

Step 6: Limit stacking examples. Design the structure instead

The old advice for getting a tool used correctly was to give Claude a handful of examples. Anthropic found this actually narrows the model's thinking; it starts pattern-matching to your examples instead of solving the actual problem in front of it.

What worked better was designing the input itself so the right behavior is obvious from its shape.

What this looks like in a real workday:

• If you're building a repeatable brief format in a Claude Project, spend the time defining the fields and their limits — not writing five sample briefs and hoping Claude generalizes correctly.

• If you keep giving Claude "here's what a good one looks like, here's what a good one looks like" and it's still drifting, the fix might be a clearer structure, not a fourth example.

Caution: One well-chosen example still earns its place, especially for a format Claude has never seen. The problem is stacking several. That's what narrows it.