Domain 7: Troubleshooting and Optimization
10% of examDiagnose underperforming prompts and outputs
Key Points
- Classify the specific symptom before fixing: generic/off-target -> under-specified prompt; wrong format -> unstated format; confidently wrong facts/fake citations -> hallucination; quality drops late in a long chat -> crowded context window; overkill cost/latency or too shallow -> model mismatch; missed part of a complex ask -> no decomposition.
- Each symptom has one matching fix -- add specifics/an example, specify format, ground + require citations + allow 'I don't know,' summarize/restart/persist, right-size the model, decompose into steps.
- A hallucination is fixed by grounding and verifiable citations, never by tone, confidence instructions, or a shorter prompt.
- Late-conversation quality drops point to context crowding, not a weaker model -- the fix is summarize/restart/persist, not downsizing the model or adding prohibitions.
- Reaching for a bigger/pricier model is a common wrong first move when the real problem is a vague prompt or crowded context.
Decision Rules
When: Output is generic, vague, or off-target
→Add audience, format, constraints, and an example -- don't just regenerate.
When: Claude states confidently wrong facts or a fabricated citation
→Ground the answer in source material and require verifiable citations, allowing 'I don't know.'
When: Quality drops only near the end of a long conversation
→Summarize, restart, or persist key context in a Project -- not switch platforms or shrink the model.
When: A complex, multi-part ask comes back missing a piece
→Decompose it into ordered, checkable steps rather than re-asking the same way.
✗ Anti-Patterns to Reject
- Regenerating repeatedly without changing anything.
- Reaching for a bigger/more expensive model when the real problem is a vague prompt or a crowded context window.
Adjust approach based on feedback and results
Key Points
- Treat troubleshooting as iterative and evidence-driven: read the result against intent, change one variable, re-run and compare.
- One-variable-at-a-time is what makes a fix diagnosable -- change five things and you can't attribute the improvement (or regression) to any one of them.
- The output itself is feedback about what's missing -- use that signal rather than guessing at an unrelated change.
- Fold recurring lessons into standard prompts and Project instructions so future similar tasks start from the improved baseline.
Decision Rules
When: A fix attempt didn't clearly help
→Check whether more than one variable changed between attempts, which would make the result undiagnosable.
When: A pattern of the same fix recurs across several tasks
→Standardize it into a reusable prompt or Project instruction rather than re-diagnosing each time.
When: Deciding what to change next
→Read what the output itself signals is missing before guessing at an unrelated change.
✗ Anti-Patterns to Reject
- Changing many variables at once to save time.
- Ignoring the feedback the output itself gives about what's missing.
Optimize workflows for efficiency and effectiveness
Key Points
- Five levers for a repeated workflow: right-size the model per step, persist reusable context in a Project, standardize proven prompts as templates/instructions, calibrate human review to stakes, decompose long tasks into checkable steps.
- These are workflow-level, standing design choices meant to pay off on every future run -- not one-time corrections for a single bad output.
- Genuine optimization balances cost, speed, and quality against the task's real requirements; it doesn't maximize one lever in isolation.
- Removing human review on high-stakes output to save time is a governance/quality risk, not an optimization -- calibrate review, don't eliminate it.
Decision Rules
When: A workflow runs the same steps repeatedly
→Right-size the model per step, persist context in a Project, and standardize the proven prompt as a template.
When: Proposing to cut review time on a high-stakes step to speed things up
→Recognize that as a governance/quality risk, not a valid optimization -- calibrate instead of removing.
When: Evaluating whether a workflow change is a genuine optimization
→Check it against cost, speed, and quality together, not just the one metric it improves.
✗ Anti-Patterns to Reject
- Optimizing only for cost or only for speed while quality drops below what the task needs.
- Treating 'remove human review to go faster' as a legitimate efficiency gain.