What this prompt does
This prompt runs a disciplined debugging loop on a prompt that is misbehaving, rather than rewriting it from scratch. You paste the [broken_prompt], describe the [failure_type], and supply real [failure_examples], and the model classifies the failure (ambiguity, conflicting instructions, missing constraints, hallucination trigger, or format drift), isolates the exact instruction causing it, applies a targeted fix, and adds regression guards. It also generates [test_count] test cases aimed at that specific failure mode and produces before/after prompts with each change explained.
The structure works because it treats prompt failures like code bugs: classify, isolate, fix the one thing, verify nothing else broke. Supplying concrete [failure_examples] is what makes the diagnosis grounded instead of speculative — the model has actual bad outputs to reason backward from. Naming the [model] matters because instruction-ordering effects and format drift behave differently across models, and the prompt explicitly checks ordering since LLMs weight later instructions differently. The [failure_type] you supply steers the classification step: a precise label like "inconsistent format" narrows the search faster than a generic complaint, and the [test_count] you choose decides how thorough the regression net becomes.
When to use it
- A prompt that used to work has started drifting or adding unwanted commentary
- Outputs are inconsistent — sometimes correct, sometimes off-format
- You suspect hallucination but want to find the triggering instruction first
- You need regression tests so a fixed failure mode does not silently return
- You want a minimal, surgical fix instead of a risky full rewrite
- You need to document the root cause for a team knowledge base
Example output
Expect a structured diagnosis: a classified failure type, the specific offending section called out, a targeted edit, and a side-by-side before/after of the prompt with each change justified. It includes [test_count] regression test cases written to catch that exact failure, plus a short monitoring recommendation so you can detect recurrence. The emphasis is on a small diff, not a rewritten prompt, and it documents the root cause so the fix becomes reusable team knowledge rather than a one-off patch.
Pro tips
- Paste 2–3 real
[failure_examples]— the more representative the bad outputs, the sharper the root-cause analysis - Be precise in
[failure_type]; "inconsistent format, sometimes adds extra commentary" beats a vague "it's bad" - Keep
[broken_prompt]complete and unedited so the model can see ordering effects it might otherwise miss - Set
[model]to the one actually in production, since fixes that work on one model can drift on another - Resist the urge to over-fix; the prompt is designed for a targeted change, so verify the suggested edit before adding more
- Use the generated
[test_count]cases as a permanent regression suite, not a one-time check
