A good request says who it is for, what it is for and how it should come out

A marketing analyst pastes the campaign results table and writes: “Make me a report.” She gets three correct, generic pages, with advice that would fit any company. Her director only wanted to know which two channels to cut next quarter.

Claude did nothing wrong: it answered what it was asked. The problem is that the request said nothing about what mattered.

The three questions the request has to answer

Before you send a prompt, check whether it answers these:

• Who is it for? A summary for the board is not the same as an explanation for someone starting at the company tomorrow.
• What is it for? Which decision it supports, or what the reader has to be able to do. “Recommend which two channels to cut” steers the whole analysis; “a report” steers nothing.
• How should it come out? The output format: length, structure, tone. “One page, with the recommendation at the top and three figures that back it up” is a format; “something neat” is not.

With those three answers, the analyst’s request becomes: “This is for the marketing director, who has to decide which two channels to cut next quarter. Using the attached table, recommend which ones and why, in half a page, with the recommendation on the first line.”

Give the reason and show an example

Two more things improve the output a lot:

• Context with the reason behind each rule. “Comment only on variances above 5%, because the board doesn’t review the rest” works better than “comment only on what matters.” With the reason, Claude can apply the criterion to cases you didn’t anticipate.
• Examples: one or two good cases, ideally with a note on what makes them good. If the HR team wants job postings that are “friendly but professional,” two approved postings show the tone far better than the adjective.

And tell it what to do when information is missing: “if a line has no note from its owner, write ‘no explanation provided’ instead of guessing a cause.” That way it doesn’t fill gaps by inventing.

The underlying idea is to give clear and direct instructions, the way you would to a very capable person who just joined and doesn’t know your company.

What doesn’t help

What people usually try	Why it falls short
“Be more precise” or “don’t be generic”	It doesn’t say in what way; Claude doesn’t know what is missing
Repeating the rule or writing it in capitals	It adds emphasis, not criteria
“You are the best analyst in the world”	Flattery adds no information about the task
Switching to the most capable model	A bigger model can’t guess who the report is for either
Asking for “longer and more detailed”	If the problem was the focus, longer is worse

Common traps

• Asking it to be “more specific” without giving the information that would make it specific.
• Pasting the same table into a new chat with the same request, hoping it comes out better this time.
• Adding tone adjectives (“professional,” “warm”) instead of an example.
• Assuming the model failed when the request never said what it was for.

On the exam

The typical scenario describes an output that is generic, too long or in the wrong tone, and almost always leaves a clue about what was missing: who reads it, what decision they have to make, a folder of approved examples nobody used. Look for the option that adds the audience, the purpose and the format to the prompt (or the examples with their reason). Rule out the ones that only ask for “more precision,” repeat the instruction, flatter the model or switch models without touching the request.