Требования к описанию работ и формированию действий

Этот документ конкретизирует правила разработки методологии для агента внедрения. Работы выводятся из сквозного процесса и применимых требований; формы, todo-листы и журналы различаются по способу ведения. Исторические материалы из maintenance/archive/ не используются как действующие основания действий.

Методология должна позволять агенту внедрения составить todo и рекомендовать ближайшие действия по её тексту и состоянию проекта. Пользователь задаёт проект, свою роль и интересующий период; переписывать правила методологии в промпт не требуется.

Это общее требование к авторам методологии, проектным адаптациям и навыкам агента. Оно не означает, что все существующие разделы уже достаточно детализированы. Недостающие основания агент показывает явно.

Что должно быть определено для работы

Описание может находиться в гайде, процедуре или чек-листе; отдельная карточка и повторение одних сведений в нескольких местах не требуются. Из текста и ссылок должно однозначно определяться:

Для регулярной работы указывается наблюдаемое событие или расписание, для однократной — условие первого выполнения. Роли подключаются по Команда и роли. Чек-лист задаёт необходимый результат, а связанная процедура объясняет способ его получения.

Если требование можно выполнить несколькими способами, перечислить условия выбора. Например, облако и локальная установка — альтернативы, а не две обязательные работы.

Какие источники использует агент

1. Зафиксированная версия методологии из README проекта.
2. Принятые проектные редакции с областью действия и датой применения.
3. Параметры проекта: паспорт, назначения, календарь, область задач, выбранные показатели и процессы. В том числе схема размещения и инфраструктура по периодам, принятые решения и открытые развилки.
4. Состояние выполнения: план, трекер, журналы, чек-листы и подтверждающие события.

Проектная редакция действует в своей области, вне неё — исходная версия. Черновик предложения не заменяет действующее правило. Код, переписка и журналы могут подтверждать состояние или выявлять противоречие; они не создают новую обязанность сами по себе.

Как собирать todo

1. Установить контекст. Прочитать README проекта, определить период, границу списка, назначения пользователя и действующие правила. Если существенные данные неизвестны, задать вопрос или отметить зависимость, продолжая независимую часть.
2. Выбрать применимые работы. Проверить этап и условия. Учесть конкретную первую задачу и последующий охват; не переносить все требования Пилота на Подготовку.
3. Определить личное участие. В личный todo включать выполнение, организацию результата и проверку, закреплённые за ролями пользователя. Работу чужого исполнителя показывать как зависимость; не поручать пользователю выполнить её лично без основания.
4. Сопоставить со сделанным. Проверить доказательства. Готовое не создавать заново; неизвестное не считать выполненным. Если обязанность проверить состояние предусмотрена, предложить её с основанием.
5. Разложить только описанные шаги. Допускается преобразовать шаги процедуры в действия и подставить проектные имена, пути и сроки. Техническую процедуру, которой нет в источниках, не сочинять как обязательную работу.
6. Объединить повторы. Совмещение ролей и несколько источников не удваивают один результат. Оставить одно действие со всеми основаниями; разные результаты не объединять только из-за одинакового названия.
7. Проверить очередность. Выделить доступные сейчас действия, ожидания и работы после наступления события. Приоритет обосновать сроком плана или зависимостью; не выдавать предположение о срочности за правило.
8. Показать основания и пробелы. Для каждого действия дать ссылку на норму и указать проектный факт, из-за которого оно нужно сейчас. Неполноту списка обозначить, если источников недостаточно.

Каждый пункт todo оформлять как что сделать → что и куда записать → ссылка на гайд ответственной роли → ссылка на гайд формируемого артефакта. Место записи — конкретный документ проекта, а до его создания — соответствующий шаблон или форма журнала. Для технической работы записывается результат проверки и подтверждение готовности. Условия начала и зависимости указывать, когда они влияют на возможность выполнить пункт сейчас.

Текст ссылки — название документа или конкретного раздела, например «Git, CI и ревью» или «Проверка первой задачи». Если название раздела само по себе неясно, добавить название документа: «Онбординг агентов — предусловия». Формулировки «Способ выполнения» и «здесь» не использовать.

Пояснения о способе выполнения, источниках данных и вариантах решения должны находиться в гайде артефакта. Например, «Зафиксировать цели внедрения в паспорте проекта» — один пункт со ссылками на шаблон паспорта, гайд РП внедрения и гайд заполнения паспорта. Выбор типовых или собственных целей, обсуждение предложения и фиксация решения описываются в гайде паспорта.

Объём одного действия и известный контекст

Группировать действия по результату. Заполнение «Команды проекта» — одна строка с составом ролей текущего периода; не дробить её на произвольные группы назначений. Создание шаблона и его заполнение можно объединить, если это один доступный сейчас результат.

Использовать только известные параметры проекта. Пока нужен Git, но он не выбран, писать «обеспечить Git для материалов внедрения» и ссылаться на способ выбора. Не вставлять в поручение примерный путь, ветку или сервер из методологии. После решения уточнить зависимые действия фактическими параметрами.

Для получения сведений использовать способы работы на Подготовке и профильные процедуры. Ссылка на пустое поле шаблона показывает место записи, но сама по себе не объясняет, откуда получить значение.

Пробелы первой работы и развитие последующего потока — разные действия с разными сроками. То, без чего нельзя выполнить выбранную первую задачу или проверить её результат, закрывается до зависимой работы; нельзя одновременно назвать это предусловием и отложить на Пилот.

Действие, вопрос и предложение — разные результаты

