Incident Triage

When this fires

Log aggregation tools can cluster errors by signature and show frequency, but they can't see your source code — they stop at "this error happened 1,200 times" without connecting it to the line that causes it. This skill picks up where the log tool stops: cluster the noise, then correlate each cluster back to the actual code so the on-call engineer gets a ranked, evidence-backed list of what to look at first.

Protocol

1. Ingest the logs (stdin, pasted text, or a file). Don't pre-filter before clustering — noise and signal both matter for frequency ranking.
2. Cluster by error signature and frequency. Group entries that share an error type/message shape (normalizing out request-specific values like IDs, timestamps, IPs), and count occurrences per cluster. This frequency ordering is what determines investigation priority, not recency or severity label alone.
3. Correlate the top clusters to source locations. For each cluster worth investigating, find the actual code path that would produce that error — read the source, don't infer it from the error message alone.
4. Rank root-cause hypotheses, each citing the specific file:line that supports it, ordered by evidence strength and cluster frequency — not by which one seems most plausible in the abstract.
5. Propose the smallest safe fix for the top hypothesis, plus a concrete verification step (a test, a log query, a specific input to check) that would confirm the fix actually addresses the cluster.

Hard rules

• Every hypothesis must cite an exact file:line in the actual source — "probably something in the auth module" is not a hypothesis, it's a guess.
• Rank by evidence (frequency × how directly the code path explains the error), never by gut feeling about what's "usually" the cause.
• Don't propose a broad rewrite as the fix when a small change addresses the identified line — match the fix size to the diagnosed cause.
• If a top-frequency cluster can't be correlated to a source location with the available code/logs, say so explicitly rather than filling the gap with speculation.

Output

Clusters (by frequency):
  1. <count>x  <normalized error signature>
  2. <count>x  <normalized error signature>
  ...

Correlated hypotheses (ranked):
  1. <file>:<line> — <mechanism, tied to cluster #N>
  2. <file>:<line> — <mechanism, tied to cluster #M>

Proposed fix (for #1): <smallest change addressing that line>
Verification: <specific test/check that would confirm it>