Четыре независимых выбора определяют что делаем, насколько глубоко проверяем, кому поручаем работу и запускаем ли UI-тесты. Обычные проверки результата входят в рабочий цикл; проверки в интерфейсе управляются отдельно.
Режим определяется запросом и риском задачи; его можно задать словами. Он описывает результат работы:
- Документация (
docs-fix) — изменить текст и проверить структуру, ссылки и согласованность. - Спецификация (
spec-authoring) — подготовить требования, сценарии и план OpenSpec, подтвердить конкретные факты 1С. Реализация начинается отдельным этапом apply. - Аналитика — исследовать вопрос, объяснить поведение, сравнить решения или подготовить рекомендации без изменения исходников. Это сценарий работы по запросу, отдельного значения в triage пока нет.
- Быстрый фикс (
quick-fix) — одна небольшая локальная правка: короткий план → изменение → применимые проверки. - Полный цикл (
full-cycle) — требования и план → реализация → проверка результата → ревью → сверка Definition of Done.
Агент повышает быстрый фикс до полного цикла при существенном риске: например, затронуты проведение, транзакции, публичные контракты или права. Название режима не отменяет эти условия. Отдельной команды /mode сейчас нет; действующий выбор описан в AGENTS.md.
Уровень задаёт глубину проверки кода через /sdlc lite|standard|full и VERIFICATION_DEPTH:
lite— синтаксис для быстрого фикса; синтаксис и анализ кода для полного цикла.standard— по умолчанию: синтаксис и анализ для быстрого фикса; дополнительно MCP-ревью кода для полного цикла.full— вся цепочка статических валидаторов для изменённого BSL, с увеличенным бюджетом подтверждения после исправлений.
Это глубина проверок, не effort модели и не выбор режима работы. full и full-cycle — разные настройки. Риск переводит задачу в полный цикл с бюджетом повторов full; набор валидаторов остаётся по выбранному уровню. Проверки XML, влияния изменений, результата в ИБ и финальное ревью выполняются по своим условиям. Синтаксис изменённого BSL обязателен при любом уровне; явный запрос ревью добавляет соответствующую проверку. Точная матрица — verification-policy.md.
/sdlc status показывает состояние; /litemode on|off — совместимые сокращения для lite|standard. Отдельной команды /quality сейчас нет. Ни одна из этих команд не меняет UI-политику.
standard— по умолчанию: головной агент выполняет небольшие задачи сам, а крупные и независимые части делегирует по правилам.economy— головной агент сохраняет решения, спецификации и итоговую проверку, чаще передаёт исполнение субагентам. Самостоятельные правки документации и быстрые фиксы остаются у головного агента.
Управление: /economymode on|off|status; on задаёт ORCHESTRATION=economy, off возвращает standard. /economymode models настраивает ярусы coding / analysis / light через SUBAGENT_MODEL_*. Заданные модели применяются при делегировании в обоих режимах, если клиент поддерживает и фактически применяет этот выбор; сами настройки моделей не включают economy. При наследовании модели головного агента экономия стоимости не гарантирована. Изменение моделей требует обновить установленные определения субагентов, иногда — перезапустить клиент.
Оркестрация не меняет Quality, UI-политику или критерии готовности. Любой уровень качества сочетается с обоими режимами оркестрации.
/uitests управляет UI_TESTING:
/uitests essential— по умолчанию: после доработки и обновления dev/test-базы автоматически проверять в интерфейсе только важные новые и изменённые возможности задачи; остальное — по запросу./uitests on(илиauto) — автоматически выполнять все применимые UI-сценарии при готовой разрешённой dev/test-среде и инструментах./uitests manual— выполнять UI-тесты только по явному запросу./uitests off— отключить UI-тесты./uitests visible/hidden— окно тест-клиента 1С при проверках через QA MCP (MCP_QA_CLIENT_VISIBLE): видимое по умолчанию или на скрытом рабочем столе; при ошибке или просьбе показать клиент перезапускается видимым./uitests status— показать состояние и источник настройки.
Основной путь UI-проверок — QA MCP (подключение 1c-qa, навык 1c-qa-testing): он управляет формами тонкого клиента через механизм тестирования платформы и читает их структуру, без скриншотов. Запуск тест-клиента, видимое или скрытое окно, скриншоты, Windows-MCP и подтверждение данных через 1c-data-mcp описаны в правиле qa-testclient. Веб-клиент через браузер — запасной путь и путь для особенностей самого веб-клиента. TOOL_QA=off отключает QA MCP, не отключая UI-проверки вообще.
Переключение само по себе не запускает тесты или deploy. Значение сохраняется в существующем .dev.env; без файла действует для сессии. /test-fix-loop — отдельный явно запрашиваемый цикл «deploy → тест → исправление → повтор», даже при auto.
Если 1c-data-mcp доступен и разрешён, модель выполняет целевые проверки, когда считает их необходимыми для подтверждения результата. Она задаёт входные данные и ожидаемый результат, проверяет запрос, данные или функцию в dev/test ИБ и сравнивает фактическое с ожидаемым. Это проверки внутри рабочего цикла; /uitests off, lite и economy их не отключают. Обязательные условия Gate 3a сохраняются; дополнительных прогонов «на всякий случай» не требуется.
Такие проверки по умолчанию не меняют данные. Сценарии с записью, проведением или другими побочными эффектами требуют отдельного разрешённого процесса на тестовой базе. Наличие MCP-подключения само по себе не разрешает эти операции.
Для сохраняемых автотестов есть навыки 1c-business-tests и 1c-ui-regression. Модель сама решает, полезны ли они в текущей задаче: создание тестового набора не обязательно после каждой правки. Навыки помогают создать, сопровождать и запускать тесты через проверенный фреймворк проекта; сам фреймворк, браузер или тестовое расширение в пакет не входят. Создание тестов не разрешает автоматически deploy или изменение данных; запуск UI сохраняет политику /uitests. Статические валидаторы и ревью дополняют фактические проверки. Если необходимое подтверждение недоступно, критерий остаётся непроверенным.
Пример: быстрый фикс + standard + стандартная оркестрация + UI off — локальная правка, статические проверки и при необходимости проверка через 1c-data-mcp. Полный цикл + full + economy + UI auto — план, делегированная реализация, проверки результата и интерфейса, финальное ревью и DoD.
Подробные схемы по режимам и сочетаниям — WORKFLOWS.md. Новые определения команд появляются в установленных проектах после обновления rules.
Если ты ИИ-агент и тебе нужно установить или обновить правила в проекте, перейди к
AGENT-INSTALL.mdи следуй инструкциям оттуда. Текущий файл — обзор для разработчика.
Каталог — этот репозиторий. Плагин вызывает install.ps1 и не копирует content/rules в always-on правила хоста.
Cursor — Dashboard → Plugins → import https://github.com/comol/ai_rules_1c, затем плагин 1c-rules.
Claude Code
claude plugin marketplace add comol/ai_rules_1c
claude plugin install 1c-rules@1c-rulesCodex
codex plugin marketplace add comol/ai_rules_1c --ref main
codex plugin add 1c-rules@1c-rulesВ приложении Codex: Plugins → Add More → https://github.com/comol/ai_rules_1c.git.
OpenCode
opencode plugin marketplace add comol/ai_rules_1c
opencode plugin marketplace install 1c-rulesЕсли команды plugin marketplace нет, в opencode.json: { "plugin": ["<clone>/plugins/1c-rules"] }.
Kilo CLI — тот же каталог, что у Claude Code / OpenCode. В Kilo Code (VS Code) своего marketplace add нет: Kilo CLI или install.ps1 init -Tools kilocode из корня проекта.
После подключения на 1С-проекте плагин сам ставит правила под хост (ensure). Обновление — /1c-rules:update или install.ps1 update.
1c-rules — это переносимый набор правил, ролей субагентов, on-demand инструкций и интеграций для разработки в 1С:Предприятие 8 (BSL) с помощью ИИ-агентов. Содержимое раскладывается в проект единым установщиком и адаптируется под формат каждого инструмента.
Правила и команды собираются под конкретный инструмент адаптерами из adapters/*.yaml. Поддерживаются:
- Cursor (
.cursor/rules/,.cursor/agents/,.cursor/commands/,.cursor/skills/) - Claude Code (
.claude/rules-1c/,.claude/agents/,.claude/commands/) - OpenAI Codex (
.codex/rules/,.codex/agents/,.codex/skills/,.codex/config.toml; slash-команды ставятся в пользовательский~/.codex/prompts/) - OpenCode (
.opencode/command/) - Kilo Code (
.kilo/rules-1c/for on-demand rules referenced byAGENTS.md,.kilo/commands/,.kilo/agents/,.kilo/skills/) - Kimi Code CLI (
.kimi-code/rules-1c/,.kimi-code/agents/,.kimi-code/skills/,.kimi-code/mcp.json; slash-команды доступны через Skills/Plugins Kimi) - Qwen Code (
.qwen/rules-1c/,.qwen/agents/,.qwen/commands/,.qwen/skills/; MCP в.qwen/settings.jsonподmcpServersсhttpUrl; entry stubQWEN.md→AGENTS.md) - Command Code (
.commandcode/rules-1c/,.commandcode/agents/,.commandcode/commands/,.commandcode/skills/; MCP в корневом.mcp.json, общий с Claude Code) - Cline (
.cline/rules-1c/,.cline/agents/,.cline/skills/; MCP только глобальный — установщик проектный MCP не пишет; не кладёт on-demand правила в.clinerules/, чтобы не раздувать контекст) - ZCode (
zcode;.zcode/rules-1c/,.zcode/agents/,.zcode/commands/,.zcode/skills/; MCP —.zcode/config.json, ключmcp.servers; проверено по исходникам ZCode v3.14.3) - MiMo Code (
mimocode;.mimocode/rules-1c/,.mimocode/agents/,.mimocode/commands/,.mimocode/skills/; MCP — корневойmimocode.json, ключmcp) - Pi (
.pi/rules-1c/,.pi/prompts/для команд,.pi/skills/; без субагентов и без MCP — у Pi нет встроенного MCP) - Прочее (
other, универсальный fallback) (.ai-agent/rules/,.ai-agent/agents/,.ai-agent/commands/,.ai-agent/skills/,.ai-agent/mcp.json) — для любого ИИ-клиента, которого нет в списке выше (Aider, Continue, Cody и т.п.). Ничего не автодетектится — выбирается вручную при установке. На диск пишутся максимально портабельные правила:AGENTS.mdв корне (де-факто стандарт для современных агентов), а on-demand-правила и описания субагентов — по нейтральным путям под.ai-agent/с минимальной frontmatter (description+alwaysApply).
Один и тот же исходный набор правил из content/ раскладывается во все активные инструменты одновременно, поэтому AGENTS.md, on-demand правила и описания субагентов остаются согласованными независимо от того, в каком клиенте вы работаете.
Например, установка для пяти клиентов (из каталога целевого проекта):
& C:\path\to\ai_rules_1c\install.ps1 init -Tools zcode,mimocode,cline,command-code,kimi -NonInteractiveАдаптер kimi рассчитан на новый Kimi Code, использующий .kimi-code/. Его формат субагентов игнорирует model, поэтому модели по ярусам для него не назначаются. В Command Code адаптер явно задаёт tools: "*" и ограничения для ролей только на чтение: отсутствие tools означает отсутствие инструментов. Для ZCode и MiMo Code установщик сохраняет прочие настройки и сторонние MCP-серверы, включая совпавшие имена; при удалении убирает только свои серверы. mimocode.jsonc, если он есть, продолжает переопределять mimocode.json по правилам клиента.
Установка спроектирована как протокол, который выполняет сам ИИ-агент. Откройте проект в любимом ИИ-агенте (Cursor / Claude Code / Codex / OpenCode / Kilo Code / Kimi / Qwen / Command Code / Cline / Pi) и отправьте сообщение:
Установи правила из
https://github.com/comol/ai_rules_1cпоAGENT-INSTALL.md.
Всё. Остальное — клонирование репозитория, определение активных инструментов, миграция существующих AGENTS.md / CLAUDE.md, запросы перед разрушительными действиями — описано в AGENT-INSTALL.md, который агент прочитает сам.
Через marketplace — команды в начале файла, раздел Подключить marketplace.
Если при первой установке в .dev.env уже указана информационная база, а исходников 1С в проекте ещё нет, установщик предложит выгрузить их. Можно выбрать «Пропустить»: правила останутся установленными, а выгрузку позже можно запустить командой /loadfrom1cbase full. В режиме PowerShell без диалога выгрузка автоматически пропускается; при установке через агента он предложит выбор в чате.
Для регулярного обновления файлов, которые индексирует MCP, выполните /installfilesupdatescript. Команда создаёт скрипт выгрузки из базы, указанной в .dev.env, и устанавливает его в планировщик Windows: по умолчанию каждые 30 минут, пока текущий пользователь вошёл в систему. Например, /installfilesupdatescript 60 задаёт часовой интервал. Каталог выгрузки определяется по подключённому источнику MCP и должен быть отделён от редактируемых исходников; журнал и скрипт хранятся в .1c-files-update/. Поддерживается Designer XML для основной конфигурации или EXTENSION_NAME; legacy-отчёт метаданных и дерево EDT требуют отдельной настройки источника MCP.
Если агент не справляется (ограниченная среда, нет FS-доступа, нужен детерминированный CI-запуск) — тот же протокол реализован как PowerShell-скрипт install.ps1:
git clone https://github.com/comol/ai_rules_1c.git $env:TEMP\1c-rules
& $env:TEMP\1c-rules\install.ps1 init -Source $env:TEMP\1c-rulesИмя локальной папки произвольное: в примерах используется 1c-rules, но установленный или рабочий каталог может называться иначе.
Параметр -Source также принимает URL напрямую — в этом случае установщик сам делает shallow-clone в кэш под $env:TEMP (ключ кэша — хэш URL) и переиспользует его при повторных запусках; требует git в PATH:
.\install.ps1 init -Source https://github.com/comol/ai_rules_1cКоманды: init / update / add <tool> / remove [<tool>] / doctor / eject.
Если MCP-серверы уже установлены дистрибутивом MCP по его INSTALL.md в мультипроектном режиме (каталог GLOBAL_ROOT, projects.registry.json, динамические порты по проектам), установщик правил это автоматически обнаруживает (переменная окружения BASESAI_MCP_GLOBAL_ROOT либо MCP_GLOBAL_ROOT в .dev.env + файл install.manifest.json) и не трогает mcp.json — ни проектный, ни глобальный. Вместо этого он записывает в USER-RULES.md секцию mcp:install_forme с фактическими серверами, url и портами из артефактов установки. Правильный порядок: сначала MCP по INSTALL.md, затем правила — повторные init / update правил рабочую MCP-схему не ломают. Принудительное поведение — флаг -McpMode auto|managed|external (по умолчанию auto). Подробности — в AGENT-INSTALL.md → External MCP installation.
Четыре настройки и команды описаны в начале README. Наглядные схемы режимов, сочетания Quality с economymode и границы ответственности — WORKFLOWS.md. Канонические условия выбора режима и проверок — AGENTS.md и verification-policy.md.
- Корневой свод правил —
AGENTS.md: исходный always-on контекст для ИИ-агента: принципы и процедура разработки с триажем задач, жёсткий гейт загрузкиmcp-policy.mdс пронумерованным индексом MCP-обязательств, гейты метаданных / ИБ / хранилища, маршрутизация on-demand правил. Подробности живут в on-demand правилах: файл входит в каждый запрос и в старт каждого субагента, поэтому его размер ограничен валидатором. В этом репозитории он хранится в корне для удобного просмотра и поддерживается как читаемый документ без обязательных плейсхолдеров путей. - Пользовательские правила —
USER-RULES.md: пустой по умолчанию файл для команды/проекта. Установщик его не перезаписывает. - Память проекта —
memory.md: строгий долговременный слой для глобальных критичных правил проекта. Для остальных заметок запись идёт в подключённый Cognee, при его отсутствии — в OpenViking, затем в память templates MCP. Поиск охватывает все подключённые инструменты памяти, включая templates MCP. Маршрутизация и обработка сбоев описаны вcontent/rules/project-memory.md;memory.md— не общий блокнот. - Самоулучшаемые правила —
LLM-RULES.md: слой правил поведения агента, накопленных из наблюдаемого «трения» (корректировки пользователя, избыточные шаги, конфликтующие правила). Пишется только командой/evolveс поштучным одобрением пользователя; агент в обычных задачах лишь фиксирует сигналы (rememberс префиксомrule-friction:) и рекомендует запустить/evolve. Приоритет при конфликте: вышеAGENTS.mdи on-demand правил, нижеUSER-RULES.mdиmemory.md. Установщик не перезаписывает. - Адаптация под модель —
AGENT_MODELв.dev.env+ профилиcontent/rules/model-opus5.md/model-sonnet5.md/model-fable5.md/model-gpt56.md/model-gpt6.md(роутер —model-adaptation.md). Базовый свод модель-нейтрален; профиль — тонкая надстройка под задокументированное поведение конкретной модели (Claude Opus 5 / Sonnet 5 / Fable 5 / GPT-5.6 / GPT-6 Astra): длина ответов и отчётов, объём нарратива, глубина планирования, охота к делегированию, лишние самопроверки, рекомендации по effort / verbosity, форма контекста, который агент пишет для других (брифы субагентам, заметки памяти, handoff: описанный интерфейс вместо примеров, ссылки на код вместо пересказа). Общие принципы промптинга, справедливые для всех моделей, живут в базовых правилах и профилем не переопределяются; хард-гейты (метаданные через1c-metadata-manage, операции с ИБ, MCP-first, цепочка валидаторов и её бюджет,templatesearch/recall,CONFUSION, обязательный отчёт) профиль ослабить не может. Включается командой/rulesmodel <модель>(название — в любом написании, нормализует сама;auto— определить текущую модель,off— выключить); при первой установке модель предлагается выбрать. Источники специфики: гайды Anthropic (промптинг конкретных моделей, контекст-инжиниринг для поколения Claude 5) и OpenAI по промптингу конкретных моделей. - Параметры проекта —
.dev.env: единый источник правды для всех правил, on-demand-инструкций, слэш-команд и субагентов. Содержит параметры генерации кода (PREFIX,COMPANY,DEVELOPER,PLATFORM_VERSION, шаблоны комментариев,NEW_OBJECTS_IN), постоянный признак использования EDT (USE_EDT=true|false— спрашивается один раз, только при создании.dev.env; в уже существующий файл дописываетсяfalseбез вопросов;trueвключает EDT-ветку правилedt-workflow.mdи рекомендацию EDT-MCP), параметры подключения к ИБ для команд и тестов (PLATFORM_PATH,INFOBASE_KIND/INFOBASE_PATH,IB_USER/IB_PASSWORD,EXTENSION_NAME,EXTENSION_NAMES— список расширений «полного снимка» cf + cfe для команд полного цикла (/initproject,/restore-testbase,/build-release, режимallу/loadfrom1cbase//update1cbase//deploy-and-test),EXPORT_PATH,EXTENSIONS_PATH— корень исходников расширений (пусто =cfe/в корне),DT_SNAPSHOT_PATH— .dt-снимок данных для/restore-testbase,RELEASE_PATH— каталог артефактов/build-release,LOG_PATH,INFOBASE_PUBLISH_URLдля веб-тестов,UI_TESTING— режим веб-тестирования UI:manual(по умолчанию — только по явному запросу) /auto/off;PLATFORM_ARGS/IBCMD_ARGS— дополнительные аргументы запуска платформы для инструментов скилла1c-metadata-manage;SUPPORT_GUARD— реакция гейта поддержки на правку объекта типовой «на замке»:deny(по умолчанию) /warn/off) и модели субагентов по ярусам (SUBAGENT_MODEL_CODING— код/метаданные/архитектура,SUBAGENT_MODEL_ANALYSIS— план/аналитика/ревью/тест/доки,SUBAGENT_MODEL_LIGHT— исследование/поиск/быстрые фиксы; пусто — модель AI-клиента по умолчанию; при первой установке предлагается профиль по бенчу onec-llm-bench.lovable.app; сами файлы субагентов имён моделей не содержат), а также режим оркестрации (ORCHESTRATION—standard(по умолчанию) /economy; переключается командой/economymode) и параметры процесса разработки (QUICKFIX_MAX_LINES— лимит строк пути quick-fix, пусто = 40;DEBUG_FAST_PATH— режим быстрого пути отладки:standard(по умолчанию) /extended/off;VERIFICATION_DEPTH— глубина статических проверок кода:standard(по умолчанию) /full/lite, выбирается командой/sdlc lite|standard|full, просмотр —/sdlc status;/litemodeсохранена для совместимости; UI-проверки управляются отдельно через/uitests on|manual|off|status;CAVEMAN— автоактивация краткого стиля общения caveman:on(по умолчанию, на всех задачах) /auto(только на разработке) /off, переключается командой/caveman;METADATA_PREVIEW— когда показывать preview метаданных черезInvoke-1CEdit -Preview:auto(по умолчанию — только генерация из DSL и незнакомая операция) /on(перед каждой записью через обёртку) /off(только по явному запросу), переключается командой/previewmode;AGENT_MODEL— модель головного агента для адаптации правил под её поведение:opus5/sonnet5/fable5/gpt56/gpt6, пусто = профиль не применяется, переключается командой/rulesmodel, которая принимает название модели в любом написании). Отдельный блок — канал поддержки (SUPPORT_KEYиSUPPORT_EMAIL— оба обязательны для отправки обращения командой/support;SUPPORT_API_URL— адрес сервиса, пусто = адрес по умолчанию). Установщик дописывает эти ключи пустыми в уже существующий.dev.envи ничего про них не спрашивает: ключ приходит с дистрибутивом MCP, e-mail указывает сам пользователь. Установщик создаёт.dev.envавтоматически наinit, заполняет автодетектомPLATFORM_VERSION(изConfiguration.xml),PLATFORM_PATH(поиск вC:\Program Files\1cv8\) иPREFIX(изNamePrefixрасширения), спрашиваетUSE_EDT(только когда создаёт файл), затем предлагает остальные параметры в интерактивном режиме. В-NonInteractiveпишетUSE_EDT=false, оставляет остальные допустимые пустые поля с явным WARNING. Шаблон —.dev.env.example. - Проверка избыточной сложности —
/ponytail-review: адаптированная команда Ponytail, которая предлагает обоснованные упрощения без изменения файлов. Без аргументов проверяет текущий Git diff;/ponytail-review <путь>— выбранный файл или каталог. Сохраняет проектные правила поиска и проверок, дополняет обычное ревью корректности. - Установщик —
install.ps1: PowerShell-инсталлятор (командыinit/update/add/remove/doctor/eject). - Спецификация установщика —
AGENT-INSTALL.md: что пишется/обновляется на диске, как происходит миграция и что принадлежит установщику.
.
├── AGENTS.md # шаблон основного свода правил (always-on контекст после установки)
├── AGENT-INSTALL.md # инструкция установки для ИИ-агентов
├── USER-RULES.md # пользовательские правила (не трогается установщиком)
├── memory.md # память проекта
├── LLM-RULES.md # самоулучшаемые правила агента (пишет только /evolve, с одобрения пользователя)
├── install.ps1 # PowerShell-установщик
├── .cursor-plugin/ # git-каталог Cursor (marketplace.json)
├── .claude-plugin/ # git-каталог Claude Code / OpenCode / Kilo CLI
├── .agents/plugins/ # git-каталог Codex (читает и OpenCode)
├── plugins/1c-rules/ # тонкий marketplace-плагин: skills/hooks + вызов install.ps1
├── .dev.env.example # шаблон параметров проекта
├── adapters/ # адаптеры под инструменты (cursor, claude-code, codex, opencode, kilocode, kimi, qwen, command-code, cline, zcode, mimocode, pi, other)
├── content/
│ ├── rules/ # on-demand правила, подключаемые по задаче
│ ├── agents/ # описания 13 специализированных субагентов
│ ├── commands/ # слэш-команды (doctor, deploy-and-test, initproject, restore-testbase, test-fix-loop, build-release, economymode, sdlc, litemode, previewmode, caveman, rulesmodel, evolve, getconfigfiles, loadfrom1cbase, update1cbase, checkmcp, setupmcp, installtools, installmcp, install-cognee, install-openviking, install-edt-mcp, install-atlassian-mcp, updatemcp, updaterules, checkupdates, support, supportstatus, check-uuid, install-agent-browser, install-windows-mcp, install-rtk, install-officecli)
│ ├── skills/ # SKILL-пакеты (1c-metadata-manage, mermaid-diagrams и др.)
│ ├── openspec-bundle/ # снапшот вывода `openspec init` для каждого инструмента
│ └── mcp-servers.json # каталог MCP-серверов экосистемы 1С
├── openspec/ # OpenSpec-воркспейс (specs/, changes/, project.md)
└── tools/ # вспомогательные скрипты (refresh-openspec-bundle.ps1)
Независимо от канала установки (агент или install.ps1) на диске будет:
AGENTS.md,USER-RULES.md,memory.md,LLM-RULES.md— в корне проекта. Это требование инструментов: Cursor, Claude Code, Codex, OpenCode, Kilo, Kimi, Qwen, Command Code, Cline и Pi читаютAGENTS.mdименно из корня; перенос в.cursor//.claude/отключит загрузку. Для Qwen дополнительно пишется stubQWEN.md→AGENTS.md.- директории активных инструментов (
.cursor/,.claude/,.codex/,.opencode/,.kilo/,.kimi-code/,.qwen/,.commandcode/,.cline/,.zcode/,.mimocode/,.pi/,.ai-agent/) — для каждого детектированного. On-demand правила лежат в каталогеrules/rules-1cадаптера, не дублируются в отдельный «общий» каталог. Особенности MCP: Kilo —.kilo/kilo.json(mcp); Qwen — mergemcpServersв.qwen/settings.json(httpUrl); Command Code / Claude Code — общий.mcp.json; Cline и Pi — проектный MCP не пишется. openspec/— OpenSpec-воркспейс (если ещё не было)..ai-rules.json— манифест с перечнем размещённых файлов, активных инструментов, выбранным каноническим каталогом on-demand правил и версией.
AGENTS.md ссылается на on-demand правила по пути одного канонического каталога (приоритет cursor → claude-code → kilocode → kimi → qwen → command-code → cline → zcode → mimocode → opencode → codex → pi → other; other становится каноном только когда выбран без «реального» инструмента). При установке только под один инструмент в проекте появится ровно одна тулзовая директория плюс AGENTS.md/USER-RULES.md/memory.md/LLM-RULES.md в корне — без дополнительных общих папок.
Если активен ровно один инструмент, агент-установщик не задаёт уточняющих вопросов. PowerShell-fallback дополнительно поддерживает флаги -Tools cursor,claude-code, -NonInteractive, -AssumeYes. Полный протокол и описание манифеста — в AGENT-INSTALL.md.
Подгружаются ИИ-агентом по задаче, когда сценарий совпадает с описанием правила. Входные точки перечислены в AGENTS.md → Additional rules; компаньонов и доменные стандарты подключают роутеры (forms.md, coding-standards.md), профили моделей — AGENTS.md → Active model adaptation. Список ниже — обзор по группам.
coding-standards.md— краткий индекс стандартов кода и ссылок на детальные правила.dev-standards-env.md— параметры.dev.env, операции с ИБ, UI-тесты, модели субагентов, оркестрация и параметры процесса.dev-standards-code-style.md— стиль BSL, метрики качества, запрещённые конструкции, документация API, типографика, комментарии и внутреннее ревью.dev-standards-change-markers.md— маркеры изменения типового кода, нейминг метаданных и выбор типа объекта.dev-standards-architecture.md— архитектурные паттерны, расширения, стандарты платформы, code smells.module-structure.md— канонические шаблоны регионов для общих модулей, модулей объектов и менеджеров, модулей форм; директивы препроцессора; обязательные регионы.forms.md— единая точка входа для задач по управляемым формам; выбирает нужные companion-правила дляForm.xml,Form.Module.bsl, событий, async, reserved names и XML-валидации.form-patterns.md— паттерны раскладки управляемых форм: архетипы (документ / обработка / список / элемент справочника / мастер), нейминг (ГруппаШапка,Отбор[Поле]+Использование), принципы layout и advanced ERP-паттерны.forms-add.md— генерация и доработка форм, включая правила представления (программная модификация типовых форм, размещение элементов, проверка заполнения, команды формы).form-module.md— работа с модулем формы: подключение обработчиков событий вForm.xml, зарезервированные имена свойств (запрет на локальные переменныеПараметрыВыбора,СвязиПараметровВыбора,СписокВыбора,ПараметрыОтбора,ОтборСтрок), данные формы.async-methods.md— практическое руководство поАсинх/Ждать/Обещание(платформа 8.3.18+) с типичными паттернами и ловушками (тихая потеря исключений безЖдать,Асинхв обработчиках событий формы, HTTP-async).extension-patterns.md— паттерны расширений (CFE): типы перехватчиков, правилаПродолжитьВызов, маркеры#Вставка/#Удаление, ограничения заимствованных объектов, антипаттерны.dcs-design.md— правила проектирования отчётов на СКД: выбор типа наборов данных, вычисляемые поля vs ресурсы, параметры и пользовательские настройки, варианты, программный override компоновки, взаимодействие с RLS, чек-лист производительности.dcs-advanced-composition.md— продвинутая программная компоновка СКД: двухпроходная предобработка (фильтрация детальных записей ДО свёртки — скрытие строк/колонок кросс-таба с нулевым итогом, рантайм-подмена набора данных в скомпилированном макете) и прямое выполнение запроса компоновки вместо движка СКД для тяжёлых по памяти отчётов. Подгружать, только когда штатного override изdcs-design.md §5не хватает.bsp-access-rights.md— программная работа с профилями групп доступа БСП:Роли.Роль— ссылка наИдентификаторыОбъектовМетаданных, а не строка (иначе роли молча теряются при записи); роли расширений живут в отдельном справочнике; шаблон создания/обновления профиля, назначение профиля пользователю, API проверки прав, ролей и RLS, антипаттерны (ОбменДанными.Загрузка, правка поставляемого профиля).registers-design.md— проектирование регистров (сведений, накопления, бухгалтерии, расчёта): измерения и ресурсы, периодичность, индексирование, подчинение регистратору, остатки vs обороты, проведение и перепроведение.query-design.md— единая точка входа для работы с запросами; выбирает companions (dev-standards-architecture.md §3, skillquery-writing/query-optimization,anti-patterns).metadata-xml-workarounds.md— типовые ошибки при ручной генерации метаданных XML (отсутствиеLineNumberв табличных частях, опечаткаPagesGroupExtInfo, обязательныйPage.enabled, уникальность UUID).tooling-playbooks.md— пошаговые MCP-плейбуки под типовые задачи (написание кода, ревью, архитектура, исправление ошибок, оптимизация, рефакторинг — включая методику безопасного рефакторинга и обязательный impact-анализ, метаданные XML, формы, интеграции, документация, сравнение версий платформы).mcp-first-search.md— дисциплина MCP-first поиска по исходникам 1С: цепочка приоритетов (граф → code-metadata → нативные инструменты) и обязательная заметка «что было испробовано» перед fallback наGrep/Glob/ поиск файлов по маске / чтение модулей целиком. Приоритет ограниченный, а не запрет: без подключённых MCP-серверов, после промаха настроенного запроса или при устаревшем индексе нативные поиск и чтение применяются сразу (одна строка обоснования).edt-workflow.md— EDT-ветка свода: включается флагомUSE_EDT=trueв.dev.env. Определение формата исходников (выгрузка XML Конфигуратора vs EDT-форматsrc/**/*.mdo) до любых действий с метаданными; правка метаданных в EDT-дереве только через EDT-MCP / интерфейс EDT / подтверждённый цикл export→XML→import (правка*.mdoруками запрещена); синхронизация «модель EDT ↔ диск» (resync_to_disk); маршрутизация между MCP-комплектом 1С и EDT-MCP; валидация средствами EDT вместоverify_xmlдля MDO; один владелец обновления ИБ (update_databaseEDT или/update1cbase); снимки форм, git и связка «ветка ↔ ИБ»; согласие на деструктивные операции не отключать. ПриUSE_EDT=falseправило не применяется и EDT не предлагается.ui-testing-tools.md— порядок путей UI-проверок: QA MCP (1c-qa) в тонком клиенте → веб-клиент (agent-browser, затем встроенный browser MCP) →Windows-MCPтолько для окон вне клиента; перед веб-тестами обязательный preflight с запросом/install-agent-browser, если его нет; запрет самодельного screenshotter/OCR.qa-testclient.md— тест-клиент 1С для QA MCP: сценарии с Windows-MCP и без него, запуск и остановка скриптомqa-testclient.ps1, видимое или скрытое окно и когда оно становится видимым, режим наблюдения, скриншоты ключевых состояний, ловушка лицензии разработчика, подтверждение данных через1c-data-mcp.web-client-driving.md— поведение веб-клиента 1С под любым драйвером (слой надui-testing-tools.md): что искать в a11y-снимке (модальные окна, подтверждения, ошибки, незаполненные обязательные, информационная строка отчёта), одинарный клик выделяет — открывает двойной, раскрытие узлов дерева, скоупинг действий к нужной таблице на форме с несколькими, заполнение полей (ввод по умолчанию, вставка как fallback,Shift+F4, составные типы, чекбокс отбора СКД), навигация по пути метаданныхShift+F11, чтение табличного документа и расшифровка, закрытие форм с проверкой, дисциплина против циклов (максимум 2 попытки, смена метода вместо повтора).model-adaptation.md— адаптация свода под модель, которая его исполняет: какAGENT_MODELиз.dev.envвыбирает профиль, какие написания названий моделей распознаются, что профилю можно менять (длина ответов и отчётов, объём нарратива, глубина планирования, охота к делегированию, самопридуманные перепроверки) и что нельзя (хард-гейты, цепочка валидаторов и её бюджет, MCP-first,templatesearch/recall,CONFUSION, обязательный отчёт), плюс модель-нейтральная база промптинга, действующая всегда.model-opus5.md/model-sonnet5.md/model-fable5.md/model-gpt56.md/model-gpt6.md— профили поведения под Claude Opus 5, Claude Sonnet 5, Claude Fable 5 (Mythos 5), GPT-5.6 и GPT-6 Astra: рекомендации по усилию (effort) и verbosity, стиль отчётов и нарратива, границы автономии, работа с субагентами и памятью, экономный контекст (подгрузка правил по триажу, описанный интерфейс вместо примеров в брифах). Подгружается ровно один — по значениюAGENT_MODEL(переключение:/rulesmodel <модель>).- Профиль GPT-6 Astra учитывает рекомендации OpenAI по навыкам и промптам: заранее определяет завершённый результат, доводит разрешённую работу до него, выбирает навыки по конкретной задаче и читает только нужные ветви документации, сохраняя обязательные гейты.
/rulesmodel astra6выбирает существующий профильgpt6. subagents.md/subagent-pipeline.md— каталог субагентов и формализованный pipeline для делегированных full-cycle задач (без делегирования full-cycle выполняется головным агентом напрямую — «стандартный путь»).subagent-core.md— общие обязательства любого субагента (CONFUSION, MCP-first, гейты метаданных/ИБ/хранилища, цепочка валидаторов, формат Handoff); субагент читает его вместо полного каталога.orchestrator-economy.md— режим экономии оркестратора: включается командой/economymode(пишетORCHESTRATION=economyв.dev.env, действует на весь проект, включая новые чаты; выключение —/economymode off); головной агент делегирует исполнение дешёвым субагентам, оставляя себе решения, спеки и верификацию. Выбор моделей не меняется — модели берутся изSUBAGENT_MODEL_*по ярусу субагента; если они не заданы, команда при включении предложит выбрать (профили по бенчу или свои слаги; сменить позже —/economymode models).getconfigfiles.md— выгрузка объектов метаданных из информационной базы в репозиторий.integrations-add.md— правила для интеграций (HTTP-сервисы, REST, очереди).sdd-integrations.md— правила работы с OpenSpec.support-feedback.md— канал поддержки: команды/support(сообщить о проблеме в MCP-сервере или в правиле),/supportstatus(статус своих обращений и ответы оператора) и/checkupdates(проверка обновлений образов MCP и набора правил, только чтение; проактивно примерно раз в месяц). Если MCP не подключены и в.dev.envнетSUPPORT_KEY, установка / обновление //checkupdatesнапоминают, что правила эффективнее всего работают с MCP-серверами vibecoding1c.ru/mcp_server. Обращение уходит в Yandex Cloud Function, которая пишет его в Yandex Database со статусом «новый»; оператор переводит его в «закрыт» и может приложить ответ. Отправка возможна, только когда в.dev.envзаполнены оба параметраSUPPORT_KEY(приходит с дистрибутивом MCP) иSUPPORT_EMAIL. Правило задаёт порог доказанности, при котором модель сама предлагает завести обращение (дефект в поставке, проверен на фактах, воспроизводится, не лечится на месте), обязательное одобрение человека перед отправкой, лимит на частоту предложений, разграничение с/evolve(локальная поправка поведения против дефекта продукта), учёт тегов образов и гигиену данных (ключи, ПДн и длинные листинги в обращение не попадают).logging-strategy.md— позитивная стратегия логирования: когда писать вЖурналРегистрации, уровни, нейминг событий, структураДанные, запрет на секреты / PII, ротация.locks-and-transactions.md— управляемые блокировки, границы транзакций, фиксированный порядок блокировок, предотвращение взаимных блокировок, режимы блокировок, диагностика через техжурнал.anti-patterns.md— каталог 1С анти-паттернов и рубрика код-ревью.systematic-debugging.md— методика отладки: 4 фазы и быстрый путь для очевидных первопричин (DEBUG_FAST_PATH).verification-policy.md— уровни глубины, quick-fix, promotion triggers и quick-fix gate.verification-gates.md— синтаксис, логика, стиль, impact-анализ и XML-валидация.verification-delivery.md— reproduction, соответствие плану, опциональные review/UI-тесты и итоговый отчёт.project-memory.md— отдельный вход для памяти: приоритет записи Cognee → OpenViking → templates MCP, область поиска по сложности задачи, гейты recall-first и correction-capture, строкаMemory:и локальный fallback. Обычная работа с памятью загружает только это правило иtool-policy.md, без общей MCP-политики 1С и скилла шаблонов.tool-policy.md— общие значенияTOOL_*=auto/off/requiredи проверка фактической доступности инструментов; правила работы с конкретной операцией остаются у её владельца.platform-solutions.md— типичные ловушки платформы и проверенные шаблоны решений (включая фоновые задания из внешней обработки через БСП).
Тринадцать ролей под конкретные задачи: 1c-explorer, 1c-analytic, 1c-planner, 1c-architect, 1c-arch-reviewer, 1c-developer, 1c-metadata-manager, 1c-refactoring, 1c-performance-optimizer, 1c-error-fixer, 1c-tester, 1c-code-reviewer, 1c-doc-writer. Когда какой использовать — описано в content/rules/subagents.md (точка входа из AGENTS.md → Skills and Subagents).
Ревьюеры 1c-code-reviewer и 1c-arch-reviewer отключены, пока модель не задана явно в SUBAGENT_MODEL_ANALYSIS или пользователем для конкретного запуска. Наследование модели клиента и подстановка SUBAGENT_MODEL_CODING их не включают. При отключённом ревьюере запрошенное пользователем ревью выполняет головной агент; MCP-проверка review_1c_code сохраняется. Подробности — content/rules/subagents.md → Reviewer model gate.
Скиллы — это самодостаточные подключаемые модули с собственной документацией и (опционально) скриптами/инструментами. Активный инструмент подхватывает их из своего skills/-каталога. В поставке:
Главный скилл для работы с метаданными конфигурации: создание, редактирование, валидация, удаление объектов, форм, отчётов, макетов, ролей, расширений, баз. Скилл — диспетчер: по ключевым словам задачи он направляет агента в нужный домен и при сложных мутирующих сценариях делегирует работу субагенту 1c-metadata-manager. Все XML-операции выполняются через скрипты в tools/, которые корректно обрабатывают BOM, кодировки, UUID, порядок ChildObjects и кросс-ссылки — то, что легко сломать ручной правкой.
Покрываемые домены:
- Объекты метаданных (
meta-manage.md) — справочники, документы, регистры (сведений, накопления, бухгалтерии, расчёта), перечисления, константы, общие модули, реквизиты, табличные части. - Целостность UUID (
uuid-check.md) — поиск объектов с одинаковым идентификатором в XML-выгрузке (атрибутыuuid, элементыxr:TypeId/xr:ValueId), с опциональной перегенерацией. Запускать после массовой генерации метаданных, ручной правки XML и слияния веток; слэш-команда/check-uuid. - Управляемые формы (
form-manage.md) — создание, редактирование, анализ, валидацияForm.xml, элементов, команд, событий. - Схемы компоновки данных, СКД (
skd-manage.md) — отчёты, наборы данных, запросы СКД. - Табличные документы, MXL (
mxl-manage.md) — макеты, печатные формы, декомпиляция MXL. - Роли и права (
role-manage.md) — права, RLS, разграничение доступа. - Внешние обработки и отчёты (
epf-manage.md) — каркас, сборка, дамп EPF/ERF. - Конфигурации и расширения (
cf-manage.md,cfe-manage.md) — создание, диффы, патчи, регистрация в БСП (bsp-manage.md). - Состояние поддержки (
support-manage.md) — типовые «на замке», снятие с поддержки, включение возможности изменения. Мутирующие скрипты скилла сами отказываются править заблокированный объект поставщика и ведут сюда либо в расширение. - Пакеты XDTO (
xdto-manage.md) — анализ пакета и типов, сборка из XSD, выгрузка схемы, точечная правка, валидация. Для обменов, интеграций и веб-сервисов. - Базы данных (
db-manage.md) — реестр, создание, запуск, загрузка/выгрузка ИБ, DT-бэкапы. - Подсистемы и командный интерфейс (
subsystem-manage.md,interface-manage.md). - Макеты и шаблоны, справка (
template-manage.md,help-manage.md); паттерны БСП — в стандартеdev-standards-architecture(§4) и вmcp-1c-tools/docs/1c-ssl-mcp.md. - Запросы — написание новых (
query-writing.md) и оптимизация (query-optimization.md). - Веб-публикация (
web-manage.md) — публикация/снятие, статус, smoke-тесты для Apache/IIS. Для четырёх Apache-операций есть Python-варианты: publish, info, stop, unpublish. Они используют отдельно установленный совместимый Apache и веб-расширение 1С, работают с локальной публикацией и управляют только собственным подтверждённым процессом. - Распаковка бинарников без платформы 1С — домен в таблице диспетчера указывает на standalone-скилл
v8unpack-cf(skill-localdocs/v8unpack-cf.md— тонкий pointer); извлечение и сборка CF/CFE/EPF через Python-утилитуv8unpack.
Мутации метаданных не «пишутся агентом в XML», а выполняются закрытым набором типизированных операций. Ниже — то, что реально объявлено в скриптах, а не список намерений.
| Что считаем | Сколько |
|---|---|
Инструментов (каталоги tools/1c-*) |
38 |
| Скриптов PowerShell / точек входа Python | 71 / 6 |
Типизированных операций -Operation |
111 |
| Видов метаданных в логической адресации | 48 (99 псевдонимов: русские и английские имена) |
Доменных документов docs/*.md |
24 |
| Регрессионных сценариев приёмки | 37 (PowerShell) + 53 (паритет PowerShell ↔ Python) |
Распределение типизированных операций по инструментам: meta-edit — 47 (реквизиты, табличные части, измерения, ресурсы, значения перечислений, формы, макеты, команды, владельцы, движения, предопределённые элементы), skd-edit — 34 (наборы данных, поля, параметры, настройки, варианты), xdto-edit — 11, cf-edit — 8, interface-edit — 6, subsystem-edit — 5.
Каждая операция валидируется до записи, а после записи meta-edit сам запускает meta-validate — отключить это можно только явным -NoValidate. Мутирующие инструменты отказываются править объект типовой конфигурации «на замке» и ведут в расширение (support-manage.md). По умолчанию инструменты пишут сразу, а _common/Invoke-1CEdit.ps1 -Preview (unified diff и откат) включается только в рискованных кейсах — режим METADATA_PREVIEW=auto, команда /previewmode, разовый показ /previewmode once (docs/edit-preview.md).
1c-repository-manage— работа с хранилищем конфигурации 1С: отчёт о состоянии, история версий, сравнение, захват / получение / помещение / отмена захвата точных списков объектов, выгрузка версии в CF/CFE. Активируется явным признакомREPOSITORY_PATHв.dev.envи распространяет на весь процесс разработки дисциплину «захват до правки, помещение после проверки» (docs/repo-sdlc.md). Пока режим хранилища включён, отключать конфигурацию от хранилища запрещено (/ConfigurationRepositoryUnbindCfgи любой эквивалент) — отказ корректный исход, обход через опустошениеREPOSITORY_PATHтоже запрещён. Все операции — через PowerShell-скриптrepo-ops.ps1, который сам строит XML списка объектов, читает кодировки/Out, ловит ошибки за нулевым кодом возврата и требует двойного подтверждения для-force; ad-hoc строки/ConfigurationRepository*— дефект.mcp-1c-tools— роутер MCP-серверов экосистемы 1С: таблица «потребность → скилл операции» и fallback-цепочка (graph → code-metadata → нативные Grep / Glob / Readпосле ограниченного промаха). Каталог серверов вынесен вdocs/server-catalog.mdи нужен только для незнакомого сервера или дополнительной интеграции. Работа только с памятью использует прямой входproject-memory.md.- Скиллы операций (по одному на типовую операцию, каждый с точными именами аргументов своих инструментов, примерами вызовов в JSON и
allowed-tools):1c-code-search— поиск BSL-кода, структуры модуля, членов контекста;1c-meta-info— факты об объекте метаданных (паспорт, реквизиты, колонки табличных частей, поиск по категории и описанию);1c-impact— использования, цепочки вызовов, влияние изменений, слои расширений;1c-form-inspect— чтение форм, артефактов, XSD и спецификаций форматов;1c-validate— цепочка валидаторовsyntaxcheck_file → check_1c_code → review_1c_codeиverify_xmlв бюджете политики;1c-platform-help— справка платформы, проверка платформенной возможности, БСП, стандарты, ИТС;1c-templates-memory— шаблоны как база и память проекта;1c-live-ib— запросы и фрагменты в живой ИБ, последняя ошибка журнала. Как сервер отвечает — так агент действует: таблица «ответ сервера → действие» вcontent/rules/mcp-policy.md. caveman— стиль общения: краткие рабочие ответы на русском, без лишнего объяснения. По умолчанию (.dev.envCAVEMAN=auto) включён на задачах разработки (реализация, отладка, деплой) и выключен на ревью / анализе / аудите / документации, где результатом является читаемый текст;CAVEMAN=onвключает его на всех задачах;CAVEMAN=offотключает автоактивацию полностью. Явные команды/cavemanработают в любом режиме.img-grid-analysis— наложение пронумерованной сетки на изображение для определения пропорций колонок. Используется при генерации MXL-макетов из скриншотов или сканов печатных форм; даёт коэффициенты ширины колонок для JSON-DSL компилятора.mermaid-diagrams— практическое руководство по диаграммам Mermaid, совместимым с большинством рендереров (плюс ASCII-сайдкары для просмотра в чистом Markdown).powershell-windows— правила скриптинга в Windows PowerShell (разделители команд, кавычки путей, заменыcurl/timeout/&&, Docker, HTTP, JSON). Подгружается, когда правила выполняют shell-команды на Windows.md-to-docx— конвертация Markdown в Word-документ (.docx) c сохранением заголовков, таблиц, списков, кода, ссылок и инлайн-изображений. Требует Node.js и пакетdocx.prompt-enhancer— превращение короткой неструктурированной заметки или ТЗ в подробную императивную постановку с пронумерованными шагами анализа, явными граничными случаями и фиксированным форматом вывода. Сохраняет термины и не добавляет новых требований.transcribe— транскрибация аудио и видео через Gemini 2.5 Flash API: дословная расшифровка с таймкодами, опциональное саммари, режим--analyze-uiдля разбора экранного интерфейса со скриншотами. Требует Python, ffmpeg иGEMINI_API_KEY.handoff— сжимает текущий разговор в самодостаточный handoff-документ для следующей сессии (новый чат, другая машина, другой ИИ-клиент). Не дублирует durable-артефакты (openspec/,memory.md, коммиты, заметки в1c-templates-mcp), а ссылается на них. Дефолтный путь —handoffs/handoff-<timestamp>.mdв корне проекта./resume [путь или тема]выбирает актуальную передачу контекста, сверяет рабочую копию и продолжает разрешённую задачу с незавершённого шага. Адаптировано изmattpocock/skills.1c-qa-testing— проверка функционала в тонком клиенте через QA MCP (qa_*/ui_*): сеанс, цикл «прочитать окно → действие → изменения → проверка», поведение платформы 8.3.27, неизвестный исход, журнал проверки и вердикты по шагам. Основной путь UI-проверок, когда сервер подключён; скриптscripts/qa-testclient.ps1запускает, снимает и закрывает тест-клиент.1c-ui-regression— сохраняемые UI-тесты с проверками результата и отчётом, запускаемые без агента через проверенный runner проекта. Модель выбирает навык по полезности повторного прогона; политикаUI_TESTINGсохраняется.1c-business-tests— сохраняемые тесты расчётов, запросов и бизнес-логики: ожидаемые результаты, тестовые данные, запуск и очистка через разрешённый процесс. Необязательный навык на усмотрение модели; дополняет целевые проверки Gate 3a.1c-change-package— изменение, которое вносит или проверяет человек, а не агент: пакет ручного внесения для Конфигуратора (пары «Найти» / «Заменить целиком на», таблицы реквизитов и элементов формы, проверка после внесения, откат) или ревью-дифф с таблицей «Сейчас / Предлагается». Для объектов на замке, бинарных форм, чужой блокировки в хранилище и доступа только через MCP. Идея изAzeevAN/mcp-1c(Apache-2.0).v8unpack-cf— распаковка и сборка бинарных файлов 1С (CF / CFE / EPF) в человекочитаемые исходники (JSON + BSL) через Python-утилитуv8unpackбез платформы 1С. Используется, когда на руках только бинарник, а инфобазы / Конфигуратора /ibcmdнет; для выгрузки из работающей инфобазы через платформу — правилоgetconfigfiles. Требует Python и пакетv8unpack.
Если серверы уже установлены, запустите /setupmcp в новом репозитории. Команда запросит адреса MCP и имеющейся памяти (Cognee, OpenViking или templates MCP), настроит подключения текущего клиента для этого проекта и проверит область индексов и памяти. Существующие серверы переустанавливать не нужно. Для первой установки — /installmcp, для проверки подключений — /checkmcp.
Обычный вариант — локальные MCP. Для коллективной разработки дополнительно можно выбрать общий сервер Debian/Ubuntu с Docker Engine и Compose: локальные Docker Desktop и WSL на компьютерах разработчиков не требуются. Установка предлагает DNS/IP сервера вместо 127.0.0.1; агент сам проверяет свободные порты на сервере, выбирает их для новых сервисов и сохраняет в параметрах запуска и подключениях клиентов. Готовые подключения и последующие обновления сохраняют выбранные адреса и порты. Общие правила размещения — mcp-deployment.
Правила рассчитаны на работу совместно с пакетом MCP-серверов от vibecoding1c.ru/mcp_server (Docker-контейнеры с HTTP-подключением). Все серверы опциональны: правила содержат graceful fallback, если конкретный MCP не поднят. Каталог идентификаторов и примерных локальных адресов — в content/mcp-servers.json; фактические адреса берутся из настроенных подключений. Маршрутизация — роутер mcp-1c-tools (content/skills/mcp-1c-tools/SKILL.md), точные аргументы и примеры вызовов — скиллы операций 1c-* (см. выше), редкие режимы — docs/<server>.md; плейбуки под типовые задачи — в content/rules/tooling-playbooks.md.
Основной инструмент для глубокого анализа конфигурации. Метаданные индексируются как граф связей, что даёт многоуровневый impact-анализ и понимание архитектуры в терминах бизнес-сущностей.
get_object_dossier— полное «досье» объекта одним вызовом: реквизиты, табличные части, измерения/ресурсы, формы, подписки, роли, зависимости (USED_IN, движения регистров), модули с сигнатурами процедур, бизнес-описание.trace_impact— рекурсивный impact-анализ глубиной 1–10 поUSED_IN/DO_MOVEMENTS_IN/CALLS. «Если изменю X — что ещё затронет?» Используется перед рефакторингом.trace_call_chain— рекурсивный обход графа вызовов BSL (callees / callers, глубина 1–10), с дизамбигуацией одноимённых процедур по объекту-владельцу.search_code— поиск по коду конфигурации:fulltext(Lucene),semantic(по смыслу),hybrid. Уровни детализации L0–L3 (от полного кода процедуры до минимальных карточек) для управления токенами.search_metadata— JSON-шаблоны Cypher-запросов (детерминированные) или NL → Cypher: списки атрибутов, объектов категории, форм, значений перечислений, измерений и т.д.search_metadata_by_description— Lucene-fulltext + опционально вектор поСиноним/Комментарий/Описание/Справка.business_search/answer_metadata_question— семантический поиск по бизнес-описаниям и Q&A на естественном языке.find_objects_using_object/find_usages_of_object/find_register_movement_docs/resolve_qualified_name/find_by_guid/compare_base_and_extension— точечные обходы графа.
Базовый «индекс» конфигурации (используется как fallback к графовому MCP).
- Метаданные:
metadatasearch(FTS/семантика, режимnames_onlyдля компактных списков),get_metadata_details(полная структура объекта по имени). - Код:
codesearch(гибридный поиск),search_function(структурный FTS-индекс по процедурам/функциям с экзакт+fuzzy),get_module_structure(содержимое модуля),get_method_call_hierarchy(плоский call-граф),graph_dependencies(плоские зависимости forward/reverse),bsl_scope_members(доступные методы/свойства/события для BSL-контекста). - Формы:
search_forms(поиск форм по элементам, реквизитам, командам),inspect_form_layout(полное дерево формы — иерархия элементов, привязки, обработчики). - XSD и валидация:
get_xsd_schema(XSD подСправочник,Документ,РегистрСведенийи пр., в т.ч. подобъектыФорма/СКД/Макет) иverify_xml(валидация XML-строки против XSD). - Справка:
helpsearch(поиск по HTML-справке). - Администрирование:
reindex,stats.
Проверка кода через BSL Language Server. По умолчанию используется syntaxcheck_file — проверка сохранённого файла по пути (при необходимости с фильтром по строкам): она стоит пути вместо целого тела модуля и не требует читать модуль в контекст. syntaxcheck с текстом кода остаётся для случаев, когда файловый инструмент не подключён (нужен смонтированный каталог исходников) или у кода ещё нет файла — только что сгенерированный фрагмент.
Бюджет общий на оба инструмента — 1 вызов на цикл по умолчанию; до 3 только тогда, когда предыдущий запуск нашёл содержательный дефект. После лимита исправляются содержательные ошибки, остаточный стилевой шум не запускает новый цикл.
Три межмодульные проверки (UnresolvedMethodCall, UnresolvedField, QueryToMissingMetadata) по умолчанию выключены: одиночный модуль не видит остальную конфигурацию. В образе есть необязательный режим полной проверки (FULLINDEX=true при смонтированном каталоге исходников): контейнер индексирует конфигурацию и дополнительно отвечает на эти три из индекса — но только в syntaxcheck_file. Без индекса сервер работает штатно: это обычная конфигурация, а не ущербная — просто трёх межмодульных проверок не будет. Индексация реальной конфигурации идёт часами, и всё это время контейнер отвечает на вызовы, так что ждать её не нужно. Состояние индекса приходит в каждом ответе как provenance.index (absent / building / ready / failed), и правила требуют читать его прежде, чем считать чистый отчёт доказательством разрешимости межмодульных ссылок.
templatesearch— гибридный поиск (вектор + fulltext) по библиотеке из 2000+ шаблонов и архитектурных паттернов 1С. Вызывается до написания кода.remember— сохранение проектного факта/корректировки/нетривиального решения в векторную память (одна самодостаточная заметка на запись, на английском, с сохранением оригинальных имён объектов/модулей 1С).recall— векторный поиск по сохранённым заметкам. Используется в начале нетривиальной задачи с ключевыми терминами (имя объекта, подсистема, текст ошибки).
Поиск в этой памяти выполняется и при подключённых Cognee / OpenViking. Новые заметки записываются сюда, когда оба основных провайдера недоступны для записи. Маршрутизация — content/rules/project-memory.md.
Установка доступна через /installtools, отдельно — /install-cognee и /install-openviking. Среди разрешённых провайдеров записи получает Cognee, затем OpenViking, затем templates MCP. Полный цикл ищет по всем доступным хранилищам, quick-fix — сначала по первому доступному для чтения. Одной успешной записи достаточно; при отсутствии записи заметка временно сохраняется в memory.md.
Если ни один MCP внешней памяти не настроен, агент один раз за сессию напоминает об установке и рекомендует Cognee через /install-cognee. Напоминание учитывает TOOL_*=off, не запускает установку и не прерывает независимую работу. Сбой уже настроенного сервера обрабатывается как проблема подключения.
В .dev.env для памяти, MCP 1С, EDT и браузеров добавлены настройки TOOL_*: auto — использовать доступный инструмент с предусмотренным fallback; off — не использовать и не предлагать установку; required — отсутствие нужной возможности блокирует зависимый этап. Например, TOOL_COGNEE=off исключает Cognee, а TOOL_SYNTAX=required требует доступного синтаксического валидатора. Флаг задаёт политику агента, а не техническую блокировку MCP: наличие инструментов в сессии, права и актуальность контекста проверяются отдельно. Пропущенные проверки не становятся успешными. При обновлении установщик добавляет отсутствующие ключи со значением auto, сохраняя прежние настройки. Полный перечень — Tool policy.
Инструкции: Cognee, OpenViking; инструменты и параметры — content/skills/mcp-1c-tools/docs/memory-providers.md.
Команда /install-atlassian-mcp настраивает mcp-atlassian для Jira, Confluence или обоих сервисов. Доступна также пунктом 8 в /installtools. Поддерживаются Cloud и Server/Data Center; по умолчанию используется uvx, при выборе пользователя — Docker.
Токены хранятся в отдельном локальном .env вне репозитория. Новое подключение по умолчанию работает только на чтение; операции записи включаются по запросу. Команда сохраняет остальные MCP-подключения и проверяет доступ чтением данных после перезапуска клиента.
ssl_search — поиск стандартных функций БСП (любой версии) по точному имени и по семантике. Перед написанием новой служебной процедуры агент проверяет, нет ли готовой в БСП, чтобы «не изобретать велосипед».
Поиск по официальной справке конкретной версии платформы — критично, потому что сигнатуры и поведение меняются между версиями. Плюс две коллекции, которые читаются целиком и поэтому имеют собственные инструменты.
docinfo— точечный поиск по известному имени объекта/метода (ТаблицаЗначений,Массив.Найти,Запрос).docsearch— гибридный (вектор + BM25) поиск по описанию, когда точное имя неизвестно.standards— детальные стандарты разработки этого набора правил (коллекция1c-standards):standards(name="anti-patterns")вернёт правило целиком,standards(query="…")ищет по стандартам,standards()отдаёт каталог.formatspec— спецификации файловых форматов конфигурации (формы, роли, СКД, MXL, расширения) — тем же способом.
Четырнадцать правил в content/rules/ (anti-patterns, dev-standards-architecture, dev-standards-code-style, platform-solutions, locks-and-transactions, systematic-debugging и др.) хранят только заголовки; их нормативный текст лежит в коллекции 1c-standards и достаётся инструментом standards. Заголовки сохранены целиком, поэтому все ссылки вида <файл>.md §N → "Раздел" продолжают резолвиться.
Практика:
- Коллекция входит в образ
comol/1c_help_mcp— отдельно монтировать или индексировать её не нужно. Если в схеме сессии нет инструментаstandards, образ устарел: обновите его (/checkmcp). - Тела стандартов редактируются в репозитории MCP-сервера (
data/corpora/1c-standards/content/standards/<имя>.md), а не здесь: в этом репозитории от каждого стандарта остался только роутер с деревом заголовков. Совпадение деревьев проверяетtools\validate-rules.ps1 -StandardsDir <путь>. - Обращаться к стандартам через
docsearch/docinfoнельзя — они видят только справку платформы; параметраcorpusнет ни у одного инструмента сервера. - Сервер необязательный. Если он не поднят, агент один раз сообщает об этом, работает по тем правилам, что остались встроенными, и пишет строку в раздел Риски итогового отчёта. Жёсткие гейты проверки (
verification-gates.md) при этом работают по своим собственным правилам деградации. - Контракт получения целиком —
content/rules/help-corpus-retrieval.md.
Кроме проверки сигнатур, сервер закрывает проверку платформенных механизмов: перед самописной реализацией специализированной возможности (криптография, СЛАУ и численные методы, анализ данных, система взаимодействия и боты, шина/очереди сообщений, полнотекстовый поиск, регулярные выражения и т.п.) агент обязан спросить справку — есть ли готовый механизм в платформе (docsearch по описанию → docinfo по найденным именам, плюс ssl_search для БСП). Память модели не считается доказательством отсутствия механизма (канон — AGENTS.md → MCP Tool Calling → A.7).
Доступ к коммерческому сервису 1С:Напарник в роли субагента + поиск по ИТС.
- Анализ кода:
check_1c_code(синтаксис, логика, производительность),review_1c_code(стиль, стандарты ИТС, нейминг, структура),rewrite_1c_code/modify_1c_code(переписывание/целевые правки),ask_1c_ai(свободный диалог с сохранением контекста). - Документация и база знаний:
search_1c_documentation(документация под конкретную версию платформы),onec_help(актуальная справка),its_help→fetch_its(поиск по ИТС-стандартам с обязательным дочитыванием полной статьи),diff_1c_documentation_versions(диффы между версиями платформы),config_help(документация по конкретным конфигурациям — ERP, БП, ЗУП, УТ).
Бюджет check_1c_code / review_1c_code такой же: 1 вызов каждого валидатора на цикл по умолчанию, до 3 только после содержательного дефекта. Output AI-инструментов всегда перепроверяется через syntaxcheck + check_1c_code + review_1c_code перед сдачей кода.
Не входит в комплект MCP выше и ставится внутрь самой EDT: плагин DitriXNew/EDT-MCP, команда установки — /install-edt-mcp (или пункт EDT-MCP в /installtools). Появляется только в проектах, которые ведутся в EDT (USE_EDT=true в .dev.env), при запущенной EDT с открытым рабочим пространством.
- Что даёт: текущее состояние проверок EDT (
revalidate_objects,get_project_errors,get_problem_summary,apply_quick_fix), точные ссылки и переходы (find_references,go_to_definition,get_content_assist), работа с метаданными и модулями в EDT-формате (create_metadata,modify_metadata,write_module_source,adopt_metadata_object), снимки форм, обновление ИБ (update_database), отладка и профилирование, git с привязкой «ветка ↔ ИБ». - Чего не заменяет: индексный поиск, impact-анализ, справку платформы, БСП, ИТС, шаблоны, память проекта и BSL-валидаторы — это по-прежнему комплект MCP выше.
- Правила работы —
content/rules/edt-workflow.md, каталог инструментов и маршрутизация —content/skills/mcp-1c-tools/docs/edt-mcp.md. Деструктивные операции (delete_metadata,rename_metadata_object,delete_project,delete_infobase,update_database, смена типа черезmodify_metadata) по умолчанию требуют подтверждения — правила запрещают отключать это за пользователя.
OfficeCLI создаёт, читает и редактирует .docx, .xlsx и .pptx без Microsoft Office. Установка для Windows, macOS и Linux — через /install-officecli или пункт 9 в /installtools. Команда /install-officecli status только проверяет наличие и версию. Нативный установщик также добавляет навык OfficeCLI для обнаруженных AI-клиентов; подключение MCP для работы через CLI не требуется.
Жёсткие гейты AGENTS.md зарегистрированы в tools/tests/gate-scenarios.json вместе с приёмочными сценариями, которые их проверяют: задача по-русски, ожидаемая цепочка MCP-вызовов с аргументами, запрещённые вызовы, порядок «MCP раньше нативного инструмента», класс ответа (ok / refused) и критерий оценки. tools/validate-rules.ps1 проверяет реестр против AGENTS.md и корпуса: заголовок гейта должен существовать в AGENTS.md, у каждого гейта должен быть хотя бы один сценарий, каждый сценарий должен ссылаться на известный гейт, а каждый инструмент из цепочки должен быть описан в каком-нибудь скилле. Гейт без сценария — ошибка валидации: либо добавляется сценарий, либо гейт снимается.
tools/render-gate-evals.ps1 превращает корпус в самодостаточный eval-плагин Claude Code (по умолчанию в tools/tests/evals). claude plugin eval запускает каждый кейс в пустой песочнице, где не загружаются ни CLAUDE.md / AGENTS.md, ни .mcp.json проекта. Поэтому рендерер ставит свод правил через install.ps1 в workspace/, копирует его в песочницу скриптом scaffold.sh, передаёт AGENTS.md через append_system_prompt и объявляет MCP-серверы в самом плагине: их инструменты называются mcp__plugin_gates_<сервер>__<инструмент>. Установленные агенты, skills и команды свода тоже становятся компонентами плагина, иначе прогон их не увидит. Граф, индекс кода, синтаксис, Напарник и память заменены агентными заглушками из tools/tests/eval-mocks/ — сохранённый tools/list настоящего сервера плюс инструкция, изображающая типовую УТ 11.5. Это делает прогон повторяемым и не пишет в настоящую память проекта. Исходники для сценариев правки кода лежат в tools/tests/eval-fixtures/: common/ попадает в каждый кейс, <ID сценария>/ накладывается поверх для одного кейса; все заглушки описывают одну и ту же конфигурацию (ERP 2.5 с этими модулями) через tools/tests/eval-mocks/_world.md, поэтому граф, индекс кода и файлы не противоречат друг другу. Справка платформы и БСП идут в живые серверы. Провайдеры памяти из opt_in_servers доступны только кейсам, которые их называют. Поле сценария mocks сужает инструменты сервера (tools), превращает вызов в отказ (errors) или в фиксированный ответ (answers); env записывает в .dev.env значения из условия задачи; fixtures добавляет наборы файлов из tools/tests/eval-fixtures/sets/. Команда запуска печатается после рендера: claude plugin eval tools/tests/evals --eval-dir cases --scaffold --allow-real-servers --trust-plugin --allow-tools Write Edit "mcp__plugin_gates_1C-docs-mcp__*" "mcp__plugin_gates_1c-ssl-mcp__*". На Windows песочницы для shell нет, поэтому набор не выдаёт Bash / PowerShell, и сценарии, которым нужен shell, честнее гонять под WSL2. Корпус — единственный источник правды; сгенерированные кейсы не редактируются вручную. Сценарий может задать max_turns, шаг цепочки — max (сколько раз вызов допустим); LLM-судья оценивает финальный ответ, а какие инструменты вызывались и в каком порядке, проверяют структурные грейдеры; грейдер порядка не считает нативным поиском чтение правил и .dev.env. Ограничения стенда: фикстуры — частичная выгрузка без XML метаданных, поэтому сценарии мутации метаданных упираются в отсутствие файлов; встроенного браузера и shell в прогоне нет; tool_order падает, если нативный инструмент не вызывался вовсе; оценка LLM-судьи — ориентир, спорные случаи сверяются по трассе (--keep-temp). CI рендерит корпус на каждом push, чтобы корпус и рендерер не разошлись; сами кейсы гоняются вручную перед релизом (полный прогон 46 кейсов — около $20).
tools/validate-rules.ps1 также держит бюджеты загрузки: AGENTS.md — не больше 11 КиБ, одно правило — не больше 40 КиБ, типовой набор full-cycle задачи на BSL — не больше 124 КиБ, стартовый контекст субагента (AGENTS.md + subagent-core.md + его промпт) — не больше 28 КиБ. Описания во frontmatter тоже попадают в каждую сессию (хосты перечисляют skills и агентов, Cursor — ещё и правила), поэтому они ограничены: skill — 300 байт, агент и правило — 250 байт. Рост любого из бюджетов — осознанное решение, а не дрейф. Служебные команды (установка, обновление, переключатели режимов) помечены userOnly: true: в Claude Code адаптер превращает это в disable-model-invocation, их описания не занимают контекст модели, и вызываются они только вручную через /. Наблюдения, из которых выросли отдельные правила, лежат в tools/rules-rationale.md и в контекст агента не попадают.
Установщик безусловно разворачивает OpenSpec-воркспейс (openspec/) с режимом «не перезаписывать существующее». Слэш-команды /opsx:propose, /opsx:apply, /opsx:archive, /opsx:explore, /opsx:sync, /opsx:update разворачиваются автоматически для каждого активного инструмента из набора cursor, claude-code, codex, opencode, kilocode (бандлы — в content/openspec-bundle/<tool>/). Особенность Codex: его бандл содержит только SKILL-пакеты OpenSpec (.codex/skills/openspec-*), без слэш-команд — workflow вызывается через скиллы напрямую. Для kimi, qwen, command-code, cline, zcode, mimocode, pi и other тулз-специфичного OpenSpec-бандла нет — работайте напрямую с openspec/specs/ и openspec/changes/ (или через установленные OpenSpec skills, где они есть). Подробности — в openspec/README.md.
- vibecoding1c.ru — портал по вайбкодингу для 1С: курсы, бенчмарк моделей, статьи, продукты для разработки 1С с ИИ.
- vibecoding1c.ru/mcp_server — пакет MCP-серверов для 1С, под который заточены правила и плейбуки этого репозитория.
- Telegram-канал «IT Does Matter» — обсуждение вайбкодинга для 1С, MCP, ИИ-агентов, практик и обновлений.
Никакой лицензии, берите и используйте как хотите