Агенты читают ваш репозиторий. Это покрывает большую часть необходимой им информации — но не решения, которые хранятся в головах людей, в вики или в разговорах двухлетней давности.
Контекст проекта объединяет инструкции из репозитория с рекомендациями, которые вы храните в Coroid.
Инструкции из репозитория тоже являются контекстом.
Coroid считывает файлы памяти, такие как файлы корневого уровня AGENTS.md, CLAUDE.md и
GEMINI.md, а также правила Cursor в .cursor/rules. Включенные источники добавляются в контекст проекта агента перед началом выполнения задач. Локальные данные репозитория @ могут подключать другие файлы инструкций. Повторные импорты, циклы и идентичные блоки инструкций включаются один раз. Вам не нужно копировать эти инструкции
в запись контекста приложения.
В Настройки → База знаний → Контекст, Источники репозитория управляют теми файлами, которые получают агенты, в то время как Контексты приложений содержат ручные заметки и сгенерированный контекст, сохранённый в Coroid. Источники включены по умолчанию, если их явно не отключить; выключите перекрывающиеся или противоречивые инструкции, которые не хотите объединять.
Инструкции из репозитория следуют вместе с кодом в Git. Контексты приложений полезны для рекомендаций и ссылок, которые вы храните вне репозитория. Оба типа контекста требуют обновления при изменении конвенций. Подробнее в разделе Настройки контекста проекта о поддерживаемых путях, распознавании файлов и параметрах управления.
Что определяет Coroid самостоятельно
Только на основе репозитория агенты могут видеть:
- используемые языки, фреймворки и библиотеки
- как собирается, тестируется и запускается проект
- существующие шаблоны — как обрабатываются ошибки, как структурируются модули, как именуются элементы
- от чего что зависит
Вам не нужно документировать всё это. Повторное изложение — пустая трата времени и риск устаревания по сравнению с кодом, который и является более авторитетным источником.
Что агенты не могут вывести самостоятельно
Код показывает что вы сделали, но никогда не почему:
- почему выбрана именно эта библиотека вместо очевидной альтернативы, причём это решение всё ещё актуально
- шаблон, который выглядит как дублирование, но является осознанным разделением логики
- модуль, к которому никто не должен обращаться без согласования с конкретной командой
- конвенции, о которых вы договорились, но которые ещё не применены повсеместно
- ограничения, исходящие извне кода — требования к соответствию нормативам, контракты, текущая миграция
Именно это и должно быть включено в контекст проекта. Простой тест: сможет ли человек, читающий только репозиторий, разобраться в этом? Если да — не включайте это в контекст. Если нет — запишите это.
В репозитории отражено следующее
Агенты считывают это для каждой задачи. Не нужно повторять.
- Языки, фреймворки и библиотеки
- Как происходит сборка, тестирование и запуск
- Существующие шаблоны и именование
- Зависимости между компонентами
Вы указываете причину
Контекст проекта включает информацию, хранящуюся в головах людей.
- Почему выбрана именно эта библиотека вместо очевидной альтернативы
- Дублирование, являющееся намеренным разделением
- Модули, к которым не следует прикасаться без согласия конкретной команды
- Договорённости, которые пока не применяются автоматически
- Внешние ограничения: требования регуляторов, контракты, текущая миграция
Тест: Сможет ли человек, читающий только репозиторий, разобраться в этом? Если да — оставьте без изменений. Если нет — запишите это.
Добавление контекста
Прикрепляйте документы, политикы и ссылки в разделе проекта Контекст . Записи об архитектуре, протоколы принятия решений, руководства по стилю и контракты API — всё это подходит.
Хороший контекст — краткий и конкретный. 40-страничное руководство по вводу в должность, написанное для людей, в основном состоит из описательного текста; важны лишь три абзаца в нём, где указаны реальные ограничения. Выделите их.
Контекст для конкретной задачи
Контекст, привязанный к проекту, применяется ко всему. Если что-то относится к одной задаче — к тикету, техническому документу, отчёту клиента — прикрепляйте его к самой задаче.
Сохраняйте контекст проекта только для информации, которая остаётся актуальной надолго. Примечание, относящееся к конкретной задаче, в контексте проекта превращается в мусор при выполнении последующих задач.
Соблюдение достоверности данных
Устаревший контекст хуже отсутствия контекста, так как агенты воспринимают его как достоверный источник информации. При изменении принятых правил обновляйте соответствующий контекст одновременно с изменением кода.
Если в комментариях к повторной работе вам приходится неоднократно исправлять одну и ту же ошибку, это признак того, что в контексте чего-то не хватает или что-то в нём указано неверно.