Debugging prompts

Help me debug this. Work from evidence, not guesses.

LANGUAGE/RUNTIME: [DETAIL AND VERSION]
WHAT I EXPECTED: [BEHAVIOUR]
WHAT HAPPENED: [ACTUAL BEHAVIOUR]
WHEN IT STARTED: [ALWAYS / AFTER A CHANGE / INTERMITTENT SINCE DATE]
REPRODUCIBLE: [always / sometimes / once]

STACK TRACE / ERROR:
```
[PASTE]
```

RELEVANT CODE:
```
[PASTE]
```

Produce:

1. WHAT THE TRACE ACTUALLY SAYS - read it line by line. Identify the deepest frame in MY code (not library code) and what it was doing. State what the error type means in this runtime, precisely.

2. RANKED HYPOTHESES - 3-5 causes, most likely first. For each:
   - The mechanism: how this cause produces exactly this trace
   - Consistency check: does it explain the 'when it started' and 'reproducible' answers I gave? If not, rank it lower and say why.
   - The cheapest test to confirm or eliminate it, as a specific command, log line or assertion

3. ELIMINATED - causes that would produce a similar error but are ruled out by the evidence, and what rules each out.

4. WHAT I HAVE NOT TOLD YOU that would most narrow this down.

Rules:
- Do not suggest 'add logging and see' as a primary hypothesis.
- Do not propose a fix before the cause is established.
- If the trace is truncated or the relevant frame is missing, say so and tell me what to capture.

Help me debug an intermittent failure.

WHAT FAILS: [DESCRIPTION]
FAILURE RATE: [e.g. 1 in 50 runs, twice a day, only in CI]
WHERE IT FAILS: [local / CI / staging / production]
WHERE IT NEVER FAILS: [ENVIRONMENTS THAT ARE FINE]
WHAT I HAVE OBSERVED: [LOGS, TRACES, TIMING, ANY PATTERN]
CODE:
```
[PASTE]
```

Intermittent failures come from a small set of causes. Work through them systematically:

1. TIME - test order dependence, timeouts too tight, clock skew, DST or timezone, expiring tokens, time-of-day effects, month/year boundaries
2. CONCURRENCY - races, shared fixtures, parallel test workers, connection pool exhaustion
3. STATE - leftover data from a previous run, cached values, shared mutable module state, filesystem residue
4. ORDERING - non-deterministic iteration (map/dict order, unordered query results without ORDER BY), randomised test order
5. RESOURCES - memory pressure, disk, file descriptors, port collisions, rate limits
6. EXTERNAL - network flakiness, third-party latency, DNS, a dependency that is occasionally slow
7. DATA - a specific input that only sometimes occurs; unicode, empty, very large, null

For each category: is it plausible given what I told you? If yes, the specific mechanism, and a test that would confirm it.

Then give:
- THE TOP TWO hypotheses and exactly how to confirm each
- HOW TO MAKE IT REPRODUCIBLE - the change that would make this fail every time rather than sometimes. This is the real goal.
- WHAT TO LOG - the minimal set of fields to capture on the next failure to distinguish between the top hypotheses

Pay particular attention to what I said never fails. The difference between those environments is the strongest clue available.

Help me find a performance regression.

WHAT GOT SLOWER: [OPERATION]
BEFORE: [TIMING/THROUGHPUT]
AFTER: [TIMING/THROUGHPUT]
WHEN IT CHANGED: [DATE OR DEPLOY, or 'gradual']
WHAT CHANGED AROUND THEN: [DEPLOYS, DATA GROWTH, TRAFFIC, CONFIG, DEPENDENCY UPDATES]
MEASUREMENTS I HAVE: [PROFILES, TRACES, SLOW QUERY LOGS, METRICS]
CODE:
```
[PASTE IF RELEVANT]
```

Produce:

1. SHAPE OF THE REGRESSION - is this a step change or gradual? Constant factor or complexity change? Test: has the input size grown, and did latency grow proportionally, super-linearly, or not at all? Say what each pattern implies.

2. RANKED CAUSES - for this specific case. Consider: an N+1 query introduced by a refactor, a missing or unused index as data grew, a query plan flip at a data-size threshold, cache hit rate dropping, a dependency update, added synchronous I/O in a loop, connection pool saturation, GC pressure, a lock now contended, serialisation of larger payloads, and a retry loop masking a slow dependency.

3. FOR EACH: the mechanism, whether it fits my timing evidence, and the specific measurement that would confirm it.

4. WHERE TO MEASURE FIRST - if I can only take one measurement, which one, and the command or tool for my stack.

5. WHAT MY MEASUREMENTS ALREADY RULE OUT.

Rules:
- Do not suggest optimisations before the cause is identified.
- Do not assume the slow part is the code that changed. Regressions frequently appear far from the change.
- If the timing suggests a complexity change rather than a constant factor, say so explicitly - that changes the whole investigation.

Explain this code precisely. I need to modify it and I do not want to break something I did not notice.

LANGUAGE: [DETAIL]
WHAT I THINK IT DOES: [YOUR GUESS, or 'no idea']
WHAT I WANT TO CHANGE: [YOUR GOAL]

CODE:
```
[PASTE]
```

Produce:

1. ONE-LINE PURPOSE - what it does, in plain terms.

2. LINE-BY-LINE for anything non-obvious. Skip the obvious lines entirely.

3. INPUTS AND OUTPUTS - every parameter, its expected type and range, what it returns in each path, and what it throws.

4. SIDE EFFECTS - everything it touches beyond its return value: writes, network calls, mutated arguments, global or module state, logging, caches, file system. This is the section that matters most for safe modification.

