Creates behavioral rules in markdown to block dangerous commands or restrict AI behavior. Use when adding safety guardrails or preventing specific commands.
npx skills add https://github.com/athola/claude-night-market --skill writing-rules
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.
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!
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
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.
regex_match: Pattern matchingcontains: Substring checkequals: Exact matchnot_contains: Must NOT containstarts_with: Prefix checkends_with: Suffix checkbash events: command
file events: file_path, new_text, old_text, content
prompt events: user_prompt
stop events: transcript
\s - whitespace\d - digit\w - word character. - any character (use \. for literal dot)+ - one or more* - zero or more| - ORrm\s+-rf → rm -rf
console\.log\( → console.log(
chmod\s+777 → chmod 777
python3 -c "import re; print(re.search(r'pattern', 'text'))"
---
name: block-destructive
enabled: true
event: bash
pattern: rm\s+-rf|dd\s+if=|mkfs
action: block
---
🛑 **Destructive operation blocked!**
Can cause data loss.
---
name: warn-debug
enabled: true
event: file
pattern: console\.log\(|debugger;
action: warn
---
🐛 **Debug code detected!**
Remove before committing.
---
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.
---
name: protect-prod
enabled: true
event: file
action: block
conditions:
- field: file_path
operator: regex_match
pattern: /production/|\.prod\.
---
🚨 **Production file!**
Requires review.
Enable/Disable:
Edit .local.md file: enabled: false
Delete:
rm .claude/hookify.my-rule.local.md
List:
/hookify:list
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.
.claude/hookify.<rule-name>.local.mdwith all required frontmatter fields present: name (kebab-case),
enabled, event, and either pattern or conditions
`python3 -c "import re; print(re.search(r'<pattern>', '<test>'))"
before the rule is saved; no untested patterns shipped
warn actionshows the message body, block action prevents the operation
tested with at least one known-safe example
Guide users through a structured workflow for co-authoring documentation. Use when user wants to write documentation, proposals, technical specs, decision docs, or similar structured content. This workflow helps users efficiently transfer context, refine content through iteration, and verify the doc works for readers. Trigger when user mentions writing docs, creating proposals, drafting specs, or similar documentation tasks.
Automatically creates user-facing changelogs from git commits by analyzing commit history, categorizing changes, and transforming technical commits into clear, customer-friendly release notes. Turns hours of manual changelog writing into minutes of automated generation.
Use when implementing any feature or bugfix, before writing implementation code
Use when you have a spec or requirements for a multi-step task, before touching code
Use when creating new skills, editing existing skills, or verifying skills work before deployment
Use when writing or improving README files. Not all READMEs are the same — provides templates and guidance matched to your audience and project type.
| Remove signs of AI-generated writing from text. Use when editing or reviewing text to make it sound more natural and human-written. Based on Wikipedia's inflated symbolism, promotional language, superficial -ing analyses, vague attributions, em dash overuse, rule of three, AI vocabulary words, negative parallelisms, and excessive conjunctive phrases.
Official Opentrons Protocol API for OT-2 and Flex robots. Use when writing protocols specifically for Opentrons hardware with full access to Protocol API v2 features. Best for production Opentrons protocols, official API compatibility. For multi-vendor automation or broader equipment control use pylabrobot.
Take athola/writing-rules from the repository into ~/.claude/skills for personal
use, or into .claude/skills inside a project.
The agent identifies a skill by the name field in its header. Two skills with the
same name cannot sit side by side — one of them will be ignored.