Diagnosing Underperforming Prompts and Poor Claude Outputs

1.Diagnose first: five causes that look alike

When Claude gives a weak answer, the instinct is to fire off the request again, reword it a little, or switch to a bigger model. Each of those is a fix for one particular cause. Applied to the wrong cause, they burn time and usage and leave the problem in place. Anthropic's prompt engineering guide says plainly that prompt changes are not the answer to every failure. Some problems are better solved another way, for example by choosing a different model when latency or cost is the constraint.

In practice, a poor output almost always comes from one of five causes. A vague prompt gives a generic or shallow answer because Claude had nothing specific to aim at. Missing context gives a fluent answer to the wrong question, or confident guesses about things Claude was never told. Stale knowledge gives an answer that faithfully quotes an outdated source. An overloaded conversation mixes up earlier threads, contradicts itself and uses up usage. A genuine limitation shows up as shallow reasoning on a hard problem, or wrong facts about recent events that Claude may never have been trained on.

These causes look similar from outside: in every case the answer is 'wrong'. The diagnostic question is where the answer came from. Was the instruction underspecified? Did the information exist anywhere Claude could see it? Was the information Claude could see out of date? Is the conversation carrying more history than the task needs? Is the task simply hard? The rest of this lesson takes each cause in turn.

Sources12

2.When the prompt is the problem: generic or too-brief answers

The most common cause of a disappointing output is the request itself. Anthropic's help article on too-brief responses gives a short diagnosis: if answers are too brief or only partly complete, rework the prompt. That fits with how recent models behave by default. Anthropic's prompting guide describes them as less verbose, and they may skip detailed summaries unless asked for them. A short answer to a short request is often the model working as designed, not a failure.

The fixes come from Anthropic's general prompting principles. First, be specific about the output format and constraints you want: length, structure, sections, and the audience it is for. The support guidance on unhelpful answers adds that you should include as much context as possible, written as if for someone with no background knowledge of the task. Second, give the reason behind an instruction, because Claude generalises from the explanation. Third, if the format or tone still drifts, add examples. Anthropic calls them one of the most reliable ways to steer output.

The pair below, from Anthropic's prompting guide, shows the gap between a bare request and one that states how far to go. The less effective version was simply 'Create an analytics dashboard'.

Create an analytics dashboard. Include as many relevant features and interactions as possible. Go beyond the basics to create a fully-featured implementation.

Explaining the reason does more than repeating the rule more firmly. Anthropic's example replaces 'NEVER use ellipses' with the sentence below. Because the instruction now says why, Claude can apply the reason to cases the rule never named.

Your response will be read aloud by a text-to-speech engine, so never use ellipses since the text-to-speech engine will not know how to pronounce them.

For a generic invitation, a thin report section or a one-paragraph summary, the fix is the same: say who the output is for, what it must include, how long and in what shape, and why. Then give Claude feedback in the same chat. The support guidance lists follow-up instructions, clarifications and requests to rewrite as normal parts of the process. Checking that the first message is clear and complete also saves the follow-up messages a vague prompt would otherwise need.

Sources3456

3.When the knowledge is the problem: missing versus stale

A confidently wrong answer usually means something different. Two cases look the same but need opposite fixes.

The first is missing knowledge. Anthropic's help article on incorrect or misleading responses explains that hallucination is a byproduct of current model limitations. It names recent events as a typical weak spot, because Claude may not have been trained on the latest information. It also warns that Claude can produce quotes that sound authoritative but are not grounded in fact. If someone asks about a regulation announced last month, and nothing in the chat or project describes it, a fluent but wrong answer is the expected failure. Rewording the question doesn't add the missing facts. The fix is to give Claude the source, by uploading the document or pasting the text, and to treat the answer as something to verify. The same article says Claude should not be relied on as a single source of truth for high-stakes advice.

Anthropic's guide on reducing hallucinations adds prompt-level safeguards that work once the source is present. Give Claude explicit permission to say it doesn't know. Ask it to quote the document word for word before analysing it. Tell it to use only the documents provided, not its general knowledge.

Focus on financial projections, integration risks, and regulatory hurdles. If you're unsure about any aspect or if the report lacks necessary information, say "I don't have enough information to confidently assess this."

The second case is stale knowledge, and here those safeguards fail. Files uploaded to a project's knowledge base are what Claude uses to understand the context of every chat in that project. In larger projects, Claude searches that knowledge and retrieves the most relevant passages. If last year's safety standard is still there, Claude retrieves it and quotes its old inspection interval correctly. Allowing uncertainty or grounding in quotes only makes Claude more faithful to the outdated file. Rewording the request makes no difference, because the prompt was never the problem.

