Слэш-команды в Claude Code: 3 готовых примера для первого вечера

Что такое команда слэшом?

Выглядит это так:

/check

Или так, если команде надо передать уточнение:

/check src/components/

Команда распознаётся только в начале сообщения. Символ / не делает любой текст командой сам по себе. Сначала Claude Code находит имя в списке, затем берёт всё после имени как аргументы.

Разница с длинным промптом простая:

• длинный промпт приходится снова находить и вставлять;
• команда слэшом хранит эти инструкции в файле;
• короткий вызов легче повторить;
• аргументы можно дописать прямо после имени.

Например, вместо такого сообщения:

Проверь текущий проект. Найди файл зависимостей. Определи команду тестов. Запусти только подходящие тесты. Если тесты упали, покажи первую ошибку, файл и строку. Не исправляй файлы без моего подтверждения.

ты пишешь:

/check

Сама команда слэшом не становится отдельной программой и не получает новый инструмент. Она запускает сохранённый сценарий через механизм Claude Code. Если инструкции требуют изменения файлов, Claude Code действует по обычным правилам разрешений.

Зачем заменять длинный промпт командой слэшом?

Представь три действия, которые повторяются в каждом рабочем цикле:

1. проверить, что изменилось в проекте;
2. запустить подходящие тесты;
3. собрать отчёт о сделанном.

Каждый раз писать полный набор инструкций неудобно. Часть текста легко забыть. Ещё проще случайно отправить старую версию промпта, где нет нового правила.

Markdown-файл решает именно эту проблему. Ты один раз записываешь последовательность действий, ограничения и формат ответа. Это приём, похожий на сжатие рабочего промпта до пяти частей. После этого вызываешь короткое имя:

/check
/test
/report

Это не делает результат автоматически правильным. Команда всего лишь удерживает повторяющиеся инструкции в одном месте. Если сам сценарий составлен плохо, Claude Code будет стабильно выполнять плохой сценарий. Поэтому в первой команде лучше оставить одну понятную задачу и явно написать, что нельзя менять файлы без подтверждения.

У готовых команд есть ещё одно практическое преимущество. Их можно посмотреть, поправить и хранить вместе с проектом. Если команда нужна только для одного репозитория, файл лежит внутри .claude/. Если это личный шаблон для разных проектов, его можно сохранить в ~/.claude/.

На этом месте я бы не начинал с команды, которая сразу меняет код. Сначала возьми отчёт или проверку. У результата будет понятный экранный след, а риск случайной правки ниже.

Как сделать слэш-команды для повторяющихся действий?

1. Выбери одно действие.

   Начни с проверки проекта, отчёта или другой операции, которую ты уже несколько раз описывал длинным промптом.

   Не объединяй в первой команде проверку, исправление, коммит и публикацию. Чем шире сценарий, тем сложнее понять, какая инструкция сработала не так.

2. Создай файл команды.

   Для старого поддерживаемого формата создай .claude/commands/check.md.

   Для рекомендуемого формата создай .claude/skills/check/SKILL.md. В нём check становится именем команды, а SKILL.md остаётся обязательным именем файла. Структура папки и файла подробно разобрана в статье про первый навык.

   Скопировать

   .claude/
   ├── commands/
   │   └── check.md
   └── skills/
       └── check/
           └── SKILL.md

   Anthropic продолжает поддерживать оба формата. .claude/commands/ назван legacy-форматом, а .claude/skills/<name>/SKILL.md - рекомендуемым.

3. Опиши помощнику проверку.

   Вставь инструкции в Markdown-файл. Для первого запуска подойдёт такая заготовка:

   Проверка проекта без правокСкопировать промпт

   Проверь текущий проект.
   
   1. Найди package.json, pyproject.toml, go.mod или другой файл зависимостей.
   2. Определи команду запуска тестов.
   3. Запусти только подходящие тесты.
   4. Если тесты упали, покажи:
      - первую ошибку;
      - файл и строку;
      - краткую причину;
      - что проверить дальше.
   
   Не исправляй файлы без моего подтверждения.
   Не выполняй git add и git commit.

   Текст команды определяет её поведение. Имя файла определяет имя вызова. Сам файл должен быть Markdown-файлом.

