The Claude prompting guide
Claude reads a prompt carefully, which means it is worth writing one carefully. Structure, explicit markers around your material, and an invitation to reason before answering do most of the work.
The base is the same
Role, context, task, constraints, format — Claude wants all five just as much as any other model, and the complete guide to prompt engineering is where they are laid out. What follows is what Claude does with a prompt after those are in place, and it comes down to one theme: this model reads carefully, so it is worth writing carefully.
Structure beats phrasing
A long, organized prompt does not confuse Claude — it helps. Where other models reward brevity, Claude rewards a prompt laid out like a brief: what you want, then the constraints, then the material. Headings, numbered requirements and short labelled sections all survive intact, and each one is a thing the model can be held to.
The practical version: stop trying to compress three requirements into one sentence. Three numbered lines are followed more reliably than one dense paragraph carrying the same information.
rewrite this to be clearer but keep it professional and dont make it longer, also fix the second paragraph which is confusing
Edit the text below. 1. Make it clearer without making it longer — the edited version must be the same length or shorter. 2. Keep the register professional; do not make it warmer. 3. Paragraph 2 is the weakest. Say in one line what is wrong with it before you rewrite it. Text: …
Separate your material from your instructions
The most common way a prompt goes wrong is that the model cannot tell which part is the job and which part is the thing the job is about. Claude handles explicit markers well — wrapping pasted content in tags such as <draft>…</draft> or <email>…</email> is enough, and you can then refer to it by name in the instruction.
This matters most when the material contains something that looks like an instruction. A pasted customer email that says "please summarize the attached" is a sentence you want reported, not obeyed, and a tag is what makes that unambiguous.
A tag turns "here is some text" into a named object. Once the material has a name, the instruction can talk about it — "quote from <draft>", "do not change anything inside <spec>" — instead of relying on position in the prompt.
Ask for the thinking, then the answer
Claude is comfortable working through a problem step by step when invited, and the invitation is usually worth its cost. "List the trade-offs first, then recommend" produces a visibly better recommendation than "recommend" — partly because the model reasons before committing, and partly because you can see which consideration it weighted wrongly and say so.
The reverse instruction is just as useful when you do not want it: "answer in one line, no preamble, no reasoning" is respected.
should we build this feature ourselves or buy it
We are a 4-engineer team deciding whether to build in-app search or buy a hosted search product. First list the three strongest arguments for each side, marking any that rest on an assumption we have not tested. Then give your recommendation in two sentences, and name the single fact that would change it.
Constrain the voice and it holds
Nuanced instructions about tone are followed closely, which makes Claude a strong pick for editing work where the point is that the result still sounds like you. Say what to preserve, not only what to change — "keep my contractions and my sentence lengths; fix only grammar and clarity" is a prompt this model can actually execute.
The same precision applies to what you want it to stop doing. "Do not add a closing summary paragraph", "do not soften the criticism", "do not add caveats I did not ask for" all work as written.
Long documents are the easy case
Pasting a long document and asking focused questions about it plays directly to the model's strengths. Ask for quotes rather than paraphrases when accuracy matters — "quote the sentence you are basing that on" turns an answer you have to trust into one you can check in a few seconds.
Three habits worth dropping
- Hedging. "Could you maybe help me tighten this a bit?" gives the model nothing to aim at. Say what "tighter" means — shorter by a third, no adverbs, one idea per sentence.
- Burying the instruction. With a long paste, put the job at the end so it is the last thing read, or state it at both ends.
- Accepting the first draft as final. One sharp correction — "the third point is generic, replace it with a concrete example from the text" — is usually higher leverage than rewriting the prompt.
One idea, built the way Claude reads
Set the target to Claude and tap Enhance. Prompt AI Keyboard rebuilds your rough line as the structured, explicitly constrained prompt this model responds to — in whatever app you are typing in.
FAQ
How should I structure a prompt for Claude?
Like a brief rather than a sentence: the task, then numbered constraints, then the material it applies to. Claude follows long, organized prompts closely, so three numbered requirements are honoured more reliably than one dense paragraph carrying the same three.
Why should I wrap pasted text in tags when prompting Claude?
So the model can tell the job from the thing the job is about. Wrapping material in a marker such as
Does asking Claude to reason first actually improve the answer?
Usually, yes — 'list the trade-offs, then recommend' produces a better recommendation than 'recommend', and it shows you which consideration was weighted wrongly so you can correct it. When you want the opposite, 'one line, no preamble' is respected.