Issue-to-PR workflow: від тикета до плану

Issue — це сигнал, а не готовий план

Тикет часто змішує симптом, вплив, припущення та запропонований фікс. Надійний Issue-to-PR workflow спочатку зменшує невизначеність, а вже потім переводить її в план, реалізацію та перевірюваний pull request.

Claude Code може пришвидшити читання issue, пошук у репозиторії та підготовку нотаток. Але scope, acceptance criteria, ризики й рішення про merge залишаються людськими рішеннями.

Артефакти, які зʼєднують етапи

• Issue Intake Note — впорядковує вхідні дані та відділяє факти від гіпотез.
• Investigation Note — показує, де в коді проходить проблемний flow і чим це підтверджено.
• Implementation Plan — описує майбутню зміну, межі, ризики та спосіб перевірки.
• PR slices — перетворюють затверджений план на невеликі контрольовані порції.
• Evidence packet — збирає diff, команди, тести та обмеження для ревʼю.

Приклад: порожній кошик у checkout

Якщо POST /api/orders із порожнім items[] завершується 500, не варто одразу редагувати контролер, названий у тикеті. Спершу потрібно простежити запит через контролер, сервіс, обчислення підсумку та глобальний обробник помилок.

Після дослідження можна зафіксувати очікувану поведінку, regression test і погоджений формат API-відповіді. Статус 400 або конкретний код помилки — це вимога, яку потрібно підтвердити контрактом, а не вгадати.

issue
  -> intake note
  -> read-only investigation
  -> approved implementation plan
  -> small PR slices
  -> tests and review evidence
  -> human merge decision

Правила роботи Claude Code на старті

1. Передайте issue та повʼязаний контекст, але не просіть одразу «виправити все».
2. Попросіть спочатку скласти intake і перелічити підтверджені факти, гіпотези та unknowns.
3. Попросіть виконати read-only investigation без редагування файлів.
4. На основі доказів сформуйте план із ризиками та перевірками.
5. Зупиніться на людському checkpoint і лише після схвалення переходьте до реалізації.