1.4 Adapting Prompting Strategy to the Type of Task

Everything covered so far -- the six building blocks, decomposition, iteration -- applies across every kind of work. But *how* those tools get used should shift with the type of task. A prompt that's well-suited to drafting a client email is poorly suited to a brainstorming session, and a prompt built for open brainstorming would be a bad fit for a compliance analysis. Matching the approach to the task type is itself part of writing an effective prompt, not a separate skill layered on top.

Analysis prompts need three things beyond the general building blocks. First, the actual source data has to be in the prompt or attached -- Claude can't analyze what it can't see. Second, state the lens explicitly: "analyze for cost risk" produces a very different, and more useful, read of a contract than a bare "analyze this." Third, and this is the piece unique to analysis and multi-step reasoning: ask for the reasoning before the conclusion.

Asking Claude to work through its reasoning before giving a final answer generally improves quality on this kind of task -- it gives the model room to weigh evidence and check its own logic before committing to a conclusion, rather than pattern-matching straight to an answer that skips a step. For a business user, this is as simple as adding a phrase like "walk through your reasoning first, then give your recommendation."

Research-style asks carry a risk that's specific to them: Claude can produce confident-sounding, well-organized output that is not actually verified. Fluency in the phrasing of an answer is not evidence that the underlying claim is correct. A research prompt therefore needs to explicitly ask for structured findings with sources or citations you can check yourself, and it should state the scope and recency required -- for example, "only sources from the last two years" or "limit to publicly available filings."

This connects directly to hallucination awareness, covered in more depth in Domain 2: a research answer that reads as thorough and well-cited is not automatically trustworthy just because it reads that way. Verifiable sourcing is the mechanism that lets a business user actually check the claims rather than taking a confident tone as a proxy for accuracy.

Drafting and brainstorming sit at opposite ends of a spectrum, which is why using the same prompt shape for both produces a mismatch. Drafting wants precision: a stated audience, tone, length, and format, ideally paired with a style example -- the same building blocks from Lesson 1.1, applied specifically to producing a finished, polished deliverable.

Brainstorming wants the opposite: quantity and range. "Give 10 varied ideas, including unconventional ones" invites breadth, and critically, it defers filtering to a later step. Judging and narrowing down ideas too early -- inside the same prompt that's supposed to be generating them -- collapses the exploration you were trying to get in the first place.

Reasoning-before-conclusions is a specific, powerful lever -- but it isn't free, and it isn't universally warranted. It earns its keep on analysis and multi-step reasoning tasks, where working through the evidence first measurably improves the quality of the conclusion. For a simple lookup ("what's the capital of the state referenced in this document?") or a short, low-stakes draft, that overhead adds length without adding benefit -- there's no chain of evidence to work through.

Knowing when to skip this lever is as much a part of task-type adaptation as knowing when to use it. Reflexively asking for step-by-step reasoning on every single request, regardless of whether the task actually involves weighing anything, is its own small inefficiency -- it doesn't hurt accuracy, but it doesn't help it either, and it's a sign the prompt wasn't actually matched to the task type.

Task Statement 1.4 questions typically present a task (analysis, research, drafting, or brainstorming) and ask which prompt instruction fits, or present a prompt and ask which task type it's mismatched to.

• 1.Using a rigid, single-format prompt for every task type -- e.g., applying a drafting-style prompt to a brainstorming task and getting three safe, filtered ideas instead of ten varied ones.
• 2.Forgetting that research-style asks need verifiable sourcing, since Claude can produce confident but unverified claims.
• 3.Reflexively asking for step-by-step reasoning on every task, including simple lookups or short drafts, where it adds length without adding benefit.
• 4.Filtering brainstorm ideas within the same prompt that's supposed to be generating breadth, collapsing the exploration before it happens.

The unifying principle across all four task types: figure out what the task type specifically needs -- a lens, sourcing, precision, or breadth -- and make sure the prompt asks for that thing explicitly, rather than defaulting to one all-purpose template.