Claude
Prompts.

What Claude Does Well, and Where to Check It

Claude is a strong choice when the task involves a lot of text you supply: a contract, a long report, a codebase, a stack of interview notes. It keeps track of detailed instructions, follows a list of things not to do, and writes prose that needs less cleanup than most models. That makes it a good fit for editing, summarising documents you can open, reviewing code and drafting in a set voice.

It is weaker where every model is weak. It does not know what happened after its training data ends unless you give it a source or turn on web search, it can misread a table in a scanned PDF, and it will sometimes state a wrong figure with confidence. The prompts on this page are built around that: give Claude the material, tell it what to do when something is missing, and check the parts that matter before you use them.

• Good fit: long-document summaries, code review, rewriting in a house style, turning notes into structured drafts.
• Check carefully: numbers, dates, legal or medical claims, quotes attributed to people, anything about recent events.
• Use another tool: live search with citations (Perplexity or Claude with web search on), or image generation.

Claude is uniquely optimized to recognize XML tags. This is the single most effective way to improve its instruction-following.

Worked Example: Summarise a Supplier Contract

Here is the XML pattern applied to a real job. You have a 30-page supplier agreement and need to brief your manager on renewal terms before Friday. A vague prompt such as "summarise this contract" gets you a generic overview. This version tells Claude what to look for, what to do when the contract is silent, and how to lay out the answer.

<instructions>
You are helping an operations manager prepare for a contract renewal.
Read the agreement in <contract> and answer the questions in <questions>.
For every answer, quote the clause number you relied on.
If the contract does not cover a question, write NOT IN CONTRACT.
Do not give legal advice. Flag anything a lawyer should review.
</instructions>

<questions>
1. When does the agreement renew, and how much notice is needed to cancel?
2. Can the supplier raise prices at renewal? By how much?
3. What happens if they miss a delivery date?
</questions>

<contract>
[paste the full agreement here]
</contract>

Put your answer in <answer> tags as a three-row table:
question, answer, clause.

A good answer gives three rows, each with a clause number you can look up, and at least one NOT IN CONTRACT or lawyer flag if the agreement is vague. If every row comes back confident and complete, be more careful, not less: open the clauses it cited and confirm the wording. The same structure works for leases, policies, grant terms and employee handbooks. Only the questions change.

Coding and Code Review

For code, give Claude the smallest useful slice: the diff, the function and the test that fails, not the whole repository. Say what the change is meant to do, which language version and framework you use, and what kind of feedback you want, for example correctness and security only, no style comments. Ask it to point to line numbers and to say when it cannot tell whether something is a bug without more context.

When Claude writes code, ask for a self-contained file or component so it opens as an artifact you can edit, and ask for the test that would have caught the original problem. Run that test yourself. Treat its review as a second reader, not an approval. Our Claude prompts for code review cover scoping a diff, security checks, migrations and comments a reviewer can post.

Writing That Does Not Sound Generic

Claude's default voice is fluent but recognisable. To get something that sounds like you or your organisation, show rather than describe. Paste a few paragraphs you wrote and liked, ask Claude to list what makes them distinctive, correct that list, and only then ask for the new draft. Add a short list of phrases you never use. It follows negative instructions well, so "no rhetorical questions, no exclamation marks, no 'in today's fast-paced world'" is worth including.

For editing, ask for changes as a list of before and after pairs with a one-line reason each, rather than a full rewrite. You keep control of the text and can accept or reject each change.

Hard Problems: Ask for the Working, Then Check It

For maths, logic, planning or a tricky refactor, ask Claude to reason step by step inside <thinking> tags and give only the conclusion inside <answer> tags, or switch on extended thinking if your plan includes it. This usually improves the answer and, just as useful, shows you where it went wrong. Read the first two or three steps closely. Most mistakes come from an assumption made early that the rest of the reasoning builds on.

Projects: Instructions and Files That Stay Put

If you run the same kind of task every week, set up a Project. Put the role, audience, format and banned phrases in the Project instructions, and upload the reference files: a style guide, last quarter's report, the API docs. Every chat in that Project starts with that context, so your weekly prompt can be two lines long. Review the instructions every month or so. Old rules that no longer apply quietly make every answer worse.

System Prompts in the API

In the API, the system prompt is where the standing rules go: who Claude is in this product, what it must never do, and the format of every reply. The user turn carries the request and any documents. Keep the system prompt short and specific, test it against awkward inputs such as an empty message or a request outside its scope, and version it like code so you know which wording produced which behaviour.

Common Mistakes

• Asking without the source. "What does our refund policy say?" only works if you paste the policy.
• Mixing instructions into the material. Wrap pasted text in tags so a line inside an email is not read as a command.
• No rule for missing information. Tell Claude what to write when the answer is not there, or it may fill the gap.
• Asking for everything at once. Split a big job into steps, check each output, then feed it into the next prompt.
• Trusting a confident tone. Fluent prose is not evidence. Check figures, names and quotes against the original.

Claude Mastery FAQ