incident-analysis
Use when analysing production logs, investigating incidents, writing postmortems, or reviewing error patterns from structured logs (JSONL, journal, HAProxy, PostgreSQL). Enforces source provenance, timezone discipline, hypothesis falsification, and evidence-graded findings. Prevents scope leakage, confidence flattening, and unreproducible counts.
npx skills add majiayu000/claude-skill-registry --skill incident-analysis --agent claude-code
Same command for any agent — swap --agent for codex, cursor, copilot.
Weekly change comes from our own snapshots, not the repository page — it measures attention, not adoption.
# Incident Analysis Analyse production incidents with falsificationist discipline. Every finding is a hypothesis. Every hypothesis has evidence with provenance. Every count has a reproducible command. This skill exists because a 2026-03-16 afternoon analysis produced 10 errors caught by two peer reviewers — all caused by operating on data without verifying it matched the analytical assumptions. The errors are catalogued in `CREATION-LOG.md` in this directory. ## When to Use - Analysing production log files (JSONL, systemd journal, HAProxy access logs, PostgreSQL logs) - Writing or reviewing postmortem documents - Investigating error patterns across multiple log sources - Any task where counts, timelines, or causal claims are derived from log data ## Phase 1: Source Inventory **Before any analysis, inventory every data source.** This is the single cheapest check that catches the most errors. (Lesson: the 2026-03-16 analysis operated on a 28-hour JSONL file believing it covered 2.5 hours.) For each log file, record: | Field | How to get it | |-------|--------------| | File path | The file you're analysing | | Line count | `wc -l` | | First timestamp | `head -1` or `jq -r '.timestamp'
- When to Use
- Phase 1: Source Inventory
- Timezone Reference
- Positive Control
- Phase 2: Enumerate Before Hypothesising
- Phase 3: Findings as Hypotheses
- Well-Formed Finding Template
- Confidence Calibration
- Report Structure Separation
- Phase 4: Cross-Source Reconciliation
- Phase 5: Causal Chain, Not Root Cause
- Phase 6: Provenance Discipline
- Phase 7: Self-Challenge Before Presenting
- Quick Reference: Verification Order
grep -oE ' [0-9]{3} ' haproxy.log | sort | uniq -c | sort -rn
Then drill into specific codes
grep ' 504 ' haproxy.log | ...
jq -r 'select(.level == "error") | .event' file.jsonl | sort | uniq -c | sort -rn
Then drill into specific events
jq -r 'select(.event == "Database session error")' file.jsonl | ...What does the incident-analysis skill do?
Use when analysing production logs, investigating incidents, writing postmortems, or reviewing error patterns from structured logs (JSONL, journal, HAProxy, PostgreSQL). Enforces source provenance, timezone discipline, hypothesis falsification, and evidence-graded findings. Prevents scope leakage, confidence flattening, and unreproducible counts.
How do I install it?
Run `npx skills add majiayu000/claude-skill-registry --skill incident-analysis --agent claude-code` — it drops the skill into your project so the agent can pick it up. Swap the --agent value for codex, cursor or copilot if you use one of those.
Where does this skill come from?
From majiayu000/claude-skill-registry, a repository with 534 stars. We read it straight from the repository tree rather than a submitted listing, so what you see here is what is actually published.
Is a popular skill a good skill?
Not necessarily. Stars measure attention, not adoption — a repository can trend for a week and be abandoned. That is why we show the weekly change from our own snapshots next to the total, instead of a single flattering number.