# D7 · Troubleshooting and Optimization

Diagnosing underperforming prompts, a systematic debugging loop, handling refusals and length limits, managing context bloat and output drift, and optimising cost and speed while measuring improvement.

import { Accordions, AccordionItem, Tabs, TabItem, Steps } from '@prosefly/astro-components';

This domain is roughly **6 of 60 items**. It tests whether you can *diagnose and fix* a disappointing result methodically instead of flailing – finding the real cause (ambiguity, missing context, conflicting instructions, wrong format, an overloaded prompt), running a disciplined debugging loop, handling refusals and length limits, resetting bloated or drifting conversations, and optimising cost and speed without sacrificing the quality that matters.

## Learning objectives

By the end of this page you should be able to:

1. Diagnose the common causes of an **underperforming prompt**.
2. Run a **systematic prompt-debugging loop**.
3. **Adjust based on feedback** with targeted changes.
4. Handle **refusals and over-caution** appropriately.
5. Handle **truncation and length limits**.
6. Recognise **context bloat** and know **when to reset**.
7. Detect and correct **output drift** in long chats.
8. **Optimise cost and speed** and measure the improvement.

---

## 7.1 Diagnosing an underperforming prompt

Most poor outputs trace to one of five causes. Name the cause before changing anything.

| Cause | Symptom | Fix |
| --- | --- | --- |
| **Ambiguity** | Off-target, generic, wrong interpretation | Clarify audience, scope, definition of success |
| **Missing context** | Vague, hedged, invented details | Supply the document/data; anchor the task to it |
| **Conflicting instructions** | Confused output, ignores part of the ask | Remove contradictions; state one clear priority |
| **Wrong format ask** | Right content, unusable shape | Specify exact format, length, schema |
| **Overloaded prompt** | Drops requirements; uneven quality | Decompose into steps (D1) |

:::tip[Exam signal]
The correct fix is almost always **change the prompt/context**, not "switch models", "raise a setting", or "regenerate blindly". Match the symptom in the stem to one of these five causes.
:::

## 7.2 The systematic debugging loop

Debugging a prompt is like debugging anything: change one variable at a time and observe.

<Steps>

1. **Reproduce** – confirm the problem is consistent, not a one-off.

2. **Isolate the cause** – map the symptom to one of the five causes above. Read the prompt as Claude would.

3. **Change ONE thing** – add the missing context, remove a contradiction, or fix the format ask.

4. **Re-run and compare** – did that specific change help? If not, revert it and try the next hypothesis.

5. **Lock in** the improvement (into a Project or Skill) once it works, so you do not re-solve it later.

</Steps>

```text
Bad debugging:  change model + rewrite prompt + raise length + regenerate,
                all at once → you learn nothing about what fixed it.
Good debugging: one change → observe → keep or revert → next change.
```

## 7.3 Adjusting based on feedback

When you know what is wrong, make **targeted** edits (this is iteration from D1 applied to fixing defects):

| Feedback | Targeted adjustment |
| --- | --- |
| "Too vague" | Add specifics: audience, criteria, examples |
| "Missed part of the task" | Split into steps; verify each part |
| "Wrong tone/length" | State tone and an explicit word/sentence count |
| "Hallucinated a figure" | Supply the source; add 'if not stated, say so' |
| "Inconsistent format" | Provide one worked example (few-shot) |

## 7.4 Handling refusals and over-caution

Claude may decline or over-hedge. Diagnose *why* before reacting.

| Situation | Right response |
| --- | --- |
| Refusal because the request is genuinely against policy/harmful | Respect it; do not seek workarounds – reconsider the task (D6) |
| Over-caution on a legitimate task due to missing context | Add context and clarify legitimacy ("this is our own internal document, for internal use") |
| Ambiguous phrasing that looks risky | Rephrase clearly and specifically, stating the legitimate purpose |
| Genuinely borderline request | Escalate to compliance rather than engineer a bypass |

