Debugging and iterating prompts

The task

A prompt works sometimes, fails on edge cases, or produces the wrong kind of answer. You need a repair path that shows what changed and why. The underlying method is prompt iteration: isolate one failure, change one variable, and compare against the same case.

Why the old approach is outdated

The common fix is to add more instructions. That can work for one failure and make the prompt worse everywhere else.

Treat prompt repair like debugging. Name the observed failure before changing the prompt.

The current approach

Debug this prompt.

Current prompt:
{{prompt}}

Bad output:
{{bad_output}}

Expected behavior:
{{expected_behavior}}

Identify the likely failure mode, then propose the smallest prompt change that would
address it. Do not rewrite the whole prompt unless the structure is the failure.

When to use a different model

Use Claude when the prompt is long or voice-sensitive. Use Gemini when failures involve image or document inputs. Use the same model that produced the failure when you need a fair before-and-after comparison.

What to avoid

• Changing the model, examples, output shape, and task wording at once.
• Treating one bad run as the whole diagnosis.
• Asking the model to grade its own prompt with a numeric score.
• Keeping vague instructions because they sound impressive.