5. HIDDEN ASSUMPTIONS - what must be true for this to work. Ordering, prior initialisation, single-threaded execution, non-null inputs, a particular configuration.

6. THE NON-OBVIOUS PART - the one thing in here that a reader would most likely miss. There usually is one - a short-circuit, an early return, an operator precedence subtlety, a mutation inside a loop, an implicit type coercion.

7. WHAT WOULD BREAK IF I CHANGE IT - given my stated goal, what else depends on current behaviour. Include callers you can infer, and mark them [INFERRED].

8. WHAT I CANNOT TELL FROM THIS ALONE - what else I need to see to modify it safely.

Do not rewrite or improve the code. Explain it.

Help me build a minimal reproduction of this bug.

THE BUG: [WHAT GOES WRONG]
ENVIRONMENT: [LANGUAGE, FRAMEWORK, VERSIONS, OS]
WHERE IT HAPPENS: [CONTEXT]
CODE (larger than it needs to be):
```
[PASTE]
```
WHAT I HAVE ALREADY TRIED REMOVING: [IF ANYTHING]

Produce:

1. WHAT IS PROBABLY ESSENTIAL - the parts of this code that plausibly participate in the bug, and why each might.

2. WHAT IS PROBABLY IRRELEVANT - what can likely be cut. Order the cuts from safest to riskiest so I can bisect.

3. A REDUCTION PLAN - a sequence of cuts, each with what to check after it (does the bug still reproduce?). Binary search where possible rather than removing one line at a time.

4. THE MINIMAL REPRO ATTEMPT - your best attempt at the smallest self-contained program that would show this. Include the exact versions and how to run it. If you need something from me to complete it, mark [NEED: what].

5. THE DEPENDENCY QUESTION - can this be reproduced without the framework/library, using only the standard library? If yes, that is the target and it tells you the bug is yours; if no, say which dependency is essential and what that implies.

6. FOR A BUG REPORT - the exact information a maintainer will ask for: versions, minimal code, expected vs actual, environment, and whether it reproduces on the latest version.

Building the repro often reveals the cause. Note anything suspicious you notice while reducing.

Help me reconstruct this incident from logs.

WHAT USERS EXPERIENCED: [SYMPTOM]
WHEN: [TIME RANGE AND TIMEZONE]
SYSTEM: [ARCHITECTURE IN TWO SENTENCES]
WHAT CHANGED RECENTLY: [DEPLOYS, CONFIG, TRAFFIC, DEPENDENCIES]

LOGS:
```
[PASTE]
```

METRICS I HAVE: [WHAT YOU CAN SEE - ERROR RATE, LATENCY, CPU, CONNECTIONS]

Produce:

1. TIMELINE - reconstructed from the logs, with timestamps. Separate three distinct things: when the underlying problem started, when symptoms appeared, and when we noticed. The gaps between them are findings in themselves.

2. FIRST ANOMALY - the earliest log line that is not normal. Quote it. Everything before it is baseline.

3. CAUSAL CHAIN - what caused what. Distinguish clearly between the trigger (what started it), the cause (the underlying condition that made the trigger harmful), and the amplifiers (retries, queue backlog, cascading timeouts, thundering herd on recovery).

4. WHAT THE LOGS DO NOT SHOW - gaps in the timeline, missing services, the window where you have no visibility. Be explicit; this is usually where the cause actually is.

5. RANKED EXPLANATIONS - with confidence levels, each checked against the timeline.

6. WHAT TO CHECK NOW - specific queries or dashboards that would confirm the leading explanation.

7. LOGGING GAPS - what should have been logged that was not, so this is faster next time.

Do not assert causation from correlation with a deploy. Say 'coincides with' and describe what would establish causation.

It works locally but fails in [ENVIRONMENT]. Help me find the difference.

WHAT WORKS LOCALLY: [BEHAVIOUR]
WHAT HAPPENS IN THE OTHER ENVIRONMENT: [BEHAVIOUR AND ANY ERROR]
LOCAL SETUP: [OS, RUNTIME VERSION, HOW YOU RUN IT, DATABASE, ANYTHING RELEVANT]
OTHER ENVIRONMENT: [PLATFORM, RUNTIME, CONTAINER, ORCHESTRATION, DATABASE]
DEPLOYMENT METHOD: [DETAIL]
ERROR:
```
[PASTE IF ANY]
```

Work through the standard difference categories and assess each against what I told you:

1. CONFIGURATION - env vars present locally but not there, defaults differing, secrets, config files not shipped
2. VERSIONS - runtime, dependency, OS library, database version differences. Is there a lockfile, and is it honoured in the build?
3. FILESYSTEM - case sensitivity (macOS/Windows vs Linux is the classic), path separators, working directory, read-only filesystems, missing directories, permissions, file ownership in containers
4. NETWORK - DNS, egress restrictions, TLS certificate validation, proxies, service discovery, localhost meaning something different inside a container
5. DATA - production data has shapes your local data does not: nulls, very long strings, unicode, duplicates, volume
6. TIMING - production is slower or faster; timeouts, cold starts, connection pool limits, startup ordering
7. CONCURRENCY - production runs multiple instances; local runs one
8. BUILD - what the build does differently: minification, tree-shaking, NODE_ENV, dev dependencies absent, source maps, compilation flags
9. PERMISSIONS - IAM, service accounts, file permissions, database grants

For each: likely / possible / ruled out given my inputs, with the reason. Then give the top three, each with a specific command to run in the failing environment to check it.

End with: how to make my local environment resemble the failing one closely enough to reproduce this.