Norms синхронизирует правила для Claude Code, Cursor, Copilot и Codex

У каждого AI-кодинг-агента свой файл с инструкциями: Claude Code читает CLAUDE.md, Codex — AGENTS.md, Cursor — правила в .cursor/rules, GitHub Copilot — собственный файл конфигурации. Когда команда использует несколько агентов, одни и те же требования приходится копировать вручную. Open-source проект Norms предлагает хранить правила один раз и генерировать из них адаптеры для разных инструментов.

Идея практичная, но важно не переоценивать зрелость проекта. На момент проверки 31 августа 2026 года в package.json указана версия 0.0.4. Репозиторий активно меняется, а значительная часть командных и организационных функций пока существует только в спецификации и roadmap.

Как устроен единый источник правил

Каноническая конфигурация хранится в каталоге .norms/. Каждая норма — обычный Markdown-файл со стабильным идентификатором и необязательной областью действия applies_to. Например, правило тестирования можно применить только к пакетам внутри монорепозитория:

---
id: testing.integration
applies_to:
  - "packages/**"
---

# Поведение тестов
Проверяй пользовательские сценарии интеграционными тестами.

Внутри нормы разрешены ссылки, изображения, таблицы, фрагменты кода и другой контекст. Поэтому механизм подходит не только для коротких запретов. В нем можно зафиксировать архитектурное решение, правила работы с зависимостями, требования к тестам, ограничения размера компонентов или порядок оформления merge request.

Команда norms sync разрешает области действия и создает четыре производных представления:

• AGENTS.md для совместимых агентов, включая Codex;
• CLAUDE.md для Claude Code;
• .cursor/rules/norms.mdc для Cursor;
• .github/copilot-instructions.md для GitHub Copilot.

Авторы прямо рекомендуют редактировать исходники в .norms/, а не сгенерированные файлы. Иначе очередная синхронизация перезапишет ручные изменения и снова создаст расхождение.

Что происходит с областями действия и конфликтами

Norms не просто склеивает Markdown. Команда norms context [path] возвращает инструкции, применимые к конкретному файлу, а norms explain <path> показывает, почему каждое правило было включено или исключено. Это полезно в крупных репозиториях, где требования к фронтенду, инфраструктуре и мобильному приложению различаются.

Модель конфликтов намеренно строгая. Одинаковые определения с одним id объединяются с общей информацией о происхождении. Разные определения одного идентификатора считаются конфликтом. Источник правила не дает ему скрытого приоритета: локальный файл не должен молча отменять командную политику только потому, что был прочитан позже. Явные несовместимости можно описать через conflicts_with, после чего norms check отклонит одновременно активную пару.

Семантические противоречия инструмент сам не решает. Если два правила сформулированы разными словами, но требуют противоположного поведения, окончательное решение остается за человеком. Это разумное ограничение: Norms не содержит встроенной LLM и не пытается изображать автоматического арбитра.

Как синхронизируются правила из других репозиториев

В .norms/config.yaml можно объединить локальные нормы и Git-источники. Обновление выполняется явно через norms sync --update: выбранные ревизии записываются в .norms/lock.json. Обычный norms sync восстанавливает закрепленные версии и способен работать офлайн, если нужные Git-объекты уже находятся локально.

Это важнее, чем кажется. Если агент каждый раз получает «последнюю» версию внешней инструкции, сборка контекста становится невоспроизводимой. Lockfile позволяет связать поведение агента с конкретным коммитом, проверить изменение через code review и откатиться к предыдущему состоянию.

Основной рабочий цикл выглядит так:

norms init
norms propose
norms sync
norms check
norms review

norms propose создает или обновляет локальное правило, norms check проверяет конфигурацию, lockfile и сгенерированные адаптеры, а norms review помогает отправить изменение через GitHub или GitLab. Для автоматизации команды поддерживают JSON-вывод.

Чего Norms пока не делает

Norms синхронизирует инструкции, но не гарантирует их выполнение. Агент все равно получает текстовый контекст и может ошибиться, проигнорировать норму или столкнуться с конфликтующей инструкцией более высокого уровня. Для запрета опасных tool calls нужен отдельный исполняемый контрольный слой, песочница или ручное подтверждение — генерация CLAUDE.md этого не заменяет.

Текущая поддержка ограничена четырьмя адаптерами. В roadmap отмечено, что расширение VS Code уже разработано, но его публикация в Marketplace еще не завершена. Механизм централизованного распространения норм по организации, роли доступа, hosted snapshots и массовые rollout-обновления описаны в начальной спецификации, однако большинство этих пунктов пока не реализовано.

Поэтому сейчас Norms корректнее воспринимать как Git-backed транспилятор инструкций для одного или нескольких репозиториев, а не как готовую enterprise-платформу управления AI-разработкой.

Вывод COMRAD404

Проект решает реальную проблему: правила для кодинг-агентов быстро расходятся, когда каждый инструмент использует собственный формат. Канонические Markdown-нормы, path-scopes, явные конфликты и закрепленные Git-ревизии дают более проверяемую модель, чем четыре файла, которые команда обновляет вручную.

Главный тест для Norms — не количество поддерживаемых агентов, а отсутствие потерь при преобразовании. Команда должна видеть, какая норма попала в конкретный адаптер, откуда она пришла и почему действует для выбранного файла. Именно поэтому context, explain, check и lockfile здесь важнее красивой команды sync.

Источники

• репозиторий Norms и README;
• описание модели норм, источников и конфликтов;
• roadmap проекта;
• обсуждение на Hacker News — использовано как сигнал обнаружения, а не как источник фактов.