4. Добавь аргумент при необходимости.

   Вставь $ARGUMENTS туда, где должен появиться весь текст после имени команды.

   markdown

   Скопировать

   Проверь часть проекта, указанную после имени команды:
   
   $ARGUMENTS
   
   Не исправляй файлы без моего подтверждения.

   Такой файл можно вызвать по-разному:

   Скопировать

   /check src/components/
   /check authentication flow

   Для отдельных аргументов доступны позиционные подстановки $0, $1 и далее. Anthropic показывает такой вариант:

   markdown

   Скопировать

   ---
   argument-hint: [issue-number] [priority]
   ---
   
   Исправь issue #$0 с приоритетом $1.

   $ARGUMENTS получает весь текст после имени команды. $0 и $1 позволяют обращаться к отдельным позициям.

5. Запусти команду в Claude Code.

   Открой Claude Code из терминала, перейди в нужный проект и введи:

   Скопировать

   /check

   Если нужны аргументы, добавь их после имени:

   Скопировать

   /check src/components/

   В Desktop список открывается через /. Ещё один путь: кнопка +, затем Slash commands.

6. Проверь результат без расширения задачи.

   Убедись, что команда прочитала нужные инструкции, выполнила проверку и не изменила файлы без подтверждения.

   Если команда слэшом должна только формировать отчёт, явно напиши это в файле:

   markdown

   Скопировать

   Не изменяй файлы.
   Не выполняй git commit.
   В конце покажи только результат проверки и список вопросов.

   Такой запрет не заменяет проверку результата. Посмотри, какие файлы затронуты и какие команды реально запускались.

Практикум помогает пройти этот путь руками: от повторяющегося промпта до устойчивого рабочего сценария для ИИ-агента. Там ты собираешь связку из инструкций, файлов проекта и проверок, а не просто копируешь набор команд.

Где хранить команду: только в проекте или для всех проектов?

Для команды конкретного проекта путь выглядит так:

project/
└── .claude/
    └── commands/
        └── check.md

Или в рекомендуемом формате:

project/
└── .claude/
    └── skills/
        └── check/
            └── SKILL.md

Проектный вариант подходит, когда команда нужна всем, кто работает с репозиторием. Файл можно хранить вместе с кодом. Другие участники получат ту же структуру инструкций.

Личная команда лежит в домашнем каталоге:

~/.claude/commands/check.md

Рекомендуемый личный путь:

~/.claude/skills/check/SKILL.md

Такая команда слэшом доступна во всех проектах для одного пользователя. В репозиторий её добавлять не нужно.

Я бы хранил в проекте только то, что относится к самому проекту: проверку его тестов, правила отчёта, локальный рабочий процесс. Универсальный личный шаблон отчёта или проверки можно оставить в ~/.claude/.

Не смешивай два места без причины. Если одновременно существуют проектная и личная команды с одним именем, потом сложнее понять, какой файл реально вызывается.

Какие команды попробовать в первый вечер?

/reviewpr и /issue отложи: они требуют GitHub CLI и процессов GitHub, поэтому не подходят для первого знакомства.

/project:session-current

Эта команда показывает активную сессию, её длительность, последние обновления и текущие задачи. Она работает с файлами проекта и не требует GitHub.

Запуск:

/project:session-current

В опубликованном примере команда проверяет файл .claude/sessions/.current-session. Это хороший первый сценарий: он читает локальные файлы и формирует отчёт, но не запускает внешние сервисы.

/test

Команда /test может определить область тестирования по $ARGUMENTS, запустить подходящие проверки и отдельно обработать указанный файл, папку или весь проект.

Примеры:

/test src/components/
/test all

Условие одно: в проекте уже должны быть тесты и подходящий тестовый фреймворк. Если тестов нет, команда не превращает их в готовую систему сама.

/report

Для отчёта можно создать собственный файл .claude/commands/report.md:

Составь отчёт по текущему проекту.

Покажи:
- что изменено;
- какие файлы затронуты;
- какие проверки запущены;
- что прошло;
- что не прошло;
- какие вопросы остались.

Не изменяй файлы и не выполняй git commit.

Запуск:

/report

Это безопасное направление для первого вечера: результат виден сразу, а команда не должна менять проект. Когда команд станет больше, собирай их в личный набор навыков.

Что отложить

/reviewpr получает Pull Request через GitHub CLI, проверяет diff и состояние CI. Для него нужны GitHub CLI, авторизация и существующий Pull Request.

