Вбудовані команди й 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   # робоче дерево чисте

Після цього вже можна спокійно відкривати /help і перевіряти гіпотези. Команда викликає сумніви — відтворіть її наявність у порожньому репозиторії. Зникла — майже напевно не базова вбудована. Залишилася, але поводиться інакше — річ у версії або налаштуваннях середовища.

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