Rule Catalog

When To Use

• Browsing available hookify rules by category
• Installing standard pre-built rules into a project
• Looking for ready-made rules before writing custom ones

When NOT To Use

• Writing custom rules from scratch: use hookify:writing-rules instead
• Debugging or modifying existing installed rules
• Converting Python SDK hooks: use hookify:from-hook instead

Table of Contents

• Quick Install
• Available Rules
• git/ - Git Safety
• python/ - Python Quality
• security/ - Security Gates
• workflow/ - Workflow Enforcement
• performance/ - Resource Management
• Installation Instructions
• Method 1: Claude-Assisted (Recommended))
• Method 2: Python Script
• Method 3: Manual Copy
• Rule File Locations
• Customizing Rules
• Creating Pull Requests for New Rules
• Related

Hookify Rule Catalog

Pre-built rules for common scenarios. Install directly or use as templates.

Quick Install

# Install a specific rule
Skill(hookify:rule-catalog) then install git:block-force-push

# Or use the Python installer for bulk operations
python3 plugins/hookify/scripts/install_rule.py git:block-force-push
python3 plugins/hookify/scripts/install_rule.py --category git
python3 plugins/hookify/scripts/install_rule.py --all

Verification: Run python --version to verify Python environment.

Available Rules

git/ - Git Safety

python/ - Python Quality

security/ - Security Gates

workflow/ - Workflow Enforcement

performance/ - Resource Management

Installation Instructions

Method 1: Claude-Assisted (Recommended)

When you invoke this skill, tell Claude which rule(s) to install:

**Verification:** Run `git status` to confirm working tree state.
Install git:block-force-push

Verification: Run the command with --help flag to verify availability.

Claude will: 1. Read the rule from skills/rule-catalog/rules/git/block-force-push.md 2. Write it to .claude/hookify.block-force-push.local.md 3. Confirm installation

Method 2: Python Script

For bulk operations or automation:

# Install single rule
python3 plugins/hookify/scripts/install_rule.py git:block-force-push

# Install all rules in category
python3 plugins/hookify/scripts/install_rule.py --category python

# Install all rules
python3 plugins/hookify/scripts/install_rule.py --all

# List available rules
python3 plugins/hookify/scripts/install_rule.py --list

# Install to custom directory
python3 plugins/hookify/scripts/install_rule.py git:block-force-push --target /path/to/.claude

Verification: Run the command with --help flag to verify availability.

Method 3: Manual Copy

1. Find rule in plugins/hookify/skills/rule-catalog/rules/<category>/<rule>.md 2. Copy to .claude/hookify.<rule-name>.local.md 3. Edit enabled: true/false as needed

Rule File Locations

Rules are stored relative to this skill:

**Verification:** Run the command with `--help` flag to verify availability.
skills/rule-catalog/
├── SKILL.md (this file)
└── rules/
    ├── git/
    │   ├── block-force-push.md
    │   ├── block-destructive-git.md
    │   ├── warn-risky-git.md
    │   └── warn-large-commits.md
    ├── python/
    │   ├── block-dynamic-code.md
    │   └── warn-print-statements.md
    ├── security/
    │   ├── require-security-review.md
    │   └── destructive-command-guard.md
    ├── workflow/
    │   ├── enforce-scope-guard.md
    │   └── require-spec-before-code.md
    └── performance/
        └── warn-large-file-ops.md

Verification: Run the command with --help flag to verify availability.

Customizing Rules

After installation, edit the rule in .claude/:

# Change action from warn to block
action: block

# Disable temporarily
enabled: false

# Modify pattern
pattern: your-custom-pattern

Verification: Run the command with --help flag to verify availability.

Creating Pull Requests for New Rules

To add rules to the catalog:

1. Create rule file in appropriate category 2. Follow naming convention: kebab-case.md 3. Include detailed message with alternatives 4. Test thoroughly before submitting 5. Update this SKILL.md catalog table

Related

• Skill(hookify:writing-rules) - Create custom rules
• /hookify:list - Show installed rules
• /hookify:configure - Manage installed rules

Run AI slop detection on documentation changes!

When creating, updating, or rewriting documentation, run Skill(scribe:slop-detector) on all modified markdown files before considering the work complete.

Common AI tells to watch for:

• Em dash overuse (>1 per 1000 words is elevated, >5 is a strong

AI signal; in prevention mode target zero)

