1.1 The Building Blocks of an Effective Prompt

Imagine handing a task to a smart, capable colleague who just joined your team. You wouldn't say "write an email" and walk away -- you'd tell them what the email needs to accomplish, who it's going to, what tone to strike, and how long it should be. Claude needs the same briefing. A prompt is not a search query; it's a set of instructions, and instructions that leave out the essentials will get filled in with the model's best guess rather than your actual intent.

Official Anthropic prompting guidance is explicit on this point: be explicit and specific rather than terse. The reason terse prompts fail so often isn't that Claude can't produce good writing -- it's that "good" is undefined until you say what you want, why you want it, who it's for, and what shape the answer should take. Ask for "a customer apology email" and you'll get a serviceable, generic one. Ask for a 150-word apology for a frustrated enterprise client whose order arrived two weeks late, warm but professional in tone, and offering a 15% credit instead of a refund, and you'll get something you can send with minimal editing.

This is the single highest-leverage habit for anyone using Claude for everyday business work: before you hit send, check whether your prompt actually states the task, the context, the audience, and the format -- or whether you're relying on Claude to guess.

Official prompting guidance breaks that briefing down into six reliable building blocks. None of them are exotic -- they're the same things you'd naturally include in a well-written work request to a person. The skill being tested is recognizing which block is missing when an output falls short, and knowing which phrasing actually delivers each one.

Notice that these blocks aren't independent add-ons you sprinkle in randomly -- they compound. Task and context tell Claude *what* is happening; audience and tone tell it *who* the output is for; format and constraints tell it *what shape* the answer must take and what it must avoid. A prompt missing even one of these leaves Claude to fill the gap with a plausible but generic default, and "plausible but generic" is exactly the failure mode the exam will ask you to recognize and fix.

Two smaller but consistently tested habits sit alongside the six building blocks. The first is favoring positive instructions over prohibitions. Telling Claude "write in plain language" points directly at the target; telling it "don't use jargon, don't use passive voice, don't use long sentences, don't be overly formal" only narrows the space of wrong answers without ever describing the right one. A long list of "don'ts" is also easy to satisfy technically while still missing the spirit of the ask. Positive instructions are more reliable because they describe the destination, not just the guardrails.

The second habit is placement: put the most important instruction close to the actual task, not buried in a long preamble of background and caveats. If a prompt opens with three paragraphs of company history before finally stating the actual deliverable, the deliverable can get lost in the noise. State the task early, or restate the critical constraint right next to where the work happens -- for example, immediately before a large pasted document, repeat "Remember: summarize only, do not add recommendations."

A third technique worth calling out on its own: when a past Claude output was well received, reusing it as an example ("match the style and structure of this: ...") is one of the most effective ways to steer tone and format on a new request. Showing the pattern is often more reliable than describing it in prose, because it removes ambiguity about what "professional tone" or "concise format" actually means in practice.

Many real prompts aren't pure instructions -- they mix an instruction with the material to work on: a transcript, a policy excerpt, a spreadsheet paste, a batch of customer comments. This is where a subtle but important discipline comes in: clearly separate the instruction from the data. A heading like "Source document:" followed by the pasted text draws a visible line between "here is what I want you to do" and "here is the raw material to do it on."

Without that boundary, the model may treat a sentence inside the source text as though it came from you. This isn't a hypothetical edge case -- it's the everyday version of the same risk that shows up in more adversarial forms elsewhere in the exam (see Domain 2 on prompt injection). For an Associate-level business prompt, the practical takeaway is simple: whenever you paste something to be analyzed, label it distinctly from the instruction that surrounds it.

A second, related discipline is not assuming shared context. Claude does not have implicit access to your organization's internal knowledge -- its acronyms, unwritten policies, product names, or team structure. Everything it can draw on for a given request comes from exactly three places.

• •The prompt itself -- whatever you typed or pasted in this conversation.
• •Any Project knowledge you've attached -- documents, style guides, or reference material set up ahead of time.
• •Its general training data -- broad world knowledge, not your company's specifics.

If a prompt assumes Claude already knows "our Q3 pricing exception process" without stating what that process actually is, the output won't come back blank -- it will come back confident, filling the gap with a generic best guess or an invented plausible-sounding policy. That's arguably worse than a visible failure, because a fluent wrong answer is easy to mistake for a correct one. The fix is always the same: state the unstated context explicitly, every time it's relevant, rather than assuming a previous conversation or a colleague's knowledge carried over.

Task Statement 1.1 is tested almost entirely through scenario recognition: you'll be shown a prompt or a described outcome and asked to identify what's missing, or to pick the better-structured of two options. The traps cluster around a small set of recurring misconceptions.

• 1."A shorter prompt is always better." False -- vague, under-specified prompts are the most common cause of weak output. Specificity beats brevity.
• 2.Assuming Claude knows your organization's unstated context. It only knows the prompt, attached Project knowledge, and its training data.
• 3.Mixing instruction and data with no separation, risking a sentence inside the source text being read as a command.
• 4.Reaching for a long list of prohibitions instead of a positive instruction that states the target directly.
• 5.Burying the key instruction in a long preamble instead of placing it near the actual task.

Every one of these traps has the same shape: the wrong answer looks reasonable on the surface (shorter is efficient, prohibitions feel thorough, a preamble feels like helpful context) but fails the actual test of whether Claude has what it needs to produce a specific, correct, on-target response.