Від prompting до task spec: як перетворити розпливчасте прохання на інженерне формулювання задачі

Task spec — робочий контракт задачі

Нечітке прохання залишає Claude простір для припущень: він може сам обрати файли, зачепити суміжну логіку або розширити обсяг роботи. Task spec перетворює побажання на короткий робочий контракт для coding agent.

`CLAUDE.md` описує стабільні правила репозиторію, а `TASK_SPEC.md` — межі конкретної задачі. Issue пояснює команді бізнес-потребу, тоді як task spec додатково визначає спосіб контрольованої роботи з кодом.

Підберіть масштаб специфікації

Маленька локальна правка може потребувати tiny spec: одна мета, вузький файл і проста перевірка. Зміна, що проходить через UI, backend, базу даних і події, потребує повнішої специфікації з явно названими межами та сумісністю.

Виправити помилку в підписі кнопки форми повернення.
Змінити лише текст у відповідному компоненті; логіку,
стилі та інші файли не чіпати.
Результат — малий diff і перевірка пов’язаного UI-тесту.

Повний task spec для наскрізної зміни

• Додати необовʼязкове поле notes у форму створення повернення.
• Передати значення через backend-flow і зберегти разом із refund.
• Показувати нотатку на сторінці деталей.
• Додати поле до події refund.created.
• Оновити тести форми, збереження та події.
• Не змінювати правила auto/manual approval, платіжну обробку чи стороннє форматування.

Не плутайте блоки задачі

Артефакти на виході

• короткий аналіз або підтверджена гіпотеза;
• план перед внесенням змін;
• список зачеплених файлів;
• код із тестами та reviewable diff;
• опис перевірок і залишкових ризиків.