• — обязательный параметр; относительный или абсолютный путь (допускается формат@docs/... ).
• --lang — вариант языка рецензента; по умолчанию — auto (определяется по проекту).
• --scope — ограничивает выводимые шаги; по умолчанию — all.
• --dry-run — выводить только разбивку на этапы и обоснование цепочки; не выводить итоговые запросы.

Авторитетная форма /orchestrate (не отклоняться)

{ORCH_CMD} custom ",,...," ""

Где {ORCH_CMD} определяется на Фазе 0 (см. ниже). Строка команды в генерируемом выводе всегда использует одну конкретную форму — никогда обе, никогда заменяющий символ.

• custom представляет собой последовательную цепочку; HANDOFF каждого агента передаёт данные следующему.
• Список агентов, разделенный запятыми. Предпочтительно без пробелов; допускается один пробел.
• Флагов --mode / --gate / --agents=... не существует — никогда их не придумывайте.
• Имена агентов берутся из каталога данного навыка. Встроенные двойные кавычки в описании задачи экранируются как \".

Формат установки ECC и пространство имён

Две формы установки определяют префикс как для команды со слэшем, так и для каждого имени агента. Эти две формы ДОЛЖНЫ оставаться синхронизированными — по одной форме на каждый вывод, смешивать их нельзя:

Пусть обозначим домашний каталог Claude Code: ~/.claude в macOS/Linux, %USERPROFILE%\.claude в Windows. Определяйте его так, как хост-платформа определяет домашний каталог пользователя (не используйте жесткую кодировку ~).

Почему это важно: при установке через плагин агенты регистрируются как everything-claude-code:tdd-guide. Имена без префикса вынуждают систему использовать неточное сопоставление, что при параллельных вызовах периодически приводит к сбоям. В устаревшей версии формы с префиксом не регистрируются и сразу же завершаются сбоем.

Доступный каталог агентов (необходимо выбрать из перечисленных)

Общие:

• планировщик — переформулировка требований, декомпозиция рисков, планирование этапов
• architect — архитектура, проектирование системы, предложения по рефакторингу
• tdd-guide — написание тестов → реализация → покрытие 80%+
• рецензент кода — общий рецензирование кода
• рецензент по безопасности — аудит безопасности, OWASP, утечка секретной информации
• рефакторинг-очиститель — мёртвый код, дубликаты, очистка классов Knip
• doc-updater — документация, карта кода, README
• docs-lookup — поиск API сторонних библиотек (Context7)
• e2e-runner — оркестрация сквозных тестов
• database-reviewer — схема PostgreSQL, миграция, производительность
• harness-optimizer — настройка локального агента
• loop-operator — автономные циклы длительного выполнения
• chief-of-staff — многоканальная сортировка (редко подходит для этапов плана)

Средства устранения ошибок сборки:

• build-error-resolver (общий) / cpp-build-resolver / go-build-resolver / java-build-resolver / kotlin-build-resolver / rust-build-resolver / pytorch-build-resolver

Рецензенты кода:

• python-reviewer / typescript-reviewer / go-reviewer / rust-reviewer / cpp-reviewer / java-reviewer / kotlin-reviewer / flutter-reviewer

Неправильно написанное имя агента приводит к сбою /orchestrate. Перед отправкой сверьте с этим списком.

Как это работает

Этап 0 — Определение режима ECC и языка

1. Считать . Если отсутствует или пусто, сообщить об этом и остановиться.

