Скилы для ИИ — это файлы SKILL.md с инструкциями, которые агент подключает сам, когда задача совпадает с описанием: в шапке файла — имя и описание навыка, в теле — порядок действий. Работают в Claude Code, Codex CLI, Cursor и других средах открытого стандарта Agent Skills. Ниже — восемь готовых скилов, от коротких до больших: скопируйте в папку агента и пользуйтесь. Пишут и «скилы», и «скиллы», суть одна: вместо того чтобы в пятый раз вставлять в чат один и тот же чек-лист из заметок, вы кладёте его в файл — дальше агент достаёт его сам.
Формат придумали в Anthropic для Claude, в конце 2025-го открыли как общий стандарт (спецификация — agentskills.io). По подсчётам Bosch Research и Карнеги — Меллона, к февралю 2026-го в открытых каталогах вроде skills.sh лежало больше 40 тысяч скилов — почти сплошь английских и под чужие проекты. Поэтому здесь не обзор, а восемь файлов под рабочие задачи — и разбор, зачем в каждом какой блок.
Скил и промпт: в чём разница
Промпт вы каждый раз ищете в заметках, вставляете и подгоняете — а у коллеги своя, чуть другая версия. Скил лежит в папке проекта, уезжает в git, и правка одного файла меняет поведение агента у всей команды. Промпт — то, что вы говорите модели. Скил — то, что она умеет сама.
Агент не держит все скилы в голове: постоянно загружены только имена и описания, а тело файла он открывает, взявшись за подходящую задачу. В документации это зовётся progressive disclosure — «постепенное раскрытие». Отсюда два следствия: чек-лист на три экрана ничего не стоит, пока лежит без дела, а описание — самая ответственная строка: по нему агент решает, доставать ли навык.
Скил при этом — не системный промпт: тот задаёт агенту характер и рамки на всю сессию, про это — отдельная статья о промптах для ИИ-агентов. Здесь — навыки-файлы под конкретные задачи.
Как устроен SKILL.md
Сверху, между двумя строками ---, — YAML-шапка с полями name и description; ниже — обычный markdown с инструкциями. Четыре правила сберегут вам вечер отладки:
- Имя папки — это команда: скил из
.claude/skills/vychitka/вызывается как/vychitka. Называйте папку латиницей, без пробелов. - Описание — это триггер. Агент сопоставляет запрос с текстом
description: пишите туда глаголы задачи («вычитывает текст; применять, когда просят проверить»), а не «полезный помощник по текстам». - Тело — короче, чем хочется. Документация Claude Code советует держать файл в пределах 500 строк; объёмные справочники — в соседние файлы папки со ссылкой из SKILL.md.
- Полей шапки в стандарте шесть: name, description, license, compatibility, metadata, allowed-tools; остальное — расширения конкретных сред.
Плейсхолдеры в квадратных скобках — вида [ТОН: спокойный, на «вы»] — работают и без замены: внутри стоит значение по умолчанию.
Вычитка текста перед публикацией
Текст дописан, глаз замылен, до публикации полчаса. Файл прогоняет текст по редакционному чек-листу и не даёт агенту «улучшить» смысл.
--- name: vychitka description: Вычитывает текст перед публикацией по редакционному чек-листу: факты, канцелярит, повторы, ссылки. Применять, когда просят проверить, вычитать или подготовить текст к выходу. --- Проверь текст по шагам, в этом порядке. 1. Цифры и факты. Каждое число без источника пометь [ПРОВЕРИТЬ], сам ничего не исправляй. Имена, названия компаний и версии вынеси в список «сверить перед выходом». 2. Канцелярит. Найди и предложи живую замену: «в рамках», «на сегодняшний день», «посредством», «вышеуказанный», «имеет место». 3. Повторы. Слова, которые встречаются чаще [ПОРОГ: 4] раз на тысячу знаков, выпиши с номерами абзацев. 4. Длинноты. Предложения длиннее [ЛИМИТ: 25] слов предложи разбить — покажи как. 5. Ссылки. Все URL собери в один список для ручной проверки кликом. Формат ответа: сначала список правок по номерам абзацев, затем исправленный текст целиком. Смысл, порядок аргументов и авторские примеры не менять. Текст короче 300 знаков не вычитывай — просто укажи опечатки.
Пометки вместо правок у цифр — решение намеренное: модель, которой велели «исправить» непроверяемое число, охотно заменит его правдоподобным выдуманным; пометка [ПРОВЕРИТЬ] оставляет решение вам. Подводный камень — прямая речь: фильтр не отличает авторский канцелярит от цитаты и предложит переписать слова спикера. Много цитат — допишите шестым пунктом «прямую речь не трогать».
Changelog, который читают
Через месяц никто не помнит, почему в версии 1.4 отвалилась выгрузка и кто её чинил. Changelog это лечит — если его вести. Скил снимает главное трение: записи дописывает агент, формат не расползается.
--- name: changelog description: Ведёт CHANGELOG.md проекта: добавляет записи об изменениях в принятом формате. Применять после мержа фичи или фикса и перед релизом, когда просят обновить чейнджлог. --- Файл: [ПУТЬ: CHANGELOG.md в корне проекта]. 1. Прочитай файл и определи формат последних записей: заголовки версий, группировку, язык. Новые пиши так же, старые не переформатируй. 2. Источник изменений: слова пользователя, а если их нет — дифф или последние коммиты. 3. Каждую запись формулируй с точки зрения пользователя продукта: что стало можно или что перестало ломаться. Плохо: «рефакторинг OrderService». Хорошо: «заказ больше не задваивается при двойном клике по кнопке». 4. Группы: Добавлено / Исправлено / Изменено / Удалено. Пустые не выводи. 5. Записи без релиза складывай в раздел [РАЗДЕЛ: «Не выпущено»] в начале файла. Номер новой версии не придумывай — его называет пользователь. Не редактируй ничего, кроме этого файла.
Рабочая лошадка — третий пункт: без него агент честно напишет «рефакторинг OrderService», и через месяц эта строка никому ничего не скажет. Первый пункт — от противоположной беды: без него агент приводит весь файл «к правильному виду», и одна запись превращается в дифф на четыреста строк.
Коммиты по конвенции команды
Сообщения коммитов — вечный спор команды и вечный бардак в истории. Скил закрывает обе беды: формат зашит в файл, а не в память сеньора.
--- name: commit-msg description: Составляет сообщение коммита по конвенции команды из текущих изменений. Применять, когда просят закоммитить или написать сообщение коммита. --- 1. Посмотри, что в индексе. Если индекс пуст — покажи изменённые файлы и спроси, что включать. Сам файлы в индекс не добавляй. 2. Формат заголовка: [ШАБЛОН: тип(область): суть, например fix(auth): токен не обновлялся после смены пароля]. Типы: feat, fix, docs, refactor, test, chore. 3. Заголовок до [ЛИМИТ: 72] знаков, без точки в конце, язык — [ЯЗЫК: русский]. 4. Изменения из двух несвязанных задач разбей на два коммита и распиши, какие файлы в какой. 5. Тело добавляй, только когда «почему» не видно из диффа. Номер задачи бери из имени ветки, если он там есть: [ТРЕКЕР: PROJ-123]. Покажи сообщение и остановись. Команду git commit выполняй только после явного «коммить».
Ключевая строка — последняя: без явного «коммить» команда не выполняется. Решать, когда случится коммит, должны вы, а не модель, которой показалось, что код готов. В Claude Code есть приём жёстче: поле disable-model-invocation: true — навык запускается только руками. Но поле нестандартное — строгие среды могут отклонить файл. Сам код скил не смотрит — для прогона перед пушем есть промпт код-ревью для Claude.
Проверка таблицы перед отчётом
Сумма в «Итого» не бьётся со строками, отчёт ждут к обеду, а где расползлось — неизвестно. Скил превращает агента в занудного ревизора: находит и показывает, но не трогает.
--- name: check-table description: Проверяет таблицу перед отчётом: суммы, пропуски, дубли, форматы, выбросы. Применять, когда просят проверить таблицу, выгрузку или данные для отчёта. --- Прогони таблицу по пяти проверкам. Ответ — список «проверка, результат, номера строк». 1. Итоги. Пересчитай суммы по числовым столбцам и сверь со строкой «Итого». Расхождения — с номерами строк. Если можешь выполнять код — считай кодом, не в уме. 2. Пропуски. Пустые ячейки в обязательных столбцах: [СТОЛБЦЫ: те, что заполнены в остальных строках]. 3. Дубли. Полностью одинаковые строки и повторы в ключевом столбце [КЛЮЧ: первый столбец]. 4. Форматы. Даты в разных форматах в одном столбце, числа то с точкой, то с запятой, лишние пробелы по краям ячеек. 5. Выбросы. Значения, отличающиеся от медианы столбца в [ПОРОГ: 10] и более раз, подай как вопросы, а не как ошибки. В файле ничего не меняй: только список находок. Исправления — отдельным запросом после решения пользователя.
Запрет на исправления — не перестраховка: агент, которому разрешили «поправить» таблицу, может тихо перезаписать исходник — и что лежало в данных изначально, уже не выяснить. Выбросы подаются «как вопросы» тоже не зря: аномалии бывают честными, декабрьская выручка и правда в десять раз выше июльской. Арифметика на сотнях строк надёжна, только когда агент считает кодом, прикидки «в уме» плывут. Итоговую цифру перед отправкой руководителю пересчитайте сами.
Ответы поддержки по стайлгайду
Клиент пишет «всё сломалось!!» в пятницу в 18:40. Ответить нужно спокойно, по делу, не пообещав лишнего — в этом порядке скил и работает.
--- name: support-reply description: Пишет ответ клиенту в поддержку по стайлгайду команды. Применять, когда пользователь вставляет обращение клиента и просит подготовить ответ. --- Тон: [ТОН: спокойный, на «вы», без смайликов и без «приносим извинения за доставленные неудобства»]. 1. Первая строка — ответ по сути или следующий шаг клиента. Никаких «спасибо за обращение» в начале. 2. Проблема на нашей стороне — признавай прямо: «да, это ошибка, чиним». Без формулировки «у некоторых пользователей наблюдается». 3. Данные от клиента запрашивай одним списком, а не по вопросу за письмо. 4. Сроки называй только те, что явно дал пользователь: [СРОКИ: сроков не обещать]. «В ближайшее время» — под запретом. 5. Возвраты, компенсации и доработки не обещай. Ответ: «передали команде, о решении сообщим» — и пометь письмо для проверки старшим. Перед выдачей проверь: после прочтения клиент понимает, что будет дальше и что делать ему? Нет — перепиши.
Пятый пункт — граница полномочий: модель без ограничений щедра и легко пообещает клиенту возврат, компенсацию и фичу к понедельнику. Список «не обещать» и маршрут «передали команде» закрывают дыру. Второй приём — самопроверка в последней строке: вопрос «понимает ли клиент, что дальше?» отлавливает вежливые пустые ответы дешевле, чем десять правил тона.
Протокол созвона: решения, задачи, сроки
Час созвона позади, а в памяти у всех одно: Дима обещал «посмотреть на неделе». Скил превращает транскрипт или черновые заметки в протокол, с которым можно работать.
--- name: meeting-notes description: Собирает из транскрипта или заметок созвона протокол: решения, задачи с ответственными и сроками, открытые вопросы. Применять, когда вставляют запись встречи. --- Собери протокол из трёх блоков. 1. Решения. Только то, о чём договорились явно. «Наверное, стоит» и «надо подумать» — не решения, им место в третьем блоке. 2. Задачи. Таблицей: задача — ответственный — срок. Ответственным пиши только того, кто назван в тексте. Задаче без срока ставь пометку [МЕТКА: «срок не назван»], дату не выдумывай. 3. Открытые вопросы. Всё, что обсуждали и не закрыли, с именем поднявшего. Правила: - Нет в тексте — нет в протоколе. Ничего не додумывай «по логике встречи». - Имена и цифры переноси дословно; сомнительные места помечай знаком (?). - Объём — не больше [ЛИМИТ: 2500 знаков]. Приветствия и болтовню выбрасывай.
Стержень — правило «нет в тексте — нет в протоколе»: оно бьёт по привычке модели дописывать сроки и ответственных, потому что «обычно так бывает». Пометка «срок не назван» неприятно выпирает из таблицы — и это работает: на следующем созвоне срок наконец называют. Знак (?) — страховка от расшифровщика: транскрипты путают «Наташу» с «Надей» и «пятнадцать» с «пятьдесят», а уверенная ошибка в протоколе опаснее вопроса.
Скилы двух весов
Шесть файлов выше — лёгкий вес: один экран, одна процедура. Но в командах ходят и SKILL.md на несколько тысяч знаков, которые ведут задачу от начала до конца: этапы, критерии «сделано», краевые случаи, запреты. Это не раздутый чек-лист, а другой жанр. Короткий скил напоминает агенту порядок действий; большой заменяет инструктаж, который вы провели бы новому сотруднику.
Ориентир для выбора такой. Задача-процедура на пять минут, где агенту нужно лишь направление, — короткий. Задача с этапами, где провал одного портит следующие — редактура, подготовка данных, — и которую вы гоняете из недели в неделю, — большой. Расплата известна: после срабатывания большой скил висит в контексте целиком, и каждый ход сессии дороже. Мерило одно на оба веса: каждый блок обязан менять результат — строку «на всякий случай» из большого скила вычёркивают первой.
Ниже два больших — старшие братья короткой вычитки и проверки таблиц. Сравните пары: видно, как процедура превращается в регламент.
Редактура по редполитике целиком
Короткий /vychitka ловит опечатки и мёртвые слова. Этот файл делает работу редактора: диагноз, структура, факты, тон, финальный проход — со стоп-краном на каждом этапе, чтобы агент не чинил запятые раньше композиции.
--- name: redaktura description: Редактирует текст по редполитике от диагноза до чистовика: структура, факты, тон, финальный проход. Применять, когда просят отредактировать черновик, довести материал до публикации или привести текст к стандарту редакции. --- Ты редактор. Доведи черновик до публикации так, чтобы автор узнавал свой текст: правишь слабости, не переписываешь голос. Настройки: - Редполитика: [РЕДПОЛИТИКА: обращение на «вы», без канцелярита, цифры только с источником, заголовки без кликбейта] - Читатель: [ЧИТАТЕЛЬ: занятой специалист, открывает с телефона, решает за первый экран, читать ли дальше] - Объём чистовика: [ОБЪЁМ: как у оригинала, отклонение до десятой части] Иди по этапам. К следующему переходи, только когда выполнен критерий текущего: правки поздних этапов бессмысленны в абзацах, которые не переживут ранние. Этап 1. Диагноз — до любых правок. Три строки: жанр (новость, инструкция, кейс, колонка); обещание читателю — что он унесёт; главная слабость черновика. Сделано: из диагноза понятно, что чинить в первую очередь и почему. Этап 2. Структура. - Ответ на вопрос читателя — в первый абзац. Обоснование в настройках: решение «читать ли» принимается на первом экране. - Один блок — один тезис. Два тезиса — режь блок надвое; ноль — помечай на удаление, сам не удаляй. - Порядок блоков — по важности для читателя, а не в той очерёдности, в которой писалось. - Заголовок и подзаголовки сверь с телом: обещанное в них обязано быть в тексте, цифры — совпадать. - Концовка — вывод, который следует из текста, или следующий шаг. Вывод «из воздуха» вычёркивай. Сделано: по подзаголовкам и первым предложениям абзацев восстанавливается весь смысл. Этап 3. Факты. - Числа без источника помечай [ПРОВЕРИТЬ] и не исправляй: выдуманное «правдоподобное» число опаснее отсутствующего. - Имена, должности, названия компаний, версии продуктов — отдельным списком «сверить». - «Сегодня», «недавно», «в этом году» заменяй абсолютной датой или помечай: текст читают и спустя год. - Термины, которых читатель из настроек не знает, расшифровывай при первом появлении или заменяй бытовым словом. - Обещания результата без подтверждения в самом тексте смягчай до проверяемого. Сделано: ни одного числа и имени без источника или пометки. Этап 4. Тон. - Мёртвые слова заменяй живыми; маркеры: «немаловажный», «целый ряд», «находится в стадии», «по итогу». - Фразы длиннее [ЛИМИТ: 25] слов дели на две. - Три ровных абзаца подряд — монотонность: разбей короткой фразой или списком. - Страдательный залог при живом деятеле переводи в действительный. Сделано: читается вслух без запинок и совпадает с редполитикой из настроек. Этап 5. Финальный проход. Перечитай чистовик целиком: опечатки, одно слово в трёх соседних предложениях, связки между абзацами — правки этапов 2–4 любят их рвать. Сделано: ни одно предложение не выглядит вставленным. Краевые случаи: - Цитаты и прямая речь неприкосновенны, включая корявые: человек сказал так, как сказал. - Авторская колонка — пропусти этап 4: выровняешь тон — убьёшь колонку. - Черновик короче 1000 знаков — только этапы 3 и 5, структуру там чинить негде. - Автор нарушает редполитику похоже что нарочно (стилизация, ирония) — спроси, не правь молча. Этот скил не проверяет факты по внешним источникам (только помечает), не пишет за автора недостающие разделы и не сокращает текст вдвое — это отдельные задачи с отдельными запросами. Ответ строй так: диагноз → правки по этапам с номерами абзацев → чистовик → списки [ПРОВЕРИТЬ] и «сверить».
Главная механика тут — очерёдность с критериями. Агент, получивший все требования одним списком, начинает с лёгкого: полирует формулировки в абзаце, который на этапе структуры будет помечен на удаление. Стоп-краны заставляют идти от несущих стен к обоям. Вторая осознанная жёсткость — неприкосновенность цитат и колонок: правка, которая улучшила бы новость, стирает авторский голос. И трезвое ожидание: скил снимает предсказуемые слабости черновика, а не превращает средний текст в блестящий. На заметку в две тысячи знаков его тянуть незачем — там хватит короткого собрата.
Подготовка данных к отчёту
Короткий /check-table отвечает на вопрос «можно ли этим цифрам верить». Большой готовит выгрузку целиком: нормализует копию, прогоняет целостность, отдельным этапом ищет ловушки, из-за которых отчёты врут, и собирает свод с оговорками.
--- name: data-report description: Готовит сырую выгрузку к отчёту: опись, нормализация копии, проверки целостности, типовые ловушки данных, свод с оговорками. Применять, когда дают таблицу, CSV или выгрузку и просят подготовить цифры к отчёту. --- Преврати сырую выгрузку в данные, по которым можно считать отчёт, и покажи всё, что способно сместить цифры. Исходный файл не меняется ни на одном шаге: работа идёт в копии, каждая замена — в журнал. Настройки: - Ключевой столбец (по нему уникальность): [КЛЮЧ: первый столбец] - Отчётный период: [ПЕРИОД: прошлый календарный месяц] - Формат дат в копии: [ФОРМАТ ДАТ: ГГГГ-ММ-ДД] - Порог выброса: [ПОРОГ: десятикратное отклонение от медианы] Все подсчёты — кодом, если среда позволяет его выполнять. Оценка на глаз на сотнях строк выглядит уверенно и врёт. Этап 1. Опись. Строки, столбцы, тип каждого столбца (число, дата, текст, смешанный), доля пустых, охват дат. Смешанный тип — первый тревожный звонок: столбец из 900 чисел и трёх кусков текста почти всегда несёт ошибку выгрузки. Сделано: опись позволяет судить о данных до единой правки. Этап 2. Нормализация — только в копии. - Даты приводи к формату из настроек. Строки, где день не больше 12, помечай отдельно: «03.04» и «04.03» без контекста неразличимы. - У чисел убирай разделители тысяч и приводи десятичный знак к одному виду: «1 000,50» и «1,000.50» — одно число в двух традициях, таблица прочтёт их по-разному. - В тексте счищай пробелы по краям и выравнивай регистр категорий: «Москва» и «Москва » при группировке — два разных города. - Объединённые ячейки разъединяй, значение дублируй в каждую строку: сводные на них считают мимо. Сделано: каждый столбец копии одного типа, журнал замен приложен. Этап 3. Целостность. - Дубли по ключу из настроек — построчным списком. - Пропуски в столбцах, участвующих в отчёте. - Итоги: суммы посчитай заново и сравни с готовой строкой «Итого», разницу покажи построчно. - Диапазоны: минус там, где его не бывает (количество, возраст), даты вне периода и из будущего. - Значения за порогом из настроек — отдельным списком вопросов пользователю, без вердикта «ошибка». Сделано: у каждой проверки вердикт «чисто» либо список строк. Вердикта «не смотрел» не существует. Этап 4. Ловушки — ищи отдельно, даже когда этап 3 чист. - Ведущие нули: телефоны, коды, артикулы вида «007» превращаются в числа и теряют нули. Такие столбцы держи текстом. - Даты, записанные текстом: сортировка даёт «01.02, 01.03, 02.01» вместо хронологии. - «Прочее» толще пятой части строк — категоризация сломана, любой вывод по ней подведёт. Помечай. - Единицы вперемешку: столбец, где часть сумм в рублях, часть в тысячах, — самая дорогая ошибка отчётов; ищи по разрыву на порядки внутри одной категории. Сделано: по каждой ловушке явный вердикт. Этап 5. Свод. - Итоги по числовым столбцам за отчётный период. - Оговорки одним списком: всё, что помечено на этапах 1–4 и способно исказить отчёт. - Нет данных прошлого периода — динамику не оценивай и слов «выросло, упало» не пиши. Сделано: свод вставляется в отчёт, оговорки — в письмо к нему. Краевые случаи: - Больше [ЛИМИТ СТРОК: 50 000] строк — только кодом и частями; среда кода не выполняет — откажись и объясни, что оценка на глаз обманет. - Листов несколько — уточни, какой отчётный; склеивать молча нельзя. - Прислали два «одинаковых» файла — сначала сверь число строк и итоги, потом выбирай. Этот скил не решает, какие строки лишние (помечает — решает человек), не формулирует выводы для руководства и не отменяет пересчёт итоговой цифры перед отправкой. Ответ строй так: опись → журнал нормализации → вердикты проверок → ловушки → свод с оговорками.
Всё здесь держится на двух запретах. Первый — исходник не трогать: нормализация только в копии и с журналом замен, иначе после «подготовки» никто не докажет, какими цифры были изначально. Второй — вердикта «не смотрел» не существует: без него агент молча пропускает проверку, которую не осилил, и дыра всплывает уже на совещании. Ловушки вынесены отдельным этапом не для солидности: ведущие нули и единицы вперемешку — формально «чистые» данные, суммы сходятся, пропусков нет, а отчёт всё равно врёт. И обратите внимание на пункт про отказ: файл на десятки тысяч строк без выполнения кода — гадание, и отказ здесь полезнее уверенного ответа.
Куда положить скил
Скил — это папка с SKILL.md внутри; создайте её там, куда смотрит агент:
- Личные — для всех ваших проектов:
~/.claude/skills/имя-скила/SKILL.mdв Claude Code. - Проектные — для команды:
.claude/skills/имя-скила/SKILL.mdв корне репозитория — файл уедет в git к коллегам. - Другие среды смотрят в свои папки: Codex CLI — в
~/.codex/skills/, а Cursor читает и папки Claude с Codex, так что один файл закрывает все три инструмента.
Проверка: спросите агента словами из description («проверь таблицу перед отчётом») или вызовите навык напрямую — /check-table. Новую папку skills агент увидит после перезапуска.
Где скилы буксуют
Четыре границы, о которых каталоги скилов молчат:
- Скил — не автоматизация. Он не запускается по расписанию: это инструкция, которую вызывает человек или агент в живой сессии. Нужны расписание, вебхуки и база — это уже сборка агента, начните с промпта проектирования ИИ-агента в n8n.
- Разовая задача файла не окупает. Скрипт падает раз в квартал — быстрее вставить готовый промпт поиска бага по логам или разбора трейсбека Python. Скил заводят на то, что повторяется хотя бы раз в неделю.
- Сработавший навык остаётся в контексте. После срабатывания тело висит там до конца разговора — большие скилы выше платят эту цену сознательно. Режьте всё, что не меняет результат.
- Новых способностей скил не даёт. Он лишь объясняет агенту, как пользоваться тем, что уже есть. Если агент не умеет открывать Excel, скил проверки таблиц не спасёт — сначала выгрузите таблицу в CSV.
FAQ
Чем скил лучше длинного промпта из заметок?
Промпт нужно найти, вставить и не забыть — и делаете это вы. Скил агент достаёт сам, когда задача совпала с описанием, а до того в контексте живут две строки шапки. А ещё скил лежит в git: правка одного файла обновляет навык у всей команды, а не у владельца заметок.
Сколько скилов можно подключить одновременно?
Жёсткого потолка документация не называет, но описания всех подключённых скилов агент держит в контексте постоянно. Двадцать навыков с короткими точными описаниями работают лучше, чем пять с размытыми: агенту проще выбрать нужный. Раз в месяц открывайте папку skills и удаляйте то, что ни разу не сработало.
Почему агент не подхватил мой скил?
Три причины закрывают почти все случаи: описание не совпадает со словами запроса (просите «глянуть пост», а в description — «вычитывает статьи»); файл лежит не там или папка названа кириллицей; папка skills создана после старта сессии — перезапустите агента. Быстрая проверка — вызвать скил напрямую через /имя-папки.
Можно ли писать SKILL.md по-русски?
Да. Латиницей нужно только имя папки — оно превращается в команду. Поле description и тело файла модели читают по-русски без потерь; все восемь скилов статьи так и написаны. Английский нужен в одном случае: скил командный, а в команде не все читают по-русски.
Как обновлять скил?
Просто правьте файл: Claude Code замечает изменения в текущей сессии, без перезапуска. Для командных скилов работает обычный процесс кода: правка, коммит, ревью — история остаётся в git. Дописывайте найденные грабли по горячим следам: скил, который не пополняют после ошибок, отстаёт от реальности.