Analyze the project, suggest practical hooks, and create them with proper testing.
Analyze your project and automatically create practical git hooks with proper testing. Detects TypeScript, Prettier, ESLint, and security patterns to suggest relevant hooks for code quality and workflow automation.
/plugin marketplace add lifangda/claude-plugins/plugin install accessibility-suite@claude-pluginsdevelopment-tools/Analyze the project, suggest practical hooks, and create them with proper testing.
Automatically detect the project tooling and suggest relevant hooks:
When TypeScript is detected (tsconfig.json):
When Prettier is detected (.prettierrc, prettier.config.js):
When ESLint is detected (.eslintrc.*):
When package.json has scripts:
test script → "Run tests before commits"build script → "Validate build before commits"When a git repository is detected:
Decision Tree:
Project has TypeScript? → Suggest type checking hooks
Project has formatter? → Suggest formatting hooks
Project has tests? → Suggest test validation hooks
Security sensitive? → Suggest security hooks
+ Scan for additional patterns and suggest custom hooks based on:
- Custom scripts in package.json
- Unique file patterns or extensions
- Development workflow indicators
- Project-specific tooling configurations
Start by asking: "What should this hook do?" and offer relevant suggestions from your analysis.
Then understand the context from the user's description and only ask about details you're unsure about:
Trigger timing: When should it run?
PreToolUse: Before file operations (can block)PostToolUse: After file operations (feedback/fixes)UserPromptSubmit: Before processing requestsTool matcher: Which tools should trigger it? (Write, Edit, Bash, * etc)
Scope: global, project, or project-local
Response approach:
Blocking behavior (if relevant): "Should this stop operations when issues are found?"
Claude integration (CRITICAL): "Should Claude Code automatically see and fix issues this hook detects?"
additionalContext for error communicationsuppressOutput: true for silent operationContext pollution: "Should successful operations be silent to avoid noise?"
File filtering: "What file types should this hook process?"
You should:
~/.claude/hooks/ or .claude/hooks/ based on scope$CLAUDE_PROJECT_DIR to reference project rootKey Implementation Standards:
additionalContext/systemMessage for Claude communicationsuppressOutput: true for successful operations⚠️ CRITICAL: Input/Output Format
This is where most hook implementations fail. Pay extra attention to:
CRITICAL: Test both happy and sad paths:
Happy Path Testing:
Sad Path Testing: 2. Test expected failure scenario - Create conditions where hook should fail/warn
Verification Steps: 3. Verify expected behavior: Check if it blocks/warns/provides context as intended
Example Testing Process:
If Issues Occur, you should:
chmod +x)#!/usr/bin/env node
// Read stdin JSON, check .ts/.tsx files only
// Run: npx tsc --noEmit --pretty
// Output: JSON with additionalContext for errors
#!/usr/bin/env node
// Read stdin JSON, check supported file types
// Run: npx prettier --write [file]
// Output: JSON with suppressOutput: true
#!/bin/bash
# Read stdin JSON, check for secrets/keys
# Block if dangerous patterns found
# Exit 2 to block, 0 to continue
Complete templates available at: https://docs.claude.com/en/docs/claude-code/hooks#examples
📖 Official Docs: https://docs.claude.com/en/docs/claude-code/hooks.md
Common Patterns:
JSON.parse(process.stdin.read()){continue: true, suppressOutput: true}{continue: true, additionalContext: "error details"}exit(2) in PreToolUse hooksHook Types by Use Case:
Hook Execution Best Practices:
✅ Hook created successfully when:
Result: The user gets a working hook that enhances their development workflow with intelligent automation and quality checks.
/create-hookGuided hook creation with brainstorming and security-first design. Triggers: new hook, create hook, hook creation, start hook, build hook, add hook, write hook, PreToolUse, PostToolUse, UserPromptSubmit Use when: creating a new hook from scratch, need security-first design guidance, want structured workflow for hook development with Socratic questioning DO NOT use when: evaluating existing hooks - use /hooks-eval instead. DO NOT use when: deciding where to place hooks - use hook-scope-guide skill. DO NOT use when: validating hook security - use /validate-hook instead. Use this command to create any new hook. Security validation is automatic.