Guard

What Is This?

Overview

Guard is a development safety mode that combines two critical protection layers into a single, unified workflow: destructive command warnings and directory-scoped editing restrictions. It activates a maximum-protection environment designed for situations where mistakes carry serious consequences, such as working on production systems, debugging live infrastructure, or making changes to sensitive codebases.

At its core, Guard merges the behavior of two distinct safety mechanisms. The first warns developers before executing destructive commands like rm -rf, DROP TABLE, or force-push operations. The second blocks any file edits that fall outside a specified directory boundary. Together, these layers create a controlled environment where accidental damage becomes significantly harder to cause.

Guard is particularly valuable in high-stakes scenarios where a single mistyped command or an edit to the wrong file could trigger downtime, data loss, or irreversible system changes. It is designed to be activated quickly using natural language triggers such as "guard mode," "full safety," "lock it down," or "maximum safety," making it accessible even under pressure.

Who Should Use This

• Backend engineers working directly on production databases or live API services who need a safety net before running schema migrations or destructive queries.
• DevOps and infrastructure engineers managing deployment pipelines where force-push or environment variable changes could break running services.
• Junior developers who are new to a codebase and want guardrails that prevent accidental edits outside their assigned working directory.

Why Use It?

Problems It Solves

• Accidental destructive commands: Without Guard, a mistyped rm -rf or an unintended DROP TABLE executes immediately with no confirmation, leaving no opportunity to catch the mistake before damage occurs.
• Scope creep during edits: Developers working in one module can accidentally modify files in unrelated directories, introducing subtle bugs or breaking unrelated features.
• High-pressure mistakes: During incident response or live debugging, engineers operate under stress. Guard adds a friction layer that forces a moment of confirmation before irreversible actions proceed.

Core Highlights

• Warns before executing rm -rf, DROP TABLE, git push --force, and similar destructive operations
• Blocks file edits outside a specified directory scope
• Activates through natural language triggers for fast deployment under pressure
• Combines two safety layers into a single mode for maximum protection
• Uses pre-tool hooks to intercept commands before execution
• Supports Bash, Read, and AskUserQuestion as allowed tools
• Designed for production and live system workflows
• Minimal configuration required for immediate use

How to Use It?

Basic Usage

Activate Guard by invoking it with any of its recognized trigger phrases in your development session:

"Enable guard mode"
"Lock it down"
"Full safety on"
"Maximum safety"

Once active, any destructive command will trigger a confirmation prompt before execution:

## Attempting this command in Guard mode:
rm -rf ./logs

## Guard intercepts and prompts:
## WARNING:

This command will permanently delete ./logs and all contents.
## Confirm? (yes/no)

Specific Scenarios

Scenario 1: Production database migration

Before running a schema migration on a live database, activate Guard. Any DROP TABLE or ALTER TABLE statement will require explicit confirmation, giving you a final review opportunity.

-- Guard will intercept this before execution:
DROP TABLE user_sessions;

Scenario 2: Directory-scoped feature work

When working inside /src/payments, Guard blocks any edit attempts targeting files outside that directory, preventing accidental changes to /src/auth or /config.

Scenario 3: Incident response

During a live outage, activate Guard immediately. All force-push attempts and file deletions will pause for confirmation, reducing the risk of compounding the incident.

Real-World Examples

• A developer running cleanup scripts on a staging server activates Guard to prevent accidentally targeting the production file path.
• An on-call engineer debugging a payment service uses Guard to restrict edits to the payments module only.
• A database administrator running maintenance queries enables Guard before connecting to the production replica.

When to Use It?

Use Cases

• Deploying hotfixes directly to production environments
• Running database migrations on live systems
• Debugging active services during an incident
• Performing infrastructure changes on shared environments
• Cleaning up files or directories on remote servers
• Reviewing and modifying sensitive configuration files
• Working in codebases where multiple modules share similar directory structures

Important Notes

Requirements

• Guard must be activated explicitly at the start of a session before any risky commands are run.
• The directory scope must be defined clearly when using the edit-restriction layer, otherwise the boundary cannot be enforced.
• Allowed tools are limited to Bash, Read, and AskUserQuestion during Guard sessions.
• The environment must support pre-tool hook execution for interception to function correctly.