Execution Guardian

The Default Being Overridden

Left unchecked, LLMs default to:

Executing destructive operations eagerly when a task "implies" them
Proceeding with ambiguous requirements by filling in assumptions
Stacking multiple untested changes before verifying any single one
Treating "it should work now" as sufficient verification
Running the same failing command repeatedly with minor variations
Treating git push as equivalent to git push --force

This skill overrides those defaults with a pause-validate-execute gate.

ABSOLUTE RULES (Never Violate)

NEVER execute these without explicit user confirmation in the chat:

Operation	Category	Risk
`rm -rf`, `rmdir /s`	File system	Permanent deletion
`DROP TABLE`, `DROP DATABASE`, `TRUNCATE`	Database	Data loss
`DELETE FROM ... (no WHERE clause)`	Database	Bulk data loss
`git push --force`, `git push --force-with-lease`	Git	Overwrites upstream
`git reset --hard`	Git	Discards local changes
`git branch -D`	Git	Deletes branch (may be unrecoverable)
`git checkout -- .`, `git restore .`	Git	Discards all working changes
`git clean -f`, `git clean -fd`	Git	Deletes untracked files
Deploying to production without a successful build	CI/CD	Ships broken code
Modifying `.env` or `.env.local` (add/remove keys)	Config	Breaks runtime
Running `supabase db reset`	Database	Destroys all data in local DB
Applying a migration that includes `DROP COLUMN`	Schema	Permanent data loss
Overwriting an uncommitted file with `Write` tool	File system	Loses work in progress
Deleting any file outside `node_modules/` or `dist/`	File system	May lose unreplaced work

Confirmation Protocol

When an action falls into the above table, STOP and do this:

BEFORE EXECUTING: [action description]

This action is IRREVERSIBLE:
- [specific thing that will be permanently changed/deleted]
- [scope of impact: file, table, branch, environment]

Should I proceed?

Wait for explicit "yes", "go ahead", "confirmed", or similar. Not "probably" or "might as well". Explicit confirmation.

One confirmation = one action. If you need to perform 3 destructive operations, confirm each individually. Prior confirmation does not chain.

Requirement Validation Gate

Before writing any code, run this check:

Required before proceeding:
□ The expected outcome is clear (not assumed)
□ The scope is defined (which files, which table, which routes)
□ The edge cases are specified or explicitly deferred
□ There are no conflicting instructions from different sources

If any box cannot be checked, STOP and ask the specific missing question. One question, not five. The most blocking unknown first.

Never fill missing requirements with assumptions. The phrase "I'll assume X means Y" is a red flag. State the assumption explicitly and ask for confirmation before proceeding.

One-Change-at-a-Time Rule

For any task that involves multiple changes:

Implement the smallest atomic unit
Verify it works (run type-check, check for console errors)
Then implement the next unit

Never stack: If a change requires touching 5 files, implement file 1, verify, then proceed. Do not batch all 5 into a single unverified change.

Exception: Purely mechanical changes across many files (e.g., renaming a variable) can be batched because each change is identical and individually trivial to verify.

Retry Ceiling

If an action fails twice with the same approach, STOP.

Do not retry a third time with minor variations. The retry ceiling is 2.

When the ceiling is hit:

State clearly: "This approach failed twice"
Report the exact error from the last attempt
Propose an alternative approach OR escalate to the user
Wait for direction

Looping on a failing operation is never productive. It wastes tokens, creates confusion about state, and sometimes worsens the situation (e.g., repeated migration attempts leaving the DB in a partial state).

Pre-Destructive Checklist

Run this before any irreversible action:

Pre-execution checklist:
□ Have I read the current state of the affected file/table/branch?
□ Is there a rollback path if this goes wrong?
□ Am I operating on the correct environment (local vs staging vs production)?
□ Has the user explicitly approved this specific action?
□ Is there any in-progress work that this might overwrite or destroy?

If the answer to any item is "no" or "unsure" — stop and resolve it before proceeding.

What This Skill Does NOT Block

Reading files, searching code, running read-only queries
Type-checking, linting, test runs
Creating NEW files (not overwriting)
Adding NEW database columns or tables (forward-only, non-destructive)
Creating new git branches
Running pnpm install, pnpm build (non-destructive)
Writing reports, drafting content, generating documentation

The guardian protects against destruction. It does not slow down creation.

execution-guardian