Шість блоків промпта, щоб агент не робив зайвого

Шість блоків на одному прикладі

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

• Мета: Зареєстровані задачі можна видалити з екрана списку. Щоб уникнути випадкових дій, перед видаленням показуй діалог підтвердження.
• Обсяг: дія видалення для кожної задачі, діалог підтвердження, оновлення списку після видалення.
• Не робимо: масове видалення, кошик і відновлення.
• Звірка: docs/spec.md і файл правил проєкту.
• Обмеження: не змінювати наявний формат даних, не додавати бібліотек, не робити commit і push.
• Готово, коли: видалення можна скасувати, видаляється лише підтверджена задача, список після видалення оновлюється.

Мету автор формулює через те, що зможе користувач. Спосіб реалізації не прописує.

Критерії готовності й звіт

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

Для звіту автор радить вимагати: змінені файли, що реалізовано, які тести запущено і з яким результатом, що не перевірено, що лишилось відкритим і що людині перевірити далі. Ключове правило: незапущені тести не подавати як запущені. Залежно від середовища агент може не мати змоги їх прогнати — тоді хай назве причину.

Що винести в CLAUDE.md / AGENTS.md

Щоб не переписувати одне й те саме, автор ділить правила на спільні й ті, що змінюються від задачі до задачі.

• Спільні (CLAUDE.md для Claude Code, AGENTS.md для Codex): політика Git-операцій, правила додавання залежностей, стандарти коду, формат звіту.
• У промпті задачі: що реалізувати, поточний обсяг, яку специфікацію звіряти, визначення «готово».

До типових обмежень автор додає ще не змінюй без потреби наявні конфіги і погоджуй нові бібліотеки заздалегідь. Git-операції та зміни залежностей він хоче перевіряти окремо від самої реалізації — це рішення, які не варто віддавати агентові.

Де шаблон не рятує

• Дрібні правки. Заповнювати всі блоки не обов'язково, коротшої інструкції може вистачити. Питання не в повноті, а в тому, чи не бракує чогось потрібного саме цій задачі.
• Вказаний файл — ще не зрозумілий файл. Посилання на docs/spec.md не гарантує правильного прочитання. Для важливих специфікацій попросіть переказати обсяг і критерії до старту.
• «Готово» від агента — не перевірка. Критерії лише показують, що саме перевіряти вам.
• Широкий обсяг за раз означає більше роботи з перевіркою. Автор ріже роботу на фази і тримає план окремо, наприклад у docs/phase-plan.md.

Перед тим як прийняти результат, звірте diff з обсягом: змінено лише заплановані файли, немає нових залежностей і змін формату даних, жодного commit чи push. Кожен критерій має бути перевірений руками або тестом, який справді запускався, а пункти «не перевірено» зі звіту — закриті.