2. Определить форму установки ECC один раз и зафиксировать её в ECC_MODE. Алгоритм (выполнять по порядку, остановиться при первом совпадении):

   1. Если существует /plugins/marketplaces/everything-claude-code/ → ECC_MODE=plugin.
   2. В противном случае, если существует каталог/agents/ и он содержит хотя бы один файл агента ECC (например, tdd-guide.md, code-reviewer.md) → ECC_MODE=legacy.
   3. В противном случае → по умолчанию устанавливается ECC_MODE=legacy и в начале вывода выводится однострочное предупреждение: > Предупреждение: не удалось обнаружить установку ECC; используется форма legacy по умолчанию. Если вы используете установку плагина, отредактируйте префиксы вручную.
   4. Если присутствуют оба маркера (смешанная установка), приоритет имеет плагин — только пространство имён плагина разрешает имена агентов без нестрогого сопоставления.

   С этого момента в каждой выводимой строке используется соответствующий префикс как в команде со слешем, так и в каждом имени агента. Никогда не выводите обе формы в одном выводе.

3. Определите --lang. При значении «auto» выполните определение с учётом поддержки нескольких языков:

   • Проверка маркеров: pyproject.toml / uv.lock / requirements.txt → python; package.json → typescript; go.mod → go; Cargo.toml → rust; CMakeLists.txt или файлы *.cpp верхнего уровня → cpp; pom.xml / build.gradle (Java) → java; build.gradle.kts или Kotlin верхнего уровня → kotlin; pubspec.yaml → flutter.
   • Разрешение ничьей при наличии нескольких языков: если совпадает более одного маркера, выбирается тот язык, исходных файлов которого больше, чем других (подсчёт производится с помощью команды git ls-files, исключая папки vendor/, node_modules/, dist/, build/, .venv/, сгенерированные файлы и очевидные тестовые фикстуры). В случае равенства или если ни один язык не превышает 60 % исходных файлов, установите lang=unknown.
   • Если ни один маркер не совпал → установите lang=unknown.
   • lang=unknown является индикатором — это не имя агента. Правила 4 и 5 фазы 2 преобразуют его в рецензента кода / решателя ошибок сборки во время формирования цепочки.

4. Обнаружение подпрофиля PyTorch: если lang=python и в любом из файлов pyproject.toml / requirements.txt / uv.lock заявлена зависимость от torch, установите pytorch=true. Это влияет только на выбор цепочки сборки (правило фазы 2 ниже); рецензентом по-прежнему остаётся python-reviewer.

5. Нормализовать все имена агентов, объявленные в плане: если в тексте плана агенты упоминаются в форме с префиксом плагина (например, everything-claude-code:tdd-guide), удалите префикс, чтобы получить чистое имя из каталога, прежде чем проверять или составлять цепочки. Повторное добавление префикса происходит только на этапе вывода в соответствии с ECC_MODE (фаза 4). Ни в коем случае не допускайте попадания имени с предварительно добавленным префиксом в состав цепочки — в режиме плагина это приведет к двойному префиксу.

Фаза 1 — Разбиение шагов

Определите «единицы шагов» в порядке приоритета:

1. Явная нумерация: ## Шаг N / ### Фаза N / ## N. ... / упорядоченный список верхнего уровня.
2. Колонка «Шаг» в таблице.
3. ----разделенные блоки с заголовками, начинающимися с глагола.
4. В противном случае каждый заголовок H2 рассматривается как один шаг.

Для каждого шага извлеките идентификатор (начиная с 1), заголовок (≤ 80 символов), цель (1–3 предложения), теги.

Этап 2 — Теги и цепочка выбора

Помечайте тегами по замыслу (допускается использование нескольких тегов; цепочка формируется из основного тега и наборных вторичных тегов):

При сопоставлении приведенных ниже триггерных слов не учитывается регистр. Поддерживаются многоязычные планы путем сопоставления корней слов на любом языке, при условии что их значение соответствует перечисленным английским триггерным словам.

Правила составления цепочек:

