Навык - это способ превратить повторяемую процедуру в продукт. Технически это папка с обязательным описанием и опциональными каталогами для скриптов, справочных материалов и вспомогательных файлов. Cursor ищет их в нескольких стандартных местах, включая совместимые каталоги других агентных инструментов, а вложенный навык автоматически получает область действия своего подкаталога. Смысл механизма не в хранении текста, а в том, что процедура подгружается тогда, когда нужна, и не занимает места, пока не нужна.
Наивная альтернатива - объяснять один и тот же порядок действий заново в каждом разговоре. Это работает, но плохо масштабируется: формулировка каждый раз чуть другая, шаги теряются, а результат зависит от того, насколько подробно вы сегодня написали запрос. Хуже всего это заметно при передаче работы: то, что живёт в вашей привычке набирать запрос, не переезжает к коллеге вместе с репозиторием. Навык фиксирует порядок, и с этого момента процедура выполняется одинаково, а её изменения проходят через обычное ревью, как код.
Прогрессивная загрузка - главная инженерная идея здесь. В начальном контексте видно только имя и описание навыка; полное содержимое подтягивается при активации, а тяжёлые материалы - справочники, шаблоны, скрипты - только тогда, когда до них дошло дело. Поэтому основной файл держат коротким: условие запуска, предварительные требования, упорядоченные шаги, условия остановки и требуемые доказательства. Всё объёмное выносят в отдельные каталоги. Экономия здесь не декоративная: десяток навыков, каждый из которых грузится целиком, съедает контекст ещё до начала работы.
Полезно один раз увидеть каркас навыка целиком. Ниже - заголовок с именем, описанием и масками путей и тело из четырёх шагов, где последний шаг - явная остановка перед действием с внешними последствиями. Именно условие остановки отличает навык-инструкцию от навыка-автомата: процедура доводит работу до точки решения и передаёт её человеку. Обратите внимание и на требование доказательств в последнем пункте: без него отчёт превращается в утверждение, что всё хорошо, а проверить это утверждение нечем.
Описание в заголовке несёт больше веса, чем кажется. По нему модель решает, релевантен ли навык текущей задаче, поэтому оно должно называть момент применения, а не абстрактную способность. Формулировка проверить релиз-кандидат и собрать чек-лист работает; формулировка помогает с релизами - нет. Есть и обратный случай: если навык должен запускаться только человеком, автоматический подбор отключают явным полем. Так поступают с процедурами, у которых цена ложного срабатывания выше, чем польза от автоматического включения.
Границу между навыком и правилом полезно провести сразу, потому что путают их постоянно. Правило описывает инвариант, который должен соблюдаться всегда, пока вы работаете с этими файлами: оно короткое, не имеет шагов и не имеет конца. Навык описывает процедуру с началом, порядком и завершением: он включается по поводу и выключается, когда работа доведена до точки остановки. Требование возвращать структурированные ошибки - правило. Порядок подготовки релиза - навык. Записанное не в свой механизм требование либо висит в контексте без пользы, либо не включается тогда, когда нужно.
Отдельная тема - скрипты внутри навыка. Они удобны и одновременно расширяют поверхность риска: это исполняемый код, который поедет вместе с навыком к тем, кто его установит, и запустится с правами процесса. Поэтому скрипт документируют как компонент - вход, выход, коды возврата, поведение в негативных случаях - и ревьюят строже, чем текстовую инструкцию. Навык без скриптов остаётся хорошим выбором по умолчанию, и переходить к скрипту стоит тогда, когда шаг действительно детерминированный и его дешевле выполнить, чем описать.
Плохой навык узнаётся по поведению, а не по тексту. Он либо включается там, где не нужен, и мешает - обычно из-за слишком общего описания или слишком широких масок путей; либо не включается там, где нужен, и о нём вспоминают вручную. Третий признак хуже обоих: навык включается, но его шаги разошлись с реальностью, потому что команды проверки в проекте поменялись, а процедура нет. Отсюда простая гигиена: навык, который ссылается на команды проекта, обновляют в том же изменении, в котором эти команды меняются.
Инженерный вывод простой: навык - это runbook, а не энциклопедия. Хороший навык умещается на экран и отвечает на вопрос как это делается у нас, а не пересказывает документацию. Он проверяем: по нему видно, что должно произойти, где остановиться и какое доказательство приложить. Такой навык переживает смену состава команды, а длинный текст-инструкция - нет, потому что его перестают читать раньше, чем он устаревает.
Типичные провалы предсказуемы. Написать размытое описание и получить навык, который не включается тогда, когда нужен. Свалить в основной файл всё сразу и платить контекстом при каждой активации. Оформить навыком то, что является правилом. Добавить скрипт там, где хватило бы инструкции. И забыть условие остановки - тогда процедура доходит до необратимого действия сама.
---
name: release-check
description: Проверить релиз-кандидат и собрать подписанный чек-лист.
paths:
- "apps/web/**"
---
# Проверка релиза
1. Прочитай канонический runbook релиза.
2. Запусти существующие линт, проверку типов и сфокусированные тесты.
3. Остановись перед публикацией и изменением состояния прода.
4. Приложи доказательства и назови нерешённые блокеры.