Built-in commands и bundled skills

1. Косая черта как источник путаницы

Когда вы впервые открываете Claude Code и видите /help, /clear, /debug и проектную /issue-analysis, мозг почти автоматически складывает всё в одну коробку «команды Claude Code». Это нормальная реакция: интерфейс специально делает их похожими. Но инженерная ловушка в том, что одинаковая форма не означает одинаковую природу.

Чтобы это стало нагляднее, представьте обычные двери в большом офисе. Ручки одинаковые, но за одной серверная, за другой переговорка, за третьей кухня с печеньками. Ориентируетесь только на ручку — удивитесь. Со slash-командами так же: одна управляет сессией, другая запускает встроенный workflow, третья живёт только в вашем проекте, четвёртая ведёт во внешний инструмент.

Это различие важно не ради теории — оно напрямую влияет на работу. Приняли проектную команду за встроенную — она «вдруг» исчезнет в другом репозитории. Не понимаете происхождение — не отладите, не перенесёте, не объясните коллеге. Отсюда главная мысль лекции:

Slash-команда — это форма вызова, а не тип механизма.

Дальше соберём карту механизмов. И проступит второе измерение той же проблемы: разные расширения маскируются под одну форму /что-то.

2. Slash-команда — это интерфейс, а не сущность

Снаружи slash-команды действительно выглядят одинаково: вы пишете косую черту, имя, иногда аргументы, и Claude Code что-то делает. Но под оболочкой прячутся разные вещи. Учитесь видеть категорию, а не красивое имя — тогда поведение системы предсказуемо, а не магично. Удобно смотреть на это через простую схему:

