Двадцать лет мы вычищали из проектов недокументированные скрипты, знания в голове у одного человека и магические настройки, работающие ровно на одном ноутбуке. Придумали CI, инфраструктуру как код, code review. А потом завели папку ~/.claude и собрали там тот же бардак заново, только теперь он называется «мои skills». Если skill, правило, агент или hook влияет на то, как Claude пишет и проверяет код проекта, он часть проекта. Его место в репозитории: под git, на виду у команды, чтобы его можно было прочитать, обсудить и при случае найти через blame нужный коммит.

Двое клонируют один репозиторий. У одного в домашней директории приватный мешок супер-skills, у другого нет. Формально код общий, фактически они собирают его по разным правилам. Один процесс лежит в git, второй — у человека под столом, и узнаете вы о нём в день, когда он уйдёт в отпуск.

Это не старая проблема в новой обёртке, она хуже Что мы обычно слыши? "А у меня локально все прекрасно работает", - говорят адепты Claude. Раньше локальный скрипт лежал файлом, кривой symlink ловился, разница в версии Node падала в CI. Вопрос был только в том, когда на это наступят. А вот Skill не оставляет следов. В diff приходит обычный код: правильные отступы, ваши naming conventions, аккуратные тесты. Всё, что этот код сформировало, жило в prompt, а prompt никуда не закоммитился. Reviewer смотрит на artifact и не видит функцию, которая его произвела. Отговорки при этом прежние: «да камон - это экспериментальный skill». Но!.. место для экспериментов придумали до нас, и оно называется got branch. А когда кто-то говорит «переиспользуемый», то заводит versioned skill bank на компанию и пусть репозиторий объявляет, что он оттуда берёт.

Skill это dependency, а не заметка Hooks выполняют команды. У агента есть tool permissions. Часть skills приезжает через npx skills add owner/repo и обновляется одной строкой, без diff. Это зависимость с правом писать в ваш working tree: без lockfile, без review, поставленная одним человеком для себя. В package.json такое не прошло бы. Здесь проходит, потому что «ну это же markdown». Ещё есть prompt injection: skill, который читает issue tracker или чужой PR, это канал, по которому посторонний текст попадает прямо в инструкции агенту.

Цена, которую платят другие Новый человек ставит всё по README, и у него получается хуже, чем у соседа. Review с третьего раза, скорость вдвое ниже. Он решит, что дело в нём. Дело в полугоде настройки в чужом ~/.claude, о которой сосед сам давно забыл. Раньше разрыв закрывался вопросом «у тебя какой конфиг?». Сейчас человек не знает, что спросить. Через год кто-то спросит, почему здесь retry с exponential backoff, а в соседнем сервисе голый цикл. Blame даст автора, автор не вспомнит: решение принял skill, с тех пор дважды переписанный. Раньше ответ лежал в ADR или хотя бы в чьей-то голове, теперь его нет нигде.

Где граница Когда работа над проектом упирается в чьи-то персональные skills, я вижу не продвинутого пользователя, а форк процесса разработки без review, без истории, без опознавательных знаков. Хотите по-взрослому?! Тогда делайте окружение декларируемым: Dockerfile в репозитории, сборка в CI, машина разработчика перестнет быть источником истины. И с агентами придётся так же. Пока инструментов нет, остаётся дисциплина и культура разработки: .claude/ под git, skills на review вместе с кодом. Всё! Конечно кто-то скажет: "Это неудобно и медленно". Но давайте вспомним, что Dockerfile много лет назад тоже выглядел лишней работой.

#разработка #ai #нейросети #it #devops #codereview #инженерныекультуры #команда