agentleFS
ValorVieValorVie/custom-skills/.agents/skills/writing-hookify-rules/SKILL.md

writing-hookify-rules

Skill5 starsChanged 36 days agoMITView on GitHub

This skill should be used when the user asks to "create a hookify rule", "write a hook rule", "configure hookify", "add a hookify rule", or needs guidance on hookify rule syntax and patterns.

  • Reads credentials
  • Deletes or force-pushes

8 other projects use a version of this.

Adopted by

Steady: 0 new projects took it in the last 4 weeks, none the 4 weeks before.thin data

Week of Sep 13: 0 new projectsWeek of Sep 20: 0 new projectsWeek of Sep 27: 0 new projectsWeek of Oct 4: 0 new projectsWeek of Oct 11: 0 new projectsWeek of Oct 18: 0 new projectsWeek of Oct 25: 0 new projectsWeek of Nov 1: 0 new projects
Sep 2026Oct 2026Nov 2026
New projects taking a version of this file each week, over the 8 weeks our latest run read: only 0 in all, so this is a hint, not a trend.

Most recently taken up by

The file

We split this skill into the rules it gives an agent

12 rules. About 0 are common, 6 are distinctive, and 6 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈6

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 6

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Very specific:

    Use kebab-case: warn-dangerous-rm, block-console-log

    line 32
  2. Distinctive:

    Start with verb: warn, prevent, block, require, check

    line 34
  3. Very specific:

    If omitted, defaults to warn

    line 51
  4. Distinctive:

    Use formatting for clarity (bold, lists, etc.)

    line 108
  5. Distinctive:

    Test regex patterns before using:

    line 256
  6. Distinctive:

    Recommendation: Use unquoted patterns in YAML

    line 281
  7. Very specific:

    Location: All rules in .claude/ directory

    line 285
  8. Very specific:

    Gitignore: Add .claude/*.local.md to .gitignore

    line 287
  9. Very specific:

    Create .claude/hookify.{name}.local.md file in project root

    line 308
  10. Distinctive:

    Test immediately - rules are read dynamically on next tool use

    line 309
  11. Distinctive:

    Test immediately - changes take effect on next tool use

    line 315
  12. Very specific:

    Permanent: Delete the .local.md file

    line 320

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Writing Hookify Rules

Overview

Hookify rules are markdown files with YAML frontmatter that define patterns to watch for and messages to show when those patterns match. Rules are stored in .claude/hookify.{rule-name}.local.md files.

Rule File Format

Basic Structure

---
name: rule-identifier
enabled: true
event: bash|file|stop|prompt|all
pattern: regex-pattern-here
---

Message to show Claude when this rule triggers.
Can include markdown formatting, warnings, suggestions, etc.

Frontmatter Fields

name (required): Unique identifier for the rule

  • Use kebab-case: warn-dangerous-rm, block-console-log
  • Be descriptive and action-oriented
  • Start with verb: warn, prevent, block, require, check

enabled (required): Boolean to activate/deactivate

  • true: Rule is active
  • false: Rule is disabled (won't trigger)
  • Can toggle without deleting rule

event (required): Which hook event to trigger on

  • bash: Bash tool commands
  • file: Edit, Write, MultiEdit tools
  • stop: When agent wants to stop
  • prompt: When user submits a prompt
  • all: All events

action (optional): What to do when rule matches

  • warn: Show message but allow operation (default)
  • block: Prevent operation (PreToolUse) or stop session (Stop events)
  • If omitted, defaults to warn

pattern (simple format): Regex pattern to match

  • Used for simple single-condition rules
  • Matches against command (bash) or new_text (file)
  • Python regex syntax

Example:

event: bash
pattern: rm\s+-rf

Advanced Format (Multiple Conditions)

For complex rules with multiple conditions:

---
name: warn-env-file-edits
enabled: true
event: file
conditions:
  - field: file_path
    operator: regex_match
    pattern: \.env$
  - field: new_text
    operator: contains
    pattern: API_KEY
---

You're adding an API key to a .env file. Ensure this file is in .gitignore!

Condition fields:

  • field: Which field to check
    • For bash: command
    • For file: file_path, new_text, old_text, content
  • operator: How to match
    • regex_match: Regex pattern matching
    • contains: Substring check
    • equals: Exact match
    • not_contains: Substring must NOT be present
    • starts_with: Prefix check
    • ends_with: Suffix check
  • pattern: Pattern or string to match

All conditions must match for rule to trigger.

Message Body

The markdown content after frontmatter is shown to Claude when the rule triggers.

Good messages:

  • Explain what was detected
  • Explain why it's problematic
  • Suggest alternatives or best practices
  • Use formatting for clarity (bold, lists, etc.)

Example:

⚠️ **Console.log detected!**

You're adding console.log to production code.

**Why this matters:**
- Debug logs shouldn't ship to production
- Console.log can expose sensitive data
- Impacts browser performance

**Alternatives:**
- Use a proper logging library
- Remove before committing
- Use conditional debug builds

Event Type Guide

bash Events

Match Bash command patterns:

---
event: bash
pattern: sudo\s+|rm\s+-rf|chmod\s+777
---

Dangerous command detected!

Common patterns:

  • Dangerous commands: rm\s+-rf, dd\s+if=, mkfs
  • Privilege escalation: sudo\s+, su\s+
  • Permission issues: chmod\s+777, chown\s+root

file Events

Match Edit/Write/MultiEdit operations:

---
event: file
pattern: console\.log\(|eval\(|innerHTML\s*=
---

Potentially problematic code pattern detected!

Match on different fields:

---
event: file
conditions:
  - field: file_path
    operator: regex_match
    pattern: \.tsx?$
  - field: new_text
    operator: regex_match
    pattern: console\.log\(
---

Console.log in TypeScript file!

Common patterns:

  • Debug code: console\.log\(, debugger, print\(
  • Security risks: eval\(, innerHTML\s*=, dangerouslySetInnerHTML
  • Sensitive files: \.env$, credentials, \.pem$
  • Generated files: node_modules/, dist/, build/

stop Events

Match when agent wants to stop (completion checks):

---
event: stop
pattern: .*
---

Before stopping, verify:
- [ ] Tests were run
- [ ] Build succeeded
- [ ] Documentation updated

Use for:

  • Reminders about required steps
  • Completion checklists
  • Process enforcement

prompt Events

Match user prompt content (advanced):

---
event: prompt
conditions:
  - field: user_prompt
    operator: contains
    pattern: deploy to production
---

Production deployment checklist:
- [ ] Tests passing?
- [ ] Reviewed by team?
- [ ] Monitoring ready?

Pattern Writing Tips

Regex Basics

Literal characters: Most characters match themselves

  • rm matches "rm"
  • console.log matches "console.log"

Special characters need escaping:

  • . (any char) → \. (literal dot)
  • ( ) → \( \) (literal parens)
  • [ ] → \[ \] (literal brackets)

Common metacharacters:

  • \s - whitespace (space, tab, newline)
  • \d - digit (0-9)
  • \w - word character (a-z, A-Z, 0-9, _)
  • . - any character
  • + - one or more
  • * - zero or more
  • ? - zero or one
  • | - OR

Examples:

rm\s+-rf         Matches: rm -rf, rm  -rf
console\.log\(   Matches: console.log(
(eval|exec)\(    Matches: eval( or exec(
chmod\s+777      Matches: chmod 777, chmod  777
API_KEY\s*=      Matches: API_KEY=, API_KEY =

Testing Patterns

Test regex patterns before using:

python3 -c "import re; print(re.search(r'your_pattern', 'test text'))"

Or use online regex testers (regex101.com with Python flavor).

Common Pitfalls

Too broad:

pattern: log    # Matches "log", "login", "dialog", "catalog"

Better: console\.log\(|logger\.

Too specific:

pattern: rm -rf /tmp  # Only matches exact path

Better: rm\s+-rf

Escaping issues:

  • YAML quoted strings: "pattern" requires double backslashes \\s
  • YAML unquoted: pattern: \s works as-is
  • Recommendation: Use unquoted patterns in YAML

File Organization

Location: All rules in .claude/ directory Naming: .claude/hookify.{descriptive-name}.local.md Gitignore: Add .claude/*.local.md to .gitignore

Good names:

  • hookify.dangerous-rm.local.md
  • hookify.console-log.local.md
  • hookify.require-tests.local.md
  • hookify.sensitive-files.local.md

Bad names:

  • hookify.rule1.local.md (not descriptive)
  • hookify.md (missing .local)
  • danger.local.md (missing hookify prefix)

Workflow

Creating a Rule

  1. Identify unwanted behavior
  2. Determine which tool is involved (Bash, Edit, etc.)
  3. Choose event type (bash, file, stop, etc.)
  4. Write regex pattern
  5. Create .claude/hookify.{name}.local.md file in project root
  6. Test immediately - rules are read dynamically on next tool use

Refining a Rule

  1. Edit the .local.md file
  2. Adjust pattern or message
  3. Test immediately - changes take effect on next tool use

Disabling a Rule

Temporary: Set enabled: false in frontmatter Permanent: Delete the .local.md file

Examples

See ${CLAUDE_PLUGIN_ROOT}/examples/ for complete examples:

  • dangerous-rm.local.md - Block dangerous rm commands
  • console-log-warning.local.md - Warn about console.log
  • sensitive-files-warning.local.md - Warn about editing .env files

Quick Reference

Minimum viable rule:

---
name: my-rule
enabled: true
event: bash
pattern: dangerous_command
---

Warning message here

Rule with conditions:

---
name: my-rule
enabled: true
event: file
conditions:
  - field: file_path
    operator: regex_match
    pattern: \.ts$
  - field: new_text
    operator: contains
    pattern: any
---

Warning message

Event types:

  • bash - Bash commands
  • file - File edits
  • stop - Completion checks
  • prompt - User input
  • all - All events

Field options:

  • Bash: command
  • File: file_path, new_text, old_text, content
  • Prompt: user_prompt

Operators:

  • regex_match, contains, equals, not_contains, starts_with, ends_with

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.