• Действие по методологии: обязанность и её применимость подтверждены источниками.
• Вопрос или пробел: неизвестны решение, ответственный, данные или способ выполнения. Указать, что именно отсутствует и какую работу это блокирует; адресовать по принятому процессу.
• Предложение улучшения: полезная гипотеза вне действующих обязанностей. Поместить отдельно, объяснить причину. В обязательный todo она попадает после принятого решения и фиксации в правилах или плане.

Отсутствие подробной инструкции установки платформы не разрешает агенту придумать состав её компонентов. Он должен сослаться на требуемый результат готовности и запросить/найти применимую документацию поставки. Без неё подробный план установки остаётся пробелом.

Успешная рекомендация может состоять из нескольких действий и одного вопроса. Агент не обязан достраивать внешне полный список ценой неподтверждённых работ.

Как рекомендовать ближайшие действия

Незакрытые развилки

Использовать развилки размещения и инфраструктуры PoC и их состояние в проекте. Для каждой развилки различать «не выбрано», «выбрано» и техническую готовность выбранного варианта. Значение «неизвестно» не означает ни облако, ни локальную установку, ни отсутствие доступов.

Пока решение не принято, список содержит три группы:

1. Можно делать сейчас: общие работы, не зависящие от ответа, и проверки уже известных условий.
2. Нужно решение: конкретная развилка, варианты, ответственный за подготовку/принятие, зависимые работы и срок из плана либо требуемого события.
3. После выбора: условные ветви с явным условием активации. Они помогают оценить последствия, но не считаются одновременно назначенными работами и не суммируются как обязательный объём.

Не останавливать весь список из-за одного неизвестного параметра. При этом не расписывать зависимое выполнение до ложной точности: без выбранного контура нельзя назначить конкретную установку, копирование кода или сетевую технологию. После решения включить соответствующую ветвь, убрать альтернативные поручения и повторно проверить зависимости. При смене решения сохранить историю и отметить затронутые работы.

Сами варианты и условия принадлежат методологии. Инструкция агента в AGENTS.md или навыке должна ссылаться на эти правила и источники проекта; отдельная копия развилок в промпте не нужна.

Выбор доступных действий

Использовать тот же набор применимых работ, но показывать только те, для которых выполнены предусловия, наступает срок или нужно начать внешнюю зависимость. Для ожидаемого результата другого исполнителя указать владельца и срок; напоминание или эскалацию предлагать по правилам проекта.

При появлении результата обновлять состояние и повторно оценивать зависимости. Не создавать поручения всем ролям только потому, что начался этап. Для задач за пределами текущего периода давать срок подключения или зависимость, а не немедленное требование выполнения.

Короткие запросы к агенту

После подключения репозитория и навыков достаточно запросов такого вида:

Используй действующую методологию и состояние проекта из README: [ссылка]. Собери мой todo до начала онбординга по назначенным мне ролям. Для действий укажи основания; недостающие сведения и предложения отдели.

По тому же проекту предложи ближайшие действия для меня. Учти готовность зависимостей, сроки плана и календарь встреч. Объясни, почему эти действия нужны сейчас.

Если человек не указан в назначениях, агент уточняет, чей список требуется; он не меняет назначения из-за предположения по тексту запроса.

Как проверить навык агента внедрения

ИИ-инженер проверяет на примерах:

• Один человек назначен РП и ИИ-инженером: одинаковая работа не дублируется, отдельного поручения «зафиксировать совмещение» нет.
• Назначается команда Подготовки: одна строка заполнения документа с нужными ролями; нет отдельных задач на формализацию времени участия, замещений и общего SLA.
• Git ещё не выбран: нет предположенных каталогов и веток; у действия есть способ получить решение. Если известен полный on-prem, установка платформы и локальных моделей включается без облачной альтернативы, но Git и трекер не считаются выбранными автоматически.
• Не хватает требований или проверок первой задачи: необходимые сведения/средства закрываются до неё; развитие остального покрытия планируется отдельно.
• Идёт Подготовка: требуется состав подготовительных работ и онбординга, а не участие всей команды Пилота прямо сейчас.
• Формируются цели: РП готовят предложение по типовым целям с рабочей командой и выносят на утверждение. Поручение стейкхолдеру составить цели или собрать данные не генерируется; обращение к нему содержит предложение, развилку, необходимое поручение коллегам или эскалацию.
• Выбрано облако: задачи локального развёртывания не включены как обязательные.
• Платформа облачная, модель или Git у клиента: проверяются конкретные связи; отсутствие установки платформы не отменяет работ по подключению.
• Размещение моделей или схема PoC неизвестны: общие действия доступны, решение выделено отдельно, альтернативные ветви не выданы за совместный обязательный план.
• PoC выполнен на копии кода и временном трекере: результат не трактуется как готовность целевых интеграций; при смене схемы определены зависимые повторные проверки.
• Результат уже подтверждён: повторное создание документа или среды не предлагается.
• Первая задача не требует регулярных операций: создание виртуального времени не становится безусловным блокером онбординга.
• Отсутствует процедура: пробел показан явно, придуманные шаги не выданы за требования.
• Есть принятая проектная редакция: действие ссылается на неё и правильную исходную версию.
• Ожидается действие клиента: личный todo инженера не подменяет исполнителя; отражена предусмотренная роль в организации или проверке.

Версия навыка, источники, результаты проверок и обнаруженные пробелы сохраняются в журнале PoC. При изменении правил планирования затронутые случаи проверяются повторно.