:::caution[Do not treat legitimate refusals as bugs]
If the refusal is because the task is actually disallowed, the fix is to change the *task*, not to jailbreak the model. Trying rephrasings to force a prohibited output is a governance violation (D6), not troubleshooting.
:::

## 7.5 Handling truncation and length limits

Outputs can be cut off (truncation) when the response is very long, or the input can exceed limits.

| Problem | Fix |
| --- | --- |
| Output cut off mid-way | Ask Claude to 'continue', or request the output in labelled parts/sections |
| Asking for too much at once | Break the deliverable into sections and assemble them |
| Input too large | Summarise or supply only the relevant portion; use a Project for large recurring docs |
| Repeatedly hitting limits | Decompose the task; do not just retry the same oversized request |

## 7.6 Context bloat and when to reset

A long conversation accumulates history. Past a point, that history hurts more than it helps: answers slow, earlier details are lost, and threads get confused.

**Reset (start a new chat) when:**

- Claude is forgetting or contradicting earlier decisions.
- The conversation has covered several unrelated topics.
- Answers have drifted from the original goal.
- You are firefighting a polluted context with endless corrections.

**How to reset well:** ask Claude to summarise the decisions/state, then start a fresh chat with that summary as the clean brief (D3). For recurring context, persist it to a Project instead of carrying it in chat history.

## 7.7 Output drift in long chats

**Output drift** is the gradual departure from the original instructions/format over a long conversation – tone creeps, format changes, earlier constraints fade.

| Detect | Correct |
| --- | --- |
| Format changed from the agreed shape | Restate the format explicitly; give one example |
| Tone crept away from the brief | Re-anchor: 'return to the formal board tone we set' |
| Earlier constraints ignored | Re-state the constraint; if it keeps happening, reset with a clean brief |
| Confusing multiple threads | Reset and separate the topics into different chats |

:::tip[Exam signal]
'Long conversation', 'answers used to be good but got worse', 'started ignoring the format' → **context bloat / output drift** → re-anchor or reset (summarise → new chat), not 'switch model'.
:::

## 7.8 Optimising cost and speed

Once quality is acceptable, optimise the cheaper/faster way to get it.

| Lever | When to use | Trade-off |
| --- | --- | --- |
| **Downgrade the model** (e.g., Opus → Sonnet → Haiku) | Routine, high-volume, latency-sensitive tasks | Watch quality on harder items; do not downgrade high-stakes work |
| **Turn off extended thinking** | Simple tasks | Faster/cheaper; keep it on for hard reasoning |
| **Reuse via Projects/Skills** | Recurring tasks | Saves re-prompting; needs maintenance (D5) |
| **Tighten prompts** | Verbose, meandering exchanges | Shorter context = faster/cheaper |
| **Right-size the output** | Over-long responses | Ask for the length you actually need |

:::caution[Do not optimise away the quality that matters]
Downgrading the model or removing review for a *high-stakes* task to save money is the wrong trade – it re-introduces the D3 mistake of under-buying quality. Optimise routine work; protect high-stakes work.
:::

## 7.9 Measuring improvement

Prove the fix worked; do not rely on impression.

- **Before/after on the same task** – compare against the original failing case.
- **Reviewer edits needed** – fewer edits = better output.
- **Consistency** – does the fix hold across several runs, not just once?
- **Cost/time** – did an optimisation actually reduce cost/latency without hurting quality?
- **Per task type** – confirm the fix did not quietly break another category (avoid aggregate-only metrics).

---

## 7.10 A troubleshooting decision tree

The exam rewards *diagnosis before action*. Route any disappointing result through this tree, which maps a symptom to its real cause and the correct first fix.