• "structured", "actionable", "comprehensive", "seamless" and other tier 1 slop words
• Participial phrase tail-loading ("...enabling researchers to analyze data")
• Uniform sentence lengths (human writing varies, AI stays at 15-25 words)
• Hedging patterns ("It's important to note", "From a broader perspective")

2026 prevention-strict tells (cross-source consensus):

• Plus-sign for "and" in prose: "hooks + skills" → "hooks and skills"
• Spatial copula with inanimate subjects: "lives in", "sits

at", "stands as", "rests on", "rooted in", "serves as", "boasts" → use "is" / "has" / "uses"

• Negative parallelism: "Not X but Y", "It's not X, it's Y",

"No X. No Y. Just Z.", "And that's okay." → rewrite positively

• Throat-clearing openers: "Here's the thing,", "Look,",

"Let that sink in.", "The uncomfortable truth is" → delete

• Three-fragment burst: "Focused. Aligned. Measurable." →

single sentence

• Significance cluster: "stands as a testament to", "marks a

turning point", "underscores the importance" → cut

• Smart quotes outside code blocks: "text" → "text"
• Loop/cascade vocabulary: "unpack" / "surface" (as verbs)

in non-technical contexts

Required workflow: 1. Write/edit the documentation 2. Run Skill(scribe:slop-detector) on each modified .md file 3. Fix any issues with score > 2.0 4. Verify em dash count is within human range (0-2 per 1000 words)

Quick checks:

# Count em dashes in a file
grep -o '—' file.md | wc -l

# Count words
wc -w < file.md

Why this rule exists:

• AI-generated documentation erodes reader trust
• Em dashes, "structured", and "actionable" are the most common tells
• The slop detector exists but is only invoked manually today
• This rule closes the gap between writing docs and quality-checking them

Uncommitted work represents someone's thinking. Destroying it erases context that cannot be rebuilt. (Care)

🛑 Destructive Git Operation Blocked!

This command can cause irreversible data loss - uncommitted changes, local branches, or reflog history may be permanently deleted.

Detected Patterns

Recovery-First Approach

Before discarding changes, always check what you're about to lose:

# See what would be affected by reset --hard
git diff HEAD                    # Unstaged changes
git diff --cached                # Staged changes
git status                       # Overall state

# See what clean would delete
git clean -nfd                   # Dry-run: shows what WOULD be deleted

# See stash contents before dropping
git stash show -p stash@{0}      # Full diff of stash

Safer Alternatives

Instead of git reset --hard

# Option 1: Save changes to a temporary branch first
git stash                        # Stash current changes
git reset --hard HEAD            # Now safe to reset
# Later: git stash pop           # Recover if needed

# Option 2: Create a backup branch
git checkout -b backup/my-changes
git checkout -                   # Return to original branch
git reset --hard HEAD

# Option 3: Reset specific files only
git checkout HEAD -- path/to/file

Instead of git checkout -- .

# Option 1: Review what you're discarding
git diff                         # See all changes first
git stash                        # Save instead of discard

# Option 2: Discard specific files only
git checkout -- path/to/specific/file

Instead of git clean -fd

# Option 1: See what would be deleted first
git clean -nfd                   # Dry run

# Option 2: Interactive clean (asks per file)
git clean -id

# Option 3: Move to trash instead of delete
mkdir -p .git/trash
git ls-files --others --exclude-standard | xargs -I{} mv {} .git/trash/

Instead of git stash drop

# List all stashes first
git stash list

# Apply the stash to a branch for safekeeping
git stash branch backup-stash stash@{0}

If You Truly Need This Operation

If you've reviewed the changes and confirm they should be discarded:

1. Verify first: Run the diagnostic commands above 2. Temporarily disable this rule:

   # Edit .claude/hookify.block-destructive-git.local.md
   # Set: enabled: false

3. Run your command 4. Re-enable the rule immediately after

Related Rules

• block-force-push - Prevents force pushing to remote
• warn-large-commits - Warns about binary files in commits

Shared history belongs to every contributor who builds on it. Force-pushing rewrites commits others depend on, breaking their work and erasing their context. (Care, Foresight)

Force push to main/master detected!

Force pushing to the main branch can:

• Overwrite team members' work
• Break production deployments
• Cause irreversible data loss
• Violate team git policies

Safer alternatives:

# Create a new branch instead
git checkout -b fix/my-changes

# Or rebase locally first
git pull --rebase origin main

# Or use --force-with-lease (safer)
git push --force-with-lease origin main

