iiuniversitet.ruЦентр обучения нейросетямОткрыть каталог

Написание правил Hookify

Объясняет, как писать правила hookify: что отслеживать в командах и правках и какое сообщение показывать Claude.

СкиллAnthropicClaudeApache-2.0Нужен терминалПроверка не требуется
Что делает
Объясняет, как писать правила hookify: что отслеживать в командах и правках и какое сообщение показывать Claude.
Когда брать
Когда нужно создать, отладить или доработать правило hookify, например запретить опасные команды или предупреждать о console.log.
Пример запроса
Создай правило hookify, которое предупреждает, когда я правлю файл .env.
Нужно подключить
Claude Code, плагин hookify

Входит в плагин hookify. В Cowork и Claude Code можно поставить плагин целиком.

Как включить

  1. Скачайте архив и распакуйте его.
  2. Положите папку writing-hookify-rules в ~/.claude/skills/.
  3. Откройте Claude Code и опишите задачу своими словами: Claude подхватит скилл по описанию.

Текст

---
name: writing-hookify-rules
description: Используй этот скилл, когда пользователь просит «создать правило hookify», «написать правило хука», «настроить hookify», «добавить правило hookify» или нуждается в подсказках по синтаксису и шаблонам правил hookify.
version: 0.1.0
---

Написание правил Hookify

Обзор

Правила hookify — это markdown-файлы с YAML-шапкой, которые описывают шаблоны для отслеживания и сообщения, которые нужно показать при совпадении этих шаблонов. Правила хранятся в файлах .claude/hookify.{rule-name}.local.md.

Формат файла правила

Базовая структура

---
name: rule-identifier
enabled: true
event: bash|file|stop|prompt|all
pattern: regex-pattern-here
---

Сообщение, которое нужно показать Claude, когда сработает это правило.
Может содержать markdown-разметку, предупреждения, советы и т. п.

Поля шапки

name (обязательное): уникальный идентификатор правила

  • Используй kebab-case: warn-dangerous-rm, block-console-log
  • Давай понятное название, описывающее действие
  • Начинай с глагола: warn, prevent, block, require, check

enabled (обязательное): логическое значение, включающее или выключающее правило

  • true: правило активно
  • false: правило отключено (не срабатывает)
  • Можно переключать, не удаляя правило

event (обязательное): на какое событие хука реагировать

  • bash: команды инструмента Bash
  • file: инструменты Edit, Write, MultiEdit
  • stop: когда агент хочет остановиться
  • prompt: когда пользователь отправляет промт
  • all: все события

action (необязательное): что делать при совпадении правила

  • warn: показать сообщение, но разрешить операцию (по умолчанию)
  • block: запретить операцию (PreToolUse) или остановить сессию (события Stop)
  • Если не указано, по умолчанию warn

pattern (простой формат): регулярное выражение для сопоставления

  • Используется для простых правил с одним условием
  • Сопоставляется с командой (bash) или с new_text (file)
  • Синтаксис регулярных выражений Python

Пример:

event: bash
pattern: rm\s+-rf

Расширенный формат (несколько условий)

Для сложных правил с несколькими условиями:

---
name: warn-env-file-edits
enabled: true
event: file
conditions:
  - field: file_path
    operator: regex_match
    pattern: \.env$
  - field: new_text
    operator: contains
    pattern: API_KEY
---

Вы добавляете API-ключ в файл .env. Убедитесь, что этот файл есть в .gitignore!

Поля условий:

  • field: какое поле проверять
  • Для bash: command
  • Для file: file_path, new_text, old_text, content
  • operator: как сопоставлять
  • regex_match: сопоставление регулярным выражением
  • contains: проверка подстроки
  • equals: точное совпадение
  • not_contains: подстроки НЕ должно быть
  • starts_with: проверка префикса
  • ends_with: проверка суффикса
  • pattern: шаблон или строка для сопоставления

Чтобы правило сработало, должны совпасть все условия.

Текст сообщения