```text
What is wrong with the output?
│
├─ Generic / off-target / wrong interpretation
│      └─► Cause: AMBIGUITY. Fix: clarify audience, scope, definition of success.
│
├─ Vague / hedged / invented details
│      └─► Cause: MISSING CONTEXT. Fix: supply the document/data; anchor to it.
│
├─ Confused / ignores part of the ask
│      └─► Cause: CONFLICTING INSTRUCTIONS. Fix: remove contradiction; set one priority.
│
├─ Right content, unusable shape
│      └─► Cause: WRONG FORMAT ASK. Fix: specify exact format/length/schema.
│
├─ Drops parts of a multi-part ask
│      └─► Cause: OVERLOADED PROMPT. Fix: decompose into ordered steps (D1).
│
├─ Cut off mid-way
│      └─► Cause: TRUNCATION. Fix: continue, or request labelled sections.
│
├─ Used to be good, now drifting / forgetting / changing format
│      └─► Cause: CONTEXT BLOAT / DRIFT. Fix: re-anchor or summarise → new chat.
│
└─ Refuses a legitimate task
       └─► Cause: OVER-CAUTION. Fix: add legitimate context. (If truly disallowed → change the task.)

NEVER the first move: switch model · raise a setting · regenerate blindly · change many things at once.
```

:::tip[Exam signal]
Almost every D7 correct answer is "identify the cause and fix the prompt/context/conversation". Options that reach for a bigger model, a setting, or blind regeneration as the *first* move are distractors – they treat the symptom, not the cause.
:::

## 7.11 Optimisation trade-offs and guardrails

Optimising cost and speed is legitimate once quality is acceptable – but only on the *right* work. The exam tests whether you protect the quality that matters.

| Optimisation | Safe on… | Unsafe on… |
| --- | --- | --- |
| Downgrade the model | Routine, high-volume, low-stakes tasks | High-stakes analysis, regulated content |
| Turn off extended thinking | Simple lookups/rewrites | Complex multi-step reasoning |
| Remove/loosen a review gate | (never for high-stakes) | Irreversible, regulated, external outputs |
| Trim the prompt/context | Verbose, meandering exchanges | Where the trimmed detail was load-bearing |
| Right-size the output | Over-long responses | Where completeness is required |

**Before/after – an optimisation gone wrong, then corrected:**

```text
Before:  "To cut cost, move the legal-contract review to Haiku and drop the
         lawyer sign-off."
Problem: Under-buys quality on high-stakes work AND removes a required review
         gate — re-introduces the D3/D4 mistakes.
After:   "Keep the top-tier model and the lawyer sign-off for contracts; cut
         cost instead on the high-volume, low-stakes ticket-tagging by moving
         THAT to Haiku, verifying quality holds."
```

:::caution[Optimise routine work, protect high-stakes work]
Cost savings that remove quality or a review gate from high-stakes tasks are the wrong trade – always. Redirect optimisation to routine, high-volume, low-stakes work where the quality bar is lower.
:::

## 7.12 Common misconceptions

| Misconception | Reality | Why it matters on the exam |
| --- | --- | --- |
| "A bigger model fixes a bad result." | If the cause is ambiguity/format/context, the model is not the problem. | Model-as-fix distractor. |
| "Regenerating is troubleshooting." | It varies wording, not the underlying cause. | Blind-regeneration distractor. |
| "Change several things at once to fix it fast." | You cannot tell what worked or reproduce it. | One-variable-at-a-time item. |
| "A legitimate refusal is a bug to jailbreak." | If the task is disallowed, change the task, not the model behaviour. | Governance-boundary item. |
| "Retry the same oversized request after truncation." | It repeats the limit; continue or section it. | Truncation-handling item. |
| "Keep correcting the drifting giant chat." | Reset: summarise → new chat; persist recurring context. | Context-bloat item. |
| "Cheaper is always better." | Not on high-stakes work; protect quality and gates. | Optimisation-guardrail item. |
| "One good run proves the fix worked." | Verify before/after, across runs, per task type. | Measurement item. |

## 7.13 Scenario walkthrough – a status report that got worse over a long session

**Scenario.** An associate has spent two hours in one chat building a weekly ops status report. Early on it was excellent. Now Claude contradicts an earlier decision about which metrics to include, has quietly switched the table from four columns to three, invented a delivery figure, and dropped the "risks" section entirely. Under time pressure, the associate is about to switch to the most expensive model and paste the whole two-hour transcript into it.

**Expert reasoning trace.**

