AGENTS.md Nearest-File-Wins Resolver
Показать, какой AGENTS.md реально применится для конкретного файла в монорепозитории с несколькими уровнями.
Как это работает
Спецификация AGENTS.md поддерживает несколько файлов внутри одного репозитория — корневой AGENTS.md с общими правилами и дополнительные AGENTS.md глубже по дереву директорий с уточнениями, специфичными для конкретного пакета или модуля. Принцип, по которому агент выбирает, какой файл (или комбинацию файлов) применить для конкретного редактируемого пути — nearest-file-wins — интуитивно понятен на словах, но быстро запутывает на практике в монорепозитории с десятком пакетов и разной глубиной вложенности. AGENTS.md Nearest-File-Wins Resolver online принимает дерево директорий с расположением всех AGENTS.md и конкретный путь редактируемого файла, и показывает, какой именно файл реально возьмёт агент.
Спросить нейросеть "какой AGENTS.md применится для этого файла" звучит как разумный шорткат, но по факту это чисто структурная задача поиска ближайшего родителя по дереву путей — детерминированный алгоритм без пространства для интерпретации, и здесь нет ничего, что реально выигрывает от привлечения языковой модели, кроме риска правдоподобной, но неверной догадки о структуре директорий, если модель их не видит напрямую.
Инструмент строит дерево из введённого списка путей, для целевого файла ищет ближайшего предка (включая саму директорию файла) с AGENTS.md, и явно показывает результат вместе с полным путём до найденного файла — включая случай, когда AGENTS.md на нужном уровне попросту отсутствует и агент поднимется на уровень выше, вплоть до корня репозитория.
Частые вопросы
Что если AGENTS.md есть только в корне репозитория, а файл лежит глубоко во вложенном пакете?
Агент возьмёт корневой AGENTS.md, потому что при отсутствии более специфичного файла на промежуточных уровнях поиск продолжается вверх по дереву директорий до первого найденного совпадения, вплоть до самого корня.
Означает ли nearest-file-wins, что более глубокий AGENTS.md полностью заменяет корневой, а не дополняет его?
Базовая спецификация действительно построена вокруг замены, применяется именно ближайший найденный файл, а не автоматическое слияние нескольких уровней, хотя отдельные инструменты и обсуждаемые расширения спецификации предлагают опциональное наследование, стоит свериться с документацией конкретного используемого агента для точного поведения.
Как правильно организовать несколько AGENTS.md в монорепозитории с общими и специфичными правилами?
Практика, устоявшаяся к середине 2026 года, — держать в корне действительно общие вещи (стиль коммитов, общие команды тестирования), а специфичные для конкретного пакета детали (например, особенности сборки именно фронтенд-пакета) выносить в AGENTS.md внутри этого пакета, чтобы агент получал только релевантный контекст для места, где реально работает.
Работает ли этот же принцип для CLAUDE.md?
У CLAUDE.md собственная, более богатая трёхуровневая модель памяти (пользовательский уровень, корень проекта, конкретная поддиректория) с явно другой механикой, чем простой nearest-file-wins у AGENTS.md, так что напрямую переносить результат этого резолвера на CLAUDE.md не стоит без поправки на разницу моделей.
Можно ли проверить сразу несколько целевых файлов одним прогоном?
Текущая версия резолвера рассчитана на один целевой путь за операцию, для проверки нескольких файлов стоит менять целевой путь и запускать резолвинг заново для каждого варианта, дерево директорий при этом менять не нужно.