fix(hookify): add read event type for Read/Glob/Grep/LS tools

[adrozdenko]

Summary

Add a dedicated read event type for Read/Glob/Grep/LS tools to prevent file-editing rules from incorrectly triggering on read operations.

Fixes Issue 1 from #13464 — Rules load for ALL tools when tool isn't mapped to an event.

Problem

Currently, Read/Glob/Grep/LS tools have no event mapping (event = None), which causes ALL rules to load regardless of their event field. This is problematic:

User: "Read src/Button.tsx"
Hookify: "⚠️ Console.log detected!"  ← WRONG - user is just reading!

As documented in #13464:

For other tools (Read, Glob, TodoWrite, etc.), event=None is passed to load_rules(), which skips filtering and loads ALL rules regardless of event type.

This causes:

• False positives: File-editing rules (event: file) incorrectly fire on read operations
• Noisy UX: Users see warnings when simply exploring code
• Unexpected blocking: Rules with negative operators can block read operations

Related: #17246

PR #17246 addresses the same issue but maps Read → file event. This approach has a UX problem: file-editing rules like "no console.log in production" would still trigger when reading files.

This PR proposes a better solution: a dedicated read event type.

Solution

Add read as a new event type:

elif tool_name in ['Read', 'Glob', 'Grep', 'LS']:
    event = 'read'

This gives users precise control:

• event: file → Only Edit/Write/MultiEdit (actual modifications)
• event: read → Only Read/Glob/Grep/LS (read operations)
• event: all → Everything

Files Changed

File	Change
hooks/pretooluse.py	Add read event mapping
hooks/posttooluse.py	Add read event mapping
README.md	Document read event type
skills/writing-rules/SKILL.md	Document read event type

Usage Examples

Prevent false positives (the problem this fixes)

---
name: no-console-log
enabled: true
event: file  # Now correctly only triggers on Edit/Write, NOT Read
conditions:
  - field: new_text
    operator: contains
    pattern: console.log
---
Remove console.log before committing.

Create read-specific rules (new capability)

---
name: warn-reading-secrets
enabled: true
event: read  # Only triggers on Read, not Edit
conditions:
  - field: file_path
    operator: regex_match
    pattern: (\.env|secrets|credentials)
---
You're reading a sensitive file. Be careful with the contents.

Why read is Better Than Reusing file

Scenario	Map to file (#17246)	Map to read (this PR)
"no console.log" rule fires on Read	❌ Yes (noisy)	✅ No
Can create read-specific rules	❌ No	✅ Yes
Backwards compatible	✅ Yes	✅ Yes
Semantic clarity	❌ Confusing	✅ Clear
Addresses #13464 Issue 1	⚠️ Partially	✅ Fully

Test Plan

• Python syntax check passes
• Manual testing confirms read operations don't trigger file rules
• Backward compatible - existing rules unchanged
• Verified against scenarios described in [BUG] Hookify plugin: Multiple foot guns causing rules to fail silently or trigger unexpectedly #13464

[adrozdenko]

Update: This feature is now available in hookify-plus - a standalone fork with community fixes.

If you don't want to wait for upstream review, you can use hookify-plus today:

# Backup original & install hookify-plus  
mv ~/.claude/plugins/cache/claude-code-plugins/hookify/0.1.0{,.bak}
ln -s /path/to/hookify-plus ~/.claude/plugins/cache/claude-code-plugins/hookify/0.1.0

hookify-plus includes:

• read event type (this PR)
• not_regex_match operator (feat(hookify): add not_regex_match operator and value key support #18419)
• value key support (feat(hookify): add not_regex_match operator and value key support #18419)
• Global rules in ~/.claude/ (feat(hookify): Add support for global rules in ~/.claude/ #13916)
• Update tool support + Write fix (fix(hookify): handle Write tool content in new_text field and add Update tool support #16081)