# Skill: Define hookify rules to block or warn on dangerous agent actions

> Lets an AI coding agent create persistent, file-based guard rules that intercept irreversible commands (file deletion, secret leaks, production DB writes) before they execute -- applies to any project where the agent has terminal or file-write access.

Source: sodigi·learn -- vibecoding/zashchita-ot-opasnyh-deystviy · https://sodigi.io/learn/vibecoding/zashchita-ot-opasnyh-deystviy

## When to use
- User is giving the agent broad autonomy over terminal commands or file writes.
- User wants persistent protection that survives restarts and new chat sessions.
- Project has secrets that could leak into git, or destructive commands that could delete irreplaceable work.
- User has already been burned by the agent doing something unexpected and wants a safety net.

## Core rules
- Rules must live in a **file** (in the `.claude/` folder inside the project), not in chat instructions. Chat instructions vanish after a restart or a compact; file-based rules are permanent.
- Every hookify rule answers three questions: **WHEN** (which event: bash, file, prompt, stop, all), **WHAT** (a regex pattern that identifies the dangerous action), **WHAT TO DO** (warn = flag but allow; block = hard stop, no exceptions).
- Use **warn** for: actions that are usually fine but occasionally worth flagging, style reminders, missing .gitignore notices.
- Use **block** for: irreversible deletions (rm -rf), writing secrets to tracked files, any command touching the production server or database.
- Make patterns **precise**. A pattern matching the word `rm` alone will catch "information" and "remove". The pattern should match the exact dangerous form, not a common word fragment.
- Every rule message must tell the agent **what to do instead** -- not just "no." A wall with no door causes the agent to loop.
- Rule file names should start with a verb: `block-rm-rf`, `warn-env-secrets`, `require-gitignore`.

## Procedure
1. Identify the top dangers for the project: destructive shell commands, secret exposure, production database access, debug code leaking to commit.
2. For each danger, decide: warn or block?
3. Create a rule file in `.claude/` (or ask the agent to generate it from a plain-language description).
4. Each rule file contains: `name`, `enabled: true`, `event`, `action` (warn/block), `pattern` (regex), and a human-readable `message` explaining what to do instead.
5. Test each rule by asking the agent to perform a safe, controlled version of the action and confirming the hook fires.
6. Do not add more than ~5-8 rules to start -- too many block rules paralyze the agent.

## Ready-to-use prompt
```
Create a hookify rule to protect against secret leaks in this project:

Rule specification:
1. Event: file write.
2. Fires when the file path ends in .env
   AND the new content contains API_KEY, SECRET, or TOKEN.
3. Action: warn (do not block).
4. Message to the agent: "You are writing a secret to .env.
   Confirm that this file is in .gitignore and will not reach a public repository."

Place the rule in the project's .claude folder.
Explain in plain words what it does and how to verify it fires correctly.
```

## Pitfalls
- Relying on chat instructions instead of a rule file -- the instruction disappears after a compact or a new session; the rule file is always there.
- Setting block on every action -- the agent becomes unable to work, and in frustration the user disables all hooks.
- Writing too broad a pattern (e.g., banning the string `rm`) -- it will match common words like "information" and block harmless actions.
- Writing a block message that just says "no" without explaining the correct alternative -- the agent loops trying to find a way forward.
- Never testing that the rule actually fires -- write it, then ask the agent to trigger a harmless version of the pattern and confirm the hook responds.
- Ignoring warn messages when the hook fires -- the guard flagged something real; read it before proceeding.