Досить писати промпти: навіщо AI-агентам робочий процес

Кожна сесія починається з чистого аркуша

Якщо ви щодня працюєте з Claude Code чи схожим агентом, вам знайомий цей момент. Ви відкриваєте нову сесію, і перш ніж агент зробить щось корисне, треба вирішити:

Що написати в промпті?
Які частини задачі, документації та коду йому показати?
Яких skills чи правил він має дотримуватися?
Спершу поставити мені запитання чи одразу писати код?
Що перевірити, коли він закінчить: тести, рев'ю, документацію?

Жодне з цих питань не складне. Але ви відповідаєте на них знову для кожної задачі, з пам'яті, і щоразу трохи інакше. У понеділок ви не забули написати «запусти тести й онови документацію». У четвер забули.

Конкретний приклад: до і після

Візьмімо звичайну задачу: «Додати на форму входу опцію "не виходити з акаунта"».

Без робочого процесу ви відкриваєте сесію й пишете щось на кшталт: «Ось задача. Подивись модуль auth. Якщо щось незрозуміло, питай. Напиши тести. Не забудь про наші правила в RULES.md». Ви самі читаєте diff, просите виправлення, пишете опис PR і, можливо, згадуєте про документацію. Наступна задача отримує іншу, знову імпровізовану версію того самого ритуалу.

З робочим процесом ці рішення вже існують як шаблон. Задача переходить у статус Implementation, а за цим статусом закріплений фіксований pipeline агентів:

# .crux/workflow.yaml (скорочено)
IMPLEMENTATION:
  role: developer
  pipeline:
    - developer      # пише код і тести, відкриває PR
    - reviewer       # перевіряє PR за правилами репозиторію і виправляє
    - wiki_curator   # оновлює документацію проєкту під зміну

Кожен агент — це невелика тека з власним system prompt і власними skills. Агент developer, наприклад, завжди працює в окремому git worktree своєї задачі, узгоджує з вами підхід до того, як писати код, тримає тести зеленими і завершує роботу skill-ом change-summary, який фіксує рівно те, що є в diff. Нічого з цього не треба писати в промпті. Ви запускаєте крок, а агент сам отримує свої інструкції.

Статуси, ролі, агенти, skills

Ідея проста. У вашому трекері вже є статуси. Робочий процес додає до кожного з них три речі:

Роль, якій належить статус: розробник, QA, дизайнер, проджект-менеджер.
Агентів цієї ролі, кожен зі своїм system prompt. Одні працюють як послідовні кроки над задачею, інші — як помічники в чаті («що мені взяти наступним?»).
Skills — записані методи, за якими працює агент. Skill технічного інтерв'ю ставить по одному запитанню, і кожне прив'язане до рядка із задачі. Skill рев'ю перевіряє архітектуру, дублювання, обхідні рішення, баги й типобезпеку і для кожного зауваження називає правило, яке порушено.

Ви плануєте роботу один раз, як шаблони, замість імпровізувати в кожній сесії.

Артефакти замість довгої історії чату

Агенти не передають роботу одне одному через історію чату. Кожен крок залишає в задачі один артефакт: tech-qa після технічного інтерв'ю, change-summary після коду, звіт рев'ю після рев'ю, оновлення wiki після кроку документації. Наступний агент читає задачу і її артефакти, а не чужу переписку.

Тож контекст агент бере з двох місць: із трекера задач (задача і її артефакти) та з вікі проєкту, яка описує, як система працює сьогодні. Вам не треба вставляти передісторію в промпт — вона вже там, куди дивиться агент. Про вікі ми написали окремо: Вікі проєкту: пам'ять, яку AI-агенти вміють читати й писати.

Кожна сесія стартує з короткого й чистого контексту, а задача стає зрозумілим записом: колега відкриє її через місяць і побачить, що вирішили, що змінилося і що знайшло рев'ю.

Агент пропонує, людина затверджує

Робочий процес не означає «нехай агенти працюють без нагляду». У наших шаблонах люди долучаються в кількох контрольних точках: коли агент зрозумів задачу, коли має план і коли показує результат. У кожній із них агент готує чернетку артефакту в чаті, ви її правите, і він публікує її лише після явного «ок». Мовчання — не згода. І агенти не переводять задачі між статусами: це робить людина.

Тож ваша робота змінюється: ви перестаєте писати промпти й починаєте оцінювати пропозиції. Чи правильний підхід? Чи чесно summary описує diff? Чи справжнє це зауваження?

Паралельні сесії: одна на задачу і роль

Коли кожен крок — шаблон, запуск кроку майже не потребує роздумів, тож можна запускати багато одночасно.

У нашому публічному плагіні для Claude Code skill crux-dispatch показує дошку ролі, дає вибрати кілька задач і закріплює кожен вибір за вами. У Claude Code desktop він готує для кожного вибору окрему картку сесії. Сам по собі нічого не запускається: сесія стартує лише тоді, коли ви клікаєте на її картку, — один клік на одну сесію. Кожна сесія переходить в окремий git worktree своєї задачі (crux-worktree), тож паралельні агенти ніколи не чіпають ті самі файли. Коли крок розробника завершено, він готує картку рев'юера для тієї ж задачі, і її ви знову запускаєте кліком.

У результаті виходить «хвиля»: група незалежних задач, що пліч-о-пліч проходять той самий pipeline, кожна у своїй сесії та своєму worktree, і кожна за тим самим шаблоном.

Як це виглядає на реальному проєкті

Сам CRUX ми будуємо саме цим робочим процесом, тож цифри нижче — з цього одного проєкту. Приблизно за пів року через нього пройшло понад тисячу задач, а в насичений день зливаються десятки pull request-ів.

Ця кількість — не хаос, який наплодили агенти. Кожна задача виросла з плану, який погодила людина, була свідомо розбита на частини й пройшла ті самі контрольні точки. Сам процес ми теж ітерували: поки ідея складалася, ми спробували кілька різних підходів, перекроювали ролі й переробляли те, як skills потрапляють до агентів. Файл робочого процесу зараз у п'ятій версії.

В історії комітів видно ритм: код від розробника, коміт із планом і зауваженнями рев'юера, виправлення, оновлення документації — задача за задачею. Головний виграш — сталість: сота задача отримує те саме інтерв'ю, рев'ю й крок документації, що й перша.

Спробуйте

Плагін CRUX для Claude Code публічний: github.com/cruxteam/skills. У ньому чотири skills: crux-dispatch (вибрати задачі з дошки ролі й відкрити сесію для кожної), crux-run (запустити один крок pipeline на одній задачі), crux-worktree (перенести роботу в окремий git worktree задачі) і crux-retro (ретроспектива за спринт або період). Встановлення в Claude Code:

claude plugin marketplace add cruxteam/skills
claude plugin install crux@cruxteam

Він також встановлюється в Codex, GitHub Copilot і Gemini CLI і працює з вашим проєктом CRUX через його MCP-сервер (див. README).

Навіть без CRUX спробуйте саму ідею: один раз запишіть, що кожен статус вашої дошки потребує від агента.