Step 1 of 4
Define the danger rule set
Enumerate what must never run silently - concretely.
Write the danger rules as data. COMMAND PATTERNS (normalized before matching: resolve quoting, collapse whitespace): recursive deletion (rm -rf and equivalents on any path), git destructive ops (force-push, hard reset on shared branches, clean -fdx), bulk data ops (DROP/TRUNCATE, mass UPDATE without WHERE), package/system mutations (global installs, chmod -R 777, curl piped to shell). PROTECTED PATHS for writes and deletes: .env* and secret/key files, .git internals, paths outside the workspace root, CI and infra configs (approval, not block). Assign each rule a verdict (approval vs block) and a reason string. Store as a versioned config file. Review the list against my actual toolset and add tool-specific rules where needed.
Expected after this step
A versioned danger-rule config with verdicts and reasons.
Should not happen
- ✕Safety rules living in the system prompt where clever phrasing routes around them
- ✕Pattern rules so naive that rm -rf ./ passes because the pattern expected rm -rf /
- ✕Hooks that crash the loop instead of returning verdicts
- ✕No project extensibility, so real deployments disable the layer entirely
Verify before continuing
Do not move on until every check is true. The complete button stays locked until then.
Do not continue if…
- !Safety rules living in the system prompt where clever phrasing routes around them
- !Pattern rules so naive that rm -rf ./ passes because the pattern expected rm -rf /
- !Hooks that crash the loop instead of returning verdicts
- !No project extensibility, so real deployments disable the layer entirely
If the AI messes this up
Use this when the AI fakes progress or breaks the feature. It forces a real fix.
The list is generic. Walk each of my tools asking 'what is the worst call this accepts?' and write a rule for every answer - the rule set must reflect this harness, not a textbook.