К содержанию
Владимир Павлунин

Шаблон Epic → Tasks: декомпозиция, критерии приёмки, Definition of Done

Шаблон, по которому Epic раскладывается в DAG задач для coding-агентов: что должно быть в Epic, в задаче, в критериях приёмки и в Definition of Done, чтобы задачу можно было отдать агенту без устных пояснений.

· опубликовано

Короткий ответ

Как разложить Epic на задачи для coding-агентов?

Epic описывает результат и границы, каждая задача — критерии приёмки, которые проверяются тестом, и Definition of Done с доказательствами. Задачи выстраиваются в граф зависимостей, чтобы агенты шли параллельно, а человек решал в двух точках: план и merge. Шаблон ниже — тот, по которому работает конвейер Rivet.

Главное

  • Материал к выпуску «Команда из coding-агентов без человека в цикле: Epic → DAG → review → merge. Что сломалось (W4)»
  • Открыт без регистрации: копируйте и меняйте под себя

Принцип: модель предлагает план, принимает его человек, исполняет детерминированный код. Шаблон — то, что должно быть заполнено до того, как задача уйдёт агенту. Поля помечены: [человек] — заполняет человек, [модель] — может предложить модель, человек правит, [код] — считает система.

Epic

epic:
  title: "Промокоды в корзине"                   # [человек] одно предложение, глагол + результат
  goal: |                                        # [человек] зачем: 2–4 предложения для планировщика
    Покупатель вводит промокод в корзине, видит скидку до оплаты.
    Коды с истёкшим сроком отклоняются с понятным текстом.
  repository: "shop/web"                         # [человек] один Epic — один репозиторий
  constraints:                                   # [человек] что нельзя трогать
    - "контракт /api/checkout не меняется"
    - "миграции только аддитивные"
  budget:                                        # [человек] лимиты, после которых — эскалация
    tokens: 2_000_000
    attempts_per_task: 3
    review_rounds_per_task: 3
  human_review_paths: ["migrations/**", ".rivet/**", "payments/**"]   # [человек] merge только кнопкой

Задача (повторить для каждой)

task:
  id: T3                                         # [код]
  title: "Эндпоинт POST /api/cart/promo"         # [модель] глагол + объект, ≤ 60 знаков
  depends_on: [T1, T2]                           # [модель] только задачи этого Epic; цикл — план отклоняется
  capabilities: [coding]                         # [модель] coding | review | deploy
  description: |                                 # [модель] что сделать, без «как»
    Принять код, проверить срок и минимальную сумму, вернуть пересчитанную корзину.
  context:                                       # [человек] что агент должен прочитать до кода
    - "docs/architecture/cart.md"
    - "src/cart/pricing.ts — правила округления"
  acceptance:                                    # [модель → человек] проверяемые утверждения, не пожелания
    - "промокод с истёкшим сроком → 422 и текст «срок действия истёк»"
    - "пустой промокод = без промокода, 200"
    - "сумма товаров ниже минимума → 422, код не применён"
    - "тесты на три случая выше — красные до кода, зелёные после"
  out_of_scope:                                  # [человек] чтобы агент не «улучшал» лишнее
    - "UI корзины"
    - "отчёт по промокодам"
  stop_and_ask_if:                               # [человек] когда печатать BLOCKED и останавливаться
    - "критерий можно понять двумя способами"
    - "нужна новая зависимость"
    - "тесты красные после двух попыток"

Definition of Done (для каждой задачи)

  • [ ] Все критерии приёмки покрыты тестами, тесты запущены в этой сессии, вывод приложен
  • [ ] Изменены только файлы в рамках задачи; out_of_scope не тронут
  • [ ] Контракты и миграции — в рамках constraints Epic
  • [ ] Ревью сделано другим агентом или человеком, замечания закрыты или вынесены в отдельную задачу
  • [ ] PR описан по шаблону: что, зачем, как проверено, что не сделано
  • [ ] Merge — кнопкой человека, если путь в human_review_paths; иначе — по политике проекта

Проверка плана перед запуском (человек, 5 минут)

  1. Граф без циклов; у каждой задачи ≤ 3 зависимостей, иначе задача слишком крупная.
  2. Критерии приёмки — проверяемые: в каждом есть вход и ожидаемый результат.
  3. Контекст указан файлами, а не «посмотри в коде».
  4. Есть хотя бы один пункт stop_and_ask_if — агент должен знать, когда остановиться.
  5. Бюджет и лимиты попыток заданы; что происходит при их исчерпании — записано.

Автор: Владимир Павлунин — pavlunin.com · Telegram «Технический фэншуй»: t.me/techfengshui

Читать дальше

Главный материалСтатьяCoding Agents Coding Agents — что это и чем агент отличается от AI-ассистента Что такое coding agent, чем он отличается от автодополнения и чата, что нужно, чтобы агент выполнял задачи целиком, и какие у него ограничения. 20 сентября 2026 Читать → СтатьяCoding Agents CLAUDE.md: что он решает для Coding Agent и где заканчивается CLAUDE.md — инструкции проекта для Claude Code: контекст, а не принудительная конфигурация. Что в него писать и что вынести в права и контекст задачи. 9 октября 2026 Читать → СтатьяCoding Agents Почему Coding Agent мало одного репозитория: 3 прогона — 3 разные цены Разбор эксперимента: Coding Agent получил задачу и репозиторий и 3 раза написал аккуратный код с зелёными тестами — и каждый раз сам придумал цену, поля API, флаг выкатки и правило возврата. Почему это не ошибка кода и чего агенту не хватает. 3 октября 2026 Читать → Главный материалСтатьяAI Development AI в цикле разработки — что это и как внедрять Что такое AI Development, из чего состоит AI Development Platform и с чего начинать внедрение AI в разработку — от требований до delivery. 20 сентября 2026 Читать →