The fix is in the knowledge base. You can add and remove project content at any time, so remove or replace the outdated document and upload the current one. Anthropic's usage guidance also recommends regularly removing project files you are no longer using, which stops old files from competing with new ones. Clear file names also help Claude retrieve the right document, so when a revised version arrives, name it so the current one is easy to identify.

Sources2789

4.When the conversation is the problem: restart, carry forward, or move to a project

Sometimes both the prompt and the knowledge are fine, and the conversation itself is the problem. A chat kept open for weeks across two separate tenders holds both tenders' details in one context. When Claude starts blending them or contradicting what it said days ago, the useful question is why so much unrelated history is in one chat.

Anthropic's documentation on length limits explains what happens as a chat grows. With code execution enabled, Claude summarises earlier messages as the context window fills so the conversation can continue. That keeps the chat going, but it costs something: longer conversations that trigger this consume more of your usage limit, and Anthropic recommends starting a new conversation in that situation. More generally, when you reach a length limit, you can start a new conversation or use projects.

The repair therefore has two parts. First, restart: open a new conversation for each separate piece of work, and bring over only what the next task needs. Anthropic's too-brief article describes the carry-forward technique: include the previous prompt and response when writing the next prompt. Second, move durable context out of the chat. Anthropic advises uploading core working documents to project knowledge at the start of a project and using projects for anything you will refer to repeatedly. Paid plans can also use memory and project summaries to build context across conversations.

This is also how you make a fix last. Once you have worked out what makes outputs good for a recurring task, such as the audience, tone or Claude's role, put it in project instructions instead of retyping it in every chat. Anthropic recommends keeping project instructions concise and limited to general context, key guidelines and Claude's role, and keeping task-specific instructions in the chat itself. That way, the lesson from one bad output applies to every later chat in the project.

Sources93610

5.When reasoning depth is genuinely the constraint

The last cause is a genuine limit on how much reasoning the task gets. It is the one people blame too early. Anthropic's model-specific prompting guidance draws the line clearly. If you see shallow reasoning on complex problems, raise the effort level instead of trying to compensate with prompt wording. The guidance also notes that at low effort, models scope their work narrowly to what was asked, so moderately complex tasks risk being under-thought.

In the Claude apps, the related settings are the model, the effort level and extended thinking. Anthropic's usage guidance describes these as trade-offs: higher effort uses more tokens, and extended thinking can be turned off when a task doesn't need deeper reasoning. Turn them up when the problem really is hard, such as multi-step analysis where the reasoning is visibly incomplete. Turn them down for routine work to save usage. The model you choose also affects how much usage each message consumes. Note that these sources describe escalation in terms of effort and thinking settings. They do not give a ranking of model tiers to escalate through.

The converse matters just as much. Higher effort or a bigger model cannot recover information that was never in the prompt. If the request did not say who the audience is, how deep to go or what format to use, a more capable model still has to guess. If the facts were missing or the project file was stale, more reasoning simply works harder from the same inputs. Only escalate after you have ruled out the first four causes. Diagnosing first also stops you wasting usage on repeated regenerations that cannot change the outcome.

Sources1195

Exam traps

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

1. 1.A larger or more capable model will fix a vague or underspecified prompt.Why is that wrong?

   A stronger model still has to guess what an underspecified prompt leaves out. Claude performs best with clear, specific instructions, so fix the prompt first and escalate only when reasoning depth is the real constraint.

   Covered in When reasoning depth is genuinely the constraint

2. 2.If Claude keeps quoting an outdated figure from a project, better prompting or 'use only current information' will correct it.Why is that wrong?

   Claude uses uploaded project knowledge as its context, so it will accurately quote whatever outdated file is there. The fix is to remove or replace the file in project knowledge.

   Covered in When the knowledge is the problem: missing versus stale

3. 3.A fluent, confident answer about a recent event shows Claude has reliable information about it.Why is that wrong?

   Claude may not have been trained on recent information, and confident-sounding output can still be wrong. Supply the source and verify high-stakes claims.

   Covered in When the knowledge is the problem: missing versus stale

4. 4.Keeping one long conversation open saves effort, because Claude automatically summarises earlier messages.Why is that wrong?

   Automatic summarisation keeps a long chat going, but it uses more of your usage limit, and unrelated history stays in context. Start a new conversation for separate work and keep durable material in a project.

   Covered in When the conversation is the problem: restart, carry forward, or move to a project