Визначай 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