Определяй повторно используемые slash-команды как Markdown-файлы, делись ими с командой через git и покрывай частые задачи: ревью кода, генерацию тестов, описания PR.
В Claude Code есть несколько встроенных slash-команд — /help, /clear, /compact. Но те, что по-настоящему ускоряют работу, — это те, что написаны вами самими.
Эта статья о том, как спроектировать систему повторно используемых slash-команд, чтобы вся команда разработчиков работала с одной библиотекой промптов, а не описывала задачи заново каждый раз.
В Claude Code пользовательская slash-команда — это просто Markdown-файл. Поместите его в нужную директорию, Claude Code обнаружит его при запуске, и ввод /имя-файла активирует его.
Содержимое файла — это промпт, который отправляется Claude. Вот и всё.
Никакого специального синтаксиса, никакого формата конфигурации — один файл .md это одна команда.
Два места, два назначения:
| Место | Путь | Область действия |
|---|---|---|
| Проект | .claude/commands/ |
Только текущий проект, можно закоммитить в git |
| Пользователь | ~/.claude/commands/ |
Все проекты, личное |
Уровень проекта — основа командного шаринга. Закоммитьте .claude/commands/ в git, и у всех, кто клонирует репозиторий, автоматически появится полный набор команд.
Уровень пользователя подходит для личных привычек — предпочитаемые проверки стиля кода или интеграции инструментов, которыми пользуетесь только вы.
В корне проекта:
mkdir -p .claude/commands
Создайте .claude/commands/review.md:
Проверь качество кода текущих изменений. Сосредоточься на:
1. Логических ошибках и граничных случаях
2. Ясности именования
3. Дублированном коде, который стоит вынести
4. Проблемах безопасности (SQL-инъекции, XSS, раскрытые секреты)
Давай конкретные, практичные предложения — без общих советов.
Перезапустите Claude Code и введите /review для активации.
Команды с фиксированным содержимым ограничены в применении. $ARGUMENTS делает их гибкими — то, что пользователь вводит после /команды, подставляется в промпт.
Пример .claude/commands/test.md:
Напиши тесты для следующего: $ARGUMENTS
Требования:
- Покрой штатный путь и граничные случаи
- Названия тестов должны быть самодокументирующими
- Используй реальные данные вместо моков там, где это возможно
Использование:
/test метод login класса UserAuthentication
Claude получает:
Напиши тесты для следующего: метод login класса UserAuthentication
Требования:
...
$ARGUMENTS может встречаться в промпте в любом месте и использоваться несколько раз.
Одна команда — одна ответственность
Не пишите команду "на все случаи жизни". /review — только для ревью кода, /test — только для написания тестов, /pr — только для описаний PR. Узконаправленные команды легче запомнить и проще переиспользовать.
Пишите конкретные промпты, не абстрактные
Плохо:
Помоги мне оптимизировать этот код
Хорошо:
```
Оптимизируй этот код по производительности. Приоритеты:
1. Сокращение лишних запросов к базе данных (проблемы N+1)
2. Избегание повторных вычислений внутри циклов
3. Замена линейных поисков более эффективными структурами данных
Интерфейс оставь без изменений — меняй только реализацию.
```
Конкретные ограничения ведут к точным результатам.
Добавляйте frontmatter к командам
Поле description отображается в списке команд Claude Code, чтобы члены команды сразу понимали назначение каждой команды:
---
description: Проверяет текущие изменения и даёт обратную связь по качеству кода
---
Проверь качество кода текущих изменений...
Для Rails-проекта эти команды покрывают наиболее частые задачи ежедневной разработки:
.claude/commands/review.md — Ревью кода
Проверь изменения в git diff. Обрати внимание на:
- Логические ошибки и обработку граничных случаев
- Проблемы безопасности: SQL-инъекции, проверки авторизации
- Читаемость именования
- Дублированную логику, которую стоит вынести
По каждой проблеме укажи конкретное место и предложение по исправлению.
```
.claude/commands/test.md — Генерация тестов
Напиши тесты для этого кода: $ARGUMENTS
Используй RSpec. Покрытие: штатный путь, граничные значения, условия ошибок.
Формат именования: describe ... context ... it ...
По умолчанию используй реальные объекты; мокай только внешние зависимости при необходимости.
```
.claude/commands/pr.md — Описание PR
На основе git diff и лога коммитов создай описание PR.
Формат:
(2-3 предложения с кратким описанием сделанного)
(Контекст и мотивация)
(Как проверить это изменение)
Лаконично, для ревьюера кода.
```
.claude/commands/explain.md — Объяснение кода
Объясни, что делает $ARGUMENTS:
- Какова общая ответственность?
- Как работает ключевая логика?
- Какие граничные случаи стоит отметить?
Пиши для разработчика, который впервые знакомится с этой частью кода. Фокус на почему, а не только на что.
```
Некоторые привычки сугубо личные и не должны навязываться всей команде. Помещайте их в ~/.claude/commands/:
~/.claude/commands/standup.md — Подготовка к ежедневному стендапу
```markdown
На основе сегодняшнего git log и открытых TODO подготовь сводку для стендапа:
- Что завершил вчера
- Что планирую сегодня
- Есть ли блокеры
Не более 5 предложений.
```
~/.claude/commands/refactor.md — Предложения по рефакторингу
```markdown
Проанализируй $ARGUMENTS и предложи улучшения через рефакторинг.
Только действительно ценные изменения — не рефакторинг ради рефакторинга.
По каждому предложению: какую проблему решает, насколько объёмное изменение, каков риск.
```
Настоящая ценность пользовательских команд — не личная продуктивность, а создание общего языка для команды.
Закоммитьте .claude/commands/ в репозиторий и задокументируйте доступные команды в README или CLAUDE.md. Новые члены команды получают накопленную библиотеку промптов в момент клонирования репозитория, не тратя время на самостоятельные поиски.
По мере развития проекта развиваются и команды. Если промпт работает неэффективно, исправьте одну строку и сделайте push — вся команда получает обновление. Это самый малозатратный способ внедрить промпт-инжиниринг на уровне команды.
.claude/
├── commands/
│ ├── review.md # Ревью кода
│ ├── test.md # Генерация тестов
│ ├── pr.md # Описание PR
│ └── explain.md # Объяснение кода
└── settings.json