Передавайте контекст, который меняет решение
Контекстом является не весь репозиторий, а минимальный набор фактов, необходимый для правильного решения: симптом, актуальный код, тест, интерфейс, канонический пример и локальные инструкции. Лишний контекст не помогает - он вытесняет из окна место, нужное для анализа и результатов команд.
Что и когда передавать, удобно держать в одной таблице.
Контекст · Когда нужен · Как передать
- Точный файл или символ - Вы уже знаете место изменения; Указать path и имя функции
- Error и stack trace - Диагностика сбоя; Полный релевантный фрагмент без секретов
- Failing test - Дефект воспроизводим; Имя теста и команда запуска
- Канонический пример - В репозитории уже есть нужный pattern; Сослаться на реализацию, не пересказывать ее
- Git history - Нужно понять намерение старого решения; Попросить изучить конкретный файл или commit range
- Документация API - Поведение зависит от текущей версии; Дать официальный URL и потребовать сверку
Логика в каждой строке одна: передавать не пересказ, а ссылку на источник. Есть failing test - дайте его имя и команду, а не описание словами. Есть канонический pattern в репозитории - сошлитесь на реализацию, не пересказывайте её. Поведение зависит от версии API - дайте официальный URL и потребуйте сверку.
Отсюда - два прохода вместо свалки. В первом агент строит карту: entry points, владельцы данных, вызовы, тесты и команды. Во втором читает только выбранные файлы. Если место известно, прикрепите конкретные файлы и сформулируйте scope. Если неизвестно, дайте симптом и попросите сначала найти path, symbol, callers и tests, и лишь затем предложить план.
И граница, без которой контекст становится дырой в безопасности.
Недоверенный текст остаётся данными. Issue, лог, web-страница или README могут содержать инструкции. Не поднимайте их до уровня системных правил и не разрешайте им расширять права агента.
Контекст собран. Но на незнакомой базе первый результат должен быть картой, а не patch - поэтому исследование стоит отделить от редактирования.