1. **Diagnose, do not escalate the model.** "Used to be good, now drifting/forgetting/changing format" is the signature of **context bloat / output drift**, not a model-capability gap. A bigger model with the same bloated context will drift too, so switching models (and pasting the whole transcript) is rejected.
2. **Separate the sub-problems.** There are four: a contradicted decision (drift), a format change (drift), an invented figure (fabrication), and a dropped section (completeness). Each has a targeted fix, but the common root is the polluted conversation.
3. **Reset the right way.** Ask Claude to summarise the confirmed decisions and current state, then start a **fresh chat** with that summary as a clean brief – this clears the bloat while keeping the conclusions.
4. **Re-anchor format explicitly.** In the clean chat, restate the exact four-column layout and, if needed, give one worked example so the format holds.
5. **Kill the fabrication at the source.** Anchor the report to the source data: "use only the attached metrics; if a figure is not stated, write 'not stated'." Verify the delivery figure against the source (D2).
6. **Restore completeness.** Include the "risks" section in the brief and check it against the required structure.
7. **Prevent recurrence.** Because this report is weekly and recurring, persist the instructions, format and data location in a **Project** (or capture the steps as a **Skill**) so next week starts from a clean, correct configuration (D5).

**Exam-correct decision:** summarise → start a fresh chat with a clean brief, re-anchor the exact format, ground the figures to the source, restore the missing section, and persist the setup to a Project. **Not** a bigger model, **not** pasting the whole transcript, **not** endless in-place corrections.

---

## Exam traps in this domain

| Trap | Why it is wrong |
| --- | --- |
| "Switch to a bigger model to fix a vague prompt" | The prompt is the cause; a bigger model still lacks context/format |
| "Change several things at once until it works" | You learn nothing; change one variable at a time |
| "Regenerate repeatedly hoping for a better result" | Blind regeneration is not debugging; fix the identified cause |
| "Jailbreak around a legitimate refusal" | If the task is disallowed, change the task, not the model behaviour |
| "Keep one giant chat and keep correcting it" | Context bloat/drift; summarise and reset to a clean brief |
| "Retry the same oversized request after truncation" | Decompose into parts or ask to continue; retrying repeats the limit |
| "Downgrade the model on high-stakes work to save money" | Under-buys quality where mistakes are costly |
| "Trust that a fix worked without measuring" | Verify before/after and across runs, per task type |
| "Paste the whole long transcript into a bigger model" | Carries the bloat forward; summarise state and start a clean chat instead |
| "A format that keeps changing needs more description" | Provide one worked example (few-shot); re-anchor or reset if drift persists |
| "Fabricated figures in a long chat mean upgrade the model" | Anchor to the source and verify; the cause is grounding/drift, not tier |
| "Cheaper is always the better optimisation" | Protect quality and review gates on high-stakes work; optimise routine work |

---

## Practice questions

Each item states how many responses to select. Attempt before revealing.