Markdown-содержимое после шапки показывается Claude, когда правило срабатывает.

Хорошие сообщения:

  • Объясняют, что обнаружено
  • Объясняют, почему это проблема
  • Предлагают альтернативы или лучшие практики
  • Используют форматирование для ясности (жирный шрифт, списки и т. д.)

Пример:

⚠️ **Обнаружен console.log!**

Вы добавляете console.log в рабочий код.

**Почему это важно:**
- Отладочные логи не должны попадать в рабочую версию
- Console.log может раскрыть чувствительные данные
- Влияет на производительность браузера

**Альтернативы:**
- Используйте полноценную библиотеку логирования
- Удалите перед коммитом
- Используйте условные отладочные сборки

Справочник по типам событий

События bash

Сопоставляют шаблоны команд Bash:

---
event: bash
pattern: sudo\s+|rm\s+-rf|chmod\s+777
---

Обнаружена опасная команда!

Распространённые шаблоны:

  • Опасные команды: rm\s+-rf, dd\s+if=, mkfs
  • Повышение привилегий: sudo\s+, su\s+
  • Проблемы с правами: chmod\s+777, chown\s+root

События file

Сопоставляют операции Edit/Write/MultiEdit:

---
event: file
pattern: console\.log\(|eval\(|innerHTML\s*=
---

Обнаружен потенциально проблемный шаблон кода!

Сопоставление по разным полям:

---
event: file
conditions:
  - field: file_path
    operator: regex_match
    pattern: \.tsx?$
  - field: new_text
    operator: regex_match
    pattern: console\.log\(
---

Console.log в файле TypeScript!

Распространённые шаблоны:

  • Отладочный код: console\.log\(, debugger, print\(
  • Риски безопасности: eval\(, innerHTML\s*=, dangerouslySetInnerHTML
  • Чувствительные файлы: \.env$, credentials, \.pem$
  • Сгенерированные файлы: node_modules/, dist/, build/

События stop

Срабатывают, когда агент хочет остановиться (проверки завершения):

---
event: stop
pattern: .*
---

Прежде чем остановиться, проверьте:
- [ ] Тесты запущены
- [ ] Сборка прошла успешно
- [ ] Документация обновлена

Применяй для:

  • Напоминаний об обязательных шагах
  • Чек-листов завершения
  • Соблюдения процесса

События prompt

Сопоставляют содержимое промта пользователя (продвинутый уровень):

---
event: prompt
conditions:
  - field: user_prompt
    operator: contains
    pattern: deploy to production
---

Чек-лист деплоя в рабочую среду:
- [ ] Тесты проходят?
- [ ] Проверено командой?
- [ ] Мониторинг готов?

Советы по написанию шаблонов

Основы регулярных выражений

Буквальные символы: большинство символов совпадает сами с собой

  • rm совпадает с «rm»
  • console.log совпадает с «console.log»

Специальные символы нужно экранировать:

  • . (любой символ) → \. (буквальная точка)
  • ( ) → \( \) (буквальные скобки)
  • [ ] → \[ \] (буквальные квадратные скобки)

Распространённые метасимволы:

  • \s — пробельный символ (пробел, табуляция, перевод строки)
  • \d — цифра (0–9)
  • \w — символ слова (a-z, A-Z, 0-9, _)
  • . — любой символ
  • + — один или несколько
  • * — ноль или несколько
  • ? — ноль или один
  • | — ИЛИ

Примеры:

rm\s+-rf         Совпадает: rm -rf, rm  -rf
console\.log\(   Совпадает: console.log(
(eval|exec)\(    Совпадает: eval( или exec(
chmod\s+777      Совпадает: chmod 777, chmod  777
API_KEY\s*=      Совпадает: API_KEY=, API_KEY =

Проверка шаблонов

Проверяй регулярные выражения перед использованием:

python3 -c "import re; print(re.search(r'your_pattern', 'test text'))"

Или используй онлайн-проверки регулярных выражений (regex101.com с вариантом Python).

Частые ошибки

Слишком широкий шаблон:

pattern: log    # Matches "log", "login", "dialog", "catalog"

Лучше: console\.log\(|logger\.

Слишком узкий шаблон:

pattern: rm -rf /tmp  # Only matches exact path

Лучше: rm\s+-rf

Проблемы с экранированием:

  • Строки в кавычках в YAML: "pattern" требует двойных обратных косых \\s
  • Строки без кавычек в YAML: pattern: \s работает как есть
  • Рекомендация: используй в YAML шаблоны без кавычек

Организация файлов

Расположение: все правила — в каталоге .claude/ Именование: .claude/hookify.{descriptive-name}.local.md Gitignore: добавь .claude/*.local.md в .gitignore

Хорошие имена:

  • hookify.dangerous-rm.local.md
  • hookify.console-log.local.md
  • hookify.require-tests.local.md
  • hookify.sensitive-files.local.md

Плохие имена:

  • hookify.rule1.local.md (не описывает правило)
  • hookify.md (нет .local)
  • danger.local.md (нет префикса hookify)

Рабочий процесс

Создание правила

  1. Определи нежелательное поведение
  2. Определи, какой инструмент задействован (Bash, Edit и т. д.)
  3. Выбери тип события (bash, file, stop и т. д.)
  4. Напиши регулярное выражение
  5. Создай файл .claude/hookify.{name}.local.md в корне проекта
  6. Сразу проверь: правила читаются динамически при следующем использовании инструмента

Доработка правила

  1. Отредактируй файл .local.md
  2. Скорректируй шаблон или сообщение
  3. Сразу проверь: изменения вступают в силу при следующем использовании инструмента

Отключение правила

Временно: поставь enabled: false в шапке Навсегда: удали файл .local.md

Примеры

Готовые примеры — в ${CLAUDE_PLUGIN_ROOT}/examples/:

  • dangerous-rm.local.md — блокирует опасные команды rm
  • console-log-warning.local.md — предупреждает о console.log
  • sensitive-files-warning.local.md — предупреждает о правке файлов .env

Краткий справочник

Минимально рабочее правило:

---
name: my-rule
enabled: true
event: bash
pattern: dangerous_command
---

Текст предупреждения

Правило с условиями:

---
name: my-rule
enabled: true
event: file
conditions:
  - field: file_path
    operator: regex_match
    pattern: \.ts$
  - field: new_text
    operator: contains
    pattern: any
---

Текст предупреждения

Типы событий:

  • bash — команды Bash
  • file — правки файлов
  • stop — проверки завершения
  • prompt — ввод пользователя
  • all — все события

Варианты полей:

  • Bash: command
  • File: file_path, new_text, old_text, content
  • Prompt: user_prompt

Операторы:

  • regex_match, contains, equals, not_contains, starts_with, ends_with

Перевод: iiuniversitet. Оригинал: https://github.com/anthropics/claude-plugins-official/tree/main/plugins/hookify/skills/writing-rules, лицензия Apache-2.0. Изменения: перевод на русский язык.

Оригинал на английском
---
name: writing-hookify-rules
description: This skill should be used when the user asks to "create a hookify rule", "write a hook rule", "configure hookify", "add a hookify rule", or needs guidance on hookify rule syntax and patterns.
version: 0.1.0
---

# Writing Hookify 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.

## Rule File Format

### Basic Structure

```markdown
---
name: rule-identifier
enabled: true
event: bash|file|stop|prompt|all
pattern: regex-pattern-here
---

Message to show Claude when this rule triggers.
Can include markdown formatting, warnings, suggestions, etc.
```

### Frontmatter Fields

**name** (required): Unique identifier for the rule
- Use kebab-case: `warn-dangerous-rm`, `block-console-log`
- Be descriptive and action-oriented
- Start with verb: warn, prevent, block, require, check

**enabled** (required): Boolean to activate/deactivate
- `true`: Rule is active
- `false`: Rule is disabled (won't trigger)
- Can toggle without deleting rule

**event** (required): Which hook event to trigger on
- `bash`: Bash tool commands
- `file`: Edit, Write, MultiEdit tools
- `stop`: When agent wants to stop
- `prompt`: When user submits a prompt
- `all`: All events

**action** (optional): What to do when rule matches
- `warn`: Show message but allow operation (default)
- `block`: Prevent operation (PreToolUse) or stop session (Stop events)
- If omitted, defaults to `warn`

**pattern** (simple format): Regex pattern to match
- Used for simple single-condition rules
- Matches against command (bash) or new_text (file)
- Python regex syntax

**Example:**
```yaml
event: bash
pattern: rm\s+-rf
```

### Advanced Format (Multiple Conditions)

For complex rules with multiple conditions:

```markdown
---
name: warn-env-file-edits
enabled: true
event: file
conditions:
  - field: file_path
    operator: regex_match
    pattern: \.env$
  - field: new_text
    operator: contains
    pattern: API_KEY
---

You're adding an API key to a .env file. Ensure this file is in .gitignore!
```

**Condition fields:**
- `field`: Which field to check
  - For bash: `command`
  - For file: `file_path`, `new_text`, `old_text`, `content`
- `operator`: How to match
  - `regex_match`: Regex pattern matching
  - `contains`: Substring check
  - `equals`: Exact match
  - `not_contains`: Substring must NOT be present
  - `starts_with`: Prefix check
  - `ends_with`: Suffix check
- `pattern`: Pattern or string to match

**All conditions must match for rule to trigger.**

## Message Body

The markdown content after frontmatter is shown to Claude when the rule triggers.

**Good messages:**
- Explain what was detected
- Explain why it's problematic
- Suggest alternatives or best practices
- Use formatting for clarity (bold, lists, etc.)

**Example:**
```markdown
⚠️ **Console.log detected!**

You're adding console.log to production code.

**Why this matters:**
- Debug logs shouldn't ship to production
- Console.log can expose sensitive data
- Impacts browser performance

**Alternatives:**
- Use a proper logging library
- Remove before committing
- Use conditional debug builds
```

## Event Type Guide

### bash Events

Match Bash command patterns:

```markdown
---
event: bash
pattern: sudo\s+|rm\s+-rf|chmod\s+777
---

Dangerous command detected!
```

**Common patterns:**
- Dangerous commands: `rm\s+-rf`, `dd\s+if=`, `mkfs`
- Privilege escalation: `sudo\s+`, `su\s+`
- Permission issues: `chmod\s+777`, `chown\s+root`

### file Events

Match Edit/Write/MultiEdit operations:

```markdown
---
event: file
pattern: console\.log\(|eval\(|innerHTML\s*=
---

Potentially problematic code pattern detected!
```

**Match on different fields:**
```markdown
---
event: file
conditions:
  - field: file_path
    operator: regex_match
    pattern: \.tsx?$
  - field: new_text
    operator: regex_match
    pattern: console\.log\(
---

Console.log in TypeScript file!
```

**Common patterns:**
- Debug code: `console\.log\(`, `debugger`, `print\(`
- Security risks: `eval\(`, `innerHTML\s*=`, `dangerouslySetInnerHTML`
- Sensitive files: `\.env$`, `credentials`, `\.pem$`
- Generated files: `node_modules/`, `dist/`, `build/`

### stop Events

Match when agent wants to stop (completion checks):

```markdown
---
event: stop
pattern: .*
---

Before stopping, verify:
- [ ] Tests were run
- [ ] Build succeeded
- [ ] Documentation updated
```

**Use for:**
- Reminders about required steps
- Completion checklists
- Process enforcement

### prompt Events

Match user prompt content (advanced):

```markdown
---
event: prompt
conditions:
  - field: user_prompt
    operator: contains
    pattern: deploy to production
---

Production deployment checklist:
- [ ] Tests passing?
- [ ] Reviewed by team?
- [ ] Monitoring ready?
```

## Pattern Writing Tips

### Regex Basics

**Literal characters:** Most characters match themselves
- `rm` matches "rm"
- `console.log` matches "console.log"

**Special characters need escaping:**
- `.` (any char) → `\.` (literal dot)
- `(` `)` → `\(` `\)` (literal parens)
- `[` `]` → `\[` `\]` (literal brackets)

**Common metacharacters:**
- `\s` - whitespace (space, tab, newline)
- `\d` - digit (0-9)
- `\w` - word character (a-z, A-Z, 0-9, _)
- `.` - any character
- `+` - one or more
- `*` - zero or more
- `?` - zero or one
- `|` - OR

**Examples:**
```
rm\s+-rf         Matches: rm -rf, rm  -rf
console\.log\(   Matches: console.log(
(eval|exec)\(    Matches: eval( or exec(
chmod\s+777      Matches: chmod 777, chmod  777
API_KEY\s*=      Matches: API_KEY=, API_KEY =
```

### Testing Patterns

Test regex patterns before using:

```bash
python3 -c "import re; print(re.search(r'your_pattern', 'test text'))"
```

Or use online regex testers (regex101.com with Python flavor).

### Common Pitfalls

**Too broad:**
```yaml
pattern: log    # Matches "log", "login", "dialog", "catalog"
```
Better: `console\.log\(|logger\.`

**Too specific:**
```yaml
pattern: rm -rf /tmp  # Only matches exact path
```
Better: `rm\s+-rf`

**Escaping issues:**
- YAML quoted strings: `"pattern"` requires double backslashes `\\s`
- YAML unquoted: `pattern: \s` works as-is
- **Recommendation**: Use unquoted patterns in YAML

## File Organization

**Location:** All rules in `.claude/` directory
**Naming:** `.claude/hookify.{descriptive-name}.local.md`
**Gitignore:** Add `.claude/*.local.md` to `.gitignore`

**Good names:**
- `hookify.dangerous-rm.local.md`
- `hookify.console-log.local.md`
- `hookify.require-tests.local.md`
- `hookify.sensitive-files.local.md`

**Bad names:**
- `hookify.rule1.local.md` (not descriptive)
- `hookify.md` (missing .local)
- `danger.local.md` (missing hookify prefix)

## Workflow

### Creating a Rule

1. Identify unwanted behavior
2. Determine which tool is involved (Bash, Edit, etc.)
3. Choose event type (bash, file, stop, etc.)
4. Write regex pattern
5. Create `.claude/hookify.{name}.local.md` file in project root
6. Test immediately - rules are read dynamically on next tool use

### Refining a Rule

1. Edit the `.local.md` file
2. Adjust pattern or message
3. Test immediately - changes take effect on next tool use

### Disabling a Rule

**Temporary:** Set `enabled: false` in frontmatter
**Permanent:** Delete the `.local.md` file

## Examples

See `${CLAUDE_PLUGIN_ROOT}/examples/` for complete examples:
- `dangerous-rm.local.md` - Block dangerous rm commands
- `console-log-warning.local.md` - Warn about console.log
- `sensitive-files-warning.local.md` - Warn about editing .env files

## Quick Reference

**Minimum viable rule:**
```markdown
---
name: my-rule
enabled: true
event: bash
pattern: dangerous_command
---

Warning message here
```

**Rule with conditions:**
```markdown
---
name: my-rule
enabled: true
event: file
conditions:
  - field: file_path
    operator: regex_match
    pattern: \.ts$
  - field: new_text
    operator: contains
    pattern: any
---

Warning message
```

**Event types:**
- `bash` - Bash commands
- `file` - File edits
- `stop` - Completion checks
- `prompt` - User input
- `all` - All events

**Field options:**
- Bash: `command`
- File: `file_path`, `new_text`, `old_text`, `content`
- Prompt: `user_prompt`

**Operators:**
- `regex_match`, `contains`, `equals`, `not_contains`, `starts_with`, `ends_with`

Источник: anthropics/claude-plugins-official / hookify / writing-hookify-rules ↗. Ссылка проверена 2026-10-10.