1. Выбор основного тега: когда шаг соответствует нескольким тегам, основным считается первый в порядке таблицы (верх таблицы = наивысший приоритет); остальные являются второстепенными. Правила компоновки 2 и 3 ниже явно обрабатывают конкретные комбинации нескольких тегов; в противном случае второстепенные цепочки добавляются в порядке таблицы тегов.
2. impl + security → tdd-guide,-reviewer,security-reviewer.
3. impl + db → tdd-guide,database-reviewer,-reviewer.
4. Удалите дубликаты из полученной цепочки (сохраните первое вхождение). Например, review + lang=unknown даст code-reviewer,code-reviewer после применения правила 5; удаление дубликатов сводит результат к code-reviewer.
5. -reviewer преобразуется в code-reviewer, если lang=unknown.
6. -build-resolver преобразуется в build-error-resolver, когда lang=unknown. Особый случай: если на этапе 0 установлено pytorch=true, для цепочек сборки следует использовать pytorch-build-resolver независимо от . Python-build-resolver отсутствует; --lang=python без pytorch=true преобразуется в build-error-resolver.
7. Шаги с нулевым тегом: если ни одно триггерное слово не совпадает, установите цепочку на code-reviewer и запишите «тег не найден»; по умолчанию используется цепочка «только ревью » в соответствии с «Обоснованием цепочки».
8. Длина цепочки ≤ 4 после удаления дубликатов. Если превышена, удалите самый слабый тег (сначалапоиск и документация ).
9. Не объединяйте планировщика и архитектора в цепочке impl (растрата токенов). Объединяйте их только на этапах проектирования.
10. Шаги с тегами «impl», «refactor» или «migration» заканчиваются агентом класса «reviewer » — любым из следующих: «-reviewer», «code-reviewer», «security-reviewer» или «database-reviewer». Рецензент, наиболее специализированный в данной области, занимает конечную позицию (например, «impl+security» по правилу 2 заканчивается на «security-reviewer»; «impl+db» по правилу 3 заканчивается на «-reviewer», поскольку «database-reviewer» уже контролирует этап «migration» ранее в цепочке). Этапы тестирования и сборки контролируются собственными валидаторами (соответственноe2e-runner и build resolver) и не требуют дополнительного рецензента.

Этап 3 — Сжатие описания задачи

Каждое выданное должно:

• быть самодостаточным (первому агенту не нужно, чтобы документ с планом был открыт).
• Начинаться со строки [Plan: #step-].
• Включать 1–3 проверяемых критерия приемки.
• Содержать ограничение области действия (Вне области действия: ...) только в том случае, если план объявляет его для данного шага. Перенимать дословно. Если в плане отсутствует заявление о выходе за пределы области действия, полностью опустить это предложение — не придумывать его.
• Объём — 200–600 символов; одна строка; встроенные символы «» экранируются как \; без буквальных символов новой строки.

Этап 4 — Вывод

Выведите Markdown, используя формат, определяемый ECC_MODE. Вывод использует одну форму на протяжении всего текста — каждый {ORCH_CMD} и каждое имя агента отображаются с соответствующим префиксом из этапа 0. Не выводите обе формы; не включайте инструкции «это форма плагина» / «удалить префикс» в отображаемый вывод.

Конкретные правила отображения:

• {ORCH_CMD} = /everything-claude-code:orchestrate в версии plugin, /orchestrate в версии legacy.
• {AGENT(name)} = everything-claude-code: в версии с плагином, в legacy.
• В столбце «Chain» таблицы обзора используется тот же формат отображения {AGENT(name)}.
• Блоки bash для каждого шага содержат только исполняемую команду. Комментарии в формате # plugin form или # legacy form отсутствуют — формат подразумевается и является единообразным во всём выводе.

Структура вывода:

# Plan-Orchestrate Результат

**План**: ``
**Язык**: ``
**Режим ECC**: ``
**Шаги**: 
**Область действия**: 

## Обзор шагов

| # | Название | Теги | Цепочка |
|---|---|---|---|
| 1 | ... | impl, db | `{AGENT(tdd-guide)},{AGENT(database-reviewer)},{AGENT(python-reviewer)}` |
| ... | | | |

---

## Шаг 1 —