agentleFS
matheusPavanelimatheusPavaneli/workbench/skills/trace-incident/SKILL.md

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.

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
  1. Very specific:

    Trace it, do not guess it: Follow the symptom to the code path with the strongest search available: ../../shared/code-search.md.

    line 30
  2. Distinctive:

    Production access is the user's: Ask for logs, metrics or a query result.

    line 68

≈ “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.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

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

  1. 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.
  2. 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 in incident.md — what was done, when, by whom, and the effect. route incident-<slug> lists it as the mitigate step.
  3. 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 a file:line you have read.
  4. 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.
  5. Plan the smallest fix. .workflow/incident-<slug>/sdd.json, persona incident-responder, shape in ../plan-change/references/sdd.md. Nothing tidied, nothing renamed, nothing upgraded. rollback states the user-visible state during and after, not just "revert the commit".
  6. 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, and pr check --key refuses until it is written.
  7. 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.
  8. Close the timeline. Detection, cause, fix, verification, and what would have caught this earlier. Each step of the chain in incident.md cites as `path:line` — `the line`; cite check .workflow/incident-<slug>/incident.md must pass. Then hand off to implement-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.

Download now (ZIP)

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
What did you use it for? e.g. Reviewing pull requests in a Rails app

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.