When to use this
- An active incident with a large volume of logs to sift through quickly.
- Post-incident, reconstructing the sequence of events from logs for a postmortem.
- Not for routine log review with no specific incident/anomaly to investigate -- too broad to be useful.
The skill file
Copy this verbatim. It's written in the SKILL.md format (YAML frontmatter + markdown instructions) that Claude Code, and increasingly other agent tools, read directly.
--- name: log-triage-assistant description: Sift a large log dump for the signal relevant to an active incident or specific anomaly -- the first error, the cascade that followed, and correlated changes -- rather than summarizing everything. Use during or after an incident with logs to review. --- # Log Triage Assistant ## Anchor to a time window Get the approximate time the incident started (from an alert, a user report, or a metric spike). Focus first on logs immediately before and during that window -- don't start by summarizing the entire log file. ## What to extract 1. **The first anomaly**: the earliest log line that looks wrong, scanning backward from when the incident was noticed -- this is often earlier than when it became visible/alerted. 2. **The cascade**: once the first anomaly is found, what happened immediately after -- retries, downstream errors, timeouts triggered by the first failure. Distinguish cause from effect; a page full of "connection refused" from twenty services is one root cause with nineteen symptoms. 3. **What changed right before**: a deploy, a config change, a traffic spike, an external dependency's status -- correlate the anomaly's timing against anything that changed recently. 4. **Scope**: how many requests/users/instances were affected, from volume of matching log lines, not a guess. ## Output A timeline: what happened first, what cascaded from it, and what correlates with the start. Flag explicitly what's confirmed from logs vs. what's a hypothesis still needing verification (e.g. against a deploy log or metrics dashboard).
Installing it elsewhere
The frontmatter/body split above is Claude Code's convention. Here's how to carry the same instructions into other tools:
Save the file below verbatim (frontmatter included) at that path, project-local or in ~/.claude/skills/ for a user-level skill. Claude Code loads the name/description pair to decide when to pull it in, or you invoke it directly as /log-triage-assistant.
Convert the YAML frontmatter to Cursor's rule format (description, globs, alwaysApply: false) and keep the markdown body as the rule content. Cursor surfaces it by description match, same idea as Claude Code's auto-load.
Codex CLI (and increasingly other agentic CLIs) read AGENTS.md at the repo root as always-on instructions. Paste the markdown body under a heading like ## {title}; for GitHub Copilot's coding agent, the equivalent file is .github/copilot-instructions.md.
Append the markdown body to .windsurfrules at the repo root. Windsurf treats the whole file as always-on context, so keep only the instructions you want applied on every request.
- Summarizing every log line with equal weight instead of anchoring to the incident window and finding the first anomaly.
- Treating a downstream symptom (twentieth service timing out) as the root cause instead of tracing back to the first failure.
- Presenting a hypothesis about correlation as confirmed causation without checking it against an actual deploy/change log.