Turn errors and stack traces into a triage order
Measured on 2026-11-14 — numbers from one real run
The run log here comes from an actual run, not an estimate. Where token usage was not captured it says so rather than guessing.
When to use
The program blew up with a pile of errors and stack traces, but you don't know which thread to pull first.
Preparation
- Host version
- 0.1.2-alpha.5
- Model
- To fill
- Mode / permissions
- --profile headless / workspace-write / Windows 11
- Plugins required
- None (add name & version after testing if used)
- Input materials
- A 19-line synthetic log with three error families: upstream timeout to 502 (twice), connection pool exhaustion, and a worker null dereference
Full instruction
From the [error text + stack trace + relevant code snippet] below, do fault triage. Do not modify code directly.
Output:
1. Most likely root causes (top 3 hypotheses), each with why you suspect it and how to verify.
2. Triage order: what to check first, then next, with commands / logs per step.
3. If it is a dependency or version issue, give specific check commands.
4. Flag information you cannot judge and need from me (repro steps, environment version).
Requirements: say when unsure; do not give a confident-but-unsupported conclusion.Run log
| Item | Value | Note |
|---|---|---|
| Time spent | 85 seconds | 2026-11-14 |
| Result | Three error families identified, split into recurring versus intermittent with stated evidence, and all 19 source lines matched verbatim | |
| In / out tokens | Not captured | |
| Leftovers | None. |
What the run showed
- It did not list by timestamp — the recipe requires grouping by error family, and the effect is that the artifact becomes a searchable index instead of a transcript.
- The most valuable part is that it flagged the log's own inconsistency: attempt one to attempt two is 15 seconds apart, which cannot contain a declared 30000 ms timeout, and the 14:02 event is missing the attempt two and three lines plus retries. It put that in a 'log defects' section rather than rationalising it.
- The recurring-versus-intermittent call came with checkable evidence: E1 appears six times across 4h48m with a successful request in between; E2 clusters in a 39-second window (waiters 37 to 52 in one episode); E3 all belong to job 4471.
- It stated its own sampling limit: 19 lines is too small, so 'intermittent' holds only within this log; and it explicitly noted no cross-family causal evidence in the data rather than forcing a root cause.
The real output is not the error list but the closing recommendation: the log lacks host or instance, request size, and DNS/TLS timings, so the first question that should be answered — whether both E1 events hit the same node — cannot be. Adding fields beats analysing further.
Output
After a successful run, list files and screenshots here, and note whether originals changed.
Acceptance checklist
Tap to tick each item off as you verify.
- Top 3 hypotheses with verification each
- Triage steps have concrete commands / logs
- Information needed is flagged
- No unsupported conclusions given
Failures & boundaries
- Triage is not a fix; fixing needs human confirmation
- Conclusions are unreliable without environment info
- This is a recipe template and has not been tested on this site