When the output fails, check the prompt first

The weekly sales summaries come out so long that the regional managers have stopped reading them. The team’s first reaction: “let’s switch to the most capable model, it’ll know what length is right.” The prompt never said what length or structure the managers expected.

Troubleshooting a poor output almost always starts with the request, not the model.

First, read the prompt as if you were Claude

When an output is weak, check:

• Does it say who it’s for and what it’s for? If not, the output will be generic.
• Does it say how it should come out? “Five bullets that open with results against target and risks” fixes the length; “be concise” barely changes anything.
• Does it say what to do when information is missing? If not, Claude fills the gaps.
• Are there rules that contradict each other?

The prompt that “used to work and stopped”

A prompt for labelling the urgency of supplier emails worked well for months. Now it labels similar cases differently. The temptation is to think the model changed. Something else is more likely: the prompt grew through additions (“always urgent if it mentions an invoice,” months later “urgent only if it’s due in less than 7 days”) and now has conflicting instructions. For a case that meets one rule and not the other, any answer is “correct.”

Before blaming the model:

1. Read the whole prompt and look for rules that clash or overlap.
2. Resolve each conflict with a single clear rule (and its reason).
3. Test the new version on a fixed set of emails you already know.

One change at a time

An assistant changed two things at once in her meeting-minutes prompt: the format and the instruction about deadlines. Some minutes improved and others started leaving out due dates. She has no way of knowing which change caused what.

The rule is one change at a time, tested on the same test cases:

• build a fixed set of real examples, including the hard ones;
• change one thing only;
• compare against the previous version using those same examples;
• keep what improves and drop what gets worse.

Situation	What to do
Output too long or generic	Specify length, structure and audience
Old prompt that became inconsistent	Find and resolve conflicting rules, test on fixed cases
A change that improved some things and worsened others	Separate the changes and test each one on its own
Complaints from the people who use the output	Ask for concrete examples and turn them into prompt requirements

Listen to whoever uses the output

The most useful feedback comes from whoever receives the result, not whoever writes the prompt. If the e-commerce team rejects the product descriptions, ask them for examples of the ones they accepted and the ones they rejected, and turn that into concrete instructions.

Common traps

• Switching to the biggest model without touching the prompt.
• Adding “be concise” or a rule in capitals.
• Rewriting everything from scratch over a weekend and using it straight away on every case.
• Changing the prompt, the model and the template at the same time.
• Asking Claude which of the changes caused the problem.
• Adding more examples without resolving the rules that contradict each other.

On the exam

If the scenario describes a poor output or a prompt that became inconsistent, look for the option that tackles the cause in the prompt (a concrete criterion, contradictions resolved) and tests on a fixed set of cases. If changes were mixed together, the answer is to separate them and test each one. Rule out “switch models,” “more emphasis,” “start over all at once” and “let Claude diagnose itself.”