
Writing Rules
- 102 installs
- 325 repo stars
- Updated August 2, 2026
- athola/claude-night-market
Writing-rules is an agent skill that creates Hookify markdown rules to block dangerous commands and restrict AI behavior in Claude Code sessions.
About
Writing-rules is an agent skill for authoring Hookify behavioral rules in markdown that constrain what Claude Code can do in a session. Solo and indie builders use it when they need durable guardrails—not one-off prompts—to block dangerous commands, flag risky edits, or require checks before destructive operations. The guide walks through rule structure, event types, condition builders, regex patterns, and concrete examples from blocking rm-style commands to protecting production files. It fits anyone shipping with agentic coding who wants filesystem and shell safety encoded as versionable rules. Complexity is beginner-oriented with an estimated ~2500-token footprint and a fast-model hint. Invoke it when adding safety guardrails or when you must prevent specific commands from ever reaching execution.
- Documents Hookify rule file format with frontmatter, event types, and field reference
- Covers operators, advanced conditions, and regex-oriented pattern writing for command matching
- Includes example rules: block destructive commands, warn on debug code, require tests, protect production paths
- Describes test patterns and management workflow for validating rules before enforcement
- Lists best practices for behavioral enforcement via hook-development patterns
Writing Rules by the numbers
- 102 all-time installs (skills.sh)
- Ranked #4,307 of 16,546 AI & Agent Building skills by installs in the Skillselion catalog
- Security screen: LOW risk (skills.sh audit)
- Data as of Aug 5, 2026 (Skillselion catalog sync)
npx skills add https://github.com/athola/claude-night-market --skill writing-rulesAdd your badge
Show developers this skill is listed on Skillselion. Paste this into your README.
| Installs | 102 |
|---|---|
| repo stars | ★ 325 |
| Security audit | 3 / 3 scanners passed |
| Last updated | August 2, 2026 |
| Repository | athola/claude-night-market ↗ |
What it does
Define persistent Hookify markdown rules so Claude Code blocks destructive shell commands and enforces session guardrails.
Who is it for?
Best when you use Claude Code hooks and want git-tracked safety rules with regex patterns and documented event types.
Skip if: Skip if you need enterprise IAM or runtime policy engines instead of session-level Hookify markdown rules.
When should I use this skill?
Adding safety guardrails or preventing specific commands; creating behavioral rules for persistent Claude Code session enforcement.
What you get
You ship a Hookify-compatible rule set with patterns, conditions, and tested examples so sessions enforce guardrails before commands execute.
- Hookify markdown rule file with frontmatter and patterns
- Tested pattern matches for target commands
- Documented event types and conditions
By the numbers
- ~2500 estimated tokens in skill metadata
- Multiple example rule categories including destructive commands, debug warnings, and production protection
Files
Table of Contents
- Overview
- Quick Start
- Rule File Format
- Frontmatter Fields
- Event Types
- Advanced Conditions
- Operators
- Field Reference
- Pattern Writing
- Regex Basics
- Examples
- Test Patterns
- Example Rules
- Block Destructive Commands
- Warn About Debug Code
- Require Tests
- Protect Production Files
- Management
- Related Skills
- Best Practices
Hookify Rule Writing Guide
When To Use
- Creating behavioral rules to prevent unwanted actions
- Defining persistent guardrails for Claude Code sessions
When NOT To Use
- Complex multi-step workflows - use agents instead
- One-time operations that do not need persistent behavioral rules
Overview
Hookify rules are markdown files with YAML frontmatter that define patterns to watch for and messages to show when those patterns match. Rules are stored in .claude/hookify.{rule-name}.local.md files.
Quick Start
Create .claude/hookify.dangerous-rm.local.md:
---
name: dangerous-rm
enabled: true
event: bash
pattern: rm\s+-rf
action: block
---
🛑 **Dangerous rm command detected!**
This command could delete important files.Verification: Run the command with --help flag to verify availability.
The rule activates immediately - no restart needed!
Rule File Format
Frontmatter Fields
name (required): Unique identifier (kebab-case) enabled (required): true or false event (required): bash, file, stop, prompt, or all action (optional): warn (default) or block pattern (simple): Regex pattern to match
Event Types
- bash: Bash tool commands
- file: Edit, Write, MultiEdit tools
- stop: When agent wants to stop
- prompt: User prompt submission
- all: All events
Advanced Conditions
For multiple field checks:
---
name: warn-env-edits
enabled: true
event: file
action: warn
conditions:
- field: file_path
operator: regex_match
pattern: \.env$
- field: new_text
operator: contains
pattern: API_KEY
---
🔐 **API key in .env file!**
Ensure file is in .gitignore.Operators
regex_match: Pattern matchingcontains: Substring checkequals: Exact matchnot_contains: Must NOT containstarts_with: Prefix checkends_with: Suffix check
Field Reference
bash events: command file events: file_path, new_text, old_text, content prompt events: user_prompt stop events: transcript
Pattern Writing
Regex Basics
\s- whitespace\d- digit\w- word character.- any character (use\.for literal dot)+- one or more*- zero or more|- OR
Examples
rm\s+-rf → rm -rf
console\.log\( → console.log(
chmod\s+777 → chmod 777Test Patterns
python3 -c "import re; print(re.search(r'pattern', 'text'))"Example Rules
Block Destructive Commands
---
name: block-destructive
enabled: true
event: bash
pattern: rm\s+-rf|dd\s+if=|mkfs
action: block
---
🛑 **Destructive operation blocked!**
Can cause data loss.Warn About Debug Code
---
name: warn-debug
enabled: true
event: file
pattern: console\.log\(|debugger;
action: warn
---
🐛 **Debug code detected!**
Remove before committing.Require Tests
---
name: require-tests
enabled: true
event: stop
action: warn
conditions:
- field: transcript
operator: not_contains
pattern: pytest|npm test
---
⚠️ **Tests not run!**
Please verify changes.Protect Production Files
---
name: protect-prod
enabled: true
event: file
action: block
conditions:
- field: file_path
operator: regex_match
pattern: /production/|\.prod\.
---
🚨 **Production file!**
Requires review.Management
Enable/Disable: Edit .local.md file: enabled: false
Delete:
rm .claude/hookify.my-rule.local.mdList:
/hookify:listRelated Skills
- abstract:hook-scope-guide - Hook placement decisions
- abstract:hook-authoring - SDK hook development
- abstract:hooks-eval - Hook evaluation
Best Practices
1. Start with simple patterns 2. Test regex thoroughly 3. Use clear, helpful messages 4. Prefer warnings over blocks initially 5. Name rules descriptively 6. Document intent in messages
Troubleshooting
Common Issues
If a rule doesn't trigger, verify that the event type matches the tool being used (e.g., use bash for command line tools). Check that the regex pattern is valid and matches the target text by testing it with a short Python script. If you encounter permission errors when creating rule files in .claude/, ensure that the directory is writable by your user.
Exit Criteria
- [ ] Rule file exists at
.claude/hookify.<rule-name>.local.md
with all required frontmatter fields present: name (kebab-case), enabled, event, and either pattern or conditions
- [ ] Regex pattern validated with
`python3 -c "import re; print(re.search(r'<pattern>', '<test>'))" before the rule is saved; no untested patterns shipped
- [ ] Rule triggers correctly on a matching input:
warnaction
shows the message body, block action prevents the operation
- [ ] Rule does not fire on a non-matching input; false positive
tested with at least one known-safe example
Related skills
How it compares
Use instead of ad-hoc 'never run rm -rf' prompts when you need enforceable hook rules with pattern validation.
FAQ
Who is writing-rules for?
Developers and small teams building with Claude Code who want Hookify rule files to enforce safety, tests, and production-file protection during agent sessions.
When should I use writing-rules?
Use it in Ship when hardening agent security, in Build agent-tooling when wiring hooks, or whenever you add behavioral rules to prevent unwanted actions or specific commands.
Is writing-rules safe to install?
It teaches rule authoring for your repo; review the Security Audits panel on this Prism page before trusting third-party skill sources.