/guard — Safety Guardrails

You have activated safety guardrails. These protect against accidental destructive operations during this session.

Modes

The user may activate a specific mode. If no mode is specified, default to careful.

Careful Mode (default)

What it does: Warns before any potentially destructive operation but does not block.

When you detect a destructive operation, pause and present:

⚠️  GUARD: Potentially destructive operation detected
Operation: {{what you're about to do}}
Impact: {{what could go wrong}}
Reversible: {{yes/no — if yes, how}}

Proceed? [y/n]

Use AskUserQuestion to get explicit confirmation before proceeding.

Destructive operations include:

rm -rf, rm -r on directories
git reset --hard, git push --force, git branch -D
DROP TABLE, DELETE FROM without WHERE, TRUNCATE
kubectl delete, docker rm, docker system prune
Writing to production configs or .env files
Modifying CI/CD pipeline files
Any operation the guard/bin/check-dangerous.sh script flags

Freeze Mode

What it does: Blocks all file writes (Edit, Write) outside of a specified scope.

When the user says /freeze or /guard freeze:

Ask which directories/files are in scope (or accept them as arguments)
Store the scope in guard/config.json
For the remainder of the session, block any Edit or Write operation outside the frozen scope

// guard/config.json
{
  "mode": "freeze",
  "allowed_paths": [
    "src/feature/**",
    "tests/feature/**"
  ],
  "frozen_at": "2025-01-01T00:00:00Z"
}

When a write is attempted outside scope:

🔒 GUARD FREEZE: Write blocked
File: {{path}}
Reason: Not in allowed scope
Allowed: {{list of allowed paths}}

To unfreeze: /unfreeze

Unfreeze Mode

What it does: Removes freeze restrictions.

When the user says /unfreeze or /guard unfreeze:

Remove the freeze config
Confirm guardrails are now in careful mode (not fully off)

🔓 GUARD: Freeze lifted. Returning to careful mode.

The Check Script

guard/bin/check-dangerous.sh uses a three-tier permission system inspired by Claude Code auto mode:

Tier 1: Allowlist. Commands like git status, ls, cat, jq skip all checks. Safe by definition.

Tier 2: In-project. Operations that only touch files inside the current git repo pass through. They're reviewable via version control.

Tier 3: Pattern matching. Everything else is checked against block and warn rules in guard/rules.json.

When a command is blocked, guard suggests a safer alternative instead of just failing:

BLOCKED [G-007] Force push overwrites remote history
Category: history-destruction
Command: git push --force origin main

Safer alternative: git push --force-with-lease (safer, fails if remote changed)

Configurable rules

Rules live in guard/rules.json. 28 block rules and 9 warn rules ship by default across 7 categories: mass-deletion, history-destruction, database-destruction, infra-destruction, production-access, remote-code-execution, security-degradation, safety-bypass.

Users can add custom rules by editing guard/rules.json. Each rule has an ID, regex pattern, category, description, and (for block rules) a safer alternative.

Gotchas

Guard is session-scoped. It activates when you invoke /guard and lasts until the session ends. It does not persist across sessions. This is intentional — always-on guardrails train people to ignore them.
Careful mode warns, it does not block. The user can always say "yes, proceed." The point is to force a conscious decision, not to prevent all risk.
Freeze mode is for focus, not security. It prevents accidental edits to unrelated files during debugging. It's not an access control mechanism.
Don't guard trivial operations. rm on a single test file is not dangerous. rm -rf / is. The script is calibrated for genuinely destructive patterns.
The script is a first line, not the only line. Use your judgment too. A command that passes the script but clearly targets production should still be flagged.