step-back
Skill1 starsChanged 3 months agoMITView on GitHub
Use before voicing any recommendation, fix, or config change whose mechanism has not been checked; when debugging or diagnosing, especially during a live incident; when a previous suggestion had to be retracted; when consecutive small fixes have failed; or when the user says the agent is thrashing, guessing, flailing, or asks it to slow down and ground itself.
2 other projects use a version of this.
Adopted by
Most recently taken up by
- iiiburnyiii/agent-skillstheir own version, first seen May 14, 2026
- EntradaInteractiveLLC/claude-skillstheir own version, first seen Apr 15, 2026
Other versions2 projects use a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 2
- EntradaInteractiveLLC/claude-skills★ 2same name
- iiiburnyiii/agent-skills★ 0same name
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 repository5 other files it gives its agents.
- before-and-afterSkill
- brevitySkill
- handoffSkill
- respawnSkill
- solveSkill
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 33
Before asserting absence: run a query that MUST return something, and look in at least one other place or phrasing.
- Distinctive: line 45
If the previous fix did not work, the next action is NOT another fix.
- Distinctive: line 46
After two consecutive failed fixes, stop is mandatory: state plainly what is known, what is assumed, and what the failed attempts rule out.
- Distinctive: line 47
Do not propose a fix mid-incident.
≈ “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
Step Back
Overview
Do not float a recommendation until the mechanism it depends on has been checked. Take the extra minute: read the code path, find where the value is actually consumed, run the probe, and then speak. This applies to plain advice, and especially to code and configuration changes.
An unverified idea labelled as unverified is fine ("worth checking, I haven't confirmed X"). An unverified idea presented as a recommendation is not. Every retraction burns the user's time, erodes trust in every other claim made, and for config changes risks degrading a live, working system.
Sanity check before sending any suggestion: what would have to be true for this to be wrong, have I actually looked, and would a single cheap query settle it?
The traps
Each of these produced a real, confident proposal that had to be retracted a turn later.
| Trap | Discipline |
| Coupled or derived values. A "safe" threshold increase fed a second setting derived from it (budget = threshold × ratio); the change would have cut retained data 4x and fought an adjustment made an hour earlier. | Before recommending a setting, check what else consumes or derives from it. |
| Restart/reload semantics. A config section was claimed to hot-reload; the values are read once at process init, so running instances silently keep old values. | Never state that a change takes effect without finding where the value is read. |
| "One-line fix" claims. A bug called a one-line diff had 13 call sites feeding keys and allowlists; the safe fix was a different, narrower change. | Count the call sites before sizing the fix. |
| Inferring identity or membership from names/counts. A group's membership was inferred from four cache filenames; one belonged to the service's own account, so a real member stayed blocked. One API call to the authoritative source settled it. | Query the authoritative source; filenames and counts are not it. |
| Stale file:line citations. Line numbers drift silently across dependency updates. | Re-verify citations after any update. |
| Speculative optimization. A projection with wide error bars is the weakest basis for degrading something that works. | Prefer adding early warning (a monitor, a threshold alert) over changing behavior now. |
Negative results need a positive control
"I searched and found nothing" is the weakest possible basis for "it doesn't exist", and it fails in two ways: the search itself can be broken (an invalid CLI flag made every query error while the wrapper printed "no matches", nearly turning three already-filed issues into "unfiled"), and the search can be aimed at the wrong place (a grep of one file "proved" a code path didn't exist; it was documented in an adapter and worked by an indirect route).
Before asserting absence: run a query that MUST return something, and look in at least one other place or phrasing.
Establish scope before proposing a remedy
One observation is not a general failure. Ask "where does this NOT happen?"; the contrast is usually the diagnosis. A single timeout in one context led to a proposal to disable the whole feature; a one-line grep of the same log showed 11-18s completions in one-on-one use vs 600s only in the group context. The feature was fine; one context failed. That grep directly measured the behavior under discussion, was available from the first minute, and was run third.
The cheapest diagnostic that measures the actual thing goes FIRST.
Stop the tweak loop
The failure compounds when fixes stack: tweak, fail, tweak again, each proposal made on top of the last unverified one.
- If the previous fix did not work, the next action is NOT another fix. Something in the mental model is wrong, and another tweak samples the same broken model.
- After two consecutive failed fixes, stop is mandatory: state plainly what is known, what is assumed, and what the failed attempts rule out; run the cheapest diagnostic that measures the actual behavior; establish scope; then present ONE grounded proposal with its mechanism verified.
- Do not propose a fix mid-incident. While something is still unfolding, gather; propose once, after. Interleaving half-diagnoses with remediation advice produces exactly the suggest-and-backtrack pattern, and each revision costs more credibility than the fix was worth.
Red flags: stop if you catch yourself thinking
| Thought | Reality |
| "I'm pretty sure that's how it works" | Pretty sure is the tell. Read the consumer, or label the idea unverified. |
| "This is obviously a one-line fix" | Count the call sites first. |
| "The search returned nothing, so it doesn't exist" | Broken or misaimed searches also return nothing. Positive control first. |
| "Just one more tweak, this one will do it" | A failed fix falsifies the model that produced the next one. Stop and ground. |
| "The incident is live, they need suggestions NOW" | Mid-incident they need facts and scope. The proposal comes once, after. |
| "I'll propose it now and verify if they push back" | The user cannot tell checked claims from unchecked ones. That asymmetry is the whole problem. |
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.