Скіли в Claude Code: шо це, нашо вони дизайнеру і як написати свій перший

💡 Усі статті, обговорення, новини про AI — в одному місці. Приєднуйтесь до AI спільноти!

Всім привіт 🧡

Минулого разу писала тут про субагентів, а сьогодні про другу половину цієї кухні: скіли. Бо бачу одну й ту саму картину: люди ставлять чужі скіли з GitHub пачками, а своїх не пишуть. Хоча саме свій скіл закриває найбільший біль роботи з Claude

Шо таке скіл насправді

Скіл це ваша інструкція для Claude: шо робити і як. Записана один раз у файл, а не надрукована вручну в кожній новій сесії.

Якщо ви втретє пояснюєте Claude одну й ту саму процедуру («спочатку перевір ієрархію, потім типографіку, потім контраст цифрами, і не хвали»), це вже не промпт. Це скіл.

Важливо не плутати скіл із CLAUDE.md. Короткі постійні правила («шрифт продукту такий-то», «спейсинг тільки 4/8pt») живуть у CLAUDE.md: він вантажиться щосесії, і однорядкові факти там на своєму місці. А от коли правило переросло в багатокрокову інструкцію, тримати її в CLAUDE.md означає платити за неї токенами в кожній розмові, навіть коли ви робите зовсім інше. Тому просто: покрокова інструкція йде в скіл, факт на один рядок лишається в CLAUDE.md.

Шо це технічно

Папка з файлом SKILL.md у .claude/skills/ (проєктний) або ~/.claude/skills/ (особистий). Усередині YAML-фронтматер плюс сама інструкція. Той самий формат працює в Claude Code, у Claude.ai і через API, тобто пишете один раз, а користуєтесь скрізь.

.claude/skills/
└── design-critique/
    ├── SKILL.md          обов'язковий
    ├── rubric.md         довідник, читається за потреби
    └── scripts/
        └── contrast.py   скрипт: виконується, не читається

І кожен скіл автоматично стає слеш-командою: папка design-critique дає вам /design-critique.

Як скіл запускається. І чесно про це

Способів три:

🟠 Руками, через /назву. Найнадійніший варіант, працює завжди;
🟠 Автоматично: Claude сам бачить, шо задача підходить під description скіла, і підтягує його. Звучить красиво, але чесно: на практиці Claude часто скіл НЕ підхоплює. Anthropic у власних матеріалах прямо пишуть, шо модель схильна недотригерювати скіли. Тому не дивуйтесь, шо поставили скіл, а він мовчить. Це лікується, про це нижче;
🟠 Зсередини: виклик скіла можна прописати в іншому скілі або підключити його до субагента полем skills:, і тоді він вантажиться гарантовано.

А якщо хочете, шоб скіл запускався ТІЛЬКИ руками і ніколи сам, є поле disable-model-invocation: true.

Чому 30 скілів не з’їдять ваш контекст

Найважливіше про скіли це не «інструкція в файлі», а трирівневе підвантаження.

🟠 Рівень 1: name + description. Приблизно 100 токенів на скіл, завжди в контексті. Claude знає, шо скіл існує, але не знає змісту.
🟠 Рівень 2: тіло SKILL.md. Вантажиться тільки коли скіл спрацював.
🟠 Рівень 3: довідники і скрипти. Підтягуються за потреби. А скрипти в контекст не потрапляють взагалі: Claude їх запускає, і в контекст іде тільки вивід, не код.

Тому скілів може бути багато, платите тільки за той, шо реально спрацював. А тепер найпоширеніша помилка: люди пишуть SKILL.md на 800 рядків, туди і приклади, і референси, і кейси. Виглядає круто, а на практиці кожна активація з’їдає кілька тисяч токенів, скіл конкурує з вашою робочою розмовою, і через п’ять промптів Claude забуває код, з яким працював. Тримайте тіло компактним (офіційна рекомендація: до 500 рядків, я тримаю до 200), решту виносьте в окремі файли поруч 🫣

