Скил research-workflow — структурированное исследование до планирования

Действовать на основе допущений дорого. Скил research-workflow — это ответ Datarim на повторяющиеся потери от обнаружения в середине реализации, что версия библиотеки не та, API ведёт себя иначе, чем написано в документации, или компонент, который план считал существующим, отсутствует. Скил структурирует внешнее исследование так, чтобы эти открытия происходили до написания кода.

Скил работает в двух основных режимах. Полный режим — для функций, новых систем или задач с незнакомыми технологиями; он охватывает все 10 контрольных точек. Облегчённый режим — для улучшений, где большая часть контекста уже известна; он проходит 5 из 10 пунктов. Быстрые исправления пропускают исследование полностью.

10 контрольных точек

Контрольные точки охватывают: текущие стабильные версии и последние крупные релизы; критические изменения и устаревшие API между текущей и целевой версиями; рекомендуемые подходы из официальных руководств; соответствующие разделы документации стека задачи; примеры похожих реализаций и эталонные архитектуры; совместимость компонентов; известные CVE и предупреждения безопасности для зависимостей; прошлый опыт из хранилища долгосрочной памяти проекта; переиспользуемые компоненты в существующей кодовой базе; инфраструктурные ограничения — ресурсы серверов, выделение портов, топология сети.

Выбор инструментов адаптивный. Если доступен context7 MCP, он обрабатывает документацию библиотек наиболее эффективно. Если доступен поиск в интернете — он берёт на себя проверку версий, поиск CVE и архитектурные паттерны. Если ничего недоступно, скил переключается на анализ кодовой базы через поиск по файлам и историю git, помечая такие точки как [OFFLINE — только на основе локального контекста].

Протокол работы с пробелами

Исследование до планирования не устраняет все неизвестные. У скила есть вторая функция: протокол обнаружения пробелов для случаев, когда реализация упирается в препятствие. Триггеры конкретные — неожиданно падает импорт, API возвращает неожиданный формат ответа, нужная функция отсутствует в библиотеке, компоненты оказываются несовместимыми. При срабатывании любого триггера агент-разработчик приостанавливается, создаёт сфокусированного субагента-исследователя и ждёт результатов перед продолжением.

Если пробел фундаментальный — неверный выбор технологии, невыполнимое требование, архитектурная несовместимость — реализация останавливается полностью. Пробел фиксируется, оператору предлагается запустить /dr-prd для пересмотра требований. Скил явно указывает: не пытайся обходить фундаментальные пробелы.

Предполётная проверка артефактов

Планы устаревают. Между /dr-plan и /dr-do более ранние задачи могли быть выпущены, схемы могли измениться, инфраструктурные ресурсы могли быть переименованы. Скил включает предполётную процедуру для начала /dr-do: перечислить именованные артефакты в плане, сверить каждый с текущим рабочим состоянием и сравнить с допущениями плана. Три возможных исхода: совпадение (продолжаем), уже готово (пропускаем шаг), расхождение (документируем и меняем подход).

Реальный случай из истории скила: план предусматривал один подход к интеграции; предполётная проверка обнаружила, что более ранняя задача уже выпустила альтернативный подход. Следование исходному плану привело бы к удалению рабочего кода. Изменение подхода было зафиксировано в файле инсайтов; трудозатраты первой фазы сократились с запланированных 1–2 дней примерно до 2 часов.

Эмпирическая проверка сторонних провайдеров

Когда задача вводит или заменяет сторонний эндпоинт, контракт должен быть подтверждён реальным запросом до того, как какой-либо код будет на него опираться. Скил требует отправить минимальный корректный запрос с реальным форматом входных данных — включая тип контента, заголовок авторизации и специфичные для провайдера флаги — и зафиксировать как успешный ответ, так и ответ об ошибке в виде фикстур. Документация устаревает; трёхминутная проверка через curl заменяет неопределённое число переделок в середине реализации.

Результаты исследования сохраняются в datarim/insights/INSIGHTS-{task-id}.md. Общий конвейер описывает пост что такое Datarim. О том, как инсайты завершённых задач возвращаются в развитие фреймворка, рассказывает статья о скиле reflecting.