suggest-follow-ups
Skill13 starsChanged 3 months agoMITView on GitHub
Suggest high-leverage incident follow-up actions from established root cause and incident context. Activate when asked for follow-ups, action items, preventive measures, or "what should we do so this doesn't happen again" after an incident.
1 other project uses a version of this.
Adopted by
Most recently taken up by
- vercel/eveword for word, first seen Nov 15, 2026
Other versions1 project uses a version of this.
Word for word · 1
- vercel/eve★ 5.9k100% same
Edited · 0
None found.
Wrote their own version · 0
None found.
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository4 other files it gives its agents.
- AGENTS.mdAGENTS.md
- deep-investigationSkill
- hypothesis-validationSkill
- on-call-handoffSkill
The file
We split this skill into the rules it gives an agent
5 rules. About 0 are common, 5 are distinctive, and 0 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈5
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 10
Prefer an established root cause.
- Distinctive: line 23
If these facts are not already in the thread, read the incident thread with Slack tools.
- Distinctive: line 38
If detection was already fast but recovery was slow, prefer mitigation over more alerts.
- Distinctive: line 57
Do not investigate or run new observability/code queries to manufacture a root cause.
- Distinctive: line 58
Do not assign owners.
≈ “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
Suggest Follow-ups
Turn an incident's root cause, timeline, and blast radius into a short, ranked list of high-leverage follow-up actions. Suggest only; do not file follow-ups.
Prefer an established root cause. If root cause is unknown, do not investigate to invent one. Suggest only what available context supports, state that prevention-level follow-ups are premature, and recommend deep-investigation first if deeper follow-ups are wanted.
Procedure
Step 1: Gather what went wrong
From the incident channel and supporting evidence, identify:
- Root cause — the underlying fragility, not just the trigger
- Timeline — detection, diagnosis, and mitigation speed
- Blast radius — services, endpoints, or users affected, and severity
- Issues that made the timeline slow or blast radius large
If these facts are not already in the thread, read the incident thread with Slack tools. Do not run new Datadog or GitHub queries to expand the investigation.
Step 2: Load existing follow-ups
Scan the thread for follow-ups that people already named. Do not duplicate those items. If this is a repeat incident, raise priority and note that earlier mitigation did not hold.
Step 3: Map to categories
Weight toward where this incident actually hurt:
- Prevent — eliminate the cause or class of cause
- Detect faster (MTTD) — close a genuine detection gap
- Mitigate faster (MTTR) — rollback automation, kill switch, missing runbook, missing dashboard
- Limit blast radius — rate limiting, load shedding, circuit breaker, isolation, graceful degradation
If detection was already fast but recovery was slow, prefer mitigation over more alerts.
Step 4: Apply a high bar
A follow-up qualifies only if it is durable/systemic, targets the failure class, is worth the cost, and is verifiable. Drop process-vigilance items ("be careful", "add review", "remind").
A proposed alert must also be symptom-based, actionable, page-worthy only if urgent, threshold-tuned, and prefer fixing/consolidating an existing monitor over adding a new one.
Step 5: Rank
Order survivors by leverage — cheap, high-impact, fast-to-land first. Typically one to three items. If nothing clears the bar, say so rather than inventing low-value items.
Result
A short ranked list of suggested follow-ups, each with priority, action, and one sentence on why it matters tied to evidence.
Boundaries
- Suggest only. Do not file follow-ups in an external system.
- Do not investigate or run new observability/code queries to manufacture a root cause.
- Do not assign owners.
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.