Надайте агенту корисний контекст репозиторію

Почніть із поточної робочої копії

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

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

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

Зберігайте сталі правила в інструкціях репозиторію

Файл інструкцій може описувати підтримувані команди, межі модулів, вимоги до перегляду та дії, що потребують рішення відповідального. Домовленість про AGENTS.md дає інструментам програмування впізнаване місце для цієї інформації. Підтримка інструментів і пріоритет інструкцій можуть відрізнятися, тому перевірте поведінку свого інструмента.

Зберігайте сталі правила проєкту в репозиторії. Поточну задачу зберігайте в її описі. Не перетворюйте файл інструкцій на історію всіх розмов чи перелік тимчасових планів.

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

Звіряйте інструкції з кодом

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

Зафіксуйте суперечність. Використовуйте прямі докази щодо поточної версії, щоб зрозуміти поведінку реалізації. Не відкидайте мовчки навмисну політику лише тому, що старий код її порушує. Політика та поточна поведінка відповідають на різні питання.

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

Зберігайте контекст доречним і безпечним

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

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

Інструкція репозиторію «не читай секрети» корисна. Вона не замінює обмеження доступу до сховища секретів і чутливих папок.

Залиште корисний запис для наступної людини

Після завершення запишіть змінену поведінку, перевірку та невирішені обмеження в pull request. Оновіть довготривалу документацію проєкту, коли підтримуваний процес змінюється. Не копіюйте всю розмову з агентом у репозиторій.

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

Якісний контекст зменшує повторні дослідження. Він також полегшує виявлення помилок, бо очікувана поведінка й робочі команди визначені явно.