Destructive Operation Guard

CRITICAL: This skill defines mandatory safety protocols for AI agents.

Core Principle

NEVER execute a destructive operation without EXPLICIT user confirmation.

"Destructive" means any operation that:

• Deletes data

• Overwrites existing data

• Resets state

• Cannot be easily undone

• Affects production systems

• Modifies data belonging to others

Destructive Operations Checklist

ALWAYS ASK BEFORE:

Database Operations

• DROP TABLE , DROP DATABASE

• TRUNCATE TABLE

• DELETE without specific WHERE clause

• DELETE affecting more than 10 rows

• UPDATE without specific WHERE clause

• UPDATE affecting more than 10 rows

• Running migrations on production

• Running migrations that delete columns/tables

• Seeding that overwrites existing data

• Any --force flag on database commands

File System Operations

• rm -rf on any directory

• rm on multiple files

• Overwriting existing files

• Moving files that might overwrite destinations

• Clearing directories

• Any recursive delete operation

Git Operations

• git push --force or git push -f

• git reset --hard

• git clean -fd

• git checkout . (discards all changes)

• git stash drop

• git branch -D (force delete)

• git rebase on shared branches

• Amending pushed commits

Deployment Operations

• Deploying to production

• Rolling back deployments

• Scaling down to zero

• Deleting cloud resources

• Modifying environment variables in production

API/Service Operations

• Calling DELETE endpoints

• Bulk update operations

• Cache invalidation (full flush)

• Queue purging

• Session/token invalidation for all users

Mandatory Confirmation Protocol

Step 1: Identify the Risk

Before ANY potentially destructive operation, assess:

Risk Assessment

Operation: [What you're about to do] Scope: [What will be affected] Reversibility: [Can this be undone? How?] Data at Risk: [What data could be lost] Affected Users: [Who will be impacted]

Step 2: Present to User

ALWAYS show the user:

⚠️ DESTRUCTIVE OPERATION WARNING

I'm about to perform an operation that could result in data loss.

Action: [Specific command/operation] Impact:

• [Specific impact 1]
• [Specific impact 2]

Data that will be affected:

• [Specific data 1]
• [Specific data 2]

This action is [REVERSIBLE/IRREVERSIBLE].

[If reversible: "Recovery method: [how to recover]"] [If irreversible: "⛔ THIS CANNOT BE UNDONE"]

Do you want me to proceed? Please confirm with "yes" or "proceed".

Step 3: Require Explicit Confirmation

ONLY proceed if user explicitly says:

• "yes"

• "proceed"

• "confirm"

• "do it"

• "go ahead"

DO NOT proceed if user says:

• "ok" (ambiguous)

• "sure" (ambiguous)

• Anything that could be interpreted as casual agreement

• Nothing (silence is NOT consent)

Step 4: Create Safety Net BEFORE Execution

For database operations

pg_dump database_name > backup_$(date +%Y%m%d_%H%M%S).sql

For file operations

cp -r target_directory target_directory.backup.$(date +%Y%m%d_%H%M%S)

For git operations

git stash git branch backup-$(date +%Y%m%d_%H%M%S)

Step 5: Execute with Logging

Log the operation

echo "[$(date)] DESTRUCTIVE OP: [command]" >> ~/.destructive_ops.log echo "[$(date)] USER CONFIRMED: yes" >> ~/.destructive_ops.log echo "[$(date)] BACKUP LOCATION: [backup_path]" >> ~/.destructive_ops.log

Execute

[actual command]

Log result

echo "[$(date)] RESULT: $?" >> ~/.destructive_ops.log

Examples of Proper Guardrails

Example 1: Database Migration

WRONG:

User: "Run the migration" AI: [Runs migration immediately]

RIGHT:

User: "Run the migration" AI: "Before running the migration, I need to check a few things:

1. Checking migration status...

   • 3 pending migrations found
   • Migration 2024_01_15_drop_users_table will DROP the legacy_users table

2. Checking existing data...

   • legacy_users table has 1,247 records

⚠️ WARNING: This migration will permanently delete 1,247 user records.

Before proceeding, I recommend:

• Creating a backup: pg_dump -t legacy_users db > legacy_users_backup.sql
• Verifying these records are not needed
• Confirming you have a rollback plan

Do you want me to: A) Create a backup first, then run migration B) Show me the migration file content first C) Run migration without backup (NOT RECOMMENDED) D) Cancel

Please choose an option."

Example 2: Resetting Development Environment

WRONG:

User: "Reset the database" AI: [Runs db:reset immediately]

RIGHT:

User: "Reset the database" AI: "I'll help you reset the database. First, let me check the current state:

Current database: myapp_development Tables: 47 tables Total records: 15,234 records

Records by table (top 5):

• users: 523 records
• orders: 8,921 records
• products: 1,245 records
• logs: 4,102 records
• sessions: 443 records

⚠️ A database reset will:

1. Drop ALL tables
2. Delete ALL 15,234 records
3. Recreate schema from migrations
4. Run seeders (if configured)

Is this a development or production database?

If development, I can proceed with your confirmation. If production, I STRONGLY recommend against this operation.

Type 'yes, reset development database' to confirm, or 'cancel' to abort."

Example 3: Git Force Push

WRONG:

User: "Force push to fix the history" AI: git push --force

RIGHT:

User: "Force push to fix the history" AI: "Before force pushing, I need to verify this is safe:

Current branch: feature/user-auth Remote tracking: origin/feature/user-auth Local commits ahead: 3 Remote commits that will be OVERWRITTEN: 2

⚠️ Force pushing will:

• Overwrite 2 commits on the remote
• These commits may be lost if not backed up elsewhere
• Other developers pulling this branch will have conflicts

Safety checks:

• Is this a shared branch? (Others may have based work on it)
• Do you have the overwritten commits backed up?
• Have you notified team members?

I recommend using --force-with-lease instead of --force:

git push --force-with-lease origin feature/user-auth

This will fail if the remote has commits you haven't seen, preventing accidental data loss.

Proceed with:
A) --force-with-lease
 (safer)
B) --force
 (I understand the risks)
C) Cancel"

## Recovery Information

Always provide recovery information BEFORE the operation:

```markdown
## Recovery Plan

**If something goes wrong:**

1. **Backup location:** [path]
2. **Restore command:** [command]
3. **Point of no return:** [when recovery becomes impossible]
4. **Who to contact:** [if applicable]

Red Flags - STOP Immediately

If you encounter these, STOP and ask for clarification:

- 
Production indicators:

- Database URL contains "prod", "production", "live"

- Environment variables show NODE_ENV=production

- Server hostname contains production identifiers

- 
Scale indicators:

- More than 1000 records to be affected

- Multiple tables involved

- Operation affects shared resources

- 
Ambiguous requests:

- "Clean up the database"

- "Reset everything"

- "Start fresh"

- "Remove all the old data"

- 
Missing context:

- No clear scope defined

- No backup mentioned

- No rollback plan discussed

Best Practices Summary

- ASK FIRST - Always confirm before destructive operations

- BACKUP FIRST - Create safety net before execution

- SCOPE CLEARLY - Show exactly what will be affected

- PROVIDE OPTIONS - Give user choices, including "cancel"

- LOG EVERYTHING - Record what was done for audit trail

- VERIFY ENVIRONMENT - Double-check prod vs dev

- SMALLEST SCOPE - Do minimum necessary, not maximum possible

- REVERSIBILITY - Always explain if/how to undo