Grounding Prompts in Source Material, Examples and the Right Depth

1.Paste the source material, not a description of it

A request can be well specified and still fail if Claude doesn't have the facts. Claude's support guidance says: "Make sure that your prompt contains as much context as possible." It suggests a test: "Pretend you are giving these instructions to someone with no background knowledge about what you are asking." Writing "summarise the attached policy changes" when nothing is attached, or describing a report from memory, leaves Claude to fill the gaps with plausible guesses. Paste the actual handbook, email thread, data or draft.

When the pasted material is long, where you put it matters. The best-practices guide says: "Place your long documents and inputs near the top of your prompt, above your query, instructions, and examples." If you paste several documents, wrapping each in its own tags with a source label keeps them apart from your instructions. For long-document tasks, the guide also suggests you "ask Claude to quote relevant parts of the documents first before carrying out its task". This keeps the answer tied to the text you supplied.

Some context applies to every request on a piece of work, such as house style, audience or recurring background. You don't have to paste it every time. The personalization guide says to "Use project instructions when you need specific guidance or context for a particular project (paid plans only)." Project instructions act as standing context that every prompt in the project builds on.

Sources123

2.Define scope and what to do when the material runs out

Pasting material raises a second question: what should Claude do when the material doesn't answer something? If you don't say, Claude may fill the gap with a plausible guess, and the guess will look just like the grounded parts of the answer. The prompt engineering guide recommends that you "Give the AI explicit permission to express uncertainty rather than guessing." Its example instruction is: "If the data is insufficient to draw conclusions, say so rather than speculating."

This is part of being specific about scope and completeness. A good request says which sources count, what range the answer should cover, and how to handle what falls outside it. For example: answer only from the attached handbook, and if a question isn't covered, say so and point the person to HR. Structured output follows the same principle. The guide's financial-extraction prompt names every field and gives Claude an explicit way to mark a missing value instead of inventing one:

Use this structure:
{
  "revenue": "value with units",
  "profit_margin": "percentage",
  "growth_rate": "percentage"
}

If any metric is not clearly stated in the report, use  ?  rather than guessing.

Sources14

3.Show the format with an example

Some requirements are easier to show than to describe, such as a house tone, the rhythm of a status update or a summary style your team already uses. The best-practices guide says: "Examples are one of the most reliable ways to steer Claude's output format, tone, and structure."

The guide asks for examples that are relevant ("Relevant: Mirror your actual use case closely."), diverse enough that Claude doesn't copy accidental features, and clearly separated from the instructions, for instance wrapped in example tags. Claude follows examples closely, so make sure each one shows only the behaviour you want. The prompt engineering guide also advises restraint: "Start with one example (one-shot)." Add more only if one example doesn't produce the output you need. The guide's summarisation case shows how this works. You paste one short summary in the style you want, then ask Claude to "summarize this article in the same style".

Sources24

4.Ask for the depth you need

A short answer is usually not a capacity problem. The support article explains that Claude's "context window applies to the prompts you provide but not the output it generates." If a response is too brief, the fix is in the request. Anthropic's notes on recent models give one reason this happens: they are "Less verbose: May skip detailed summaries for efficiency unless prompted otherwise". Without a stated depth, you get the model's default.

So say how much depth you want in the first request. The prompt engineering guide tells you to "Be specific about quality and depth expectations", and asking for comprehensive output explicitly is how the dashboard example earns its fuller result. Name the depth concretely: which sections, how many options, whether to include worked numbers or only conclusions. Most other disappointing results also come from something missing in the request, and the guide's troubleshooting list connects each symptom to it:

Sources524

Exam traps

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

1. 1.Describing a document in a sentence or two gives Claude enough to work with.Why is that wrong?

   Claude has no background on your organisation or task. Paste the actual material and write the prompt as if for someone who knows nothing about it.

   Covered in Paste the source material, not a description of it

2. 2.A brief or incomplete answer means Claude hit a size limit, so the request itself is fine.Why is that wrong?

   The context window limits the prompts you provide, not the output. A brief answer means the request needs reworking to ask for the depth you want.

   Covered in Ask for the depth you need