<Accordions>
  <AccordionItem title="Q1 · A prompt returns a generic, off-target answer. Before anything else, what should the user do? (Select one)">
    A. Switch to the most expensive model.
    B. Identify the cause — likely ambiguity or missing context — and fix that specific issue in the prompt.
    C. Regenerate five times.
    D. Turn on extended thinking.

    **Answer: B.** Diagnosis precedes action: match the symptom (generic/off-target) to its cause (ambiguity/missing context) and fix it. A bigger model (A) does not add the missing context; regenerating (C) varies wording, not relevance; thinking (D) does not fix a vague ask.
  </AccordionItem>

  <AccordionItem title="Q2 · A user changes the model, rewrites the prompt, raises the length, and regenerates all at once — and the output improves. What is the PROBLEM with this approach? (Select one)">
    A. Nothing; it worked.
    B. Changing multiple variables at once means the user cannot tell what actually fixed it or reproduce it reliably.
    C. It used too little compute.
    D. It should have used a cheaper model.

    **Answer: B.** Systematic debugging changes one variable at a time so the effective fix is identifiable and repeatable. 'It worked' (A) ignores reproducibility; compute (C) and model cost (D) are not the issue.
  </AccordionItem>

  <AccordionItem title="Q3 · Claude's output is repeatedly cut off before it finishes a long report. What are the TWO BEST responses? (Select two)">
    A. Ask Claude to continue from where it stopped.
    B. Request the report in labelled sections and assemble them.
    C. Keep retrying the same single oversized request.
    D. Switch to a cheaper model.
    E. Turn off extended thinking.

    **Answer: A and B.** Truncation is handled by continuing or by breaking the deliverable into sections. Retrying the same oversized request (C) repeats the limit; model tier (D) and thinking (E) do not address output length.
  </AccordionItem>

  <AccordionItem title="Q4 · A two-hour chat has covered several topics and Claude now contradicts earlier decisions and ignores the agreed format. What is the BEST fix? (Select one)">
    A. Keep correcting it in the same chat.
    B. Ask Claude to summarise the decisions, then start a fresh chat with that summary as a clean brief.
    C. Switch to a bigger model.
    D. Turn on extended thinking.

    **Answer: B.** This is context bloat/output drift; the cure is to capture state and reset to a clean context. Continuing to correct (A) fights the bloat; model tier (C) and thinking (D) do not clear a polluted context.
  </AccordionItem>

  <AccordionItem title="Q5 · Claude over-cautiously refuses to help edit the company's OWN internal document, apparently unsure it is legitimate. What is the BEST response? (Select one)">
    A. Try many rephrasings to force compliance.
    B. Clarify the legitimate context — that it is the user's own internal document for internal use — and restate the task clearly.
    C. Escalate to compliance immediately.
    D. Give up.

    **Answer: B.** Over-caution on a legitimate task is usually fixed by adding context that establishes legitimacy. Forcing compliance via rephrasings (A) is inappropriate for genuinely disallowed tasks and unnecessary here; escalation (C) is premature; giving up (D) is wasteful.
  </AccordionItem>

  <AccordionItem title="Q6 · A team runs a simple, high-volume classification task on Opus 5 and wants to cut cost. What is the BEST optimisation? (Select one)">
    A. Keep Opus 5; it is safest.
    B. Downgrade to Haiku (or Sonnet), verifying quality holds for this routine task.
    C. Turn on extended thinking to be thorough.
    D. Add more instructions.

    **Answer: B.** Routine, high-volume work should run on the cheapest model that maintains quality; downgrade and verify. Keeping Opus (A) over-buys; extended thinking (C) adds cost for no benefit here; more instructions (D) do not reduce cost.
  </AccordionItem>

  <AccordionItem title="Q7 · An Associate wants to reduce cost on a HIGH-STAKES legal analysis by moving it to Haiku and dropping human review. What is wrong? (Select one)">
    A. Nothing; cost savings are always good.
    B. This under-buys quality and removes a required review gate on high-stakes work — the wrong trade-off.
    C. Haiku is too expensive.
    D. Extended thinking should be off.

    **Answer: B.** Optimisation must not sacrifice quality/review where stakes are high; that re-introduces under-buying and removes a needed gate. Cost savings are not always good (A); Haiku is the cheap option, not expensive (C); thinking settings (D) are not the core issue.
  </AccordionItem>

  <AccordionItem title="Q8 · A prompt contains two contradictory instructions ('be extremely detailed' and 'answer in one sentence'). What is the symptom and fix? (Select one)">
    A. Missing context; add a document.
    B. Conflicting instructions; remove the contradiction and state a single clear priority.
    C. Wrong model; upgrade.
    D. Truncation; ask to continue.

    **Answer: B.** Contradictory instructions confuse the output; resolve the conflict and set one priority. It is not missing context (A), a model issue (C) or truncation (D).
  </AccordionItem>

  <AccordionItem title="Q9 · How can a user BEST confirm that a prompt fix actually improved results? (Select one)">
    A. Trust that it feels better.
    B. Compare before/after on the same task and check the fix holds across several runs and task types.
    C. Assume one good run proves it.
    D. Only check the overall satisfaction score.

    **Answer: B.** Measuring improvement means before/after comparison, consistency across runs, and per-task-type checks. Feelings (A), a single run (C) and aggregate-only satisfaction (D) can mislead.
  </AccordionItem>

  <AccordionItem title="Q10 · Claude keeps drifting away from the agreed table format halfway through a long working session. What are the TWO BEST corrective actions? (Select two)">
    A. Restate the exact format and provide one worked example.
    B. If drift persists, reset with a clean, consolidated brief.
    C. Switch to a cheaper model.
    D. Ignore it; format does not matter.
    E. Turn on extended thinking.

    **Answer: A and B.** Re-anchoring with an explicit format and example corrects drift; a reset fixes it when the context is too polluted. Model tier (C) and thinking (E) do not address drift; ignoring format (D) accepts the defect.
  </AccordionItem>

  <AccordionItem title="Q11 · A prompt bundles five deliverables and consistently drops two of them. What is the cause and fix? (Select one)">
    A. Truncation; raise the length.
    B. Overloaded prompt; decompose into ordered steps and verify each.
    C. Refusal; add context.
    D. Wrong model; upgrade.

    **Answer: B.** Dropping parts of a bundled ask is the overloaded-prompt pattern; decomposition fixes it. It is not truncation of a single output (A), a refusal (C) or a model issue (D).
  </AccordionItem>

  <AccordionItem title="Q12 · A user hits the input size limit pasting a very large document repeatedly. What is the BEST durable fix? (Select one)">
    A. Keep retrying the paste.
    B. Supply only the relevant portion, or store the document in a Project's knowledge so chats can draw on it without re-pasting.
    C. Switch to extended thinking.
    D. Use a cheaper model.

    **Answer: B.** Oversized recurring input is best handled by using only the relevant part or persisting the document in a Project. Retrying (A) repeats the limit; thinking (C) and model tier (D) do not solve input size.
  </AccordionItem>

  <AccordionItem title="Q13 · Which sequence reflects a SYSTEMATIC prompt-debugging loop? (Select one)">
    A. Change everything, ship it, move on.
    B. Reproduce the issue, isolate the cause, change one thing, re-run and compare, then lock in the fix.
    C. Regenerate until it looks fine.
    D. Escalate to Developers immediately.

    **Answer: B.** The disciplined loop is reproduce → isolate → change one variable → compare → lock in. Changing everything (A) and regenerating blindly (C) are not systematic; immediate escalation (D) skips diagnosis.
  </AccordionItem>

  <AccordionItem title="Q14 · A weekly report chat, excellent two hours ago, now contradicts an earlier decision, changed the table format, invented a figure, and dropped a section. What is the BEST FIRST action? (Select one)">
    A. Switch to the most expensive model and paste the whole transcript in.
    B. Ask Claude to summarise the confirmed decisions and state, then start a fresh chat with that summary as a clean brief.
    C. Keep correcting each issue in the same chat.
    D. Turn on extended thinking.

    **Answer: B.** These are context-bloat/drift symptoms; the cure is to capture state and reset to a clean context. A bigger model with the pasted transcript (A) carries the bloat forward; in-place correction (C) fights the bloat; thinking (D) does not clear it.
  </AccordionItem>

  <AccordionItem title="Q15 · To cut cost, a colleague proposes moving legal-contract review to Haiku AND dropping the lawyer sign-off, while leaving high-volume ticket-tagging on Opus. What is the BEST correction? (Select one)">
    A. Approve it; cheaper is always better.
    B. Keep the top model and lawyer sign-off for contracts (high-stakes), and instead move the routine ticket-tagging to Haiku, verifying quality holds.
    C. Move both to Haiku.
    D. Move both to Opus.

    **Answer: B.** Protect quality and the review gate on high-stakes contract work; redirect optimisation to the routine, high-volume tagging. Cheaper-is-always-better (A, C) under-buys and removes a gate on high-stakes work; Opus for tagging (D) over-buys.
  </AccordionItem>

  <AccordionItem title="Q16 · Claude's long report is repeatedly truncated. Which TWO responses are BEST? (Select two)">
    A. Ask Claude to continue from where it stopped.
    B. Request the report in labelled sections and assemble them.
    C. Retry the same oversized single request.
    D. Switch to a cheaper model.
    E. Turn off extended thinking.

    **Answer: A and B.** Truncation is handled by continuing or by sectioning the deliverable. Retrying the same oversized request (C) repeats the limit; model tier (D) and thinking (E) do not address output length.
  </AccordionItem>

  <AccordionItem title="Q17 · A prompt contains two contradictory instructions ('include every detail' and 'answer in one sentence') and the output is confused. What is the cause and fix? (Select one)">
    A. Missing context; attach a document.
    B. Conflicting instructions; remove the contradiction and state a single clear priority.
    C. Truncation; ask to continue.
    D. Wrong model; upgrade.

    **Answer: B.** Contradictory instructions confuse the output; resolve the conflict and set one priority. It is not missing context (A), truncation (C) or a model issue (D).
  </AccordionItem>

  <AccordionItem title="Q18 · Claude over-cautiously refuses to help edit the company's own internal onboarding doc, unsure it is legitimate. What is the BEST response? (Select one)">
    A. Try many rephrasings to force compliance.
    B. Clarify the legitimate context — the user's own internal document for internal use — and restate the task clearly.
    C. Escalate to compliance immediately.
    D. Give up on the task.

    **Answer: B.** Over-caution on a legitimate task is usually fixed by adding context that establishes legitimacy. Forcing compliance via rephrasings (A) is inappropriate and unnecessary here; escalation (C) is premature; giving up (D) is wasteful.
  </AccordionItem>

  <AccordionItem title="Q19 · Claude keeps drifting from the agreed four-column table format midway through a long working session. Which TWO corrective actions are BEST? (Select two)">
    A. Restate the exact four-column format and provide one worked example.
    B. If drift persists, reset with a clean, consolidated brief.
    C. Switch to a cheaper model.
    D. Ignore it; format does not matter.
    E. Turn on extended thinking.

    **Answer: A and B.** Re-anchoring with an explicit format and an example corrects drift; a reset fixes it when the context is too polluted. Model tier (C) and thinking (E) do not address drift; ignoring format (D) accepts the defect.
  </AccordionItem>

  <AccordionItem title="Q20 · An associate applied a prompt fix and one run looked great, so they declared success. What is the FLAW and the better practice? (Select one)">
    A. No flaw; one good run is enough.
    B. A single run is not proof; compare before/after on the same task and confirm the fix holds across several runs and task types.
    C. They should only track overall satisfaction.
    D. They should switch models to be sure.

    **Answer: B.** Measuring improvement means before/after comparison, consistency across runs, and per-task-type checks — not a single lucky run. One run (A) can mislead; aggregate-only satisfaction (C) hides segment failures; switching models (D) does not validate the fix.
  </AccordionItem>
</Accordions>

## Key takeaways

- Diagnose before you change: most poor outputs are ambiguity, missing context, conflicting instructions, wrong format, or an overloaded prompt.
- Debug systematically – reproduce, isolate, change one variable, compare, lock in.
- Fix defects with targeted adjustments, not blind regeneration or model swaps.
- Respect legitimate refusals; fix over-caution by adding legitimate context – never jailbreak a disallowed task.
- Handle truncation by continuing or sectioning; handle oversize input by trimming or using a Project.
- Reset bloated, drifting chats: summarise, then start fresh; persist recurring context to a Project.
- Optimise cost/speed on routine work (downgrade model, trim prompts, reuse via Projects/Skills) but protect high-stakes quality and review.
- Verify improvements with before/after and per-task-type measurement.
- Route symptoms through the troubleshooting tree; a bigger model/setting/blind regeneration is never the correct first move.
- Never paste a whole bloated transcript into a bigger model – summarise state and reset instead.
- Optimisation must never strip quality or a review gate from high-stakes work; redirect it to routine tasks.