Команды Claude Code: от встроенных функций до своих навыков

В полезной командной процедуре указаны входные данные, материалы для проверки и формат результата. Это своего рода рабочее задание, которое хранится рядом с кодом. Вызов команды подставляет в него данные текущей задачи.

Начните с /plan, /diff, /context и /compact. Затем добавьте /team-pr-check из шаблонов ниже. Ревью хорошо подходит для первого опыта: вопросы о правах доступа, данных и тестах возникают при каждом изменении.

Встроенные команды Claude Code, которые стоит освоить

Вводите эти команды в начале сообщения внутри Claude Code. Квадратные скобки обозначают необязательные аргументы, угловые — обязательные. Синтаксис в этой подборке соответствует актуальному справочнику команд Anthropic, проверенному 13 октября 2026 года. Доступность команд зависит от платформы, тарифа и окружения.

Используйте /compact, когда продолжаете ту же задачу, и /clear, когда переходите к другой. При работе над функцией пригодится такая инструкция: /compact keep the acceptance criteria, unresolved risks, and exact test commands.

Команда /release-notes открывает список изменений Claude Code. Она не составляет описание релиза вашего приложения. Поэтому у пользовательской команды ниже намеренно другое имя.

О том, как встроить эти команды в повседневную работу, читайте в руководстве по эффективной работе с Claude Code.

В меню команд есть и встроенные навыки

Некоторые команды со слешем передают Claude готовую процедуру. Это встроенные навыки, а не фиксированные средства управления CLI:

• /code-review выполняет ревью diff или другого поддерживаемого объекта. /review — её псевдоним. Аргумент --fix запрашивает правки, а --comment — публикацию комментариев ревью.
• /simplify проверяет изменённый код на возможности упрощения и вносит исправления.
• /verify собирает и запускает приложение, чтобы проверить его поведение.
• /doctor диагностирует проблемы настройки и предлагает исправления.

Если сначала нужны замечания, а уже потом изменения, выбирайте обычное ревью. Полный синтаксис этих команд, требования и условия доступности приведены в разделе встроенных навыков справочника команд.

Свои команды Claude Code теперь создают как навыки

Для новой процедуры сохраните Markdown-файл с инструкциями в репозитории по пути .claude/skills/<name>/SKILL.md. Добавьте его в коммит, чтобы коллеги получили ту же процедуру. Личные процедуры храните в ~/.claude/skills/<name>/SKILL.md.

Прежний формат .claude/commands/<name>.md по-прежнему работает. Оба варианта создают команды /<name>. В каталоге навыка можно также хранить шаблоны, справочные материалы и скрипты. По мере усложнения процедуры этот формат становится удобнее. Руководство Anthropic по навыкам

Откуда берутся команды плагинов и MCP

Плагины объединяют возможности в пакеты для повторного использования. Их каталоги skills/<name>/SKILL.md создают команды с пространством имён, например /plugin-name:skill-name. Команды плагинов в старом формате хранятся в commands/. Эти каталоги должны находиться в корне плагина, рядом с каталогом .claude-plugin/, содержащим манифест, а не внутри него. Управляйте плагинами через /plugin, а после изменений вызывайте /reload-plugins. Компоненты плагинов

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

Промпты MCP поступают с подключённых серверов. MCP, или Model Context Protocol, связывает Claude Code с внешними инструментами и данными. Сервер также может предоставлять готовые промпты для повторного использования. В меню они отображаются как /servername:promptname (MCP); вызвать их можно и через /mcp__servername__promptname. Такие команды появляются только в том случае, если подключённый сервер предоставляет соответствующие промпты. Наличие инструментов у интеграции само по себе не означает, что в ней есть любой нужный вам промпт. Документация по промптам MCP

Аргументы промптов MCP разделяются пробельными символами и соответствуют параметрам, объявленным сервером. Результат промпта добавляется в диалог. Не стоит рассчитывать, что серверный промпт обрабатывает аргументы так же, как локальный навык.

Создайте файл и укажите входные данные задачи

Frontmatter — небольшой блок настроек YAML перед инструкциями Markdown. Открывающий разделитель --- должен стоять в первой строке файла. В таблице — поля, которые пригодятся для этих шаблонов:

