Claude skills 2026: как упаковать командные стандарты и 3 проверки

Что такое Skills в Claude Code и зачем они нужны?

Agent Skills - это инструкции и возможности для агента. ai skills в Claude Code задают конкретные процедуры: изменить код по правилам, проверить сборку, найти локальную ошибку.

Раз в неделю разбираю одну рабочую связку claude skills. Подпишись в Telegram, чтобы не пропустить: https://t.me/vibeceh

Минимальная структура выглядит так:

.claude/
└── skills/
    └── project-standard/
        └── SKILL.md

Внутри папки могут лежать:

• SKILL.md с основной процедурой;
• скрипты для проверки;
• справочные файлы;
• примеры правильного и неправильного результата;
• локальные правила, о которых модель сама не догадается.

Anthropic описывает Skill коротко:

«В самом простом виде Skill - это каталог, который содержит файл SKILL.md.»

• Barry Zhang, Keith Lazuka и Mahesh Murag, Anthropic

Сначала Claude получает name и description установленных Skills. По этому описанию он решает, подходит ли пакет к текущей задаче. Если подходит, читает полный SKILL.md. Дополнительные файлы открывает только при необходимости.

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

Skill задаёт Claude контекст и процесс, но не гарантирует строгого соблюдения стандарта. Соблюдение стандарта всё равно надо подтверждать тестом, build, screenshot, hook или скриптом.

Когда Skill лучше CLAUDE.md и обычной команды?

В CLAUDE.md держи то, что относится к проекту всегда. Подробнее о том, как не раздуть файл и когда его пересобрать, я писал в отдельном разборе:

• как запускать проект;
• где лежат основные каталоги;
• какие зависимости уже используются;
• какие общие правила нельзя нарушать.

Skill нужен для цепочки действий. Например: перед изменением кода прочитать связанные файлы, использовать существующий API-клиент, после правки запустить проверку.

Обычная команда нужна, когда ты хочешь вызвать действие сам. Старый путь .claude/commands/ продолжает работать, но Skills стали рекомендуемым способом упаковки повторяемых процессов.

Критерий отбора простой:

Я бы не превращал в Skill каждое пожелание вроде «пиши аккуратный код». Такое правило слишком общее. Оно добавляет текст, но не даёт агенту локального решения.

Хороший кандидат выглядит иначе:

• действие повторяется;
• порядок шагов важен;
• в проекте есть свои ловушки;
• результат можно проверить;
• процедуру приходится объяснять заново.

CLAUDE.md отвечает на вопрос «что здесь постоянно принято». Skill отвечает на вопрос «как выполнить конкретную повторяющуюся работу». Командой ты говоришь: «запусти это прямо сейчас».

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

Как собрать Skill для проекта?

1. Выбери повторяющиеся сценарии.

   Я записываю 2-3 задачи, которые реально повторяются в проекте. Например: изменить экран по существующему паттерну, проверить результат после правки, подготовить код к ревью. Пошаговую сборку первого навыка я разбирал в отдельной инструкции.

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

2. Создай папку Skill.

   Выполни действие из корня проекта.

   bash

   Скопировать

   mkdir -p .claude/skills/project-standard/examples
   touch .claude/skills/project-standard/SKILL.md
   touch .claude/skills/project-standard/gotchas.md
   touch .claude/skills/project-standard/check.sh

   Минимальный пакет должен содержать SKILL.md, gotchas.md, примеры и исполняемый check.sh.

3. Опиши основную процедуру.

   Открой SKILL.md и вставь минимальный frontmatter. Основной файл держи сфокусированным и не раздувай больше 5000 слов.

   yaml

   Скопировать

   ---
   name: project-standard
   description: Apply project conventions when adding or changing application code.
   ---
   
   # Project standard
   
   1. Read the relevant files before editing.
   2. Reuse existing patterns.
   3. Do not introduce a new dependency without asking.
   4. Run `./.claude/skills/project-standard/check.sh` after changes.
   
   ## Gotchas
   
   - Do not edit generated files directly.
   - Use the existing API client instead of calling fetch manually.
   - A successful HTTP 200 is not enough; check the response body.
   
   ## Additional resources
   
   - For common mistakes, read [gotchas.md](gotchas.md).
   - For examples, read the files in [examples/](examples/).

4. Добавь локальные ловушки.

   В gotchas.md запиши 3-5 мест, где агент уже ошибался или легко ошибётся. Не переписывай базовые знания модели: нужны правила именно этого проекта.

   markdown

   Скопировать

   # Local gotchas
   
   - Do not edit generated files directly.
   - Reuse the existing API client.
   - A successful HTTP 200 does not prove that the webhook was processed.
   - Read the current implementation before adding a new pattern.

5. Покажи два результата.

   Сохрани в examples/bad-example.md и examples/good-example.md короткие образцы. Для плохого примера покажи нарушение локального правила. В хорошем - тот же случай после правильной обработки.

   Такой пример помогает Claude отличить требуемый результат от просто похожего текста или кода.

6. Собери отдельную проверку.

   Сделай check.sh исполняемым. В него положи команды, которые дают однозначный результат.

   bash

   Скопировать

   #!/usr/bin/env bash
   set -euo pipefail
   
   npm test
   npm run lint
   git diff --check

   Запусти:

   bash

   Скопировать

   chmod +x .claude/skills/project-standard/check.sh
   ./.claude/skills/project-standard/check.sh

   Если проверка невозможна, результат нельзя считать готовым. Слова Claude «всё хорошо» не заменяют тест, build, screenshot или скрипт.

