Контекст — це бюджет, а не склад усього репозиторію
Контекст є обмеженим ресурсом, за який змагаються історія діалогу, файли, логи, правила проєкту та критерії готовності. Передавання всього репозиторію часто додає шум, розширює scope і провокує зайві правки.
Оптимальний підхід — мінімально достатній контекст із можливістю точкового розширення, якщо під час дослідження виявилася конкретна нестача даних.
| Сигнал | Роль у задачі |
|---|---|
| Goal | Що має змінитися |
| Affected area | Де шукати повʼязану реалізацію |
| Evidence | Чому проблему вважають реальною |
| Constraints | Що не можна змінювати |
| Зразок стилю | Як виглядає прийнята схожа реалізація |
Порядок відбору контексту
- Сформулюйте мету та очікуваний результат.
- Визначте affected area: модуль, файли, класи або тести.
- Зберіть evidence: лог, stack trace, reproduction steps, failing test чи скриншот.
- Зафіксуйте обмеження та незмінні API або залежності.
- Додайте один-три релевантні файли чи один невеликий модуль.
- Додайте схожу реалізацію, якщо потрібно наслідувати стиль.
- Розширюйте контекст лише після конкретного сигналу про нестачу.
Контекст залежить від типу задачі
| Задача | Мінімальний корисний набір |
|---|---|
| Bugfix | Кроки відтворення, stack trace, failing test і повʼязаний код |
| Документація | Фактичний API, приклад використання та чинні правила |
| Feature | Goal, affected flow, обмеження й критерії приймання |
| Investigation | Симптоми, докази, гіпотези та питання для перевірки |
Як просити знайти кандидатні файли
Знайди файли, класи й тести, пов’язані із симптомом.
Не редагуй код.
Назви кожен кандидатний файл і поясни, який факт
потрібно перевірити перед внесенням змін.
Не додавай весь репозиторій без конкретної причини.Що не варто передавати
- весь репозиторій без потреби;
- багатогодинні логи замість короткого фрагмента;
- неперевірені старі припущення;
- несуміжні задачі та застарілу документацію;
.env, ключі, токени та інші чутливі дані.
Канонічне джерело уроку · JavaRush
Відкрити матеріал JavaRush