flowchart TD
    A["Вы видите /команду"] --> B["Что она делает на самом деле?"]
    B --> C["Встроенная команда
управляет сессией и продуктом"]
    B --> D["Встроенный workflow
bundled skill"]
    B --> E["Пользовательский workflow
custom skill"]
    B --> F["Поверхность plugin или внешнего инструмента"]

Если перевести эту схему на человеческий язык, получится следующее. /clear меняет состояние сессии. /debug не «чинит продукт изнутри», а запускает готовую процедуру анализа. /issue-analysis из нашего Workflow Kit проектная — появляется, потому что команда положила skill в .claude/skills/. А команда внешнего трекера может быть точкой входа во внешний инструмент или plugin. Эту разницу полезно держать в короткой таблице:

Здесь важны две оговорки. Во-первых, это учебные примеры. Точные названия и доступность зависят от версии Claude Code и вашей конфигурации. Во-вторых, форма /что-то специально уравнивает механизмы, чтобы не учить пять способов запуска. Обычному человеку удобно. Инженеру — мало: он спрашивает дальше, откуда команда пришла и по каким правилам живёт.

3. Built-in commands: управление сессией

Когда говорят «встроенная команда», обычно имеют в виду то, что приходит с самим Claude Code и управляет продуктом или сессией — не ваша проектная логика. Это приборная панель: очистить историю, посмотреть статус, сжать контекст, открыть справку, глянуть диагностику. Она помогает вести работу, но обычно не создаёт артефакт предметной области вроде TASK_SPEC.md.

В условной сессии /help может показать примерно такое:

/help

Сеанс и контекст:
  /clear
  /compact
  /context

Диагностика:
  /status
  /doctor

Встроенные workflows:
  /debug
  /review

Опять же, это не обещание, что именно такой вывод вы увидите строка в строку — но сам признак очень устойчивый: встроенная команда отвечает не на «какой workflow выполнить?», а на «что сделать с текущей сессией?». /clear не связан с Commerce OS, issue, refund-запросом или TASK_SPEC.md — он про ваш разговор с Claude Code. Потому переносится между проектами надёжнее: в другом репозитории /clear почти точно останется, а /issue-analysis уже не факт. Из этого вытекает важная привычка: каталог встроенных команд не заучивайте как таблицу умножения — каждый раз берите /help как источник истины.

4. Bundled skills: встроенные workflow под /

Теперь начинается самая коварная часть. Есть команды, которые выглядят как встроенные сервисные, но это встроенные workflow «из коробки». В документации их зовут bundled skills. Термин вторичен, важна идея: это не механизм управления сессией, а готовая процедура работы.

Если встроенная команда вроде /clear отвечает на «что сделать с разговором?», то встроенный workflow — на «какую процедуру выполнить поверх текущего контекста?»: /debug разворачивает отладочный разбор, /review проходится по изменениям, /simplify предлагает упрощение. Именно поэтому многие студенты путаются: снаружи /clear и /debug — одно семейство, но первая меняет состояние сессии, вторая запускает рабочую процедуру. Разница как между кнопкой «стереть доску» и кнопкой «подготовить разбор задачи»: обе на панели, а делают вещи разного класса.

Есть ещё один полезный признак workflow: его описывают словами «проанализировать», «проверить», «помочь», «упростить», «разобрать». Он не настраивает среду, а производит содержательный результат — текст, план, ревью-замечания. И это «подвижная» часть продукта: состав и названия меняются заметнее, чем у базовых команд. Потому особенно опасно копировать список из чужого скриншота и считать его вечным. Увидели в статье /debug или /review — сначала откройте /help у себя.

Удобно один раз зафиксировать терминологию. Skill — reusable workflow. Приехал с продуктом — bundled skill; описан вашей командой внутри проекта — custom skill. Снаружи оба вызываются через один slash-интерфейс, поэтому смотрите не на косую черту, а на источник и владельца.

5. Практическая разметка слой за слоем

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

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

Второй вопрос: существует ли команда вне текущего проекта? Это можно проверить очень простым способом — откройте пустой репозиторий и вызовите /help там. Команда живёт только в Commerce OS с подключённым Workflow Kit, а в пустом репозитории её нет — значит, не базовая. Это не баг и не обида ИИ, а проектное расширение.

Третий вопрос: где источник истины? Для первого ответа годится /help. Но если команда явно не базовая и связана с вашим процессом — стоит заглянуть и в сам репозиторий. Условно это может выглядеть так:

workflow-kit/
  .claude/
    skills/
      issue-analysis/
        SKILL.md

Если вы нашли в проекте такую структуру, вопрос почти закрыт. Команда не упала с неба, её создала ваша команда как reusable workflow — и это хорошая новость: её можно читать, ревьюить и сопровождать как инженерный артефакт.

Полезно также понимать, почему команды иногда «ведут себя не так». Одна из частых причин — конфликт имён: свой skill назвали слишком общо, а продукт или plugin уже занял похожее. Вывод: не давайте проектным командам слишком общие имена. /issue-analysis безопаснее, чем /review, которое легко спутать со встроенной командой.

Если команда вас смущает, порядок действий может быть очень коротким:

1. Сначала открыть /help и прочитать, как команда описана именно в этой сессии.

2. Потом проверить, остаётся ли она в другом, чистом репозитории.

3. Если нет, заглянуть в .claude проекта — не живёт ли она там как skill или часть командного набора.

Эта тройка работает надёжно и не требует феноменальной памяти.

6. Сценарий из Workflow Kit с /issue-analysis

Теперь привяжем всё к сквозному проекту, чтобы тема не повисла в воздухе. В Commerce OS команда регулярно получает входящие issue: баги, мелкие фичи, непонятные запросы от бизнеса. Чтобы не писать каждый раз длинный prompt руками, процесс выносят в Workflow Kit как skill issue-analysis — так появляется /issue-analysis, которая собирает TASK_SPEC.md по стандарту команды.

С точки зрения новичка ситуация выглядит обманчиво простой. Он видит /clear, /debug и /issue-analysis — все три кажутся одинаково «родными». Переключается в репозиторий без Workflow Kit — и /issue-analysis исчезает. Рождается классическое «у меня что-то сломалось». А не сломалось ничего: одна команда встроенная, другая — workflow, третья — артефакт команды.

Вот почему в документации важно писать не только «используйте /issue-analysis», но и что это за команда по происхождению. Часть Workflow Kit — так и скажите. Тогда onboarding проходит гораздо спокойнее: за пределами проекта команды может не быть, а если её нет — надо подключить артефакт, а не переустанавливать Claude Code в попытке умилостивить цифровых духов. Slash-поверхность у всех одна, жизненный цикл — разный.

7. Песочница вместо живого проекта

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

Минимально безопасный ритуал:

git checkout -b sandbox/commands
git status   # working tree clean

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

Итог простой: за одинаковой косой чертой стоят команды с разной судьбой. Одна управляет сессией и переезжает в любой репозиторий. Другая — встроенный workflow, который меняется от версии к версии. Третья живёт только там, где команда положила skill в .claude/. Три вопроса — чем управляет, есть ли вне проекта, где источник истины — разводят их без гадания и без переустановки Claude Code «на всякий случай». А /help и чистый репозиторий на песочница-ветке всегда под рукой, когда команда ведёт себя не так. Дальше берём последнюю из этих категорий — собственный skill проекта — и в следующем шаге откроете, отревьюите и разовьёте его как часть Workflow Kit.