Скил evolution — правила самообновления фреймворка
Как Datarim предлагает и применяет улучшения к собственному фреймворку — после каждого архива, по запросу и в явном режиме — при этом каждое изменение одобряется человеком и может быть независимо откатано.
Фреймворк, используемый в множестве задач, со временем накапливает трение: скил, описывающий паттерн, которым больше не пользуются; два скила с пересекающимися задачами; описание, точное полгода назад, но теперь расходящееся с реальным поведением кода. Скил evolution определяет правила, по которым Datarim исправляет себя.
Каждое изменение требует явного одобрения человека. Скил не применяет ничего предположительно.
Два пути к изменениям
Рост происходит в конце каждой завершённой задачи. Скил reflecting — вызываемый шагом 0.5 команды /dr-archive — анализирует только что написанную рефлексию, выявляет паттерны, полезные для будущих задач, и генерирует предложения по эволюции. Это могут быть обновления существующего скила, уточнённое описание агента, новый шаблон для повторяющегося паттерна или совершенно новый скил для непокрытой области. Каждое предложение содержит категорию, целевой файл, однопредложенческое описание изменения и свидетельство, его обосновывающее.
Обслуживание выполняется через /dr-optimize. Оптимизатор строит граф зависимостей всего фреймворка, находит неиспользуемые компоненты, слишком большие файлы, дублирующиеся скилы и битые перекрёстные ссылки, затем представляет структурированный отчёт с предложениями по удалению, объединению или разделению компонентов.
Пороги состояния здоровья
Скил определяет конкретные пороги, при превышении которых выдаётся предложение запустить оптимизацию. Более 20 скилов, более 18 агентов, более 25 команд, любой скил длиннее 500 строк, любое описание длиннее 155 символов или доля файлов-сирот выше 15% — любое из этих условий вызывает предложение запустить /dr-optimize. Пороги существуют потому, что каждый новый файл и каждое более длинное описание увеличивают токенный бюджет, который каждая команда конвейера оплачивает при вызове.
Один конкретный пример
Рефлексия задачи фиксирует, что подход с тестированием на основе свойств обнаружил граничные случаи, которые пропустили юнит-тесты. Скил reflecting генерирует предложение роста: категория skill-update, цель skills/testing/SKILL.md, изменение: добавить раздел о тестировании на основе свойств с конкретным примером. Оператор одобряет. Файл скила обновляется на месте. Изменение фиксируется в datarim/history/evolution-log.md с идентификатором задачи, категорией, целью и однострочным обоснованием.
Правило против раздувания и откат
Перед любым предложением создать новый файл скил требует проверки, способен ли существующий компонент поглотить это содержимое. Каждый новый файл увеличивает накладные расходы для агентов, которые его загружают. Предложение нового скила допустимо только если содержимое явно относится к отдельной области, не покрытой ни одним существующим скилом.
Каждое одобренное изменение — дискретная правка конкретного файла. Журнал эволюции содержит достаточно информации для ручной отмены любого изменения. При удалении компонентов оптимизатор архивирует удалённые файлы в documentation/archive/optimized/ перед удалением. С 2026-04-22 скилы, команды, агенты и шаблоны в $HOME/.claude/ являются символическими ссылками на git-репозиторий Datarim — откат изменения — стандартный git revert.
Смотрите также: пост о команде /dr-archive о том, как предложения появляются в конце каждой задачи, и пост что такое Datarim для общей картины фреймворка.