Скил coworker-context — соглашения для внешних LLM при редактировании артефактов Datarim
Как скил coworker-context в Datarim передаёт внешней LLM точные соглашения для корректной генерации или редактирования артефактов задач — frontmatter, заголовки этапов, поля снапшотов и многое другое.
Datarim делегирует объёмную I/O-работу внешней LLM через инструмент coworker — черновики планов, длинные исследовательские документы, архивные записи. Внешняя модель не имеет доступа к истории разговора, накопленной основным агентом. Без явных соглашений она делает правдоподобные предположения: переупорядочивает ключи YAML, придумывает имена полей или пропускает обязательное поле frontmatter. Скил coworker-context — это единый справочный документ, который внешняя LLM читает перед тем, как трогать любой артефакт в datarim/.
Что он делает
Скил содержит одиннадцать разделов. Чаще всего применяются правила сохранения YAML frontmatter, заголовков этапов и полей снапшотов.
Сохранение frontmatter означает: никогда не переупорядочивать ключи, не менять стиль кавычек, не изменять отступы и не редактировать имена ключей. Если нужно изменить значение — редактируются только символы значения. Правило существует потому, что скрипты Datarim разбирают frontmatter по точному порядку ключей и отступам — переупорядоченный файл сломан с точки зрения инструментов.
Соглашение о заголовке этапа требует, чтобы каждый ответ пайплайнной команды, обращённый к оператору, начинался жирным строчным заголовком в формате **TASK-ID · title** в качестве буквально первой строки. Заголовок берётся дословно из файла задачи; разделитель — средняя точка Unicode, не дефис.
Раздел frontmatter снапшота определяет десять обязательных скалярных полей для каждого артефакта stage-snapshot: ID задачи, тип артефакта, версия схемы, этап, команда, временная метка захвата, captured-by, следующая рекомендуемая команда, размер в байтах и флаг усечения. Скил задаёт точные имена полей и допустимые значения, чтобы внешняя LLM не придумывала альтернативы.
Другие разделы охватывают зеркалирование PRD в архив (каждый пункт валидации в архиве ссылается на соответствующий критерий приёмки из PRD), таксономию документации (четыре категории Diátaxis, не больше) и базис безопасности (девять именованных областей, S1–S9). Каждый раздел написан без привязки к истории — называются контрактные поверхности, не конкретные идентификаторы задач.
Один конкретный пример
Внешней LLM поручено написать черновик отчёта о compliance. Без этого скила она может создать собственную структуру frontmatter с полями, которые сочтёт логичными. С загруженным coworker-context модель знает, что frontmatter отчёта должен содержать task_id, date и verdict, а verdict должен быть одним из трёх точных строковых значений. Результат требует только смыслового ревью, а не структурной переработки.
Когда загружается
Скил указывается в профиле datarim в конфигурации профилей coworker. Любой вызов coworker write --profile datarim или coworker ask --profile datarim инъектирует содержимое этого скила как префикс системного промпта. Также загружается во время /dr-write и /dr-archive, когда задействовано внешнее делегирование.
О полной картине пайплайна — в посте что такое Datarim. Где внешнее делегирование применяется чаще всего — в статье о команде /dr-archive.