Diagnose an error

Get a root cause and the smallest fix, with the exact triggering input named — not a lecture on error handling.

When to use it

A bug where the stack trace is not the whole story — an environment difference, an edge-case input, something that passes locally and fails in production.

What it prevents

The plausible wrong answer. Given an error, a model will confidently propose a cause and a broad fix — often a rewrite that “improves error handling” without addressing the actual bug. Asking for the specific triggering input and the smallest patch keeps the diagnosis honest and the change reviewable.

The prompt

Find the root cause of the error below and propose the smallest fix.

### Context
Node.js service in TypeScript. The stack trace points at a date-parsing helper that passes local tests and fails only in production, where the timezone is UTC.

### Requirements
- Output format: Three short sections — likely cause, the one-line reason, and the minimal patch as a code block.
- Name the specific input that triggers the failure, not a category of inputs.
- Do not rewrite the function; propose the smallest change that fixes the reported case.
- Avoid: speculation you cannot support from the trace, and unrelated style fixes.

### Error
"""
RangeError: Invalid time value
  at formatDueDate (dates.ts:14)
"""

Why each part is there

Every section of that prompt exists because a specific failure happens without it. These are the checks it passes, and what each one is protecting you from:

• States a concrete task — why this matters
• Avoids vague language — why this matters
• Specifies an output format — why this matters
• Gives context or audience — why this matters
• Avoids dangling references — why this matters
• Avoids over-aggressive phrasing — why this matters
• Defines what a good answer looks like — why this matters

How to adapt this one

Paste the real trace and, critically, the environment detail that the trace does not show — the timezone, the locale, the version, the input that differs. That context is the whole diagnosis; a model reasoning only from the trace is guessing. Keep “name the specific input” and “smallest fix”, which together stop the model from turning a one-line bug into a refactor.

The mistake this prompt avoids

Accepting the first confident cause. Models are fluent at post-hoc explanation and will justify a wrong diagnosis as smoothly as a right one. Make it name the exact input that reproduces the failure — a cause that cannot produce a concrete failing input is a hypothesis, not a diagnosis, and treating it as fact is how you “fix” the wrong thing.

A variation

Faced with an intermittent bug rather than a reproducible one? Ask for a ranked list of candidate causes with the specific observation that would confirm or rule out each, instead of a single fix. Flaky failures are rarely diagnosable from one trace; what you need is a differential — the next thing to check — not a confident answer built on too little evidence.

Check your version

Once you have adapted it, run it through the checker. The same nine checks that graded this page will grade yours, free and in your browser — paste it in, or build one from scratch by answering a few questions.