What this prompt does
This prompt designs an AI-powered error diagnosis workflow for a [application_type] running on [runtime_environment], handling [request_volume] and instrumented with [logging_stack]. It defines a six-stage process that takes a raw failure and drives it to a root cause, ranked fixes, and a regression test — built around structured intake rather than ad hoc prompting.
The structure works because it gives the model the right context in a parseable block. The intake template pairs the stack trace with the 50 lines of surrounding code, recent git changes to that file, and the request payload, so the AI can reason about cause instead of guessing. Root-cause analysis classifies the failure into your [error_categories] and traces execution backward to the earliest point the bug entered. A related-errors finder scans [log_source] over a [lookback_period] to tell a regression from a new or intermittent bug. The fix step returns three ranked options — hotfix, proper fix with tests, and a preventive guardrail — and a generator produces a failing test that reproduces the issue before the fix lands.
When to use it
- You are triaging a production incident and need structured root-cause analysis fast.
- You want to know whether an error is a regression, a new bug, or intermittent.
- You need three fix options — quick, proper, and preventive — rather than one.
- You want a regression test that reproduces the bug before you ship the fix.
- Your team needs a consistent intake format for
[error_categories]failures. - You produce incident reports for an audience like
[incident_audience].
Example output
Expect a workflow with reusable prompt templates: a structured intake block combining stack trace, surrounding code, git history, and payload; a root-cause analysis that classifies into [error_categories] and traces backward to the origin; a related-errors summary grouped by frequency from [log_source]; three ranked fix proposals; a failing-then-passing regression test; and an incident report formatted for [incident_audience].
Pro tips
- Give the intake step real context — the surrounding code and recent git changes are what move it from guessing to diagnosing.
- Tailor
[error_categories]to your stack so the classification step lands on categories you actually triage against. - Use the related-errors step before fixing; knowing it is a regression versus a new bug changes the fix you choose.
- Treat the three-tier fix as a menu — ship the hotfix under pressure, but schedule the guardrail so the class of error stops recurring.
- Always run the generated regression test in its failing state first; a test that passes before the fix is not reproducing the bug.
- Set
[lookback_period]to match how far back your logs stay queryable, or the pattern search returns nothing useful.