To override this rule: If you really need to force push (rare): 1. Get team approval 2. Temporarily disable: .claude/hookify.block-force-push.local.md - enabled: false 3. Force push 4. Re-enable the rule

Large binary file detected in git add!

You're adding a large binary file (.zip, .tar, .mp4, etc.)

Problems:

• Bloats repository size permanently
• Slows down clones
• Binary files can't be diffed
• Wastes team bandwidth

Better alternatives:

# Add to .gitignore
echo "*.zip" >> .gitignore
echo "*.tar.gz" >> .gitignore

# Use Git LFS for large files
git lfs track "*.mp4"
git lfs track "*.zip"

# Or use external storage
# - S3/Cloud storage
# - Package registries
# - Artifact repositories

⚠️ Risky Git Operation Detected

This command modifies history or discards work. Please verify before proceeding.

What This Command Does

Before Proceeding

# Always check current state
git status
git log --oneline -5

# Check what reflog can recover
git reflog -10

Recovery Reference

If something goes wrong:

# Find the commit you want to return to
git reflog

# Reset to that state
git reset --hard HEAD@{N}

Proceeding with caution...

Large file operation detected!

You're writing a large amount of data (>10KB) in a single operation.

Performance impact:

• High token usage in context
• Slower Claude responses
• Memory pressure
• Network bandwidth

Better approaches:

For large data:

# Instead of one large write
with open('huge_file.json', 'w') as f:
    f.write(massive_json_string)  # Large context

# Use streaming or chunking
import json
with open('huge_file.json', 'w') as f:
    for chunk in data_chunks:
        json.dump(chunk, f)  # Smaller operations

For generated code:

# Generate to file directly
with open('generated.py', 'w') as f:
    for section in code_sections:
        f.write(section + '\n')

Resource monitoring:

# Check file sizes
/conserve:analyze-resources

# Monitor token usage
/conserve:token-usage

SECURITY: Dynamic code execution detected!

Using functions that execute arbitrary strings as code is a critical security risk.

Dangers:

• Arbitrary code execution
• Injection attacks
• Difficult to audit
• Bypasses security controls

Safer alternatives:

For expression evaluation:

# Use ast.literal_eval for safe evaluation
import ast
result = ast.literal_eval(user_input)  # Only evaluates literals

# Use operator module for math
import operator
ops = {'+': operator.add, '-': operator.sub}
result = ops[op](a, b)

For dynamic behavior:

# Use importlib for dynamic imports
import importlib
module = importlib.import_module(module_name)

# Use getattr for dynamic attribute access
fn = getattr(obj, method_name)
result = fn(*args)

# Use configuration files
import json
config = json.load(config_file)

If you absolutely must use dynamic execution: 1. Document the security review 2. Sanitize all inputs 3. Use restricted execution environments 4. Get security team approval 5. Temporarily disable this rule

Print statements bypass the logging that future debuggers will depend on to diagnose problems. (Diligence)

Print statement detected in Python!

You're adding print() calls to Python code.

Why this matters:

• Print statements bypass proper logging
• Can't be filtered or configured
• Pollute stdout in production
• Hard to track and remove

Better alternatives:

# Use logging module
import logging
logger = logging.getLogger(__name__)

# Instead of print
logger.debug("Debug info: %s", data)
logger.info("Status update: %s", status)
logger.warning("Warning: %s", warning)

# Configure logging levels
logging.basicConfig(level=logging.INFO)

Quick logging setup:

import logging
logging.basicConfig(
    level=logging.DEBUG,
    format='%(asctime)s - %(name)s - %(levelname)s - %(message)s'
)
logger = logging.getLogger(__name__)

For debugging only: If this is temporary debugging code, remember to remove before committing.

Irreversible actions on production systems have caused real data loss. The Replit/SaaStr incident (July 2025) erased 1,200 executive records and 1,190 company records during a code freeze. The design flaw: an agent could reach a self-destruct button with no affordance making the wrong action harder than the right one. (Care, Reversibility)

WARNING: Destructive command targeting production-shaped path or environment!

You're about to run a destructive command on what looks like a production resource.

Why This Warns

Production data loss is rarely recoverable within an agent session. This rule fires when:

• rm -rf, git push --force, kubectl delete,

terraform destroy, DROP TABLE, or DELETE FROM

• AND the command references prod, production,

live, PROD_* / PRODUCTION_* env-vars, or a prod-scoped namespace/workspace

Before Proceeding, Verify

