Claude-kit hookify

Create dynamic hook rules from natural language descriptions. Generates .claude/hookify.*.local.md files that warn or block operations matching patterns. Triggers on "hookify", "create hook rule", "warn me when", "block when", "don't let me".

install
source · Clone the upstream repo
git clone https://github.com/luiseiman/dotforge
Claude Code · Install into ~/.claude/skills/
T=$(mktemp -d) && git clone --depth=1 https://github.com/luiseiman/dotforge "$T" && mkdir -p ~/.claude/skills && cp -r "$T/stacks/hookify/skills/hookify" ~/.claude/skills/luiseiman-claude-kit-hookify && rm -rf "$T"
manifest: stacks/hookify/skills/hookify/SKILL.md
source content

Hookify — Dynamic Hook Rules

Create hook rules from natural language without editing hooks.json.

Step 1: Understand Intent

Parse the user's description to determine:

  • Event type: bash (commands), file (edits/writes), stop (session end), prompt (user input)
  • Action: warn (show message, allow) or block (deny operation)
  • Pattern: regex to match against the relevant field
  • Field: what to match (command, file_path, new_text, user_prompt, etc.)

Examples:

  • "Warn me when I use rm -rf" → event: bash, action: warn, pattern:
    rm\s+-rf
  • "Don't let me edit .env files" → event: file, action: block, field: file_path, pattern:
    \.env$
  • "Block console.log in TypeScript" → event: file, action: warn, field: new_text, conditions on file_path AND new_text
  • "Don't stop without running tests" → event: stop, action: block, field: transcript, operator: not_contains, pattern:
    pytest|npm test

Step 2: Generate Rule File

Create

.claude/hookify.<short-name>.local.md
:

---
name: <descriptive-kebab-case-name>
enabled: true
event: <bash|file|stop|prompt>
action: <warn|block>
pattern: <regex>  # for single-condition rules
---

<Warning/block message in markdown. Be helpful — explain WHY and suggest alternatives.>

For multi-condition rules:

---
name: <name>
enabled: true
event: <event>
action: <action>
conditions:
  - field: <field>
    operator: <regex_match|contains|not_contains|equals|starts_with|ends_with>
    pattern: <value>
  - field: <field>
    operator: <operator>
    pattern: <value>
---

<Message>

Step 3: Confirm

Show the user:

  1. The generated file path and content
  2. What it will catch (with example triggers)
  3. What it will NOT catch (edge cases)

Step 4: Test Suggestion

Suggest a way to test the rule immediately:

  • For bash rules: "Try running
    <command that triggers>
    "
  • For file rules: "Try editing a file matching the pattern"
  • For stop rules: "The rule will trigger next time the session ends"

Rule Naming Convention

  • hookify.block-rm-rf.local.md
    — block dangerous rm
  • hookify.warn-console-log.local.md
    — warn about debug code
  • hookify.require-tests.local.md
    — require tests before stopping
  • hookify.warn-env-edit.local.md
    — warn about .env edits

Management Commands

If user asks to list/manage rules:

  • List:
    ls .claude/hookify.*.md
    and show name + event + action + enabled for each
  • Disable: set
    enabled: false
    in frontmatter
  • Delete: remove the file
  • Enable: set
    enabled: true
    in frontmatter

Notes

  • Rules take effect immediately — no restart needed
  • .local.md
    files are gitignored by convention
  • To share rules with the team, drop the
    .local
    suffix
  • Keep regex patterns simple — complex patterns are hard to maintain
  • Prefer
    warn
    over
    block
    for most cases
  • All conditions in a rule must match (AND logic)
  • No external dependencies — stdlib Python only