Home / Writing a request that works
Being clear, direct, and giving the why
Claude behaves like a brilliant new employee with no implicit context about your habits, so a request benefits from stating the why and who will read or hear the response, not just the task to carry out.
Claude behaves like a brilliant new employee who knows neither your habits nor your sector. Claude's documentation puts it in these terms: think of Claude as a brilliant but new employee who lacks context on your norms and ways of working, and the more precisely you explain what you want, the better the result. A short request can seem clear to the person who wrote it while still resting on context that Claude never received.
The colleague test
The same documentation offers a concrete test for checking that a request is clear enough: show your request to a colleague who has almost no context on the task, and ask them to follow it to the letter. If they are lost, Claude will be too. This test works because it moves the judgement outside your own head: you generally understand your own request without effort, precisely because you already know the context that is missing from the written words.
Giving the why, not just the task
Stating the task is not always enough. Providing the context or motivation behind an instruction, by explaining why a given behaviour matters, helps Claude better understand the goal and produce more targeted responses. The documentation illustrates this point with a concrete example: a request that says to remove the ellipses from a text leaves the why to be guessed. A request that adds that the text will be read aloud by a text-to-speech engine, which cannot pronounce that mark, steers Claude towards a rewording that keeps the rhythm of the sentences rather than a simple mechanical removal.
Version faible :
Retirez les points de suspension de ce texte.
Version avec le pourquoi et le destinataire :
Ce texte sera lu à voix haute par un moteur de synthèse vocale qui ne sait pas prononcer les points de suspension. Reformulez les phrases concernées pour garder leur rythme sans ce signe.
The same logic applies to who will read or hear the response. A report intended for the board of an association does not call for the same level of detail as a message intended for a new member who is discovering the subject. Naming this reader in the request, one sentence is often enough, spares Claude from guessing a register instead of having it written down in black and white, building on the three blocks of a request already covered.
A clear request and a request that gives the why are not two separate steps to carry out one after the other: they are checked together, with the same colleague test, in a single re-read before sending the message.
The same task, with and without the why
Rédigez un message pour annoncer le changement d'horaires de la permanence.
Rédigez un message pour annoncer le changement d'horaires de la permanence, destiné aux adhérents qui découvrent tout juste le nouveau local ; expliquez que le changement vient d'une contrainte de bail, pour éviter les questions répétées au téléphone.
A treasurer writes Claude a seven-word request to reword a paragraph of a financial report. Claude replies with a rewording in very technical language, using several accounting terms. She reads the response back, then rewrites her request to specify that the report will be read by volunteer members who encounter the accounts every year. Claude produces a second rewording that replaces the accounting terms with everyday explanations.
Write, in one sentence, what this situation establishes, and in one sentence what it does not establish.
What this establishes: It establishes that adding, in the request, who would read the text changed the vocabulary used in the response Claude produced for that same paragraph.
What this does not establish: It does not establish that this second rewording is actually understandable to the volunteer members targeted, which only a reading by one of them would confirm.
The three most common miscalibrations
- Too broad Concluding that specifying the reader is always enough to make an accounting text understandable to any audience, whatever the subject covered.
- Too narrow Concluding that nothing changed between the two responses because only one paragraph was reworded, when the vocabulary used differs markedly from one version to the other.
- Off target Concluding that the treasurer now spends less time writing her financial reports.
- The colleague test consists of showing your request to a person who knows almost nothing about the subject, then checking that they would be able to follow it to the letter.
- Explaining why a behaviour matters steers Claude towards a better solution, such as rewording a sentence rather than simply removing a mark that a text-to-speech engine cannot pronounce.
- Naming who will read or hear the response, in one sentence, spares Claude from guessing a register instead of having it written down.
- An instruction that seems obvious to the person who wrote it can remain obscure to Claude, for lack of context it has not received anywhere else in the conversation.
Take a recent request you sent to Claude without specifying who would read it, add the reader and the why in one sentence, ask the question again and compare the two responses obtained.
Every datable claim in this lesson links here to the public text behind it. A source that does not open proves nothing.
- Prompting best practices, Claude Docs consultée le 2026-09-02