Adds the hookify plugin to public marketplace. Enables users to create custom hooks using simple markdown configuration files instead of editing JSON. Key features: - Define rules with regex patterns to warn/block operations - Create rules from explicit instructions or conversation analysis - Pattern-based matching for bash commands, file edits, prompts, stop events - Enable/disable rules dynamically without editing code - Conversation analyzer agent finds problematic behaviors Changes from internal version: - Removed non-functional SessionStart hook (not registered in hooks.json) - Removed all sessionstart documentation and examples - Fixed restart documentation to consistently state "no restart needed" - Changed license from "Internal Anthropic use only" to "MIT License" - Kept test blocks in core modules (useful for developers) Plugin provides: - 4 commands: /hookify, /hookify:list, /hookify:configure, /hookify:help - 1 agent: conversation-analyzer - 1 skill: writing-rules - 4 hook types: PreToolUse, PostToolUse, Stop, UserPromptSubmit - 4 example rules ready to use All features functional and suitable for public use. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <noreply@anthropic.com>
7.5 KiB
| description | argument-hint | allowed-tools | |||||||
|---|---|---|---|---|---|---|---|---|---|
| Create hooks to prevent unwanted behaviors from conversation analysis or explicit instructions | Optional specific behavior to address |
|
Hookify - Create Hooks from Unwanted Behaviors
FIRST: Load the hookify:writing-rules skill using the Skill tool to understand rule file format and syntax.
Create hook rules to prevent problematic behaviors by analyzing the conversation or from explicit user instructions.
Your Task
You will help the user create hookify rules to prevent unwanted behaviors. Follow these steps:
Step 1: Gather Behavior Information
If $ARGUMENTS is provided:
- User has given specific instructions:
$ARGUMENTS - Still analyze recent conversation (last 10-15 user messages) for additional context
- Look for examples of the behavior happening
If $ARGUMENTS is empty:
- Launch the conversation-analyzer agent to find problematic behaviors
- Agent will scan user prompts for frustration signals
- Agent will return structured findings
To analyze conversation: Use the Task tool to launch conversation-analyzer agent:
{
"subagent_type": "general-purpose",
"description": "Analyze conversation for unwanted behaviors",
"prompt": "You are analyzing a Claude Code conversation to find behaviors the user wants to prevent.
Read user messages in the current conversation and identify:
1. Explicit requests to avoid something (\"don't do X\", \"stop doing Y\")
2. Corrections or reversions (user fixing Claude's actions)
3. Frustrated reactions (\"why did you do X?\", \"I didn't ask for that\")
4. Repeated issues (same problem multiple times)
For each issue found, extract:
- What tool was used (Bash, Edit, Write, etc.)
- Specific pattern or command
- Why it was problematic
- User's stated reason
Return findings as a structured list with:
- category: Type of issue
- tool: Which tool was involved
- pattern: Regex or literal pattern to match
- context: What happened
- severity: high/medium/low
Focus on the most recent issues (last 20-30 messages). Don't go back further unless explicitly asked."
}
Step 2: Present Findings to User
After gathering behaviors (from arguments or agent), present to user using AskUserQuestion:
Question 1: Which behaviors to hookify?
- Header: "Create Rules"
- multiSelect: true
- Options: List each detected behavior (max 4)
- Label: Short description (e.g., "Block rm -rf")
- Description: Why it's problematic
Question 2: For each selected behavior, ask about action:
- "Should this block the operation or just warn?"
- Options:
- "Just warn" (action: warn - shows message but allows)
- "Block operation" (action: block - prevents execution)
Question 3: Ask for example patterns:
- "What patterns should trigger this rule?"
- Show detected patterns
- Allow user to refine or add more
Step 3: Generate Rule Files
For each confirmed behavior, create a .claude/hookify.{rule-name}.local.md file:
Rule naming convention:
- Use kebab-case
- Be descriptive:
block-dangerous-rm,warn-console-log,require-tests-before-stop - Start with action verb: block, warn, prevent, require
File format:
---
name: {rule-name}
enabled: true
event: {bash|file|stop|prompt|all}
pattern: {regex pattern}
action: {warn|block}
---
{Message to show Claude when rule triggers}
Action values:
warn: Show message but allow operation (default)block: Prevent operation or stop session
For more complex rules (multiple conditions):
---
name: {rule-name}
enabled: true
event: file
conditions:
- field: file_path
operator: regex_match
pattern: \.env$
- field: new_text
operator: contains
pattern: API_KEY
---
{Warning message}
Step 4: Create Files and Confirm
IMPORTANT: Rule files must be created in the current working directory's .claude/ folder, NOT the plugin directory.
Use the current working directory (where Claude Code was started) as the base path.
-
Check if
.claude/directory exists in current working directory- If not, create it first with:
mkdir -p .claude
- If not, create it first with:
-
Use Write tool to create each
.claude/hookify.{name}.local.mdfile- Use relative path from current working directory:
.claude/hookify.{name}.local.md - The path should resolve to the project's .claude directory, not the plugin's
- Use relative path from current working directory:
-
Show user what was created:
Created 3 hookify rules: - .claude/hookify.dangerous-rm.local.md - .claude/hookify.console-log.local.md - .claude/hookify.sensitive-files.local.md These rules will trigger on: - dangerous-rm: Bash commands matching "rm -rf" - console-log: Edits adding console.log statements - sensitive-files: Edits to .env or credentials files -
Verify files were created in the correct location by listing them
-
Inform user: "Rules are active immediately - no restart needed!"
The hookify hooks are already loaded and will read your new rules on the next tool use.
Event Types Reference
- bash: Matches Bash tool commands
- file: Matches Edit, Write, MultiEdit tools
- stop: Matches when agent wants to stop (use for completion checks)
- prompt: Matches when user submits prompts
- all: Matches all events
Pattern Writing Tips
Bash patterns:
- Match dangerous commands:
rm\s+-rf|chmod\s+777|dd\s+if= - Match specific tools:
npm\s+install\s+|pip\s+install
File patterns:
- Match code patterns:
console\.log\(|eval\(|innerHTML\s*= - Match file paths:
\.env$|\.git/|node_modules/
Stop patterns:
- Check for missing steps: (check transcript or completion criteria)
Example Workflow
User says: "/hookify Don't use rm -rf without asking me first"
Your response:
- Analyze: User wants to prevent rm -rf commands
- Ask: "Should I block this command or just warn you?"
- User selects: "Just warn"
- Create
.claude/hookify.dangerous-rm.local.md:--- name: warn-dangerous-rm enabled: true event: bash pattern: rm\s+-rf --- ⚠️ **Dangerous rm command detected** You requested to be warned before using rm -rf. Please verify the path is correct. - Confirm: "Created hookify rule. It's active immediately - try triggering it!"
Important Notes
- No restart needed: Rules take effect immediately on the next tool use
- File location: Create files in project's
.claude/directory (current working directory), NOT the plugin's .claude/ - Regex syntax: Use Python regex syntax (raw strings, no need to escape in YAML)
- Action types: Rules can
warn(default) orblockoperations - Testing: Test rules immediately after creating them
Troubleshooting
If rule file creation fails:
- Check current working directory with pwd
- Ensure
.claude/directory exists (create with mkdir if needed) - Use absolute path if needed:
{cwd}/.claude/hookify.{name}.local.md - Verify file was created with Glob or ls
If rule doesn't trigger after creation:
- Verify file is in project
.claude/not plugin.claude/ - Check file with Read tool to ensure pattern is correct
- Test pattern with:
python3 -c "import re; print(re.search(r'pattern', 'test text'))" - Verify
enabled: truein frontmatter - Remember: Rules work immediately, no restart needed
If blocking seems too strict:
- Change
action: blocktoaction: warnin the rule file - Or adjust the pattern to be more specific
- Changes take effect on next tool use
Use TodoWrite to track your progress through the steps.