Поле allowed-tools выдаёт разрешение, а не ограничивает набор доступных инструментов только этим списком. Все поля frontmatter необязательны; description рекомендуется. Файлы команд старого формата принимают те же поля, кроме name и paths. Справочник по frontmatter

Аргументы: $ARGUMENTS подставляет всю входную строку. $0 или $ARGUMENTS[0] обозначает первый аргумент, $1 — второй. Именованные аргументы сопоставляются с позициями по порядку. Если позиционный аргумент состоит из нескольких слов, заключите его в кавычки. Поле argument-hint описывает входные данные, но самой процедуре всё равно нужно их проверять. Подстановка аргументов

В шаблонах нет поля name: имя берётся из названия каталога. Их frontmatter работает и в старом формате файлов команд. Постоянные сведения о репозитории храните в командной памяти CLAUDE.md, а порядок выполнения конкретной задачи — в её навыке.

Пять готовых команд для вашей команды

Создайте каждый из указанных ниже каталогов и вставьте соответствующий блок в SKILL.md. Затем выполните /reload-skills, чтобы повторно просканировать файлы. Это авторские шаблоны для адаптации под ваши задачи, а не встроенные команды Anthropic и не заявления о результатах тестирования.

Сначала идут повторяемые инженерные проверки, затем — подготовка сообщений о проделанной работе. Шаблоны по возможности опираются на данные локального репозитория. Чтобы получить полезный результат, им не нужно подключение к трекеру задач или сервису PR.

Чек-лист ревью PR, затрагивающего клиентские данные

Небольшая SaaS-команда может запускать эту процедуру перед тем, как просить коллегу о ревью. Она каждый раз задаёт одни и те же вопросы об изоляции арендаторов, авторизации и тестовом покрытии, даже если автор изменений торопится. В результате на ревью поступает более последовательно подготовленный материал, где каждое замечание привязано к месту в коде и сценарию сбоя.

Сохраните файл как .claude/skills/team-pr-check/SKILL.md. Вызовите /team-pr-check main, чтобы проверить текущую ветку относительно её общего предка с main.

---
description: Review a branch against the team's business-risk checklist
argument-hint: "[base-ref]"
disable-model-invocation: true
---

Review the current branch against this base ref: $ARGUMENTS
If no base is supplied, ask for it. Confirm it exists locally.
Read CLAUDE.md and any repository review guidance first.
Inspect the diff from the merge base to HEAD. Report uncommitted
changes separately; do not silently mix them into the branch review.

Check:
- Authorization and tenant boundaries on every changed data path.
- Validation, failure handling, retries and duplicate side effects.
- Schema compatibility, rollout assumptions and rollback options.
- Regression coverage for the changed behavior.
- Secrets, sensitive logs and changes to public contracts.

For each finding: severity, file and line, triggering scenario,
user impact and a concrete repair or test. Separate verified findings
from questions. Mark checks you could not assess as unknown.
Return findings first, then the checklist with pass/fail/unknown
and supporting evidence. If none are found, say so and name gaps.
Review only. Do not edit files, post comments, approve or merge.

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

Воспроизводимый баг: сначала тест, затем исправление

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

Сохраните файл как .claude/skills/team-test-first-fix/SKILL.md. Вызовите /team-test-first-fix duplicate webhook events create duplicate invoices.

---
description: Reproduce a bug with a failing test before fixing it
argument-hint: "[bug description or local issue file]"
disable-model-invocation: true
---

Bug: $ARGUMENTS
If the expected behavior is unclear, ask before changing code.
Read CLAUDE.md, inspect the working tree and preserve unrelated edits.
Find the relevant code and the repository's existing test runner.
Use local fixtures or mocks; do not call production services.

Add the smallest regression test that demonstrates the reported bug.
Run it before changing implementation. Confirm that it fails for
this bug, not because the environment or test setup is broken.
If you cannot demonstrate that failure, explain the blocker and stop.

Make the smallest implementation change that fixes the behavior.
Rerun the regression test and relevant nearby tests. Do not weaken
assertions to obtain a pass or expand into unrelated refactoring.

Report the cause, changed files, failing-before evidence,
passing-after evidence and any tests you could not run.
Do not commit, push or deploy.

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

План миграции до изменений в общей системе