# What will this touch?
git diff --stat HEAD          # For git operations
kubectl get <resource> -n production   # For k8s deletes
terraform plan -var-file=prod.tfvars   # For infra ops

# Is there a snapshot or backup?
# Is this inside a code-freeze window?
# Have you confirmed the target environment?

Safer Alternatives

If You Are Sure

This is a warning rather than a block. The command will run. If you are certain and want to silence this rule temporarily:

# Edit .claude/hookify.destructive-command-guard.local.md
# Set: enabled: false
# Run your command
# Re-enable immediately after

Related

• block-destructive-git: blocks irreversible local git ops
• block-force-push: blocks force push to main/master
• Source: HN #48022742, Replit/SaaStr incident (2025-07)

Security-sensitive code protects the people who trust this system with their data. Changes here deserve careful review. (Care, Diligence)

BLOCKED: Security-sensitive code requires pensive review!

You're modifying authentication/security code.

Required before this change:

Skill(pensive:security-review)

Security review checklist:

• [ ] No hardcoded secrets
• [ ] Proper input validation
• [ ] Secure session management
• [ ] Password hashing (bcrypt/argon2)
• [ ] Rate limiting on auth endpoints
• [ ] Error messages don't leak info
• [ ] Logging doesn't expose secrets
• [ ] HTTPS only for sensitive data

After review, to proceed:

# Disable temporarily
# .claude/hookify.require-security-review.local.md - enabled: false
# Make changes
# Re-enable rule

Why this blocks (not warns): Security vulnerabilities can cause severe damage. Review MUST happen before changes.

Stewardship: Leave the campsite better than you found it.

Before wrapping up, a brief reflection on the work just done:

• Care: What did you leave better for the next person?
• Curiosity: What did you learn about this code?
• Humility: Where were you uncertain? Did you handle

it honestly?

• Diligence: Did you follow through on the small things?
• Foresight: Will your choices be easy to change tomorrow?

If any prompt surfaces an improvement you can make in under a minute, consider making it now. Small acts compound.

For deeper reflection, see modules/reflection.md in Skill(leyline:stewardship). Record voluntary improvements with the stewardship tracker.

Building only what is needed today preserves tomorrow's freedom to choose differently. (Humility, Foresight)

Scope-guard check required!

Imbue's scope-guard prevents over-engineering. Before proceeding:

Run scope evaluation:

Skill(imbue:scope-guard)

Worthiness formula:

Score = (BizValue + TimeCrit + RiskReduce) / (Complexity + TokenCost + ScopeDrift)

> 2.0  - Implement now
1.0-2.0 - Discuss first
< 1.0  - Defer to backlog

Current branch status:

• Check: git diff --stat main | tail -1
• Thresholds: 1000/1500/2000 lines

Anti-overengineering rules:

• No abstraction until 3rd use case
• Ask clarifying questions BEFORE solutions
• Stay within branch budget

Planning before dispatching agents respects the context window and the work that depends on coherent results. (Foresight)

Plan mode required for large agent dispatch!

Tasks involving comprehensive analysis, audits, or research across the codebase typically require 4+ parallel agents. Before dispatching:

MUST enter plan mode first: 1. EnterPlanMode: design the agent strategy 2. Specify: agent roster, scope per agent, output contract 3. Get user approval before launching agents

Agent Dispatch Plan template:

Why this rule exists:

• 4+ agents without a plan → lost observability, context overflow, wasted compute
• Research agents produce large outputs → continuation agents lose state
• Without user alignment, agents may investigate the wrong dimensions

Threshold: 1-3 agents can dispatch directly. 4+ agents require plan mode.

Reference: plugins/sanctum/skills/do-issue/modules/parallel-execution.md

BLOCKED: No spec file for this feature

Spec-kit enforces specification-driven development:

The workflow:

1. Write spec    - /spec-kit:write <feature>
2. Review spec   - /spec-kit:review specs/<feature>.md
3. THEN implement - (this action)
4. Verify        - /spec-kit:verify specs/<feature>.md

To proceed, either:

1. Create the spec first:

/spec-kit:write <feature-name>

2. Or link to existing spec:

# Add to your file header:
# Spec: specs/<feature>.md

3. Or disable for this project (not recommended):

# Edit: .claude/hookify.require-spec-before-code.local.md
# Set: enabled: false

Why spec-first matters:

• Clear requirements before coding
• Better test coverage from spec
• Documentation generated from spec
• Team alignment on expectations