Шаблони промптів для рефакторингу коду

Виконайте рефакторинг [компонента/модуля/функції], щоб покращити [конкретну
проблему супроводу].

Збереження поведінки: Залиште без змін [публічний API, видиму поведінку, події,
обробку помилок, доступність, характеристику продуктивності].

Межі завдання: Обмежте зміни [файлами/межею]. Не змінюйте [явні цілі поза межами завдання].

Тести: Визначте наявні тести, що доводять поточний контракт. Додайте цільове
регресійне покриття, якщо захищену поведінку не охоплено.

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

Перевірка: Запустіть [цільову команду тестування], перевірку типів і [ручний сценарій].
Перед редагуванням опишіть поточний контракт і найменше безпечне виділення.

Виділіть повторювану [область інтерфейсу] з [батьківських компонентів] у найменший
багаторазовий компонент.

Збереження поведінки: Залиште ідентичними видимі мітки, фокус клавіатури, атрибути
aria, стан завантаження, події аналітики та мобільне компонування.

Межі завдання: Лише [батьківські компоненти], новий компонент і безпосередні тести. Не
переносьте володіння отриманням даних або мутаціями до виділеного компонента.

Тести: Збережіть або додайте тести для станів [порожній, завантаження, помилка, заповнений] і
інтерактивної поведінки, на яку покладаються користувачі.

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

Перевірка: Запустіть цільові тести компонентів, перевірте відрендерені стани на ширині
настільного комп’ютера й мобільного пристрою та повідомте про поведінку, яку не вдалося перевірити.

Проаналізуйте наявні відмінності, перш ніж щось виділяти.

Знайдіть дубльовану логіку в [списку файлів] і запропонуйте найменшу
спільну абстракцію.

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

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

Тести: Зіставте кожен наявний тест зі спільною поведінкою, яку він захищає. Додайте один тест
для кожної значущої відмінності.

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

Перевірка: Запустіть цільові тести викликів і порівняйте їхній спостережний вивід
до та після.

Поверніть аналіз спільних і навмисних відмінностей до написання коду.

Дослідіть проблему продуктивності в [екрані/робочому процесі].

Докази: [вимірювання, трасування, час, звіт користувача або сценарій відтворення].
Не припускайте, що відповідь — [мемоїзація/кешування/поділ коду].

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

Межі завдання: Спершу дослідіть [шляхи]. Не додавайте постійне кешування, нову бібліотеку
стану або серверну залежність без виміряної потреби.

Тести: Збережіть наявні тести поведінки. Додайте регресійну перевірку або перевірку вимірювання
лише якщо в проєкті для цього є стабільна домовленість.

Критерії прийняття: Назвіть вузьке місце, покажіть базовий і кінцевий результат та
збережіть захищену поведінку.

Перевірка: Запустіть відповідні тести, зафіксуйте погоджене вимірювання та задокументуйте
компроміси, наприклад актуальність або пам’ять.

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

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

Межі завдання: Працюйте в [модулі/межі]. Не оновлюйте не пов’язані залежності й не
переписуйте виклики в межах тієї самої зміни.

Тести: Спершу охарактеризуйте поточну поведінку тестами або фікстурами там, де бракує
покриття. Додайте відомі крайні випадки та некоректне введення.

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

Перевірка: Запустіть тести характеризації, наявні інтеграційні тести, перевірку типів
і репрезентативний ручний сценарій або сценарій командного рядка.

Поясніть невідому поведінку та ризик до пропонування реалізації.

Сплануйте поетапний рефакторинг [системи], щоб досягти [цільової архітектури].

Збереження поведінки: Підтримуйте [публічні API, сумісність даних, дозволи,
робочі процеси користувачів, поведінку розгортання та шлях відкату].

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

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

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

Перевірка: Перевірте план за поточною архітектурою, запускайте перевірки кожного етапу
та зупиніться, якщо етап спростовує початкове припущення.

Не редагуйте код, доки не представите етапи, ризики та альтернативи.