Claude Prompting Best Practices, With Before-and-After Examples

The best way to prompt Claude is to write the request you would give a capable new colleague on their first day: what you want, why you want it, what good looks like, and what to work from. Anthropic’s prompting best practices↗ (opens in a new tab) put it almost exactly that way, and offer a test: show your prompt to someone with little context on the task, and if they would be confused, Claude will be too. The rest of the guidance is detail on how to do that well. Below are the habits, then seven work prompts rewritten with them.

This post is about the words in a single request. What else goes into Claude’s context, such as files, tools and memory, is the subject of context engineering vs prompt engineering, and a ready-made set of prompts for running a board is in prompts for project management AI.

What Anthropic recommends

• Be clear and direct. Say what output you want, in what format, within what limits. Use numbered steps when the order or completeness of steps matters. If you want more than the basics, ask for it; newer models do what you ask rather than guessing that you wanted extra.
• Give the reason. Anthropic’s example: “never use ellipses” works less well than explaining that the text will be read aloud by a speech engine that cannot pronounce them. Claude generalises from the reason.
• Show examples. Three to five that mirror your real case and vary enough that Claude does not copy an accident of one of them, wrapped in <example> tags so they are not mistaken for instructions.
• Separate the parts. Tags such as <instructions>, <context> and <document> stop a long prompt from blurring instructions into material.
• Set a role. Even one sentence, such as “you are reviewing this as a support lead”, focuses tone and judgement.
• Put long material first. For inputs of around 20,000 tokens or more, place the documents at the top and the question at the end; Anthropic says a query at the end can improve quality by up to 30 percent on complex, multi-document inputs. Ask Claude to quote the relevant passages before answering.
• Say what to do, not what to avoid. “Write in flowing paragraphs” works better than “no markdown”, and the style of your prompt pulls the style of the answer towards it.
• Leave room to think. For multistep problems, say so: “this involves several steps; think it through before answering”, or ask it to reflect on results before its next step.

Anthropic’s prompt engineering overview↗ (opens in a new tab) adds a step most people skip: before tuning a prompt, decide what success looks like and how you will check it. For a work prompt that can be as simple as keeping two past outputs you liked and comparing.

Seven rewrites

1. A weekly status update

Write a status update for the project.

<context>
Audience: the client's operations director. She reads this on her phone
between meetings and decides from it whether to call us.
</context>
<material>
[paste this week's completed tasks and open blockers]
</material>
Write a status update in under 150 words: first line says on track, at risk
or off track and why, then what finished, then anything we need from her.
Name tasks by their ref. If a date is not in the material, write "not set".

What changed: an audience and a reason (a busy reader on a phone), a length, an order, and a rule against inventing dates. The material comes before the instruction.

2. Bug triage

Triage these bugs.

You are triaging for a two-person team that can fix about five bugs a week.
For each report below: say whether it is reproducible from what is written,
suggest a priority from 1 (most urgent) to 10, and give one sentence of why.
Anything that loses customer data or money is priority 1 or 2.
Where a report is too vague to judge, write the one question to ask the reporter.
<example>
BUG-112 | reproducible: yes | priority 2 | Checkout total ignores the discount on mobile, so customers are overcharged.
</example>
<reports>
[paste reports]
</reports>

A role with a constraint (five a week) gives Claude a reason to rank rather than call everything urgent. One example fixes the output format better than a paragraph describing it; for a recurring job, add two more that vary.

3. A spec review

Can you look over this spec and suggest improvements?

<spec>
[paste spec]
</spec>
Review the spec above as the engineer who will build it next week.
List every place where two people could build different things from the
same words, quoting the sentence each time. Then list what is missing for
the acceptance criteria to be testable. Do not rewrite the spec.

“Suggest improvements” invites a general essay. The rewrite names a concrete failure to look for, asks for quotes so every point can be checked, and sets the scope, including what not to touch.

4. A meeting summary

Summarise this meeting. Don't make it too long and don't use bullet points.

<transcript>
[paste transcript]
</transcript>
First, quote the lines where a decision was made or a job was given to someone.
Then write three short paragraphs for people who missed the meeting:
what was decided, who is doing what next, and what is still open.
Use names as they appear in the transcript.

Two “don’t”s become a positive instruction about shape. Quoting first grounds the summary in the transcript, which is Anthropic’s advice for long documents.

5. A task for an AI agent

Fix the login bug.

Task BUG-208: users with a + in their email address cannot sign in.
Why it matters: business customers often use plus addresses, and they are locked out.
Done means: a test covering plus addresses passes, and the existing sign-in
tests still pass. Only change code under src/auth/.
If the cause is outside src/auth/, stop and describe it instead of fixing it.
When finished, comment on BUG-208 with what changed and how it was tested.

An agent cannot ask a follow-up halfway through, so the outcome, the check, the boundary and what to do when blocked all go in up front. The full method is in how to write a task for an AI agent.

6. A customer reply

Reply to this angry customer. IMPORTANT: be polite!!!

<email>
[paste email]
</email>
Draft a reply from our support team. The customer is right that the invoice
was late; say so plainly in the first sentence. Explain what we changed so it
does not happen again, in two sentences at most. Warm and direct, no
corporate phrases. Do not offer a refund; that needs a manager.

Capital letters and exclamation marks carry no information. The rewrite says what polite means here, and gives the reason for the one limit.

7. A question about a long document

What does the contract say about termination? [pastes 40 pages below]

<document>
<source>supplier-agreement-2026.pdf</source>
<document_content>[contract text]</document_content>
</document>
Find every clause about ending the agreement, by either side. Quote each one
with its clause number in <quotes> tags. Then, in <answer> tags, explain in
plain English how much notice we must give and what it costs us.

The document goes first, wrapped and labelled with its source, and the question comes last, with quotes before the answer.

What changed for newer models

Anthropic keeps a prompting page per recent model, and a few changes recur across them.

• More literal. Anthropic’s notes on prompting Claude Sonnet 5↗ (opens in a new tab) say it does not silently apply an instruction from one item to the next or infer requests you did not make. If a rule applies everywhere, say “every section, not just the first”.
• Suggest means suggest. Asked “can you suggest some changes”, Claude may list suggestions rather than make them. Say “make these changes” when you want action, and “propose, do not change anything” when you do not.
• Less shouting. Prompts written for older models often said “CRITICAL: you MUST”. Anthropic says recent Opus models respond to the system prompt more strongly, and advises plain wording such as “use this tool when…” to avoid overreacting.
• Length varies by model. Most recent models are more concise and may skip a summary after they work; ask for one if you want it. Claude Opus 5 runs longer by default, so ask it for brevity.
• Thinking is built in. Recent models decide for themselves when and how much to think, so “think step by step” matters less than telling Claude the task is multistep or asking it to check its own work.

Keep the prompts that work

A good prompt written once and lost in a chat is rewritten from memory next week, worse. Keep the ones that earn their place where the team can find them: a shared project’s instructions for standing rules, a skill for a job you repeat, and the task itself for a one-off. On a fenbs board, a task’s note holds the problem and its plan holds how it will be done, so an assistant connected over MCP reads the same brief a person would, and records its own test status and notes against it when it finishes.