undo — independently scanned and version-tracked by SaferSkills.
SaferSkills independently audited undo (Agent Skill) and scored it 92/100 (green). The audit ran 55 deterministic rules across Security, Supply Chain, Maintenance, Transparency, and Community; it found 0 high-severity and 2 lower-severity findings. The full rule-by-rule trace and per-finding evidence are below. Free, methodology-open.
Findings & checks · 2 flagged
The text {match} tells the agent to skip the normal "ask the user first" gate. Used adversarially it removes the human-in-the-loop check before destructive or sensitive actions, turning a normally-gated agent into a fire-and-forget executor.
The text {match} tells the agent to skip the normal "ask the user first" gate. Used adversarially it removes the human-in-the-loop check before destructive or sensitive actions, turning a normally-gated agent into a fire-and-forget executor.
Every scanned point with the score it earned and what moved between them.
First recorded scan — no prior version to compare against.
The primary manifest — the file an agent reads to learn what this artifact does.
Wraps bin/undo.sh. History-mutating operation — treat as destructive.
Before any mutation, run bin/undo.sh --dry-run and show the user which commits will be undone. The preview JSON lists them newest- first with SHA and subject. Read it back and ask the user to confirm — even for a single-commit undo.
Exception: the user's request explicitly included "don't ask" / "just do it" AND --count is 1 AND --strategy is soft (the safest default). For anything multi-commit or non-soft, always confirm.
Default is soft (safest — all changes stay staged). When the user's intent is unclear, you MUST call the `AskUserQuestion` tool (not plain text):
{
"questions": [
{
"question": "How should the commit be undone?",
"header": "Strategy",
"multiSelect": false,
"options": [
{ "label": "Soft (Recommended)", "description": "Undo commit, keep changes staged" },
{ "label": "Mixed", "description": "Undo commit, keep changes in working tree (unstaged)" },
{ "label": "Hard", "description": "Undo commit AND discard all changes permanently" }
]
}
]
}For hard, warn the user twice: the work is gone after hard reset. Confirm before executing even after the picker selection.
when the user says "undo the last 3 commits" or similar.
last-N-commits is more dangerous because commits partway down the stack are harder to recover. For N > 3, suggest using git reflog + targeted revert instead of a bulk reset.
| Refusal reason | What to tell the user |
|---|---|
long-lived branch | "Can't undo on main/master/develop. Use git revert <sha> to create a reverting commit." |
merge commit | "HEAD is a merge commit — undo with git revert -m 1 <merge-sha> manually." |
already on upstream | "The commit is already pushed to <upstream>. Either git revert it (safe) or pass --allow-pushed to force-push after the reset (only if nobody else pulled)." |
detached HEAD | "Detached HEAD — checkout a branch first." |
fewer than N commits | "Branch only has M commits; can't undo N." |
bin/undo.sh --target <cwd> \
[--scope last-commit|last-N-commits] [--count N] \
[--strategy soft|mixed|hard] [--allow-pushed] [--dry-run]On success, echo back:
undone_commits).or gone (hard).
soft/mixed: suggest git status to see what's pending.git reflog canrecover the discarded history if they change their mind soon.
commit skill after undo.commit with --allow-pushed), they'll need git push --force-with-lease. Don't run this automatically; explain and let them decide.
git reflog + git reset --hard <prior-sha>.Handle this as a separate one-off; don't add reflog logic to the undo skill itself.
~30 seconds. Free. No account. Every finding cites a rule and a line of evidence.