Использование skill-creator: создайте свой собственный skill с помощью skill
📚 Навигация по серии: Предыдущая статья [27 Примеры использования Skills] научила вас, как правильно использовать skills, созданные другими: как их устанавливать, запускать автоматически и делать их удобными в использовании. В этой статье мы пойдем от обратного: научим вас создавать свои собственные. И не вручную, а с помощью официального skill, специально предназначенного для создания skills —
skill-creator.
Говорят, что SKILL.md — это просто файл markdown, и его можно написать вручную, зачем нужен еще один инструмент?
Честно говоря, это лишь половина правды. Сам файл действительно прост, но вот «создать skill, который будет точно срабатывать» — задача совсем не из простых. И те, кто пишет его вручную, в 90% случаев спотыкаются об одно и то же: неправильно написанный description, из-за чего этот skill никогда не вызывается.
Мой первый написанный вручную skill провалился именно так. Тогда я хотел создать skill, который будет «генерировать commit message в соответствии с командными стандартами». Каталог был создан, основной текст был предельно ясен, а в description я на скорую руку вписал «Commit message helper». И что в итоге? Каждый раз, когда я просил Claude сделать коммит, он полностью игнорировал мой skill и писал по своим общим привычкам. Я был уверен, что он неправильно установлен, долго возился с /doctor, перезагружал, переустанавливал — все впустую. Только потом я понял: проблема была не в том, «установлен он или нет», а в том, что «в описании не было тех слов, которые сказал бы пользователь». Такую ошибку при ручном написании вы просто не заметите, вам нужна вещь, которая заставит вас сделать это правильно.
skill-creator — это именно та самая вещь.
Прочитав эту статью, вы узнаете:
- Почему писать
SKILL.mdвручную кажется проще, но на деле легче всего ошибиться, и какие именно вещиskill-creatorпомогает вам сделать правильно - Полный процесс создания skill с помощью
skill-creator: создание основы → руководство по написаниюname/description/ основного текста → организацияscriptsиreferences→ упаковка - Самый ценный раздел всей статьи: как написать
description, чтобы он точно срабатывал (включая ключевые слова сценариев срабатывания, а также необходимость быть немного «проактивным») - В каком каталоге должны находиться личные skills и skills проекта, и кто сможет их использовать
- Практическое задание, которое можно выполнить по шагам: создание минимального skill с помощью
skill-creatorи личная проверка того, что он действительно срабатывает
01 Вопреки интуиции: написать SKILL.md вручную не сложно, сложно заставить его работать
Сначала свяжем это с базой из предыдущей статьи. В 27 статье вы уже узнали: один skill — это один каталог, в основе которого лежит файл SKILL.md, сверху — фрагмент YAML с name и description, а ниже — основной текст для Claude. Оригинальный текст из официальной документации:
Каждому skill требуется файл
SKILL.md, содержащий две части: YAML frontmatter (между маркерами---), который сообщает Claude, когда использовать этот skill, и markdown-контент, содержащий инструкции, которым должен следовать Claude при вызове этого skill.
Выглядит очень просто, не так ли? Создать папку, написать файл, и готово. Поэтому первая реакция новичков: можно просто написать вручную, зачем нужны инструменты.
В этом и заключается неочевидный момент: само по себе ручное написание действительно не сложно, сложно то, что написанный вручную skill «не работает» — вы думаете, что он автоматически появится, когда должен, а в итоге он продолжает спать в углу.
Аналогия: «Мастер создания инструмента», заполняющий форму. Вы ведь видели таких мастеров при установке новых программ — они не заставляют вас вслепую заполнять пустой файл конфигурации, а спрашивают вас страница за страницей: «Как называется этот инструмент», «В каких случаях его следует использовать», «Как выглядит ввод, какой формат вывода требуется». Вы отвечаете на несколько вопросов, а он за кулисами правильно расставляет для вас структуру каталогов, основу и расположение каждого поля. skill-creator — это такой мастер в мире skills: вы отвечаете ему на несколько вопросов, и он делает за вас те вещи, о которых вы даже не задумываетесь при ручном написании.
Конкретно, какие ошибки ручного написания он помогает предотвратить? Посмотрите на эту сравнительную таблицу — это самое важное, что нужно запомнить в этом разделе:
| Уязвимый этап | ❌ Частый результат при ручном написании | ✅ Как skill-creator помогает сделать правильно |
|---|---|---|
description | Написано что-то вроде «Commit helper», нет слов-триггеров, никогда не срабатывает | Помогает вам четко написать «что делает + когда использовать», включая ключевые слова, которые сказал бы пользователь |
| Структура каталога | Скрипты и справочные документы свалены в SKILL.md, файл длинный и запутанный | Помогает разделить их на scripts/ и references/, оставляя основной текст кратким |
| Проверка срабатывания | После написания неясно, сработает он или нет, все на уровне мистики | Дает вам тестовые сценарии, чтобы прогнать их и посмотреть, действительно ли он вызывается |
| Улучшение | Не срабатывает — и остается только смотреть, непонятно, что исправлять | Есть специальный этап оптимизации описания, чтобы настроить частоту срабатывания |
Заметили? Все ошибки при ручном написании связаны с теми вещами, которые «вы не видите и поэтому не контролируете». Ценность skill-creator не в том, что он помогает вам печатать (в печати он не сильно быстрее), а в том, что он заставляет вас безошибочно выполнить эти невидимые задачи одну за другой.
💡 Вкратце: Написать
SKILL.mdвручную не сложно, сложно заставить его срабатывать тогда, когда нужно;skill-creatorработает как мастер создания инструментов, заполняющий форму, и берет на себя заботу оdescription, каталоге, проверке и улучшении — тех вещах, которые не видны при ручном написании.
02 Что такое skill-creator и как его вызвать
Сначала вывод: сам skill-creator — это skill, и его специализация — «создание других skills». Звучит как скороговорка, но логика безупречна — раз skill нужен для расширения возможностей Claude, то и сама повторяющаяся задача «создания skill» заслуживает того, чтобы стать отдельным skill.
Он не входит в стандартный набор Claude Code (в отличие от связанных skills, таких как /code-review, /debug и др.), его нужно устанавливать отдельно — поместить каталог skill в ~/.claude/skills/ (глобально для пользователя) или в .claude/skills/ проекта (действует только для этого проекта), об этом механизме уже говорилось в 27 статье. В официальном магазине плагинов (claude-plugins-official) набор инструментов для «создания плагинов» называется plugin-dev, а skill-creator — это независимо выпущенный skill. Способ установки — напрямую клонировать или скачать каталог в путь для skills:
# Поместить каталог skill-creator в каталог skills пользователя
cp -r skill-creator ~/.claude/skills/Ожидание: После размещения в списке /skills должен появиться skill-creator с описанием «Create new skills, modify and improve existing skills...».
После установки есть два способа вызвать его, они точно такие же, как «использование skill», описанное в 27 статье:
Способ 1: Прямой вызов по имени (явная команда).
/skill-creatorСпособ 2: Объяснить своими словами, что вы хотите сделать (автоматическое срабатывание). Это более частый способ — поскольку description у skill-creator написан очень «полно», если вы скажете «Я хочу создать skill, чтобы...», он это поймет:
Я хочу создать skill, который каждый раз будет помогать мне обобщать изменения в git в виде стандартизированного commit messageНезависимо от способа, дальше он не просто выдаст вам файл вслепую, а начнет задавать вам вопросы, как мастер. В официальной инструкции к skill-creator первый шаг называется «Capture Intent (Захват намерений)», он спросит вас о следующем:
- Что этот skill должен позволить делать Claude?
- Когда он должен срабатывать? (Какие фразы будет использовать пользователь / В каких сценариях)
- Каков ожидаемый формат вывода?
- Нужно ли создать тестовые сценарии, чтобы убедиться, что он работает нормально?
Обратите внимание на 2-й вопрос — он специально спросит вас еще раз, «когда он должен срабатывать». В этом его самое большое отличие от ручного написания: при ручном написании никто не заставляет вас отвечать на этот вопрос, вы просто накидываете какое-то описание и идете дальше; skill-creator считает это приоритетной задачей, потому что знает, если не ответить на этот вопрос правильно, созданный skill будет бесполезен.
Аналогия: Организатор свадеб, который сначала расспрашивает вас досконально. Надежный организатор не станет сразу предлагать варианты, сначала он спросит «Какой бюджет», «Сколько людей приглашаете», «Хотите китайский стиль или на природе», «Есть ли какие-то табу». Только разобравшись в этом, предложенный вариант будет соответствовать вашим требованиям, а не просто шаблонным решением. «Capture Intent» в skill-creator — это тот самый процесс «выяснения требований» — сначала понять, что вам нужно, а потом уже браться за создание skill.
💡 Вкратце:
skill-creator— это «skill для создания skills», устанавливается из официального магазина плагинов (может потребоваться VPN); его можно вызвать через/skill-creatorили объяснив задачу простыми словами, и первое, что он сделает при появлении — это начнет задавать вам вопросы в ответ, особенно подробно расспрашивая, «в каких случаях должен срабатывать этот skill».
03 Полный процесс, который он проходит за вас
skill-creator не просто помогает вам сгенерировать один файл и умывает руки, он сопровождает вас на протяжении всей сборочной линии создания skill. Разобрав его процесс на части, вы поймете, что именно он помогает вам сделать на каждом шаге.
Официальный skill-creator описывает весь процесс как цикл, я переведу это на простой язык:
- Понять, что нужно сделать: Сначала обсудить с вами, что будет делать этот skill и примерно как (это и есть «Capture Intent» из предыдущего раздела).
- Написать черновик: На основе ваших ответов заполнить
name,descriptionи основной текст, сгенерировавSKILL.md. - Создать тестовые сценарии: Написать 2-3 «фразы, которые мог бы сказать реальный пользователь» в качестве тестовых prompt-ов и спросить вас «Похожи ли эти тесты на правду, нужно ли их добавить».
- Прогнать и оценить: Запустить эти prompt-ы в реальности, чтобы вы посмотрели, хорош ли результат — оценивая как «правильность вывода», так и «сработал ли он, когда должен был».
- Исправить по отзывам: Вернуться и исправить skill на основе вашей оценки и результатов тестов, и прогнать еще раз после исправлений, пока вы не будете удовлетворены.
- (Необязательно) Оптимизировать описание: Есть специальный этап для оптимизации
description, чтобы повысить точность срабатывания. - Упаковка: В конце весь каталог skill упаковывается в файл
.skillдля удобного распространения или установки.
Видите, в чем хитрость этой сборочной линии? При ручном написании вы делаете только шаг 2 (пишете файл), а шаги 3-7 полностью пропускаете — поэтому сработает ли ваш skill, зависит только от удачи, а если не сработает, вы не знаете, как его исправить. Ценность skill-creator в том, что он делает шаги после 2-го обязательными, особенно этот цикл «запуск тестов для проверки срабатывания» и «исправление по отзывам».
Здесь стоит упомянуть правильную структуру каталога, которую он вам помогает создать. В официальной документации в разделе «Добавление вспомогательных файлов» приведен такой пример каталога:
my-skill/
├── SKILL.md # Основные инструкции (обязательно)
├── reference.md # Подробная справочная документация, загружается по необходимости
├── examples.md # Примеры вывода, загружаются по необходимости
└── scripts/
└── helper.py # Скрипт, который может выполнить ClaudeКлючевое понимание: SKILL.md должен быть коротким, все тяжелое нужно выносить наружу. В официальной документации это сказано предельно ясно:
Сохраняйте объем
SKILL.mdменее 500 строк. Перенесите подробные справочные материалы в отдельные файлы.
Зачем нужно так разделять? Потому что как только skill срабатывает, содержимое SKILL.md целиком попадает в контекст и остается там на весь сеанс — каждая строка — это повторяющиеся затраты на токены. А скрипты в scripts/ «выполняются, но не загружаются», документы в references/ «читаются только при необходимости». Самая частая ошибка при ручном написании — это вставить API-документацию на триста строк прямо в SKILL.md, что и съедает контекст, и создает беспорядок. skill-creator поможет вам правильно разложить все по полочкам — в основном тексте оставить только «что делать и где искать», тяжелые данные перенести в references/, а исполняемые задачи — в scripts/.
Аналогия: Оглавление и приложения в книге. Вы же не станете сваливать все содержание на страницу оглавления, оглавление только говорит «в какой главе о чем рассказывается и на какой странице», а подробное содержание находится в основном тексте и приложениях. SKILL.md — это и есть та самая страница оглавления — она говорит Claude «какие материалы есть и когда какой из них читать», а сами материалы лежат в references/ и scripts/.
💡 Вкратце:
skill-creatorсопровождает вас по всей конвейерной ленте: «понять задачу → написать черновик → прогнать тесты для проверки срабатывания → исправить по отзывам → оптимизировать описание → упаковать»; при ручном написании часто выполняется только второй шаг, а он восполняет остальные, а также помогает вам разнести тяжелые материалы вreferences/иscripts/, сохраняяSKILL.mdкомпактным.
04 Самый ценный раздел всей статьи: как написать description, чтобы он срабатывал
Если из этой статьи вы запомните только одну вещь, запомните это: description — это «главный рубильник», который определяет, сработает skill или нет.
Почему именно он? Потому что в каждом диалоге Claude видит не весь текст вашего skill целиком — сначала он видит лишь список «имя skill + description», и на основе этого description решает, «стоит ли в этот раз вызывать этот skill». Правильно ли написан description напрямую определяет, вспомнят о нем или нет. В официальном руководстве по устранению неполадок в разделе «Skill не срабатывает» первый же пункт посвящен этому:
Проверьте, содержит ли описание ключевые слова, которые пользователь сказал бы естественным образом.
Причина провала моего skill для коммитов в самом начале была именно в этом. Было написано «Commit message helper» — в этой фразе нет ни одного «слова, которое сказал бы пользователь». В повседневной речи я говорю «помоги мне закоммитить», «напиши коммит», «сгенерируй сообщение коммита», но в описании не было ни одного из этих слов, и Claude, естественно, не мог сопоставить их. Позже я попросил skill-creator изменить описание на следующее, и стоило мне сказать «помоги мне закоммитить», как он тут же его подхватил.
Сравните эти два варианта написания, разница очевидна:
| ❌ Частые бесполезные описания при ручном написании | ✅ Хорошие описания, созданные с помощью skill-creator |
|---|---|
Commit message helper | Обобщает изменения в git в виде стандартизированного commit message, соответствующего командным нормам. Используется, когда пользователь говорит "помоги мне закоммитить", "напиши коммит", "сгенерируй сообщение коммита" или просит вас просмотреть изменения и подготовиться к коммиту. |
| Сказано только «что это» | Говорится и «что делает», и «когда использовать, как пользователь это скажет» |
| Нет слов-триггеров, никогда не срабатывает | Содержит реальные слова-триггеры, появляется вовремя |
Можно свести это к формуле: хороший description = что делает + когда использовать (включая те самые слова, которые пользователь скажет в оригинале). «Что делает» дает Claude понять, для чего нужен этот инструмент, а «когда использовать» — это и есть настоящий крючок для срабатывания, причем эту часть нужно писать простым языком, которым бы выразился пользователь, а не терминологией из вашей головы.
Еще один неочевидный момент, которому можно научиться у skill-creator: описание должно быть немного «проактивным», даже слегка «настойчивым». Потому что в настоящее время у Claude есть тенденция, называемая «undertrigger (срабатывает реже, чем должен)» — он часто ленится вызывать skill, даже когда тот явно мог бы помочь. Во внутренних инструкциях skill-creator специально сказано бороться с этим:
В настоящее время у Claude есть тенденция неохотно активировать skills — не использовать skill тогда, когда он мог бы пригодиться. Чтобы противостоять этому, пожалуйста, сделайте описание skill немного более «проактивным».
Что значит «проактивным»? Вот пример того, как это должно звучать: вместо сухой фразы «создает дашборд для отображения внутренних данных», лучше написать «……Всякий раз, когда пользователь упоминает дашборд, визуализацию данных, внутренние метрики или хочет отобразить любые данные компании, даже если он прямо не просит "дашборд", должен использоваться этот skill». Явно пропишите сценарии «даже если пользователь не сказал прямо, все равно нужно появиться» — этот трюк может значительно повысить вероятность его вызова.
Аналогия: Написание текста для вывески магазина. Если на вывеске написано только «У Чжана», прохожие не знают, что вы продаете, и не зайдут; если написать «Лапша с говядиной у Чжана · Добавка лапши бесплатно · Есть острая и не острая», и включить все слова, которые клиенты могут искать, людей зайдет сразу больше. description — это вывеска вашего skill — на вывеске должны быть слова, которые будут крутиться на языке у покупателей, и она должна активно зазывать.
💡 Вкратце:
description— это главный рубильник срабатывания, формула такая: «что делает + когда использовать (включая оригинальные ключевые слова, которые скажет пользователь)», и писать нужно немного проактивно, вписывая сценарии «появиться, даже если не сказано прямо» — если эта фраза написана хорошо, skill будет вызываться; если криво — даже самый красивый основной текст будет бесполезен.
05 В каком каталоге сохранять: личные skills vs skills проекта
Skill создан, где его сохранить? Место сохранения напрямую определяет, кто сможет им пользоваться. Об этом вас спросит skill-creator, но вы должны сами понимать, что к чему.
Из официальной таблицы расположений выделим два самых частых варианта для новичков:
| Место | Путь | Кто может использовать |
|---|---|---|
| Личное | ~/.claude/skills/<skill-name>/SKILL.md | Все проекты на вашем компьютере |
| Проект | .claude/skills/<skill-name>/SKILL.md | Только текущий проект |
Как выбрать? Критерий всего один: Этот skill — ваша «личная привычка» или «правило этого проекта»?
- То, что вы хотите использовать везде — например, «писать коммиты в моем любимом стиле», «переводить выделенный текст на китайский» — поместите в личный каталог (
~/.claude/skills/), один раз настроили, и работает во всех проектах. - То, что жестко привязано к конкретному проекту — например, «генерировать интерфейсы по стандартам API этого репозитория», «запускать процесс развертывания, специфичный для этого проекта» — поместите в каталог проекта (
.claude/skills/), причем закоммитьте в Git, чтобы каждый член команды при клонировании автоматически получал этот skill.
Аналогия: Набор инструментов, который вы носите с собой, vs инструментальная в мастерской. Тот привычный швейцарский нож вы носите в кармане, куда бы ни пошли (личный skill); но какое-то крупное оборудование для конкретной стройки закрыто в инструментальной на этой стройке, на другой стройке оно не пригодится и его не унести (skill проекта). Критерий — «инструмент следует за человеком или за местом».
Простой способ запомнить: общие привычки отправляются в ~/.claude/skills/, а специфичные для проекта — в их собственные .claude/skills/ и коммитятся в Git. Такие вещи, как skill для перевода или коммита, постоянно живут в личном каталоге и следуют за вами по всем проектам; а те skills в командных проектах, которые «только для этого проекта», все отправляются в репозиторий — таким образом, когда новичок клонирует репозиторий, skills уже на месте, и не нужно устно передавать "не забудь установить те несколько skills".
Есть еще одно преимущество, на которое указывает официальная документация: skills проекта будут искаться от вашего начального каталога вверх к родительским каталогам, поэтому, если вы запустите Claude в подкаталоге, skills проекта, определенные в корневом каталоге, все равно будут найдены. Различные подпакеты в monorepo также могут иметь свои собственные skills, не мешая друг другу.
💡 Вкратце: Личные skills кладите в
~/.claude/skills/, они следуют за вами по всем проектам; skills проекта кладите в.claude/skills/и коммитьте в Git, они действуют только в этом проекте и делятся с командой; критерий — одной фразой: инструмент следует за человеком или за проектом.
06 Практика: создаем минимальный skill с помощью skill-creator и проверяем его срабатывание
Теория без практики мертва. Ниже мы вместе с вами создадим реальный минимальный skill с помощью skill-creator, и самое важное — своими руками проверим, что он действительно срабатывает — это как раз тот шаг, который чаще всего пропускают и на котором чаще всего ошибаются те, кто пишет вручную. Никакие сложные проекты нам не понадобятся.
Целевой skill очень мал: заставить Claude обобщить незакоммиченные изменения в текущем git-репозитории в несколько пунктов.
Шаг первый: убедитесь, что skill-creator на месте
После запуска Claude Code введите:
/skillsОжидание: В списке должен быть skill-creator. Если его нет, вернитесь к разделу 02, скопируйте каталог skill-creator в путь для skills и установите (не забудьте включить VPN, если нужно).
Шаг второй: объясните ему задачу простыми словами
В поле ввода скажите, что вам нужно (заодно укажите, «когда срабатывать», чтобы он не переспрашивал):
Помоги мне создать skill с помощью skill-creator.
Функция: обобщить незакоммиченные изменения в текущем git-репозитории в 2-3 пункта.
Сценарии срабатывания: когда я спрашиваю «что я изменил», «обобщи мои изменения», «какие вещи я затронул в этот раз».
Имя пусть будет summarize-changes.Ожидание: Вызовется skill-creator и начнет уточнять ваши намерения — может спросить о формате вывода, нужны ли тестовые сценарии. Просто отвечайте на его вопросы, главное — следите, чтобы в сгенерированный им description попали такие слова-триггеры, как «что я изменил», «обобщи изменения» (это самое важное из раздела 04).
Шаг третий: позвольте ему сохранить файл в личный каталог
Подтвердите, что он должен сохранить skill в ~/.claude/skills/summarize-changes/ (личный каталог, доступен для всех проектов). Сгенерированный им SKILL.md будет выглядеть примерно так — обратите внимание на frontmatter:
---
name: summarize-changes
description: Обобщает незакоммиченные изменения в текущем git-репозитории в несколько пунктов. Используется, когда пользователь спрашивает «что я изменил», «обобщи мои изменения», «какие вещи я затронул в этот раз» или хочет быстро понять текущее состояние рабочего дерева.
---
## Текущие изменения
!`git diff HEAD`
## Ваша задача
Обобщите вышеуказанные изменения в 2-3 ясных пункта. Если diff пуст, просто скажите «В настоящее время нет незакоммиченных изменений».Строка
!`git diff HEAD`— это официальный синтаксис «динамического внедрения контекста»: Claude Code сначала выполнит эту команду, заменит эту строку реальным diff-ом, а затем покажет содержимое skill Claude. Так что он получит фактические изменения вашего рабочего дерева, а не будет угадывать из воздуха. Об этом синтаксисе упоминалось в 27 статье, и здесь он как раз пригодился.
Шаг четвертый: сделайте какие-нибудь изменения, чтобы skill было что обобщать
Найдите любой git-проект (если нет, сделайте пустой git init) и измените любой файл. Например:
cd ~/some-git-project
echo "// test change" >> README.mdОжидание: git status должен показать, что README.md изменен и не закоммичен.
Шаг пятый (самый важный): проверьте, действительно ли он «срабатывает»
Этот шаг делится на две проверки, официальная документация четко указывает эти два пути:
Проверка А — автоматическое срабатывание: Спросите простыми словами в Claude Code (обратите внимание, не называйте имя skill, используйте естественную фразу, посмотрите, вспомнит ли он сам):
что я изменил?Ожидание: Если description написан правильно, Claude автоматически вызовет summarize-changes и выдаст несколько пунктов с изменениями (например, «В конец README.md добавлена строка комментария»). Если он смог подхватить его сам = срабатывание успешно, ваш description прошел проверку.
Проверка Б — прямой вызов: На случай, если автоматически он не сработает, вызовите его жестко по имени:
/summarize-changesОжидание: В этот раз он точно отработает и также выдаст пункты с изменениями.
Как определить успех или неудачу:
| Симптом | Описание | Что делать |
|---|---|---|
| И А, и Б выдают пункты | Идеальное срабатывание | Задача выполнена |
| А не срабатывает, Б работает | Не хватает ключевых слов в description, с основным текстом все в порядке | Попросите skill-creator оптимизировать описание, добавьте слова-триггеры |
| Ни А, ни Б не выдают пункты | Файл создан неправильно / проблема в основном тексте | Проверьте пути и основной текст SKILL.md |
Особое внимание обратите на среднюю строку — если А не срабатывает, а Б работает, это как раз и доказывает главный тезис этой статьи: с самим skill проблем нет, проблема в том, что он «не работает автоматически», а это почти всегда вина description. Это та самая яма, в которую тысячу раз наступали любители писать вручную, так и не поняв, в чем дело. В этот момент достаточно попросить skill-creator пройти этап «оптимизации описания», и все можно исправить.
Пройдя эти пять шагов, вы лично проверили всю цепочку: «создание основы → правильное написание description → сохранение в нужный каталог → создание изменений → проверка автоматического срабатывания / прямого вызова». В будущем создание любого skill по сути будет заключаться в изменении содержимого в рамках этого процесса.
💡 Вкратце: На практике следите за двумя вещами — содержит ли сгенерированный
descriptionреальные слова-триггеры, и сработает ли он автоматически, если спросить простыми словами; если автоматически не срабатывает, но/имяработает, это винаdescription, попроситеskill-creatorоптимизировать описание и добавить ключевые слова.
07 Бонус: упаковка в .skill для раздачи другим
Если skill создан и проверен, и вы хотите отправить его коллегам или команде, skill-creator также может помочь вам упаковать его в файл .skill — получателю достаточно одного файла для установки, и вам не придется учить его вручную создавать каталоги.
За кулисами работает скрипт упаковки, вам не нужно запоминать команду, просто попросите skill-creator упаковать его для вас:
Помоги мне упаковать этот skill в файл .skillОжидание: Он запустит скрипт упаковки, сожмет весь каталог summarize-changes/ (включая SKILL.md и все scripts/, references/) в один файл summarize-changes.skill и сообщит вам путь к файлу.
Смысл этого шага в распространении: предыдущая, 27-я статья учила вас «устанавливать чужие skills», а skill, созданный вами в этой статье, после упаковки как раз и будет тем самым, что нужно будет установить другим — круг замкнулся. Внутри команд передача skills обычно так и происходит: кто-то создал хороший, запаковал и кинул в чат, другие скачали и установили, это гораздо надежнее, чем на словах объяснять «создай-ка вот такой каталог по моему примеру».
💡 Вкратце: Созданный skill попросите
skill-creatorупаковать в файл.skill, для распространения достаточно одного файла; это отлично стыкуется с 27-й статьей об «установке чужих skills» — то, что создаете вы, устанавливают другие.
08 Резюме
В этой статье мы прошли путь от «почему не стоит писать просто вручную» до «лично создадим skill, который будет срабатывать» — суть в одной фразе: сложность создания skill не в написании файла, а в том, чтобы заставить его срабатывать, и skill-creator специализируется именно на этом.
Давайте сведем все ключевые моменты воедино:
| Что вам нужно сделать | Что использовать | Ключевой момент |
|---|---|---|
| Установить инструмент для создания skill | Клонировать / скопировать каталог в путь для skills | cp -r skill-creator ~/.claude/skills/ (независимый skill, не встроенный в маркет) |
| Вызвать его, чтобы начать создание | /skill-creator или сказать требования простыми словами | Он спросит вас «что делает, когда срабатывает» в ответ |
| Заставить skill работать | Хорошо написать description | Что делает + когда использовать (включая оригинальные слова пользователя), быть немного проактивным |
| Выбрать место сохранения | Личный каталог vs каталог проекта | То, что следует за человеком, кладите в ~/.claude/, то, что за проектом — в .claude/ и коммитьте в Git |
| Подтвердить успех | Автоматическое срабатывание + прямой вызов /имя | Автоматически не срабатывает = вина description |
| Раздать другим | Упаковать в .skill | Для установки нужен только один файл, стыкуется с 27-й статьей |
Теперь вы должны уметь: понимать, почему ручное написание SKILL.md легко приводит к проблемам со срабатыванием, проходить весь процесс «создание основы → правильное написание description → проверка срабатывания → упаковка» с помощью skill-creator, лично написать description, который будет «срабатывать», поместить skill в правильный каталог и проверить, что он действительно вызывается. Этот набор навыков «правильно создать, заставить работать» — это ваш переход от «использования чужих skills» к «созданию собственной цепочки инструментов».
Тот провальный skill для коммитов из начала статьи позже был пересоздан с помощью skill-creator, и всего-то было изменено одно предложение в description, после чего он больше никогда не подводил. В этом и заключается главная ценность этого инструмента — он не заставляет вас больше печатать, он помогает вам избежать той невидимой ямы.
💡 Вкратце: Сложность создания skill в его срабатывании,
skill-creatorвосполняет такие вещи, как «правильное написание description, запуск тестов, исправление по отзывам», которые легко пропустить при ручном написании — ключ к умению создавать skills заключается в том, чтобы научиться ясно описывать условия срабатывания, а не просто понятно описывать функционал.
Следующая статья 29 «Agent teams: команды интеллектуальных агентов» (экспериментально, может меняться) — до сих пор ваш Claude Code «воевал в одиночку»: один диалог, один помощник, вы с ним один на один. Но с некоторыми задачами один человек справляется слишком медленно — можно ли, как при создании проектной группы, заставить несколько интеллектуальных агентов работать вместе: один отвечает за архитектуру, другой пишет код, третий запускает тесты? Следующая статья поможет вам перейти от «одиночного боя» к «командной работе». Подумайте: если бы у вас под рукой было три Claude, работающих на вас одновременно, какие три вещи вы поручили бы им сделать в первую очередь?