Prompting for different task types

Everything in 1.1 still applies — every one of these needs a task, an audience, a format and constraints. What changes is which of those carries the weight, what you must forbid, and which product features belong in the loop. The table below is the short version; the sections after it are the reasoning.

Analysis: pin it to the data

An analysis task has a right answer that lives inside material you already hold — a spreadsheet, a contract, six months of tickets. The single most important instruction is therefore the boundary: use only this, and say so where it is silent. Without it, a plausible-sounding average or a “typical industry practice” slips in beside the real figures and is indistinguishable from them.

Three other things make analysis prompts work. State the question as a question, not a topic — “which three cost centres moved most against budget” rather than “look at the budget”. Ask for the workings, so that a wrong number can be traced to a wrong step rather than discovered later. And, for large inputs, follow the long-context placement rule: put the documents at the top, the question at the end, and ask Claude to quote the relevant passages before it answers, which keeps it focused on the parts that matter. For genuinely hard reasoning the Claude apps also let you raise the effort setting or turn on thinking, which the help centre recommends for mathematical problems and technical analysis rather than routine questions.

Analyse the attached support
ticket data and tell me what
you find.

Using only the attached Q2 ticket
export, answer these, in order:

1. Which product areas generated
   the most tickets? Table: area,
   count, % of total.
2. Which had the longest median
   time to resolution?
3. Did any area get worse between
   April and June?

Show the calculation for each
figure. Where the export cannot
answer, write "not in the data".
Label any cause you infer as
"assumed".

Research: send it out into the world

A research task has an answer that lives outside your files and outside the model. The failure mode is the opposite of analysis: instead of inventing facts about your data, Claude answers from training data that has a cutoff date, which means anything that changed recently may be quietly out of date. The fix is to make the search explicit and the sources visible.

In the Claude apps, web search is turned on from the plus button and Claude will invoke it for topics that benefit from current information; responses come back with citations and source links you can open. For questions that need several angles rather than one lookup, Research runs multiple searches that build on each other and returns an answer with citations designed to be easy to check; it is available on paid plans and needs web search enabled. Research counts against usage limits the same way ordinary conversations do, but can consume them faster because it retrieves many sources.

Good research prompts therefore carry three extra things: a recency requirement (“as of this year; say when each source was published”), a breadth requirement (“cover at least three independent sources and note where they disagree”), and a traceability requirement (“cite each claim, and tell me what you could not find”). That last one matters most. An honest “no reliable source states this” is far more useful than a confident sentence you then have to chase.

Drafting: it is about the reader

In a drafting task the facts are usually settled and the work is in the expression. The prompt weight shifts to audience, voice, format and length — and the highest-value move is to stop describing your style and show it. Anthropic describes examples as one of the most reliable ways to steer output format, tone and structure, and recommends three to five, chosen to be relevant to your actual use case and diverse enough that Claude does not lock onto an unintended pattern. Wrapping each in <example> tags keeps them distinct from your instructions.

Two constraints belong in nearly every drafting prompt. First, the factual boundary, for the same reason as in analysis: a draft that needs a statistic will invent a plausible one unless told not to. “Do not invent figures, names or dates — leave [TK] where you need one from me” turns a subtle risk into a visible list. Second, phrase the request as an instruction. Current models are precise instruction-followers, and the documentation contrasts asking for suggestions with asking for the work itself; “write the announcement” and “suggest how we might announce this” produce genuinely different artefacts.

Drafting is also where the artifacts feature earns its place. Claude opens content as an artifact when it is significant and self-contained — typically over fifteen lines — and something you are likely to edit, iterate on or reuse outside the conversation. A press release or a policy page becomes a document beside the chat that you can edit in place and switch between versions of, instead of a block of text you re-derive each round. Choosing between an artifact, an inline answer and a structured format is objective 2.6, and the product surface itself is 3.1.

Brainstorming: the one where constraints come last

Brainstorming inverts almost everything above. There is no source to stay inside and no single right answer; the goal is range. The characteristic mistake is to write a brainstorming prompt as though it were an analysis prompt — tightly scoped, one deliverable, “give me the best option” — which produces four safe ideas that everyone in the room had already thought of.

Prompt instead for volume and spread, and say explicitly that judgement comes later. Name the axes you want covered so the list does not cluster: cheap versus expensive, this quarter versus next year, things we can do alone versus things needing a partner. Ask for deliberately uncomfortable entries — “include three that would make the finance director wince and three that a competitor would try” — because that is what pushes past the obvious. And be specific about the constraint you are pushing against, since a brainstorm with no constraint at all drifts into generality.

Then converge in a separate step. Once you have thirty ideas, a second prompt does the evaluation: cluster them, score them against your real criteria, and pick a shortlist with reasons. Keeping divergence and convergence in different turns is the same checkpoint logic as the chaining in 1.2, and it stops the model quietly filtering its own list before you have seen it.

One caution that applies to all four. Adapting your strategy changes the quality and shape of the draft; it does not certify it. Analysis can still miscalculate, research can still misread a real source, drafting can still invent a statistic, and a brainstorm can still surface an idea that is illegal in one of your markets. The check against sources and the judgement about human review sit in Domain 2, and they come after whichever of these four strategies you used.

Traps the wrong answers are built from

You should now be able to

• Classify a request as analysis, research, drafting or brainstorming from the scenario wording.
• Write an analysis prompt that names the question, bounds the source and requires visible workings.
• Set up a research prompt with recency, breadth and citation requirements, using web search or Research.
• Build a drafting prompt from audience, voice samples, format and factual guardrails.
• Run a brainstorm as divergence then convergence, with named axes and a forbidden cluster.
• Split a mixed request into its component task types with a checkpoint between them.