Diagnosing Bad Output

When Claude's output disappoints, the instinct is to type "no, try again" or to add more words to the prompt. Both are guesses. Experienced users diagnose first: they look at what went wrong, infer why, and apply the fix that matches. The exam presents bad-output scenarios constantly and asks for the most likely cause or the best fix, so this lesson organises the common failures into a table you can run through in your head.

Start with the symptom

Describe precisely what is wrong before deciding what to do. "It is bad" is not a diagnosis. "It answered a different question", "it invented a statistic", "it is twice as long as I wanted", "it used the old template" are diagnoses, and each points to a different cause.

The diagnostic table

Symptom	Most likely cause	Fix
Answered a different or broader question	Ambiguous task statement; vague verb	Restate the task with an operational verb and a concrete deliverable
Generic, could apply to any company	Missing context about your situation	Add the facts only you know; attach the source; use a Project
Invented facts, figures or sources	Asked for precision Claude did not have	Supply the facts; restrict to provided material; ask for placeholders and flagged uncertainty
Right content, wrong tone	Register unspecified or described vaguely	Show an example; name a reference; apply a Style
Wrong length or structure	Format not specified, or specified inconsistently	State length, headings and shape explicitly; give a template
Ignores part of the instructions	Too many competing constraints; instruction buried in a long paste	Shorten; put key instructions first and last; split into steps
Follows an earlier instruction that no longer applies	Conversation drift	Restate current rules, or start a fresh chat with a consolidated brief
Misses information that is in the Project	Retrieval did not surface it; poorly named or structured document	Ask Claude to search for it explicitly; improve file naming and structure; state which document is authoritative
Shallow reasoning on a hard problem	Model tier too light; extended thinking off	Switch to a stronger model; enable extended thinking; ask for reasoning before the answer
Numbers do not reconcile	Estimated rather than computed; wrong column or filter	Ask Claude to run the calculation; define columns, units and exclusions
Declines a legitimate request	Request resembles a prohibited or high-risk pattern	Add context and purpose; rephrase (next lesson)

Three questions that resolve most cases

Did I actually say that? Reread your prompt as a stranger would. Most "Claude ignored me" cases turn out to be "I assumed Claude knew". The missing piece is usually audience, format or a fact.

Is the problem in the prompt or in the material? If you attached a messy, contradictory or outdated document, the output will inherit the mess. Fix the inputs.

Has the conversation gone stale? If the thread is long and has changed direction, Claude is juggling obsolete instructions. A fresh chat with a tight brief often fixes "mysterious" problems instantly.

Over-constraint

A less obvious failure is over-constraint: so many rules that no output can satisfy them all, so Claude satisfies some and quietly drops others. Signs include outputs that follow the first few instructions and ignore the later ones, or responses that feel stilted and hedged. Remedy: prioritise. Tell Claude which constraints are hard and which are preferences, and cut any rule that is not earning its place.

Letting Claude help diagnose

Claude is a decent diagnostician of its own output when asked the right way.

The draft above missed the mark. Before rewriting, tell me: which of
my instructions did you find ambiguous or conflicting, what did you
assume to fill the gaps, and what information would have helped?

The answer often reveals the missing block in your brief.

Scenario: the stubborn summary

A programme manager keeps getting a summary of a 60-page report that covers only the early chapters and misses the recommendations. Diagnosis: the document is long and attached to a chat that already holds a lengthy conversation; the later chapters may not be fully in view, and the prompt never said recommendations were the priority. Fix: new chat, attach only the report, and prompt "Summarise this report with emphasis on the recommendations in the final chapter; list every recommendation verbatim first, then summarise the supporting argument." The output is right first time.

A diagnostic habit

1. Name the symptom precisely.
2. Find it in the table and consider the cause.
3. Apply one fix at a time so you learn what worked.
4. If two fixes fail, rewrite the brief from scratch using the five blocks.
5. Record what fixed it in your Project instructions so it does not recur.

Exam focus

• Diagnose by naming the symptom precisely; each symptom (wrong question, generic, invented facts, wrong tone, ignored instructions) maps to a distinct cause and fix.
• Most failures trace to the brief (missing block), the material (messy inputs) or the conversation (drift), not the model.
• Over-constraint causes Claude to drop instructions silently; prioritise hard constraints and cut the rest.
• Claude can report which instructions were ambiguous and what it assumed; use that to repair the brief.
• Apply one fix at a time, and after two failures rewrite the brief rather than continuing to patch.