| name | data-loss-guard |
| description | Stop-and-check protocol before any destructive or hard-to-reverse operation — rm, overwrite, force-push, reset --hard, DROP, bulk delete, killing processes. Use the moment a planned action would destroy state that cannot be trivially recreated. |
data-loss-guard
Almost every catastrophic agent failure is a destructive command run on a wrong assumption. Before any destructive action:
- Look at the target first.
ls the directory before rm -rf; git status/git stash list before reset --hard or checkout .; SELECT before DELETE/UPDATE (same WHERE clause, check the row count). If what you find contradicts what you expected — files you didn't create, more rows than predicted — stop and surface it instead of proceeding.
- Distinguish recoverable from gone. Committed work is recoverable via reflog; uncommitted work is not. A dropped column is gone. Overwritten files have no undo. Rank the action's blast radius honestly before choosing convenience.
- Prefer the reversible variant:
git stash over discard; move to a trash/backup path over rm; soft-delete or export-then-delete over hard delete; --dry-run flags wherever they exist (rsync, terraform, kubectl, many CLIs) on the first pass.
- Scope the command tightly. No wildcards where an explicit list will do; absolute paths so a surprise cwd can't redirect the deletion; never
rm -rf a variable-built path without checking the variable is non-empty and expected.
- Uncommitted user work is sacred. If the working tree holds changes you didn't make, don't clean, checkout, or stash over them without the user's explicit say-so — that's their morning, not your scratch space.
- Force-push and history rewrites on shared branches need explicit user authorization, every time.
Rule of thumb: cheap check, irreversible mistake — the one-command look-before-delete is always worth it.
