Incident

Read-only, without exception. This skill diagnoses. A person decides what to do about it. If the conclusion is "purge the queue", it prints the command and stops.

Fill in the four placeholders below once, for your infrastructure. Half an hour of work, and after that the skill knows your stack.

• LOG_QUERY — how you query logs (Loki, CloudWatch, Datadog…)
• QUEUE_INSPECT — how you list queue depth read-only
• SERVICE_MAP — service name to repository path
• ENVIRONMENTS — what your environments are called

Steps

1. Pin down the symptom before touching anything. Which environment, which service, since when, and what a user actually sees. Ask if any of the four is missing. A diagnosis built on a guessed environment is worse than none.

2. Queues first. Dead letter depth tells you where things stopped, and it is one command:

   # QUEUE_INSPECT — read-only listing, no purge, no ack

   A DLQ that grew from zero at a specific minute is the strongest signal you will get. Note the minute.

3. Logs around that minute. Search the window, not the last hour:

   # LOG_QUERY for {service} between T-5m and T+5m

   Pull a trace id from the first failure and follow that single trace across services. One complete trace beats a thousand log lines.

4. Source code last, and only where the trace pointed. Read the handler that threw. Check whether the error is typed recoverable or terminal (standards/01-error-handling.md), because that decides whether the retry behaviour you are seeing is correct.

5. Correlate with what changed. A deploy, a migration, a config change or a dependency bump inside the window:

   git log --since='<window start>' --oneline

Output

## Symptom
<what was reported, and what is actually observable>

## Timeline
<T0: first failure — with the evidence line that proves it>

## Root cause
<the specific thing. If uncertain, say so and give the two candidates.>

## Evidence
- <queue/log/commit — each one chaseable by someone else>

## Recommended action — for a human to run
```bash
<the exact command, unexecuted>

What would prevent a repeat

<one thing, or nothing>

## Rules

- **Never run a mutating command.** No purge, no requeue, no restart, no scale,
  no deploy, no `UPDATE`. Print it, do not run it.
- Read-only database access only, and always with a `LIMIT`.
- **No third-party data in the output.** Ids, not names. Never a payload with
  personal data in it.
- "I do not know yet" is a valid diagnosis. A confident wrong root cause costs
  more than an honest gap.