setback-check
Skill0 starsChanged 3 months agoMITView on GitHub
Use at specific moments — before certifying a preflight, before counting a dispatch as returned, before declaring work complete, before git or publish operations, and before trusting a negative search result. Reads only the incidents tagged for that moment. Never read the whole log at startup.
In this repository14 other files it gives its agents.
- capability-scanSkill
- conveneSkill
- decision-recordSkill
- deliverySkill
- escalateSkill
- flag-checkSkill
- haltSkill
- interface-contractSkill
- merge-guardSkill
- profile-bootstrapSkill
- roster-preflightSkill
- setback-logSkill
- stability-checkpointSkill
- work-orderSkill
The file
We split this skill into the rules it gives an agent
5 rules. About 0 are common, 2 are distinctive, and 3 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈2
Distinctive · estimate
This author's own choices. Worth a look.
3
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 14
Do not load every incident at startup.
- Very specific: line 34
Read INDEX.md — the table only, from .agentic/incidents/ for the project and this framework's docs/incidents/ for the machinery.
- Distinctive: line 39
If a matching incident's closure is a GUARD, confirm the guard is actually in place — a guard that was reverted is worse than none, because …
- Very specific: line 48
Before verify, and before preflight, ask the question this log keeps answering:
- Very specific: line 65
Run setback-log. Do it at the time — the exact error text is the most valuable part and it is gone in ten minutes.
≈ “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
Setback check
An incident log that is written but never read is archaeology. This is the read side — deliberately narrow, because the failure mode of a mistakes file is that it grows until nobody reads it, including agents.
Never read the whole log
Do not load every incident at startup. A 40-entry log costs context on every run, gets skimmed, and buries the two entries that mattered under thirty-eight that did not. Read by trigger, at the moment the trigger fires.
The triggers
| Trigger | Fires before you… |
preflight | certify a roster or declare a component available |
dispatch | count a returned session as a result |
verify | declare work complete, fixed, passing, or done |
git | worktree, checkout, push, or branch operations |
search | trust a negative result from a search or traversal tool |
write | generate a file others or agents will read as data |
shell | run a command across a shell or OS boundary |
setup | install, authenticate, or configure a harness |
publish | do anything outward-facing or irreversible |
How to check
- Read
INDEX.md— the table only, from.agentic/incidents/for the project and this framework'sdocs/incidents/for the machinery. - Take rows whose Triggers column contains the firing trigger.
- The title and closure are usually enough. Open the full entry only when the situation in front of you resembles it.
- If a matching incident's closure is a GUARD, confirm the guard is actually in place — a guard that was reverted is worse than none, because everyone believes it is there.
Typically one to three rows match. If a trigger routinely matches ten, the tagging is too loose — tighten it rather than reading them all.
The check that matters most
Before verify, and before preflight, ask the question this log keeps
answering:
Did a check succeed and mean nothing?
Nine of the eleven incidents in this framework's own log share exactly that shape. A binary resolved but could not execute. A traversal tool returned zero from a directory full of files. A model list came back empty for working agents. A dispatched session returned on time carrying the wrong conversation. A directory was fully readable and was not a repository.
The general form: a negative or empty result is not evidence until you have confirmed the tool can see the thing at all. Invoke, do not resolve. Read a file, do not count files. Check that a return answers the question you asked.
When you hit something new
Run setback-log. Do it at the time — the exact error text is the most
valuable part and it is gone in ten minutes.
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.