7. Попроси Claude собрать черновик.

   Я использую такой запрос для первого варианта - он сработает как skill builder для черновика:

   Собрать черновик SkillСкопировать промпт

   Проанализируй текущий проект и помоги собрать узкий Skill для повторяющейся задачи.
   
   Сначала предложи 2-3 сценария, которые подходят под один Skill.
   Затем выпиши локальные ловушки, примеры неправильного и правильного результата.
   Создай структуру .claude/skills/project-standard/:
   - SKILL.md
   - gotchas.md
   - examples/bad-example.md
   - examples/good-example.md
   - check.sh
   
   В SKILL.md оставь только основную процедуру и условия применения.
   Не добавляй дополнительные поля frontmatter без отдельного объяснения.
   После создания проверь, что check.sh запускается.

8. Проверь границы срабатывания.

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

   Я проверяю полезное срабатывание и отдельно отслеживаю ложное. Ложное срабатывание тоже расходует контекст и уводит агента в сторону.

9. Прочитай файл вручную.

   Я открываю SKILL.md, gotchas.md, примеры и check.sh. Убедись, что названия файлов совпадают, ссылки ведут в существующие места, а команда проверки запускается из корня проекта.

   На этом месте я останавливаюсь до публикации Skill. Наличие папки ещё не доказывает, что Claude увидит её и сможет прочитать файл.

Как подключить Skill из GitHub к проекту?

github skills ищи как исходный код пакета. Сначала проверь, что в репозитории есть папка Skill, SKILL.md, описание и связанные скрипты.

Для standalone-варианта структура внутри проекта должна прийти к такому виду:

.claude/
└── skills/
    └── project-standard/
        ├── SKILL.md
        ├── gotchas.md
        ├── examples/
        └── check.sh

Если пакет нужен только одному проекту, оставь его в репозитории проекта. Так правила будут лежать рядом с кодом и попадут в Git-историю.

Если один и тот же пакет нужен команде и нескольким проектам, используй plugin. Plugin позволяет версионировать и распространять пакет как единое расширение.

use skill проверяй из корня проекта. Сам факт, что файл лежит в .claude/skills/, не гарантирует обнаружение.

cd /path/to/project
claude
/имя-skill

Если Claude отвечает Unknown skill, проверь путь, текущую папку и наличие Skill в глобальном размещении. После этого перезапусти Claude Code и повтори вызов.

Не добавляй поля frontmatter наугад. Для первого подключения хватит name и description. Дополнительные поля добавляй по одному, каждый раз проверяя реальным вызовом.

Как проверить, что Skill сработал и результат готов?

Проверка состоит из трёх слоёв.

1. Отправь очевидный запрос по теме Skill.
2. Перефразируй тот же запрос.
3. Отправь нерелевантную задачу и проверь, что Skill не запускается.

Дальше вызови Skill явно:

/имя-skill

После вызова попроси Claude прочитать сам файл:

Прочитай установленный Skill и выведи его раздел «Проверка результата».

Это отделяет наличие метаданных от доступности файла. Бывает, что название и описание отображаются, а SKILL.md среда исполнения не отдаёт агенту. Результат проверяй отдельно от инструкции:

• тестом;
• скриптом;
• build;
• screenshot;
• hook;
• проверкой git diff --check.

Формулировка «проверь, всё ли хорошо» оставляет решение самой модели. Лучше дать команду с понятным кодом завершения:

./.claude/skills/project-standard/check.sh

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

Anthropic формулирует границу так:

Skill объясняет, что делать. Проверка показывает, получилось ли. Эти две части нельзя смешивать.

Что делать, если Skill не запускается или игнорируется?

Если получаешь Unknown skill, пройди короткую диагностику:

1. Запусти Claude Code из корня проекта.
2. Проверь папку .claude/skills/.
3. Проверь наличие SKILL.md.
4. Вызови /имя-skill.
5. Проверь глобальное размещение в ~/.claude/skills/.
6. Перезапусти Claude Code.

В issue Claude Code описан случай, когда проектный Skill не обнаруживался, а тот же файл в глобальной папке начинал работать:

Другая поломка выглядит коварнее. Название и описание Skill видны, но сам SKILL.md отсутствует в среде исполнения. Поэтому проверяй не только список доступных Skills, но и чтение файла.

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

Начни с такого frontmatter:

---
name: project-standard
description: Apply the project coding standard when changing application code.
---

Если валидатор ругается на allowed-tools, context, agent или hooks, не добавляй всё сразу. Оставь минимальный набор, проверь запуск, затем добавляй поля по одному.

После compaction старый Skill может выпасть из контекста. Разрешения allowed-tools тоже не считаются постоянными: инструкции Skill сохраняются отдельно, а разрешение на инструмент действует только на текущий ход.

Главная поломка не техническая. Claude может прочитать Skill и всё равно решить, что правило необязательно. Усиление словами MUST и ALWAYS не превращает текст в блокировку. Обязательные ограничения переноси в тесты, скрипты и hooks.

Сколько Skills можно держать включёнными без лишнего контекста?

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

В пользовательском замере три неиспользуемых Skill занимали 8,7 тысячи токенов за сессию. При расширении набора число описаний выросло с 35 до 157.

При 20-50 одновременно включённых Skills пересмотри набор и используй selective enablement. Оставляй только то, что нужно текущему проекту. Отдельно убирай Skills, которые месяцами не срабатывали.

Вопросы и ответы