Часть знаний о проекте - это не строчка-ограничение, а целая процедура: как отревьюить API, как подготовить release notes, как собрать план миграции. Такое слишком длинно для always-on правила и слишком специфично, чтобы каждый раз держать в голове и диктовать заново. Нужно место, где процедура живёт целиком, но не мешает, пока не понадобится. Между "всегда в контексте" и "каждый раз заново руками" должно быть что-то третье, и это третье - навык.
Наивных ходов два. Первый - записать процедуру одним большим always-on правилом, чтобы она была "всегда под рукой". Второй - вставлять её в промпт заново перед каждым применением. Оба кажутся надёжными: в первом ничего не забудется, во втором - всё перед глазами.
Ломаются оба на одном. Постоянная процедура жжёт токены на каждом turn, даже когда задача к ней не относится: десять шагов ревью API - мёртвый груз во время правки стилей. Вставленная руками процедура каждый раз чуть другая, дрейфует и обрастает ошибками копипаста. Знание есть, но подано в самой дорогой и самой хрупкой форме. Навык снимает обе беды разом: он записан один раз и целиком, но грузится только по требованию.
Skills решают это как знание по требованию. Project skill живёт в .devin/skills/<name>/SKILL.md, глобальный - в ~/.config/devin/skills/ (на Windows - в %APPDATA%\devin\skills). Пользователь вызывает навык как /name, а модель может выбрать его сама, если разрешён trigger model. В контекст навык попадает лишь когда релевантен, а не висит постоянно. Это ровно то различие, ради которого документация Devin советует предпочитать skills правилам: always-on правило платит контекстом всегда, а навык - только в тот момент, когда действительно вызван.
Устройство навыка объясняет, почему он безопаснее правила. Это папка с SKILL.md и, при нужде, вспомогательными файлами. Навык может ограничить allowed-tools (read, edit, grep, glob, exec), добавить собственные permissions с allow, deny и ask (они дополняют базовые права сессии, а не заменяют), выбрать другую model и даже запуститься как subagent со своим контекстным окном. Поля subagent и agent помечены как experimental - фиксируйте проверенную версию, если полагаетесь на это поведение. Глобальный навык виден во всех проектах, project-навык - только в своём и едет вместе с репозиторием, так что команда получает его вместе с кодом.
Что делает навык хорошим: один навык - один законченный результат. Отревьюить API, собрать план миграции, подготовить release notes - у каждого ясный вход и ясный выход. "Все стандарты компании" - плохой навык: он слишком широк, быстро устаревает и превращается в свалку, которую невозможно проверить. Узкая роль - это и точность, и предсказуемость.
Цена широты не абстрактна. Раздутый навык воспроизводит ту же болезнь, что и раздутое правило, только грузится по требованию: много неприменимого текста в момент вызова. Experimental-поля могут измениться между релизами и тихо сломать привычный запуск. А навык с широкими permissions - это шире поверхность доверия: чем больше он может, тем больше придётся проверять после него. Поэтому широту навыка стоит воспринимать не как удобство, а как долг: каждый лишний инструмент и каждое лишнее разрешение вы потом оплачиваете проверкой его результата.
Оправдан навык там, где есть повторяемая процедура с ясным результатом, которую вы вызываете осознанно. Узкий набор инструментов и явные permissions делают намерение навыка проверяемым: по frontmatter видно, что он читает, что меняет и чего не может в принципе. Это и есть практическая ценность узкой роли: не только предсказуемый результат, но и заранее известная граница того, что навык физически способен сделать с проектом.
Проверять навык нужно так же конкретно, как строили. Вызовите /name и убедитесь, что он загрузился и остался в границах своих allowed-tools. Сверьте, что результат - именно тот единственный выход, ради которого навык создан, а не что-то смежное. Если полагаетесь на experimental-поведение subagent, зафиксируйте версию, на которой оно работает, и перепроверяйте после обновлений.
Типичные провалы повторяют ошибки правил. Навык превращают в свалку знаний - и теряют и точность, и проверяемость. Полагаются на experimental-поля без фиксации версии - и удивляются, когда запуск меняется после обновления. Ревью-навыку "на всякий случай" дают право на запись - и он перестаёт быть независимым взглядом. Признак один: навык делает больше, чем обещает его имя. Держите один результат на навык, урезайте инструменты и доверяйте загрузке по требованию делать своё дело.