trace-incident
Skill1 starsChanged 44 days agoMITView on GitHub
Traces a production symptom to its cause and produces a minimal hotfix plan at .workflow/incident-<slug>/sdd.json with a timeline. Use when something is broken in production now.
In this repository9 other files it gives its agents.
- address-reviewSkill
- draft-prSkill
- frame-productSkill
- implement-changeSkill
- plan-changeSkill
- review-diffSkill
- triage-taskSkill
- write-commitSkill
- write-handoverSkill
The file
We split this skill into the rules it gives an agent
2 rules. About 0 are common, 1 is distinctive, and 1 is very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈1
Distinctive · estimate
This author's own choices. Worth a look.
1
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Very specific: line 30
Trace it, do not guess it: Follow the symptom to the code path with the strongest search available: ../../shared/code-search.md.
- Distinctive: line 68
Production access is the user's: Ask for logs, metrics or a query result.
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
trace-incident
wb <args> # wb not on PATH: python <this skill's directory>/../../lib/wb.py <args>The entry is a symptom — an error, an alert, a user report — not a ticket. Speed matters, which is exactly why the discipline does not loosen: a hotfix built on a guess extends the incident.
Steps
- Write down the symptom first, before touching code. What is observed,
since when, affecting whom, and how it was noticed. This becomes the timeline
in
.workflow/incident-<slug>/incident.md, and it is what stops the investigation drifting to a more interesting problem than the real one. - Separate stopping the bleeding from fixing the cause. They are two
changes. Decide explicitly which one you are doing now. A rollback, a flag
flip or a config change often beats a code fix as the immediate step — say so
if it does. A mitigation that is not code needs no
sdd.json: record it as a timeline entry inincident.md— what was done, when, by whom, and the effect.route incident-<slug>lists it as themitigatestep. - Trace it, do not guess it. Follow the symptom to the code path with the
strongest search available:
../../shared/code-search.md. Then read the actual lines. Every step of the chain from symptom to cause needs afile:lineyou have read. - Label the confidence. A plausible cause you cannot demonstrate is a hypothesis, and calling it one is not weakness — it is the difference between a fix and a second incident. Say what would confirm it: a log line, a metric, a reproduction.
- Plan the smallest fix.
.workflow/incident-<slug>/sdd.json, personaincident-responder, shape in../plan-change/references/sdd.md. Nothing tidied, nothing renamed, nothing upgraded.rollbackstates the user-visible state during and after, not just "revert the commit". - Audit it anyway.
sdd audit incident-<slug>. Urgency is when a wrong citation is most likely and most expensive. A missing handover is reported as pending, not failed: it is owed before the PR, not before the hotfix, andpr check --keyrefuses until it is written. - The regression test ships with the fix, not after. A hotfix without one is how the same incident happens twice. If it genuinely cannot be written before the fix goes out, say so explicitly and name the follow-up.
- Close the timeline. Detection, cause, fix, verification, and what would
have caught this earlier. Each step of the chain in
incident.mdcites as`path:line` — `the line`;cite check .workflow/incident-<slug>/incident.mdmust pass. Then hand off toimplement-change.
Rules
- The symptom is the scope. Other problems found on the way get written down as follow-ups, not fixed in this change.
- Never widen a permission or disable a check to make it work. That trades an outage for an incident of a different kind.
- Say what you did not verify. Under time pressure the honest gap is worth more than a confident guess.
- Production access is the user's. Ask for logs, metrics or a query result; do not reach for production yourself.
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