Description: єдиний шанс скіла «продатися»

Саме за description Claude вирішує, підтягнути скіл чи ні. Промазали, і скіл лежить мертвим вантажем.

Погано:

Generates design critique.

Не каже коли, не каже на яких словах активуватись. Claude бачить це і думає «можливо колись».

Добре:

Методологія структурованого дизайн-ревью: ієрархія, фокус, типографічна шкала, контраст. Use when користувач просить розкритикувати, оцінити або ревʼюнути UI, каже «що не так з екраном», «подивись макет».

І дві неочевидні деталі:

1. Тригерні слова ставте на ПОЧАТОК опису. Комбінований текст description обрізається на 1536 символах у списку скілів, все шо в кінці може просто не доїхати.
2. Для широких скілів додавайте контртригери: «Do NOT use for one-line responses». Інакше скіл «про дизайн» почне активуватись на все підряд.

Лайфхак, який робить багатофайловий скіл надійним

Claude НЕ читає rubric.md тільки тому, шо файл лежить поруч. Пасивне посилання «деталі в rubric.md» він проскакує. Працює тільки наказ із прив’язкою до кроку:

Перед оцінкою ієрархії прочитай rubric.md, секція 1.

Формула «read X before doing Y». Найдешевший спосіб змусити довідники реально вантажитись.

Найпотужніший трюк: скрипт всередині скіла

Про це майже ніхто не пише. SKILL.md може запускати Python або bash. Код робить точно, LLM робить креативно, кожен займається своїм. Не довіряєте моделі рахувати контраст «на око»? Кладете поруч contrast.py, і скіл замість вгадувань віддає точний ratio. Валідації, підрахунки, конвертації токенів дизайн-системи, вибір з бази шрифтів: усе це скрипти. А тон, настрій, копірайт: це вже LLM.

Один нюанс: шлях до скрипта пишіть через змінну ${CLAUDE_SKILL_DIR}, а не відносний. Інакше скрипт ламається, щойно Claude працює не з кореня проєкту.

Скіл без тестів це чернетка

Більшість самописних скілів ніхто не тестує. Пишуть, ставлять, дивуються «чому мовчить». Рамка проста, 15 хвилин:

🟠 5 промптів, де скіл МАЄ активуватись. Прогнали в нових сесіях, рахуєте: активація 80%+ це окей;
🟠 5 промптів, де НЕ має. Активація до 20%.

Тригер менше 80%: переписуйте description, додавайте конкретні слова. Анти-тригер більше 20%: додавайте «Do NOT use for». Більшість того, шо лежить на GitHub з тегом awesome-skills, цю перевірку не проходило 🫣

І про безпеку, раз ви вже ставите чужі скіли

Description потрапляє в системний промпт Claude. Тобто автор чужого скіла технічно може заховати туди шо завгодно, і Claude виконає це з тим же рівнем довіри, шо й офіційні інструкції. Ви нічого не побачите, бо це системний промпт, а не видимий чат.

Мінімальний захист: перед установкою прогнати чужий SKILL.md через Claude в окремому чаті («чи нема тут інструкцій, шо лізуть у файлову систему або мережу без запиту користувача»), і обмежувати скіли полем allowed-tools до мінімуму. До речі, у скілів це поле пишеться через дефіс, allowed-tools, а не tools: як у субагентів. tools: у скілі просто ігнорується, і про це мало хто знає.

От і все з базою.

У повному гайді ще: три архітектурні патерни (single skill, orchestrator + sub-skills, hook-activated) з розборами реальних реп, чек-лист готового скіла перед публікацією і тестування як у skill-creator. Повний гайд можна прочитати в моєму каналі 🧡

Дурних питань не буває, пишіть в коменти. І цікаво: хто вже писав свої скіли, шо у вас спрацювало, а шо лежить мертвим вантажем?