/issue разбирает GitHub Issue, создаёт план, ветку, код, тесты и Pull Request. Кроме GitHub CLI, тут уже надо понимать Issues, ветки и Pull Request.

В репозитории awattar/claude-code-best-practices reviewpr и issue описаны как команды, за которыми стоит внешний GitHub-процесс. Для первой команды бери локальный сценарий, результат которого можно проверить в текущем проекте.

Что делать, если команда не появляется или не получает аргументы?

1. Запусти именно Claude Code. Обычный веб-чат Claude не поддерживает проектные команды Claude Code.

   Из терминала запусти:

   Скопировать

   claude

   Затем вводи / уже внутри интерфейса Claude Code. Если вставлять /check в обычный чат, проектный Markdown-файл не будет использован.

2. Проверь текущую папку. Проектная команда слэшом должна лежать в .claude/ текущего проекта.

   Проверь структуру:

   Скопировать

   project/
   └── .claude/
       └── commands/
           └── check.md

   Для личной команды проверь:

   Скопировать

   ~/.claude/commands/check.md

   Файл в случайной папке Claude Code не ищет. Для рекомендуемого формата путь должен включать каталог команды и файл SKILL.md.

3. Перезапусти сессию после создания каталога. Если .claude/skills/ появился уже после запуска Claude Code, новая команда может не попасть в текущий список сразу.

   Сделай так:

   1. проверь путь к файлу;
   2. заверши текущую сессию;
   3. снова запусти Claude Code;
   4. введи / и проверь список.

   Для старого формата безопасно сделать то же самое после создания .claude/commands/.

4. Проверь вложенную папку. Skill внутри вложенного .claude/skills/ может не появиться в автодополнении сразу после запуска из корня.

   Пример:

   Скопировать

   packages/frontend/.claude/skills/ui/SKILL.md

   Сначала попроси Claude прочитать или изменить файл в этой папке. После этого skill может стать доступен в текущей сессии. Если команда нужна из любой точки проекта, положи её в корневой .claude/.

5. Убери одинаковые имена. Если одновременно существуют такие файлы:

   Скопировать

   .claude/commands/review.md
   .claude/skills/review/SKILL.md

   приоритет получает skill. Ты можешь менять commands/review.md, но запускать содержимое skills/review/SKILL.md.

   Оставь один вариант или назови их по-разному:

   Скопировать

   .claude/commands/review.md
   .claude/skills/deep-review/SKILL.md

6. Напиши $ARGUMENTS без ошибки. Рабочая переменная пишется с долларом и заглавными буквами:

   markdown

   Скопировать

   Задача для проверки:
   
   $ARGUMENTS

   Эти варианты не подходят:

   Скопировать

   $arguments
   $ARGUMENT
   ARGUMENTS

   Вызов:

   Скопировать

   /report changes in the login flow

   Если $ARGUMENTS отсутствует в тексте команды, Claude Code не получает явное место для подстановки. Поэтому вставляй переменную прямо в нужную часть инструкции.

7. Не путай ручной и автоматический запуск. Команда запускается вручную через /имя. Автоматический вызов skill зависит от его описания и настроек.

   Если команда должна запускаться только вручную, в YAML-блок можно добавить:

   yaml

   Скопировать

   ---
   name: review
   description: Review the current git diff
   disable-model-invocation: true
   ---

   После этого запускай её явно:

   Скопировать

   /review

   В этой статье я не разбираю shell-подстановки через !: у неё отдельный синтаксис, и для первой команды она не нужна.

Как использовать слэш-команды в Discord?

Запрос слэш команды дискорд относится к другому сценарию. В Claude Code команда хранится в .claude/ или ~/.claude/ и запускает сохранённый Markdown-сценарий внутри Claude Code.

Для Discord в фактуре есть список внешних страниц и поисковый запрос, но нет проверенной инструкции, которую можно безопасно пересказать. Поэтому я не буду писать, какие права включать, где регистрировать команду и поддерживаются ли команды внутри тредов. Это касается и запроса slash commands not supported in threads: подтверждённого источника по этой теме в фактуре нет. Запрос команда слэш майнкрафт и команды слэш майнкрафт тоже относятся к другой теме: это игровые команды Minecraft, для которых нужны отдельные источники.

Вопросы и ответы