Команда, которая меняет схему базы данных или заменяет API, может заранее прояснить порядок действий и вопросы совместимости. Полезный результат здесь — план, который можно критически разобрать, особенно в части одновременной работы старых и новых версий.

Сохраните файл как .claude/skills/team-migration-plan/SKILL.md. Вызовите /team-migration-plan "billing storage" "new invoice schema".

---
description: Plan a migration with compatibility checks and rollback gates
argument-hint: "[scope] [target-state]"
arguments: [scope, target]
disable-model-invocation: true
---

Plan a migration of $scope to $target.
If either input is missing or ambiguous, ask for clarification.
Read CLAUDE.md and inspect the current implementation and consumers.
Do not edit files, execute migrations or connect to production.

Describe the current state with file references. List affected data,
APIs, background jobs, integrations and deployment dependencies.
Separate verified facts from assumptions that need an owner.

Propose small phases with dependencies, acceptance checks and a
stop/go decision for each. Include compatibility between old and new
versions, backfill validation, retries and observability.
For each phase, describe rollback or recovery. Flag irreversible
steps and data that a code rollback cannot restore.

Return a reviewable plan, open questions and the smallest safe pilot.
Do not invent a duration, data volume or owner.

Инструкция составить план не меняет режим разрешений Claude Code. Если сессия тоже должна работать в Plan Mode, введите /plan перед вызовом навыка. Письменная процедура и разрешения на использование инструментов в сессии — отдельные средства управления. Plan Mode

Описание релиза вашего продукта

Разработчик, отвечающий за релизы, может с помощью этой процедуры превратить заданный диапазон изменений в черновик для клиентов. Она упрощает перевод коммитов на язык пользы для пользователя и требует подтверждения для каждого утверждения.

Сохраните файл как .claude/skills/team-release-notes/SKILL.md. Вызовите /team-release-notes previous-release HEAD, заменив previous-release существующим тегом или коммитом.

---
description: Draft product release notes from a verified Git range
argument-hint: "[base-ref] [head-ref]"
arguments: [base, head]
disable-model-invocation: true
---

Draft release notes for $base..$head.
If either ref is missing, ask. Confirm both resolve locally.
Read CLAUDE.md and the project's existing release-note format.
Inspect commits in the range and compare the endpoint trees.
Use the changed code and tests to verify what each change does.

Group the draft into Added, Changed, Fixed and Breaking Changes.
Omit empty sections. Describe user impact without exposing internal
secrets or vulnerability details that need coordinated disclosure.
Attach a commit or file reference to each item for the reviewer.
Do not claim a change is deployed, enabled for every customer or
faster by a measured amount without evidence of that fact.

Finish with upgrade actions, unresolved questions and any changes
excluded because their impact could not be established.
Return a draft in chat. Do not edit the changelog, tag a release,
publish, send messages or deploy.

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

Еженедельная сводка изменений для команды

Руководитель разработки может использовать эту процедуру для еженедельного отчёта продуктовой команде и поддержке. Она отделяет изменения, влитые в ветку, от подтверждённых релизов, чтобы в отчёте случайно не объявили о функции, которая ещё скрыта за флагом.

Сохраните файл как .claude/skills/team-weekly-changelog/SKILL.md. Вызовите /team-weekly-changelog START_DATE END_DATE main, заменив даты временными метками ISO с указанием часового пояса. Начало интервала включается, конец — нет.

---
description: Draft a weekly engineering changelog from branch history
argument-hint: "[since] [until] [branch]"
arguments: [since, until, branch]
disable-model-invocation: true
---

Prepare a weekly changelog for $branch from $since inclusive to
$until exclusive. If an input is missing, ask. Confirm the timezone
and that the branch exists locally. State whether its checkout may
be stale; do not fetch or assume it matches the remote.

Read CLAUDE.md and the team's update format. Inspect commits reachable
from the branch, filtering by committer timestamp in this window.
Explain that commit timestamps do not prove merge or release dates.
Read diffs for claimed outcomes. Group related changes into themes
and avoid counting a merge and its constituent commits as separate
outcomes. Separate product changes, fixes and maintenance.

For each item, give its impact and a commit or file reference.
Label release status unknown unless deployment evidence is available.
Do not infer blockers, revenue, adoption or completion percentages
from commit messages. List evidence gaps at the end.
Return a concise draft in chat. Do not write files or send the update.

