incident-revert-review
Skill8 starsChanged 6 months agoMITView on GitHub
Review a proposed incident revert for the protection it removes, the failure it may restore, and the adjacent path to check. Produce a read-only risk note before the change decision.
In this repository129 other files it gives its agents.
- AGENTS.mdAGENTS.md
- guidance/AGENTS.mdAGENTS.md
- CLAUDE.mdCLAUDE.md
- guidance/CLAUDE.mdCLAUDE.md
- .github/copilot-instructions.mdCopilot instructions
- blast-radius-checkSkill
- brainstormingSkill
- branch-flow-gateSkill
- branch-sync-gateSkill
- codebase-reconSkill
- codeowners-drift-auditSkill
- code-review-batterySkill
- cognitive-complexity-refactoringSkill
- debateSkill
- debug-conductorSkill
- dispatching-parallel-agentsSkill
- domain-buildSkill
- evidence-adjudicatorSkill
- executing-plansSkill
- external-cli-auditSkill
- feature-developmentSkill
- field-rename-verificationSkill
- finishing-a-development-branchSkill
- git-branch-conventionsSkill
- gitlab-cliSkill
- hotfix-charterSkill
- implementation-trackerSkill
- infra-config-investigatorSkill
- investigation-stateSkill
- kernel-splitSkill
- llm-behavior-investigatorSkill
- llm-skill-reviewSkill
- merge-authorization-gateSkill
- micro-harsh-reviewSkill
- output-verificationSkill
- pre-commit-gateSkill
- progressive-code-review-gateSkill
- progressive-harsh-reviewSkill
- providing-code-reviewSkill
- pr-triage-gateSkill
- push-authorization-gateSkill
- receiving-code-reviewSkill
- reproduction-experiment-investigatorSkill
- requesting-code-reviewSkill
- requirements-validation-pmSkill
- requirements-validationSkill
- scope-tripwireSkill
- session-handoffSkill
- skills-hierarchy-tuningSkill
- sp-bughuntSkill
- state-consistency-investigatorSkill
- subagent-driven-developmentSkill
- systematic-debuggingSkill
- test-driven-developmentSkill
- timeline-trace-investigatorSkill
- token-estimationSkill
- unified-commit-gateSkill
- using-git-worktreesSkill
- using-superpowersSkill
- verification-before-completionSkill
- The first 60 shown.
The file
We split this skill into the rules it gives an agent
4 rules. About 0 are common, 4 are distinctive, and 0 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈4
Distinctive · estimate
This author's own choices. Worth a look.
0
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 36
When the original change or the incident record is missing, say so instead of guessing what the change was for, and review only what the …
- Distinctive: line 40
Trace both sides of the change: Read the original issue/PR and proposed reverse diff.
- Distinctive: line 48
Keep the note short enough to link from the existing incident, PR/MR, or issue record.
- Distinctive: line 60
Keep the decision owner and any later observation handoff in the authoritative incident record.
≈ “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
Incident Revert Review
Wrong skill? Scoping callers/consumers of touched code →
blast-radius-check. Hotfix branch discipline (symptom, LOC budget, pre-commit verdict) →hotfix-charter. Root-causing the original bug →systematic-debugging.
Use for a proposed revert or rollback during an incident, whether the change is on a hotfix branch, an ordinary branch, or created directly in the hosting platform's UI. This review informs the change decision; it does not approve, merge, deploy, or block the change.
Inputs
- The incident or issue, and the symptom users see that the revert is meant to stop.
- Proposed revert PR/MR, commit, or diff, plus the original change it reverses. If the proposed diff does not exist yet, use the stated target commit and label code impact unverified.
- Affected repo(s) and any available test or production evidence.
When the original change or the incident record is missing, say so instead of guessing what the change was for, and review only what the diff shows.
Review
- Trace both sides of the change. Read the original issue/PR and proposed reverse diff. State the original problem, the behavior the change added, and the behavior the revert would restore. Distinguish observed behavior from an inferred risk.
- Scope consumers and boundaries. Apply
blast-radius-checkto touched functions, state transitions, configuration, and callers across affected repos. Inspect the path through the touched boundary before and after the change, including at least one path outside the symptom the revert intends to fix. Record what was searched and what remains unverified. - Inspect change discipline. If this repo uses a hotfix-branch convention gated by
hotfix-charter, check for aHOTFIX-CHARTER.mdon the branch and tell the change author to run its gate before commit if it is pending. The authoring hook cannot be run or inferred by this read-only review. For a UI-created or ordinary-branch revert, state the symptom, diff scope, and review/test evidence without claiming any charter ran. - Compare the options. State the likely impact of reverting and of leaving the current behavior in place. Identify any protection the revert removes, the failure it could restore, and at least one plausible adjacent path that could worsen. Check whether data, schema changes, messages, or cache entries written since the original change are still readable by the reverted code; a revert restores code, not state. If no adjacent path can be identified from the sources, mark that gap unknown, not safe.
- Prepare verification. Identify existing tests and the missing scenario, then name immediate checks for both the intended fix and the adjacent path. Name production signals, time windows, and denominators where available. Do not invent a traffic threshold or claim that a successful deploy proves recovery.
Output: revert risk note
Keep the note short enough to link from the existing incident, PR/MR, or issue record. Render it for the requester; do not write to an external system unless separately asked.
| Row | What it must say |
| Sources | The incident or issue, the original change, and the revert diff or target commit; name any that could not be found |
| Intended outcome | Symptom the revert should resolve |
| What the revert takes away | The behavior the original change guarded, the evidence for it, and how sure that is |
| Adjacent path | Concrete scenario that could worsen, with the affected boundary |
| Revert vs. keep | The risk of each choice, each backed by evidence or marked as inference |
| Checks | Existing tests, missing test, target and adjacent verification steps, production signals and denominators |
| Still unknown | Evidence that is missing and the next check that would settle it |
Keep the decision owner and any later observation handoff in the authoritative incident record; this skill does not infer them.
Failure Modes
| Failure | Symptom | Recovery |
| Treating "deploy succeeded" as "incident resolved" | Risk note claims recovery with no production signal cited | Require a named metric, time window, and denominator before calling it resolved |
| Skipping the adjacent-path check | Risk note only covers the symptom path | Mark the adjacent-path row unknown, not safe, until a real scenario is named |
| Assuming the original change's intent from memory | Risk note states a motivation not found in the source issue/PR | Report the missing source explicitly and scope the review to what the diff shows |
| Claiming a hotfix charter ran when it did not | Charter-gated branch but no charter evidence available | State charter status as pending/unknown, not assumed-run |
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.