title: Root Cause Analysis

description: Systematically find the true root cause of a bug, not just a symptom.

content:
I have this bug: {{symptom}}

Help me find the root cause, not just a patch. Work through it:
1. Restate the expected vs. actual behavior precisely.
2. List the most likely hypotheses, ordered by probability.
3. For each, name the single cheapest observation that would confirm or rule it out.
4. Tell me exactly what to inspect, log, or run next.

Do not propose a fix until we've isolated the cause. Ask for any log, stack trace, or code you need.

symptom

description: What's going wrong


title: Explain This Error

description: Decode a stack trace or error message and pinpoint the fix.

content:
Explain this error and how to fix it:

```
{{error}}
```

Tell me:
1. In plain language, what the error actually means.
2. The most likely cause given the trace.
3. The specific line/condition to look at first.
4. The minimal fix, and how to verify it's gone.

If the trace is ambiguous, list the top 2-3 causes and how to tell them apart.

error

description: The error message or stack trace


title: Add Strategic Logging

description: Instrument code to capture exactly the evidence a bug requires.

content:
I'm chasing this intermittent bug: {{bug}}

Show me where to add logging to capture the evidence needed to diagnose it. For each log point:
- What to log (state, inputs, timing) and at what level.
- Why that data discriminates between hypotheses.
- How to keep it cheap enough to leave in production if useful.

Prefer a few high-signal logs over blanket tracing.

bug

description: The bug you're tracking


title: Minimal Reproduction

description: Reduce a bug to the smallest reliable reproduction.

content:
Help me build a minimal reproduction of this bug: {{bug}}

Guide me to strip it down:
1. What to remove first to test whether it still reproduces.
2. How to replace external dependencies with fakes/stubs.
3. How to make it deterministic (seed randomness, pin time, fix ordering).

The goal is the smallest self-contained snippet that fails every time. Tell me what to try next based on what I report.

description: The bug to reproduce


title: Why Is This Slow?

description: Diagnose a performance problem before optimizing.

content:
This is slow: {{what}}

Before changing anything, help me locate the bottleneck:
1. What to measure and how (profiler, timing, counters).
2. The usual suspects for this kind of workload, ranked.
3. How to confirm the bottleneck is what we think before optimizing.

Once we've measured, propose the highest-leverage fix and predict its impact. Don't guess-optimize.

what

description: What is slow


title: Debug Failing Test

description: Figure out why a specific test fails and whether the test or the code is wrong.

content:
This test is failing:

```
{{test_and_output}}
```

Determine:
1. Is the test asserting the right thing, or is the test itself wrong?
2. What is the actual vs. expected value, and where they diverge.
3. The smallest change that makes it pass for the *right* reason.
4. Whether it might be flaky (timing, ordering, shared state) rather than a real failure.

description: The test code and its failure output


title: Bisect a Regression

description: Track down which change introduced a regression.

content:
Something that used to work now breaks: {{regression}}

Help me bisect it:
1. Define a crisp pass/fail test I can run at any commit.
2. Walk me through using git bisect (or manual halving) to find the culprit commit.
3. Once found, explain how to read that diff to understand WHY it broke things.
4. Recommend a fix that doesn't reintroduce whatever the bad commit was trying to do.

regression

description: What regressed


title: Heisenbug Hunt

description: Approach a bug that disappears under observation or happens only sometimes.

content:
I have an intermittent bug that's hard to pin down: {{bug}}

Treat it as a non-determinism problem. Help me:
1. Enumerate sources of non-determinism (threads, I/O ordering, time, randomness, uninitialized memory, network).
2. Pick the cheapest way to make each source observable or controllable.
3. Design a stress harness that makes it reproduce more often.

Give me a concrete next experiment, not general advice.

bug

description: The intermittent bug


title: Diagnose a Memory Leak

description: Find what is retaining memory that should be freed.

content:
Memory keeps growing in: {{context}}

Help me find the leak. Tell me what to capture (heap snapshots, retained-size comparison over time) and how to read it. The usual suspects: unbounded caches or maps, event listeners never removed, closures capturing large scopes, growing arrays. For each, how to confirm and fix. Give me the next concrete measurement to take.

context

description: Where memory is growing


title: Diagnose a Deadlock

description: Find why concurrent code hangs.

content:
My program hangs here: {{symptom}}

Walk me through diagnosing a deadlock: how to capture the state of all threads or tasks and see who is waiting on whom. Identify the lock-ordering or wait-cycle causing it. Propose a fix that breaks the cycle (consistent lock order, timeouts, lock-free, or removing the shared lock). Explain why your fix cannot reintroduce the deadlock.

symptom

description: How or where it hangs


title: Compare Expected vs Actual

description: Systematically find where two outputs diverge.

content:
Expected:
{{expected}}

Actual:
{{actual}}

Find exactly where and why they diverge. Point to the first MEANINGFUL difference, not just the first textual one. Hypothesize the cause of that difference, then tell me what to inspect to confirm it. Ignore differences that are downstream effects of the first one.

expected

description: What you expected

actual

description: What you got


title: Validate an Assumption

description: Test a belief you are relying on while debugging.

content:
While debugging, I am assuming: {{assumption}}

This might be wrong. Tell me the cheapest way to actually verify it (a log, an assert, a one-line check, a debugger watch). Do not let me keep building on an unverified assumption. If it is false, what does that immediately imply about where the bug really is?

assumption

description: The belief you are relying on


title: Read a Stack Trace

description: Interpret a stack trace and find the real culprit.

content:
Help me read this stack trace:

{{trace}}

Find the frame where MY code actually went wrong, not just the top of the trace or the deepest library frame. Explain what the error type and message really mean. Translate the chain into a plain-language story of what happened. Then tell me the single most useful place to put a breakpoint or log, and what to inspect there.

trace

description: The stack trace


title: Debug a Production-Only Bug

description: Works locally, fails in production — find the difference.

content:
This works locally but fails in production: {{symptom}}

The bug is almost certainly an environment difference. Walk me through the usual suspects: config and env vars, data volume and shape, concurrency and load, versions, timezones and locales, network and permissions, and resource limits. For each, how to check it quickly. Help me find the smallest difference that reproduces it, so I am not debugging blind against prod.

symptom

description: What fails in production


title: Debug with Print Statements

description: Find a bug systematically when no debugger is handy.

content:
I am stuck on this bug and only have print/log to work with: {{problem}}

Guide me through binary-searching the code path: where to put the first prints to cut the suspect region in half, what to print (values AND that a line was reached), and how to read the output to halve it again. Stop me from scattering prints randomly. Tell me the one assumption to verify first, and when the output proves the bug is somewhere I wasn't looking.

problem

description: The bug you are chasing


title: Debug an Intermittent Failure

description: Track down a bug that only happens sometimes.

content:
This fails only sometimes: {{symptom}}

Intermittent means timing, ordering, state, or external dependency. Help me make it reproducible: what to vary (load, concurrency, ordering, slow network) to raise the failure rate, and what to log so a rare failure leaves enough evidence. Identify whether it smells like a race, a resource limit, a dependency flake, or uninitialized state. Tell me how to confirm which, then fix the cause rather than adding a retry.

symptom

description: The intermittent symptom