Разделяйте описание релиза и еженедельный отчёт. У релиза есть чётко заданные границы изменений кода и клиентская аудитория. У еженедельного отчёта — отчётный период; в него может входить полезная работа, которая ещё не дошла до пользователей.

Как понять, что команду стоит оставить?

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

Польза за неделю рассчитывается так: число запусков × (прежнее время подготовки и исправлений − новое время подготовки и исправлений) × стоимость часа работы команды − дополнительные расходы на модель − время поддержки процедуры, оценённое по той же часовой ставке. Подставляйте собственные замеры. Длинный промпт, после которого требуется больше работы по проверке результата, может приносить убыток, даже если процесс кажется более автоматизированным.

Наиболее вероятный источник экономии — время старших разработчиков, которое уходит на повторное объяснение одного и того же процесса и доработку неполных результатов, переданных коллегами. При изменении архитектуры или порядка выпуска релизов процедуру тоже придётся обновлять.

Сохранённая команда по-прежнему расходует ресурсы модели, когда Claude выполняет её инструкции. /usage показывает оценку стоимости токенов и сведения об использовании тарифа; показанная оценка стоимости API не является счётом за подписку. Документация Anthropic о расходах

Две идеи продукта на основе этих команд

Шаблоны полезны как внутренние инструменты. Чтобы превратить их в продукт, нужно предложить преимущество весомее, чем хранение промпта.

Самая перспективная идея: проверки ревью под конкретный репозиторий

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

В отчёте Keyword Overview от DataForSEO по англоязычному поиску Google в США за 13 октября 2026 года оценка для запроса «ai code review» составила 1,300 поисковых запросов в месяц. Это сигнал интереса к задаче, а не подтверждение спроса на конкретный плагин Claude Code. DataForSEO Keyword Overview

Минимальная версия, за которую можно брать деньги, могла бы объединять проектный чек-лист, пояснения к архитектуре и набор прошлых ошибок для оценки качества. Прежде чем распространять её как плагин, добейтесь, чтобы на этих примерах она выдавала замечания с подтверждениями.

Главная сложность — сильная конкуренция: в Claude Code уже есть средства ревью, а CodeRabbit продаёт инструменты для ревью кода. Универсальный промпт для ревью слабо отличает продукт от других. Я бы выбрал эту идею только при наличии доступа к истории ошибок конкретной команды и человека, который отвечает за актуальность проверок.

Более скромная идея: сообщения о релизах с подтверждениями

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

В том же отчёте оценка для фразы «release notes generator» составила 70 поисковых запросов в месяц. Это скромный поисковый сигнал, поэтому я бы начал с услуги или внутреннего процесса, прежде чем разрабатывать отдельное приложение. DataForSEO Keyword Overview

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

Какие ограничения важны в кодовой базе бизнеса

Команда стандартизирует инструкции. Приемлемость результата по-прежнему определяют тесты, ревью и контроль выпуска релизов. Считайте пять шаблонов отправной точкой и проверяйте изменения в них вместе с кодом приложения.

Полное содержимое навыка загружается при его использовании, поэтому саму процедуру стоит делать краткой, а подробные справочные материалы выносить в отдельные файлы. Личные навыки могут иметь приоритет над проектными с тем же именем; в локальных терминальных сессиях навыки также могут перекрывать встроенные команды. Выбирайте различимые имена и проверяйте источник, если у коллег поведение отличается. Загрузка навыков и приоритеты

Правила доступа к инструментам настраивайте отдельно. Фраза «только ревью» сообщает Claude о вашем намерении, но не задаёт ограничение на уровне операционной системы. Разрешения Claude Code

С чего начать в понедельник

Первым добавьте в репозиторий /team-pr-check. Замените общие пункты проверками, которые должно было пройти последнее проблемное изменение. Запустите команду на завершённом изменении, результат которого вам известен, сопоставьте замечания с реальной проблемой и доработайте процедуру, прежде чем вводить её в повседневную работу команды. Команды для релизов и еженедельных отчётов добавляйте после согласования форматов результата.

Если вы хотите связать эти процессы со своими бизнес-системами, я разрабатываю автоматизацию на базе ИИ с учётом проверок, которые действительно нужны вашей команде.