Скил evolution — правила самообновления фреймворка
Как Datarim предлагает и применяет улучшения к собственному фреймворку после compliance, по запросу и в явном режиме — при этом каждое изменение одобряется человеком и может быть независимо откатано.
Фреймворк, используемый в множестве задач, со временем накапливает трение: скил, описывающий паттерн, которым больше не пользуются; два скила с пересекающимися задачами; описание, точное полгода назад, но теперь расходящееся с реальным поведением кода. Скил evolution определяет правила, по которым Datarim исправляет себя.
Каждое изменение требует явного одобрения человека. Скил не применяет ничего предположительно.
Два пути к изменениям
Рост начинается после успешного /dr-compliance. Скил reflecting анализирует завершённую работу, выявляет паттерны, полезные для будущих задач, и генерирует предложения по эволюции. Если при начале архивации рефлексия отсутствует или устарела, шаг 0.5 команды /dr-archive служит запасным маршрутом, а не молча пропускает её. Предложения могут обновлять существующий скил, уточнять описание агента, добавлять шаблон для повторяющегося паттерна или создавать отдельный скил для непокрытой области. Каждое содержит категорию, целевой файл, краткое описание изменения и обосновывающее свидетельство.
Follow-up, найденный во время рефлексии, возвращается на стадию архивации для явного добавления в backlog. Изменения фреймворка по-прежнему требуют одобрения человека, а предложение класса B, меняющее существующий контракт, также требует обновить соответствующий PRD до реализации.
Обслуживание выполняется через /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-25 навыки, команды, агенты и шаблоны в $HOME/.claude/ являются символическими ссылками на git-репозиторий Datarim — откат изменения — стандартный git revert.
Смотрите также: пост о команде /dr-compliance как основном завершающем гейте, пост о команде /dr-archive для запасного маршрута и добавления в backlog, а также пост что такое Datarim для общей картины фреймворка.