Tooling Note
`shell-guard` exists because expensive Git mistakes are usually boring, local, and preventable. The issue is rarely that Git is weak. The issue is that normal commands stay powerful even when context is wrong.
The practical problem was protecting active work during normal development: the wrong branch, the wrong staged files, the wrong command, or a local state that was less safe than it looked.
Those failures are easy to dismiss because each one looks small in isolation. In aggregate they cost focus, create recovery work, and can damage confidence in the repo itself.
Native Git hooks help, but they are often fragmented, repo-specific, and easy to bypass without much visibility. Broader policy tools can enforce rules at team scale, but many of them operate later than the moment of local risk.
What was missing was a lightweight local layer that focused on ordinary integrity failures at the exact point a developer is about to do something costly.
This kind of tool is more trustworthy when people can inspect what is being blocked and why. For local integrity guardrails, hidden logic is a weak fit. The assumptions should be visible, debatable, and easy to adapt.
It also maps cleanly to other workflows. The specific repo changes, but the operational pattern stays the same: detect local danger early and reduce the chance of self-inflicted damage.
On Hubsays, `shell-guard` is one example of the broader live-systems philosophy: small, readable tools that protect real work by narrowing avoidable failure paths.