Lab 7 · Domain 7 · 10%

Troubleshooting & Optimization

When Claude gives you something bad, the untrained reflex is to rewrite the whole prompt and reroll until something sticks. That works by luck, and luck does not scale. This lab teaches the opposite discipline: name the failure before you touch anything. Bad output is not one problem: it is at least seven distinct problems, each wearing a different disguise and each demanding a different fix. Diagnose first, change one variable, measure the delta. Then we turn the same rigor on your workflow, because a process that produces work you have to redo is not fast, no matter how quick the AI step looks.

Exam objectives covered

Identify, diagnose, and resolve issues with underperforming prompts or poor outputs
Adjust approach based on feedback and results
Optimize workflows for efficiency and effectiveness

What you need: a Claude account (claude.ai), about 40 minutes, and a prompt of your own that has been disappointing you. No installation, no code.

1. Diagnose Before You Fix

This is the whole lab in one sentence. Before you change a single word, you must be able to say what kind of bad the output is. "It's not good enough" is not a diagnosis; it's a feeling, and you cannot fix a feeling. Every category of bad output has a distinct cause and a distinct remedy, and applying the wrong remedy wastes an iteration while teaching you nothing.

Run every disappointing output through this tree. Name the failure mode out loud, then (and only then) reach for the matching fix.

