Одного AGENTS.md хватает на универсальный контракт, но в реальном проекте много правил, которые нужны не всегда: одному языку, одному каталогу, одному типу задач. Если сложить их все в always-on файл, контракт превращается в шум, где условное соседствует с обязательным и мешает читать и то и другое. Контракт, в котором обязательное тонет в частном, перестаёт быть контрактом: его либо читают невнимательно, либо не читают вовсе.

Наивный ход - дописывать в постоянный файл строку на каждый частный случай: "в Python-файлах делай так", "для миграций делай эдак". Выглядит аккуратно: всё в одном месте и всегда под рукой. Кажется, что так ни одно правило не забудется.

Ломается это на двойной цене always-on: стоимость плюс нерелевантность. Правило про SQL-миграции, загруженное во время правки CSS, - это чистый шум и потраченные токены; чем больше условных правил стекается в постоянный файл, тем дольше модель продирается сквозь неприменимый текст к тому, что важно сейчас.

Devin разносит это по активации. Дополнительные правила лежат в .devin/rules/.md, у каждого - свой trigger во frontmatter; .devin/global_rules.md остаётся единым always-on файлом, а ~/.devin/rules/.md - личными глобальными правилами. Поддерживаются triggers always_on (в каждой сессии), manual (только по вызову пользователя), model_decision и agent (агент сам решает применимость) и glob (включается по совпадению файлового шаблона). Devin при этом читает и внешние форматы - правила Cursor из .cursor/rules, Windsurf из .windsurf, Claude из .claude, - если это включено в read_config_from, так что мигрировать всё разом не обязательно.

Почему так, а не одним списком. Активация привязывает правило к моменту, когда оно уместно. glob подгружает правило только когда затронуты подходящие файлы; manual держит правило вне контекста, пока вы не позовёте его через @-mention; model_decision позволяет агенту вытянуть правило, когда оно относится к делу. Путь .devin предпочтительнее legacy .windsurf, и это же место имеет приоритет при совпадении. Смысл в том, чтобы правило появлялось в контексте ровно тогда, когда относится к делу, и исчезало, когда нет: активация - это способ платить за правило только по факту его пользы.

Что куда класть, следует из этого прямо. Always-on оставляйте только для универсальных ограничений и команд, которые верны везде. Длинную процедуру переносите в skill, который грузится по требованию. Разовую подсказку добавляйте в разговор как ручное правило через @-mention. Документация Devin советует предпочитать skills правилам там, где можно, именно потому, что навык попадает в контекст лишь когда релевантен, а always-on правило - всегда.