Home / Writing a request that works
The three blocks of a request
A request that works separates three blocks, what Claude must be, what has already been said, and what is being asked now, and an explicit instruction gives a more reliable result than a vague instruction left to Claude's judgement.
A request that works separates three blocks: what Claude must be for this conversation, what has already been said, and what is being asked now. Claude's documentation states this directly: Claude responds well to clear, explicit instructions, and if you want behaviour that goes beyond the bare minimum expected, you need to ask for it explicitly rather than counting on the model to guess it from a vague instruction. An explicit instruction therefore gives a more reliable result than a vague instruction left to Claude's judgement.
What Claude must be
The first block sets the role and the frame before the conversation even begins. On claude.ai, this block does not appear as a separate field to fill in with every message: it lives in a project's instructions, a workspace that gathers several conversations around the same subject. Once these instructions are written, Claude applies them to every conversation opened within that project, without you needing to repeat them each time. This block is what Claude's designers call, in their technical documentation, the system prompt: the underlying instruction that steers the tone and priorities before the first question.
What has already been said, and what is being asked now
The second block is the history of the current conversation, every message sent and every answer received since the exchange began. Behind the scenes, this entire history is resubmitted with every new message, not just the last sentence typed. A conversation that drifts far from its original subject therefore weighs down this block without clarifying it, and an instruction given right at the start can end up diluted behind dozens of messages that no longer recall it. The third block is the message you have just typed: it is the only one of the three that changes with every turn, and it is also the one you have the most control over, since you are writing it at this very moment.
Project instructions (block 1):
You help an agricultural cooperative write meeting minutes, clear, in plain language.
Message typed in the conversation (block 3):
Write a three paragraph summary from these notes: 2026 budget approved, decision to hire a part time employee, next meeting set for 15 October.
A precise request in the third block partly makes up for a poorly defined role in the first, but the reverse also holds: a well set role at the start lightens what needs to be spelled out again with every new request. Without a project, the first block is often reduced to the very first sentence typed, and it is worth writing it as a role rather than as a simple question. The lesson on Claude's training introduced this separation implicitly; this one makes it actionable for a real conversation.
The three blocks of a request, stacked with every message
An association manager opens a Claude project and writes in its instructions that he helps write clear meeting minutes for a cooperative. He then types, in the conversation, the request to draft minutes from notes taken during the meeting. Claude answers with a three paragraph summary in plain language.
Write in one sentence what this situation establishes, and in one sentence what it does not establish.
What this establishes: It establishes that the instructions written in the project shaped the style of the answer produced for this specific request.
What this does not establish: It does not establish that this same project instruction would produce a comparable result for a request of a different nature, for example a table of figures rather than a narrative summary.
The three most common miscalibrations
- Too broad Concluding that any instruction written in a project automatically shapes every future answer, whatever the task requested.
- Too narrow Concluding that this result proves nothing because only one set of minutes was produced, when it shows an observable effect on this specific task.
- Beside the point Concluding that the cooperative saved time writing its meeting minutes.
- On claude.ai, the first block, what Claude must be, is written in a project's instructions rather than in a separately named field, and it applies to every conversation opened within that project.
- Behind the scenes, the entire conversation already exchanged is resubmitted with every new message, which explains why a conversation that strays from its subject dilutes an instruction set at the start.
- The third block, the request of the moment, is the only one that changes with every turn, and its precision partly makes up for a role left vague at the start of the conversation.
- A conversation with no project often reduces the first block to the very first sentence typed, which is worth writing as a role rather than as a simple question.
Open a Claude conversation and write, as your first message, a one sentence role for your activity, for example you help an association write clear letters, then ask your real question in the following message and compare the result with what you usually get without this first sentence.
These points depend on an interface or a rule that may have changed since this was written. Check them on your own screen before relying on them.
- Check on your own account the exact name of the field where a project's instructions are written: it may differ slightly from the interface described here depending on the version of claude.ai you are using.
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
- Using the Messages API, Claude Docs consultée le 2026-09-02
- How can I create and manage projects, support.claude.com consultée le 2026-09-02