Symptom (what you're seeing)	Likely cause	The fix	Related lab
Wrong — factually incorrect or fabricated	A validation and sourcing problem. Claude is answering from its own memory instead of your material.	Ground it in supplied knowledge, require citations back to the source, and add the failure instruction ("if the source doesn't say, tell me").	Lab 2
Off-target — answers a different question than you asked	A task-specification problem. The prompt didn't actually say what you meant.	State the task as a specific verb and add the criteria that define a good answer.	Lab 1
Right but unusable — correct, but wrong shape, tone, or length	A format and audience problem. The content is fine; the packaging is wrong.	Specify the format explicitly and name the reader it's for.	Lab 1
Shallow across the board — thin on every part	A scope problem. The request is compound: several tasks crammed into one.	Decompose. Split into sequential steps; depth returns when scope narrows.	Lab 1
Drifting or contradicting earlier turns	A context problem. The conversation has outgrown its useful window.	Summarize the thread and start fresh, or restart with the key facts folded into the first prompt.	Lab 1
Inconsistent between runs — different answer each time	An under-constrained problem. The prompt permits too many valid answers.	Tighten the criteria until only the answer you want qualifies.	Lab 2
Ignoring your instructions	An instruction-conflict problem. Something earlier in the thread (or in the Project instructions) contradicts what you're now asking.	Find the conflicting instruction and remove or reconcile it. Check the Project's custom instructions, not just the chat.	Lab 5

Notice that four of these seven symptoms point at other labs. That is the point. Troubleshooting is not a separate skill you bolt on at the end; it is the moment you realize which earlier lesson you skipped. The diagnostic tree is a router: it tells you which foundation to go reinforce.

The single-variable rule. Change one thing, then observe what it changed. If you rewrite the task and tighten the format and add citations all in one go, you may get better output, but you will have no idea which change did the work, so you can't reproduce it and you can't reuse it. Keep the failing output on screen next to the new one. Diagnosis requires a before and an after, and that only exists if you changed exactly one variable between them.

A diagnosed-and-repaired prompt

Here is a prompt that failed with a specific symptom: it kept coming back off-target. An associate wanted a decision, and Claude kept handing back a neutral survey of options.

Weak

Look at these three vendor proposals and tell me about them.

Diagnosis: not wrong (the summaries were accurate) and not unusable in shape; it was off-target. "Tell me about them" is not the task. The associate wanted a recommendation, so the fix is a task-specification fix: state the actual verb and the criteria that decide it. One variable changed (the task), not the format, not the sourcing.

Strong

I have to choose one of these three vendors and defend the choice to my director this week. Using only the three proposals below, recommend one vendor. Rank them against exactly these criteria, in this priority order: total 3-year cost, implementation time, and support SLA. Give me: the recommendation in one sentence, then a short table scoring all three against the three criteria, then the single strongest argument against your own recommendation. If a proposal is missing the data needed to score a criterion, mark it "not stated" rather than estimating.

The "argument against your own recommendation" line and the "not stated" line are borrowed straight from Lab 2, because a decision you can defend is a decision that survived its own strongest counterargument.

Try it in Claude

Find a prompt of your own that produced genuinely disappointing output. Run it again and keep that output on screen: it's your baseline.
Run it through the diagnostic table. Name the single symptom that fits best. Write the name down before doing anything else.
Apply exactly one fix: the one the table prescribes for that symptom. Change nothing else.
Compare the new output against the baseline. Record the delta in one sentence: what specifically got better, and did it match the symptom you diagnosed?
If it didn't improve, you likely misdiagnosed. Re-classify. Don't just pile on a second change.

2. When to Stop Iterating

Deliberate iteration is powerful, but it has a ceiling, and hitting it is diagnostic in itself. The rule: if three deliberate, single-variable corrections have not moved the output, the problem is not the prompt. Stop editing the prompt and look one level up. It is almost always one of three things:

The thread is poisoned. Early turns are anchoring every new attempt. Restart in a clean conversation with everything you've learned folded into the first message.
The knowledge is wrong or missing. No prompt can extract an answer the source material doesn't contain. Fix the sources: add the missing document, correct the stale one (see Lab 5).
The task is a poor fit for Claude at all. Some work is not language work, or needs a system of record Claude can't see. Go back to the fit framework in Lab 4 and ask honestly whether this was ever the right tool.

"Deliberate" is load-bearing in that rule. Three rerolls tell you nothing; you have to have changed a named variable each time and observed no movement. Three real experiments that all fail is strong evidence the problem lives above the prompt.

3. Adjusting Based on Feedback and Results

You adjust based on feedback. The trap is which feedback you listen to. It arrives from three sources, and they are not equally trustworthy:

The output itself — what you can see is wrong by reading it. Fast, but limited to what's visible on the surface.
The humans who consume it — the reviewer, the client, the director who sends it back. Slower, but catches what you can't.
The measure you set before you started — the standard of "good" you defined up front. This is the one to trust most, because it can't be talked out of by a fluent-sounding answer.

Act on the measure, not on vibes. Fluent output is persuasive; that's exactly why "it reads well" is a dangerous signal. If you decided beforehand that a good answer cites its sources and ranks by revenue impact, then an answer that does neither has failed, no matter how confident it sounds.

The highest-leverage move in this whole domain: when reviewers keep making the same edit, that edit belongs in the prompt or the Project instructions permanently. If your director softens the tone of every draft the same way, stop letting Claude produce the wrong tone and stop fixing it by hand. Encode the correction once, upstream, and the whole class of rework disappears. That is the bridge from troubleshooting a single output to optimizing a workflow, and it lives in Lab 5.

Efficiency that creates rework is not efficiency. A process that is twice as fast but produces work that must be redone half the time is slower, and it feels productive the whole way down. The only honest measure is end-to-end: time from request to accepted deliverable, including every round of review and every redo. Optimize that number. Optimizing the AI step alone is optimizing the part that was already cheap.

4. Optimizing Workflows for Efficiency and Effectiveness

Efficiency is doing the thing faster. Effectiveness is doing the thing that doesn't have to be redone. Chase efficiency alone and you get a faster path to output that fails review, a treadmill that feels fast and goes nowhere. The associate-level skill is holding both at once, and always measuring the full loop.

Optimization	What it buys you	Risk if overdone
Promote repeated corrections into standing instructions	Eliminates a whole recurring class of rework; the fix happens once, upstream, forever.	Instruction bloat: pile on too many and they start contradicting each other, producing the "ignoring your instructions" symptom from section 1.
Right-size the model to the task (see Lab 3)	Faster, cheaper responses on routine work; heavier capability reserved for work that needs it.	Under-powering genuinely hard tasks to save time, producing shallow output you then have to escalate and redo anyway.
Batch similar tasks together	One well-tuned prompt applied across many items; you stop re-solving the same setup each time.	Batching things that only look similar, so one prompt fits none of them well and every result needs individual repair.
Eliminate steps the redesign made unnecessary	Real speedup: removing work beats accelerating work every time.	Cutting a review or verification step that was actually load-bearing, trading rework you could see for errors you can't.

Read that last row against the row above it carefully, because it is the crux. The winning move is almost never "make the slow step faster." It is "notice the slow step no longer needs to exist." If promoting a correction into the Project instructions means a review pass now catches nothing, that review pass can go; you didn't speed it up, you deleted it. But be honest about which steps are load-bearing: the verification step from Lab 2 exists to catch confident errors, and deleting that to save time is how you ship the fabrication.

Try it in Claude

Pick a real, recurring task you do with Claude, something you run at least weekly.
Instrument it end-to-end. Time every stage the next time you run it: writing the prompt, Claude's response, your review, and (critically) every round of rework and correction until the deliverable is actually accepted.
Add it up. Now look at where the time actually went. For most people it is not the AI step; it's the review-and-redo loop at the end.
Identify the single most repeated correction across recent runs. Promote it into a standing instruction (a saved prompt, or a Project instruction from Lab 5).
Run the task again, timed the same way. Compare total cycle time, not the AI step. If the rework loop shrank, you optimized the right thing.

When to escalate. Everything in this lab is troubleshooting one prompt or one workflow by hand, inside claude.ai. The moment troubleshooting requires systematic evaluation across many cases (running a prompt against a scored test set, automated regression testing to catch when a prompt change breaks something that used to work, or instrumenting a production workflow to measure it continuously), you have crossed out of Associate territory. That is engineering work for a Claude Architect or Developer. Recognizing that line, rather than trying to hand-test a hundred cases in a chat window, is itself the exam-relevant judgment.

5. Lab Exercise: Diagnose, Fix, and Optimize a Real Task

Objective: run one disappointing output through the full discipline: name the symptom, fix one variable, and then optimize the workflow it lives in by end-to-end time.

Baseline. Take a prompt of your own that recently produced poor output. Run it. Save the result untouched.
Diagnose. Classify the failure against the seven symptoms in section 1. Name exactly one. Write down which related lab it points to.
Fix one variable. Apply only the prescribed fix. Run it. Record the delta in one sentence, and confirm it matches the symptom you named.
Test the stopping rule. If it's still failing, make a second and third deliberate single-variable change. If three changes haven't moved it, stop. Decide whether the problem is the thread, the knowledge, or the task fit, and act on that instead.
Find the repeated correction. Look across your recent uses of this prompt. Is there an edit you make almost every time? That's a candidate for a standing instruction.
Promote it. Fold that correction into a saved prompt or a Project instruction so it happens automatically from now on.
Measure the loop. Time the task end-to-end before and after the promotion, including review and rework. Confirm total cycle time improved, not just the AI step.

Step 7 is the one that separates people who feel busy from people who are fast. The AI step was never your bottleneck. The rework loop was.

Check Yourself

Exam-style items. Commit to an answer before expanding.

Deep into a long working session, Claude's latest output contradicts a key constraint the associate established about 30 turns earlier; it keeps recommending an approach the associate explicitly ruled out at the start. What is the most likely cause, and the right fix?

A. Claude is wrong on the facts; add citations and a failure instruction.
B. A context problem: the conversation has outgrown its useful window. Summarize the key constraints and start a fresh chat with them in the first message.
C. The prompt is under-constrained; add more criteria to this turn.
D. Switch to a more capable model and continue in the same thread.

Correct: B. The tell is the distance: a constraint set 30 turns ago is now being contradicted. That is the classic drifting / contradicting earlier turns symptom, whose cause is context, not facts or criteria. The fix is to summarize what still matters and restart clean, so the constraint sits in the first message where it anchors everything rather than being buried far upthread.

A treats a context problem as a sourcing problem: the output isn't fabricated, it's ignoring an early instruction. C adds constraints to a thread that is already failing to honor the constraints it has; more of the same won't stick. D keeps the poisoned thread intact, so a stronger model inherits the same drifting context and is likely to drift the same way.

An associate's prompt is producing weak output. In a single edit they switch to a more capable model, change the requested format from prose to a table, and add three new criteria. The next output is much better. What is wrong with how they did this?

A. Nothing: the output improved, which is the only thing that matters.
B. They violated the single-variable rule: with three changes at once, they can't tell which one caused the improvement, so they can't reliably reproduce or reuse it.
C. They should have rerolled the original prompt a few more times first.
D. Changing the format was the mistake; format never affects quality.

Correct: B. Getting a better result is not the same as learning anything. Because three variables moved together, the associate has no idea whether the model, the format, or the criteria did the work; maybe two helped and one hurt and they netted out positive. They can't distill the win into a reusable prompt or apply the lesson elsewhere. Change one thing, observe, then change the next.

A confuses a lucky outcome with a repeatable method; the exam tests process, not one-off results. C is rerolling, which is the anti-pattern this entire domain is built to replace. D is simply false; wrong format is the "right but unusable" symptom, and fixing it absolutely affects usability.

A team optimized a recurring report-drafting workflow. The AI drafting step is now four times faster than before. But total time from request to an accepted, sign-off-ready report has barely changed. What most likely happened, and what should they measure instead?

A. The optimization failed; they should revert it.
B. They optimized a step that wasn't the bottleneck. The real cost is in the review-and-rework loop, and they should measure and optimize end-to-end cycle time, including rework, not the AI step alone.
C. They need to make the AI step even faster.
D. The reports must be getting worse; speed always costs quality.

Correct: B. When a step gets 4x faster and the total doesn't move, that step was never the constraint. The time is going somewhere else, almost always the review and rework at the end. The fix is to instrument the whole loop and attack the biggest segment, which usually means promoting the reviewers' repeated corrections into standing instructions so the draft needs less fixing in the first place.

A throws away a genuine local improvement instead of redirecting effort to the real bottleneck. C doubles down on optimizing the part that was already cheap, the treadmill this lab warns against. D invents a quality regression the scenario never states; the problem is where the time sits, not the report's quality.

Key Takeaways

Name the failure before you fix it. Wrong, off-target, unusable, shallow, drifting, inconsistent, and instruction-ignoring are seven different problems with seven different remedies; the diagnostic table routes each to its fix and its lab.
Change one variable, keep the failing output. Diagnosis needs a before and an after; three changes at once teach you nothing you can reuse.
Three deliberate corrections that don't move the output mean the problem is above the prompt: the thread (restart), the knowledge (fix sources), or the fit (back to Lab 4).
Trust the measure you set, not the vibe of a fluent answer. When reviewers keep making the same edit, promote it into the prompt or Project instructions permanently.
Optimize end-to-end, including rework and review. A faster AI step that still fails review is slower overall; efficiency that creates rework is not efficiency.