Skill Dreaming — схема, в которой кодовый агент ведёт библиотеку навыков для конкретного репозитория и переписывает её после каждого нового pull request (PR, предложенного изменения кода). Из принятых PR и из неудачных попыток вытягиваются правила: когда навык применять, как делать, как проверить результат. Новые правила не просто складываются в кучу, а сверяются со старыми по семи операциям: добавить, обновить, сузить, расширить, отметить конфликт, заменить устаревшее, оставить как есть.
Боль знакомая каждому, кто ведёт файл инструкций для агента (CLAUDE.md, AGENTS.md, скилы). Репозиторий живёт, API меняется, договорённости сдвигаются. А старая инструкция остаётся и уводит агента к прежним приёмам, которые уже не работают. Агент честно следует устаревшему правилу и ломает то, что вчера было нормой. Обычный поиск по истории PR здесь не помогает: он достаёт старые примеры, но не отличает живое от протухшего.
Метод решает это так. После каждого PR автор навыков (та же LLM) пишет кандидатов в навыки по шаблону «условие → способ → проверка». Затем каждый кандидат сравнивается с уже существующими навыками и получает одну из семи меток. Устаревшие навыки не удаляются, а архивируются с привязкой к версии репозитория, и агент видит только активные. Сверху авторы показали прирост на бенчмарке задач из реальных репозиториев: с 79% до 88% решённых задач при той же модели.
Схема метода
ШАГ 1: Найти в истории PR, связанные с задачей → пометить: годится / можно починить / устарел / не относится / опасен
ШАГ 2: Собрать кандидатов: переиспользовать, починить или написать заново → прогнать тесты и проверки
ШАГ 3: Из успешных PR и из провалов написать навыки по шаблону «когда / как / как проверить» + запреты из ошибок
ШАГ 4: Сверить новые навыки со старыми → Add / Update / Specialize / Extend / Conflict / Supersede / Keep
ШАГ 5: Подать агенту ограниченное число подходящих активных навыков → он делает PR вместе с тестами, документацией и конфигом
ШАГ 6: Проверить результат, записать исход → он становится материалом для следующего круга
В статье это автоматический конвейер на коде (поиск по эмбеддингам, Docker, прогон тестов). Но сами шаги 3–5 повторяются вручную в обычном чате и в файле инструкций агента.
Пример применения
Сначала про границы. Метод сильнее всего там, где есть история изменений и автоматическая проверка: тесты, CI, ревью. Он слабее на проектах без тестов и на разовых задачах: навыкам не на чем «созревать». Поэтому берём живой проект с историей.
Задача: Небольшой интернет-магазин на Python/Django. Полгода назад команда подключила оплату через ЮKassa, потом добавила СБП, на прошлой неделе перевела все платежи на новый клиент SDK. В CLAUDE.md всё ещё написано, как «правильно» подключать платёжный провайдер по старой схеме. Агент в Claude Code регулярно делает новые интеграции по старой схеме, и тесты падают.
Промпт:
Ты — автор навыков для репозитория интернет-магазина (Django, платежи ЮKassa и СБП).
Ниже: (1) текущий навык «Подключение платёжного провайдера» из CLAUDE.md,
(2) diff и описание последнего принятого PR «Переход на новый клиент SDK ЮKassa»,
(3) комментарии ревью к этому PR и лог упавших тестов из первой попытки.
Сделай по шагам:
1. Из PR выпиши, что изменилось в соглашениях: что делать, чего больше не делать, что проверять.
2. Реши, что сделать с текущим навыком: Add / Update / Specialize / Extend / Conflict / Supersede / Keep. Обоснуй решением в одну-две фразы.
3. Если Supersede: перенеси старую версию в раздел «Архив» с пометкой, до какой версии SDK она действовала. Не удаляй.
4. Напиши обновлённый навык по шаблону: «Когда применять», «Как делать», «Как проверить», «Чего не делать» (из ошибок и правок ревью).
5. Отдельно перечисли обязательства, которые нужны вместе с кодом: тесты, документация, конфиг, changelog.
[текущий навык]
[diff и описание PR]
[комментарии ревью и лог тестов]
Результат: Модель выдаст разбор изменений в соглашениях, решение по каждому старому правилу с краткой причиной, обновлённый навык по четырём блокам и отдельный список «что ещё сделать кроме кода». Устаревшая схема уйдёт в архив с пометкой версии, а не пропадёт.
Почему это работает
Слабость модели. Агент не знает, что инструкция устарела. Для него всё, что написано в файле, одинаково «правда». Если дописывать новые правила в конец, файл распухает и начинает противоречить сам себе: два способа подключить провайдера, оба «правильные».
Сильная сторона. Модель хорошо сравнивает два текста и выделяет, что в них несовместимо. А ещё хорошо пишет по шаблону, если заданы блоки. Тест и ревью дают ей внешний сигнал: что реально сработало, а что нет.
Как метод это использует. Он заставляет каждое новое знание пройти сверку с существующим и получить явное решение. Плюс правила держатся на доказательствах: к навыку привязаны PR, из которых он вышел, и версия репозитория.
Рычаги управления: - Число подаваемых навыков (в статье — жёсткий потолок) → меньше для простых задач, меньше шума в контексте. - Блок «Чего не делать» → его строят из провалов и правок ревью; убери, если ошибок ещё не набралось. - Список операций → для небольшого файла хватит трёх: Add, Update, Supersede. - Архив вместо удаления → оставляй, если проект часто откатывает изменения; иначе файл можно чистить. - Шаблон «когда / как / как проверить» → добавь свои блоки, например «риски».
Шаблон промпта
Ты — автор и хранитель навыков репозитория {проект}.
Дано:
<текущие_навыки>{файл инструкций или список навыков}
<новый_PR>{описание и diff принятого изменения}
<ревью_и_проверки>{комментарии ревью, результаты тестов, упавшие попытки}
ШАГ 1. Оцени источник: PR годится / можно починить / устарел / не относится к делу / опасен.
Если не годится — остановись и объясни почему.
ШАГ 2. Выпиши кандидатов в навыки. Каждый строго по шаблону:
- Когда применять: {условие}
- Как делать: {шаги}
- Как проверить: {тест, команда, признак готовности}
- Чего не делать: {запреты из ошибок и правок ревью}
- Основание: {какие PR}, версия: {версия репозитория}
ШАГ 3. Сверь каждого кандидата с текущими навыками и выбери ровно одну операцию:
Add — такого навыка нет
Update — уточнить существующий новой информацией
Specialize — сузить условие применения
Extend — добавить совместимые шаги или обязательства
Conflict — правила несовместимы, нужно решение человека
Supersede — старое правило устарело: перенеси в «Архив» с версией, не удаляй
Keep — менять нечего
К каждому решению: одна фраза причины.
ШАГ 4. Выдай итоговый список активных навыков и отдельно «Архив».
Для Conflict сформулируй вопрос человеку и не выбирай сторону сам.
Отдельным блоком перечисли обязательства вместе с кодом: тесты, документация, конфиг, примеры, changelog.
Что подставлять: {проект} — название и стек; файл инструкций вставь целиком; PR — описание плюс изменения кода; ревью и проверки — всё, что показало ошибки. Для следующего PR запускай шаблон снова с обновлённым списком навыков.
🚀 Быстрый старт — вставь в чат:
Вот шаблон Skill Dreaming. Адаптируй под мой проект: [твой проект и стек].
Задавай вопросы, чтобы заполнить поля.
[вставить шаблон выше]
LLM спросит про текущий файл инструкций, последний принятый PR и результаты проверок — потому что метод опирается на сверку нового со старым и на сигналы тестов и ревью. Она возьмёт структуру операций и адаптирует под твой файл.
Ограничения
⚠️ Нужен код и инфраструктура: в статье это конвейер с поиском по эмбеддингам, разбором коммитов, Docker и автоматическим прогоном тестов. В чате воспроизводится лишь ядро — сверка и переписывание навыков.
⚠️ Опора на проверки: метод держится на тестах и CI. Без них нет сигнала, что PR «успешный», и навыки накапливают непроверенные догадки.
⚠️ Свежесть — на вашей совести: вручную придётся каждый раз приносить новый PR и результаты. Забыл обновить — навык снова устарел.
⚠️ Эффект измерен на узком наборе: задачи из нескольких репозиториев, и это один подход одной команды. Видна польза пошагового обновления, но нет оснований считать, что та же прибавка повторится в вашем проекте.
⚠️ Конфликты не решаются сами: правила могут оказаться несовместимыми, и выбирать придётся человеку.
Как исследовали
Исследователи собрали оценку на SWE-bench Pro (задачи из репозиториев Ansible, qutebrowser, Open Library) и SWE-bench Verified (12 репозиториев). Для каждой задачи брали исторический срез репозитория и использовали только те PR и навыки, что существовали до неё, чтобы будущее не «подсматривалось». Агентом служил mini-swe-agent на моделях семейства Claude (Opus-5 и Sonnet-4.6).
Сравнивали с классическим поиском по истории (BM25, плотные эмбеддинги, гибрид) и с пятью свежими методами обучения навыкам (Trace2Skill, Learning to Commit, SkillLens, CODESKILL, Socratic-SWE). Отдельные проверки отключали части метода: без навыков, только дописывание, только удачные примеры, без фильтра устаревших.
Главный результат: официальная доля решённых задач выросла с 79% до 88%. Дополнительно измеряли «покрытие обслуживания»: делает ли агент не только код, но и тесты, документацию, конфиг и changelog. Идея в том, что агент с навыками обслуживает репозиторий целиком, а не затыкает одну дыру.
Что важно для практики: выигрыш дают не сами примеры из истории, а управление их жизненным циклом — кто устарел, кто заменён, кто противоречит. Полные таблицы абляций в доступном тексте обрезаны, поэтому вклад каждой части отдельно оценить нельзя.
Адаптации и экстраполяции
🔧 Техника: добавить блок «Чего не делать» → агент перестаёт повторять прошлые ошибки
В каждый навык добавь раздел «Чего не делать» и заполняй его из комментариев ревью и упавших тестов. Формулируй как запрет с причиной: «Не используй старый клиент ЮKassa: он ломает возвраты».
🔧 Техника: ввести версию в навык → меньше путаницы при откатах
К каждому навыку добавь поле «Действует с версии … по версию …». Агент проверяет её перед применением.
Для файла инструкций, который ведёт одна команда, можно сократить цикл до еженедельной ревизии:
Вот мой CLAUDE.md и список PR за неделю. Для каждого правила в файле укажи: подтверждено / устарело / противоречит новым PR. Для устаревших предложи замену и перенеси старую версию в «Архив».
Ресурсы
Skill Dreaming: Evolving Repository Skills through Pull Request Streams. Авторы: Xinyuan Song, Ryan Turner, Hasibul Haque, Bowen Zhu, Jay Somasundaram, Liang Zhao (Causal Dynamics Lab, США). Опираются на SWE-bench Pro, SWE-bench Verified, mini-swe-agent, а также на работы Learning to Commit, Trace2Skill, SkillLens, CODESKILL, Socratic-SWE.