Prompt Debugging Reasoning Pattern Transfer Prompt

This prompt is for prompt engineers and AI reliability teams who need to diagnose why a prompt is failing in production. Instead of writing lengthy debugging instructions, you provide 3-5 worked examples that demonstrate the systematic diagnosis pattern: observe the failure, isolate the conflicting instructions, generate a root cause hypothesis, construct a minimal test case, and propose a concrete fix. The model learns the reasoning pattern from the examples and applies it to new failure reports. Use this when you have a library of known failure cases and want to scale debugging throughput.

The ideal workflow pairs this prompt with a failure report template that captures the original prompt text, the problematic output, the expected output, and any relevant context about the model version and parameters. Your worked examples should cover common failure categories: instruction conflicts where two constraints collide, format drift where the output schema degrades over long generations, over-refusal where safety instructions block legitimate requests, hallucination patterns where the model invents plausible but incorrect details, and context blindness where the model ignores critical instructions buried in long prompts. Each example must demonstrate the full diagnosis chain, not just the fix, so the model internalizes the reasoning process rather than memorizing patch patterns.

Do not use this prompt for live user-facing responses or when the failure report itself contains sensitive production data that should not leave your environment. The prompt is designed for offline debugging sessions where you control the examples and can review the model's diagnosis before applying any fixes. For high-risk domains like healthcare or finance, always require human review of the generated root cause hypothesis and proposed fix before modifying production prompts. Pair this with regression tests from your golden dataset to verify that the fix resolves the reported failure without introducing new regressions. If you lack a library of well-documented failure cases, invest in building that library first—the pattern transfer is only as good as the examples you provide.

This template transfers a structured debugging reasoning pattern to the model by providing worked examples of prompt failure analysis. Instead of describing how to debug, you show the model diagnosing a failure, forming hypotheses, constructing test cases, and proposing fixes. The model then applies this same reasoning pattern to a new, unseen prompt failure. Replace every square-bracket placeholder before use. The [FAILURE_EXAMPLES] teach the diagnosis pattern; [NEW_FAILURE] is the prompt and output you need analyzed now.

textCopy
You are a prompt debugging analyst. Your job is to diagnose why a prompt produced a bad output and recommend fixes.

Follow this reasoning pattern for every analysis:
1. Identify the specific failure: what did the prompt produce that was wrong?
2. List possible root causes, ranked by likelihood.
3. For each likely cause, construct a minimal test case that would isolate it.
4. Propose concrete prompt changes with before/after diffs.
5. Flag any instruction conflicts or ambiguous constraints that contributed.

Here are examples of this reasoning pattern applied to real prompt failures:

[FAILURE_EXAMPLES]

---

Now analyze this new failure using the same reasoning pattern:

**Prompt that failed:**
[NEW_FAILURE_PROMPT]

**Input given to the prompt:**
[NEW_FAILURE_INPUT]

**Actual output (the failure):**
[NEW_FAILURE_OUTPUT]

**Expected behavior:**
[EXPECTED_BEHAVIOR]

**Constraints to consider:**
[CONSTRAINTS]

Provide your analysis following the 5-step reasoning pattern above.

How to adapt this template: The [FAILURE_EXAMPLES] section is where you invest the most effort. Include 2-4 worked examples that demonstrate the full 5-step reasoning pattern on failures similar to what you expect in production. Each example should show a real-looking prompt, its bad output, and a thorough diagnosis. Vary the failure types across examples: include instruction conflicts, ambiguous constraints, missing edge-case handling, and format drift. The [NEW_FAILURE] placeholders accept the actual prompt text, input, output, and expected behavior you need diagnosed. For high-risk production systems, add a [RISK_LEVEL] field and require human review of the diagnosis before applying suggested fixes. If your prompts use structured output, include the expected schema in [CONSTRAINTS] so the model can detect format violations. Test this template by feeding it known failures where you already understand the root cause, then compare the model's diagnosis against your ground truth.

This prompt is designed to be called programmatically as part of an automated prompt evaluation and debugging pipeline, not as a one-off chat interaction. The harness should treat the prompt as a diagnostic function: it receives a failing prompt, a set of test cases (passing and failing), and the model's raw outputs, and it returns a structured diagnosis. The primary integration point is a CI/CD step that runs after an eval regression is detected, or a manual debugging tool used by prompt engineers. The harness must enforce a strict input contract because the quality of the diagnosis depends entirely on the completeness of the failure evidence provided.

Input Assembly: The harness must collect three critical inputs before calling the model. First, the full text of the [TARGET_PROMPT] that is failing. Second, a [TEST_CASES] array where each object contains an input, the expected_output, the actual_output, and a pass/fail boolean. Third, any [SYSTEM_INSTRUCTIONS] or tool definitions that wrap the target prompt. These must be serialized into the placeholders, preferably as a structured JSON block within the prompt to avoid parsing ambiguity. Model Choice: Use a model with strong reasoning capabilities (e.g., Claude 3.5 Sonnet, GPT-4o) for the diagnosis step, even if the target prompt runs on a smaller model. The diagnostic model needs to be smarter than the system it's debugging. Validation: Before calling the prompt, validate that the [TEST_CASES] array contains at least one failing case and one passing case; a diagnosis based solely on failures is prone to overfitting. The harness should reject the request if this condition is not met.

Output Handling and Retries: The prompt returns a structured JSON object with root_cause_hypotheses, test_cases_to_add, and fix_suggestions. The harness must validate this JSON against a strict schema. If parsing fails, implement a single retry with a stronger instruction to output only valid JSON. Do not loop indefinitely. Logging and Versioning: Log the full prompt, the diagnosis, and the target prompt's version hash to an observability store. This creates an audit trail that links a specific prompt version to its diagnosed failure modes. Human Review Gate: The fix_suggestions array is a starting point, not a direct patch. The harness should surface these suggestions in a review interface where a prompt engineer can accept, reject, or modify them. Automatically applying model-generated prompt fixes is high-risk and can introduce subtle regressions. The next step is to feed the accepted fixes into a prompt versioning system and re-run the full eval suite to confirm the fix resolves the failure without breaking passing cases.