Writing Effective Prompts: Task, Format, Constraints and Reasons

1.Description: briefing Claude like a new contractor

Anthropic's support guidance on prompt design starts with one image: "Think of Claude as a newly-hired contractor." A new contractor can be very capable and still know nothing about you, your team, your customers or why the job matters. Anything you leave out, they have to guess. The same guidance says to "Give it very specific instructions about exactly what" you want done.

The AI Fluency framework calls this skill Description, one of its four competencies alongside Delegation, Discernment and Diligence. Description and Discernment make up the inner loop of everyday AI work. You describe what you need, then judge what comes back. This lesson covers the first half of that loop.

The framework splits Description into three parts. Each one maps to something a good prompt contains:

- Product Description defines the output: what it is, who reads it, what shape it takes. - Process Description guides the approach: which steps to follow, what to look at first, what to set aside. - Performance Description shapes how the AI behaves while you work together, for example whether it should ask before assuming or flag gaps it can't fill.

Most weak prompts are thin on all three. "Write something about the new policy" defines no product, gives no process and sets no expectations for behaviour. The rest of this page goes through how to fill each of those in.

Sources12

2.Say what you want: task, audience, format, constraints

Claude's prompting best practices put the basic rule plainly: "Be specific about the desired output format and constraints." Claude does what you ask for, so it can't reliably supply ambition you never stated. The docs compare a bare request, "Create an analytics dashboard", with one that adds "Include as many relevant features and interactions as possible." Only the second one asks for a full-featured result.

Anthropic's prompt engineering guide recommends that you "State what you want the output to include, not just what to work on". Lead with the action verb (write, analyse, generate), skip the preamble and go straight to the request. Its meal-plan example shows the difference. "Create a meal plan for a Mediterranean diet" becomes a request for a pre-diabetic plan at 1,800 calories a day, built on low-glycemic foods, listing breakfast, lunch, dinner and one snack with complete nutritional breakdowns. Each addition settles something Claude would otherwise have had to guess.

The output format matters most when the result goes somewhere else afterwards, such as a spreadsheet, a template or another team's process. In that case, spell out the exact structure. The consistency guide advises: "Precisely define your desired output format using JSON, XML, or custom templates so that Claude follows every output formatting element you require." The prompt below names every key and the allowed values for each, so the result lines up the same way every time:

You're a Customer Insights AI. Analyze this feedback and output in JSON format with keys: "sentiment" (positive/negative/neutral), "key_issues" (list), and "action_items" (list of dicts with "team" and "task").

Being specific doesn't mean writing long. The same guide warns that "Longer, more complex prompts are NOT always better." Specificity comes from naming the decisions Claude would otherwise guess at, not from word count. Hard limits, such as a page length or a list of things that must not appear, belong in the request itself, stated as constraints.

Sources345

3.Give the reason behind each instruction

A bare rule tells Claude what to do. A rule with its reason tells Claude what you're trying to achieve. The best-practices guide says that "Providing context or motivation behind your instructions, such as explaining to Claude why such behavior is important, can help Claude better understand your goals".

The docs' example: "NEVER use ellipses" is less effective than explaining that the response will be read aloud by a text-to-speech engine that won't know how to pronounce them. Once Claude knows the output is spoken, it can make related choices on its own, such as avoiding other symbols that don't read aloud well, without a separate rule for each. The prompt engineering guide gives a similar case. "NEVER use bullet points" works less well than explaining that you find flowing prose easier to read, because the reason "allows it to make better decisions about related formatting choices."

The guide lists when this kind of context pays off: explaining the purpose or audience for the output, "Clarifying why certain constraints exist", describing how the output will be used, and naming the problem you're trying to solve. A related habit is to phrase the instruction as what you *do* want. The docs advise you to "Tell Claude what to do instead of what not to do". For example, ask for "smoothly flowing prose paragraphs" instead of banning markdown.

Sources35

Exam traps

Each one states something that sounds right. Open it to see what is actually true.

1. 1.Writing an instruction in capitals with NEVER or ALWAYS is the best way to make Claude follow it.Why is that wrong?

   Anthropic's own example says an emphatic bare rule is less effective than the same instruction with its reason. Claude generalises from the explanation, so the reason helps with related cases too.

   Covered in Give the reason behind each instruction

2. 2.A more specific prompt is simply a longer one, so adding more text always improves the result.Why is that wrong?

   Specificity means stating the decisions Claude would otherwise guess at: audience, format, constraints and restrictions. Extra length that doesn't settle any of them doesn't help.

   Covered in Say what you want: task, audience, format, constraints