Debugging Prompts for Reproducible Diagnosis

This reviewed prompt collection is for developers, learners, and technical support teams. It favors diagnosis and evidence gathering over immediate code replacement.

When to use these prompts#

Use this page when you need diagnostic prompts that collect reproducible inputs, expected versus actual behavior, environment, logs, and constraints before proposing ranked hypotheses and tests. Replace every bracketed variable with verified, non-sensitive information before using a template in your own AI product.

Inputs to prepare#

• exact error text and stack trace
• language, versions, operating system, and environment
• minimal reproducible code or configuration
• steps that trigger the issue
• expected versus actual behavior
• recent changes and attempted fixes
• relevant logs, inputs, and data shape
• security, uptime, and change constraints

Draft prompt templates#

1. Debugging intake and missing questions#

Purpose: Improve the problem report before proposing a fix.

Act as a debugging facilitator for [SYSTEM]. Review this report: [REPORT]. First ask only the highest-value missing questions needed for reproduction, grouped by environment, input, timing, state, and recent changes. Then restate the issue as expected behavior, actual behavior, reliable steps, and unknowns. Do not propose a fix until the reproduction gaps are visible.

Before use, remove irrelevant fields, replace every placeholder, and verify that the requested judgment can be supported by the material you supplied.

2. Ranked hypothesis and experiment plan#

Purpose: Test likely causes one at a time.

Given [MINIMAL REPRODUCTION], [ERROR], [ENVIRONMENT], and [RECENT CHANGES], produce ranked hypotheses. For each include supporting evidence, contradictory evidence, a low-risk diagnostic test, expected observation if true, and rollback step. Prefer tests that isolate one variable. Do not modify production data or recommend destructive commands.

Before use, remove irrelevant fields, replace every placeholder, and verify that the requested judgment can be supported by the material you supplied.

3. Explain a verified fix#

Purpose: Document why a confirmed change resolves the issue.

The verified cause is [CAUSE], demonstrated by [EVIDENCE], and the working change is [FIX]. Explain the failure mechanism, why the fix works, possible side effects, regression tests, and monitoring. Distinguish confirmed facts from remaining uncertainty. Do not introduce unrelated refactoring.

Before use, remove irrelevant fields, replace every placeholder, and verify that the requested judgment can be supported by the material you supplied.

Why the structure matters#

Premature fixes hide the conditions that produced a bug. These prompts make reproduction, environment, evidence, and reversible experiments the core of the workflow before a patch is proposed.

Weak prompt and what it misses#

My app crashes. What is wrong? Give me the fixed code.

There is no error, reproduction, environment, expected behavior, or code. Any answer will be guesswork, and replacement code may create new failures or security problems.

Human review checklist#

• Redact secrets, personal data, production URLs, and proprietary code.
• Reproduce the issue in a safe environment before changing production.
• Run one diagnostic experiment at a time and record the result.
• Verify version-specific advice in official documentation.
• Add a regression test after the cause is confirmed.

Testing and maintenance#

1. Use original, non-sensitive sample values when testing a prompt.
2. Retest examples after material changes to the prompt, page, or AI product.
3. Check factual preservation, requested format, missing-data behavior, and task-specific risks.
4. Update the visible test date when a material retest is completed.
5. Keep the site operator responsible for the final human review.

A dated operator attestation is sufficient for the site's internal publication check; full chat transcripts are not retained or published.