What you’ll be able to do
- Describe a failure in terms that point to its cause, not just “it’s bad”
- Match a recurring problem to its likely root cause and the fix that addresses it
- Test a fix so you know it worked, rather than got lucky once
What you need to know
Diagnosis is different from iteration
Lesson 1.3 covered refining a draft that's basically on track. This lesson covers the other situation: output that is consistently off, across rounds, across chats or across team members. When follow-ups keep failing, the problem usually isn't the wording of your follow-ups. Something upstream is wrong, and more refinement on top of it just produces polished versions of the same miss. The job is to find that cause and fix it.
Start by naming the symptom precisely
"It's not good" can't be diagnosed. Compare the output with what you needed and say what's actually wrong:
- Generic, could apply to any organization?
- Factually wrong, outdated, or containing details that don't exist in your materials?
- The right content in the wrong shape, length or tone?
- Answering a different question from the one you meant?
- Ignoring an instruction that used to be followed, or forgetting earlier decisions?
- Inconsistent: good one day, poor the next, for the same task?
Each symptom points to a different cause, which is why this step matters.
Common root causes and their fixes
- Missing context — Symptom: generic output. Claude doesn't know your product, audience, policies or history. Fix: supply it, either in the prompt or, for recurring work, in Project instructions and project knowledge.
- Vague success criteria — Symptom: output is reasonable but never quite "it," and people disagree about whether it's good. Fix: define done, with length, structure, must-include points, audience and a sample of good output. If you can't describe a good result, Claude can't aim for it.
- Wrong task framing — Symptom: Claude answers a different question. Asking to "summarize" a contract when you need risks flagged, or asking for "the best option" when you need a comparison to decide yourself. Fix: restate the task as what you really need.
- Bad or outdated source files — Symptom: confident answers that are wrong in a consistent way. If the project knowledge holds last year's price list, two versions of the same policy, or a badly scanned document, Claude will faithfully use them. Fix: correct the source, remove superseded versions and check the file is readable. Rewording the prompt won't help.
- Context too long or cluttered — Symptom: in a very long conversation, earlier instructions get followed less reliably, or old, abandoned drafts creep back. Fix: start a new chat with a concise summary of decisions and the current version, and move standing instructions into a Project so they don't depend on one long thread.
- Wrong feature or model for the job — Symptom: the output's limits match the tool's limits. A plain chat answer to a question that needed current, multi-source information (use web search or research); a one-off chat for a task that repeats weekly with the same files (use a Project); a fast, lighter model for a complex judgment call, or the heaviest model for simple high-volume work. Fix: match the feature and model to the task.
- Conflicting instructions — Symptom: Claude seems to ignore a rule. Often the Project instructions say one thing and the prompt says another ("be brief" versus "include full detail"). Fix: remove the contradiction.
Sometimes the diagnosis is that the task isn't suitable for Claude as configured. It needs data Claude can't access, a system integration, or a decision that must stay with a person. Saying so, and escalating where appropriate, is a valid outcome of troubleshooting.
Fix one cause, then test properly
Change one thing at a time, starting with the most likely cause, so you learn what actually mattered. Then test on several realistic examples, including an awkward one, not just the case that prompted the complaint. A single good result can be chance; consistent results across varied inputs show the fix worked. If the prompt is shared by a team, tell people what changed so they don't keep using their own workarounds.
Key concept
When output consistently underperforms, name the symptom, trace it to a root cause (context, criteria, framing, sources, length, tool or model) and fix that cause, then confirm across several examples.
Exam questions describe a recurring problem and offer several plausible fixes. The best answer addresses the specific cause the scenario points to (an outdated file, a missing audience, an overgrown chat), while the distractors add emphasis, switch to the biggest model, or abandon the task.
Practice scenario
Work it through, then open this
The symptom is consistent, specific and wrong in the same way, which points to the source material, not the prompt. The most likely cause is that the project knowledge still contains the previous policy document, or both versions, so Claude finds the old rule there. Capital letters can’t fix that: Claude can’t tell which document is “current” unless the sources make it clear. The fix is to remove the superseded file, make sure the current policy is uploaded and readable, then test with several carry-over questions, including an edge case. She should also let managers know answers given before the fix may have been wrong.
Hands-on exercise — Diagnose before you rewrite
Intermediate · 20 min
What you’ll learn
- How to turn “it’s not good” into a diagnosable symptom
- How different causes produce different symptoms
- How to confirm a fix across several inputs
-
Pick a prompt or Project at work whose output often disappoints. Write down three recent poor outputs and, for each, one sentence on exactly what was wrong.
- Why: Precise symptoms point to causes; vague ones lead to random rewrites.
- You should see: A pattern, such as “always generic” or “always uses old figures.”
-
Match the pattern to the likeliest cause from the list in this lesson, and check that cause directly. Open the project files, look for conflicting instructions, or check how long the conversation has become.
- Why: Checking the cause is faster than guessing at fixes.
- You should see: A concrete finding: a missing audience, an outdated file, a contradictory instruction.
-
Fix only that cause, then run the task on three varied examples, including one awkward one.
- Why: One good result can be luck; three varied ones are evidence.
- You should see: Consistent improvement on all three. If not, move to the next likely cause.
Exam traps
Adding emphasis or capital letters instead of finding the cause
Shouting the instruction doesn’t supply missing context, fix a bad file or resolve a contradiction.
Blaming the model when the source file is outdated or wrong
Claude works from what you give it. Consistent, confident errors often trace back to the documents in the Project.
Switching to the most capable model as the first fix for every problem
A bigger model can’t know context it wasn’t given or tell which outdated file to ignore. Change models only when the task’s difficulty is the actual cause.
Continuing a very long, drifting conversation instead of starting fresh with a summary
Long, cluttered chats can lose track of earlier instructions. A fresh chat with a concise summary often fixes it.
Rewriting everything at once so you can’t tell what fixed it
Change one cause at a time so you learn what mattered and can repeat it.
Declaring the problem solved after one good result
Test on several realistic and awkward examples before telling the team it’s fixed.
Sources
- Anthropic, Claude Certified Associate – Foundations Exam Guide v1.0 (July 2026)
- Claude Help Center
- Claude Docs (includes prompt engineering guidance)