Тонкий оркестрационный скилл для больших или рискованных задач: код и миграции, аудиты, research, документы, данные, дизайн, инфраструктура. Это не обязательный пайплайн, а набор режимов и инвариантов: direct / paired critic / swarm.

Вызов

/agent-swarm <задача>

или просто опишите задачу — скилл подключится по описанию.

Режимы

Режим	Когда	Что добавляет
Direct	одна задача, быстрый фидбек, низкий риск	ничего
Paired critic	средняя задача или рискованное решение	независимую проверку
Swarm	8+ независимых кусков или ширина	ownership, параллельных воркеров, verifier

Если куски делят один экран, один дизайн-язык или один mutable-артефакт — не swarm. Один implementer + один critic обычно дают более цельный UI, чем параллельные владельцы панелей.

Инварианты

Сначала outcome и quality bar, потом процесс.
Один владелец на артефакт; shared-файлы — у лида/интегратора.
Воркер получает пакет, а не всю историю чата.
Автор не проверяет сам себя; для рискованной работы нужен свежий контекст.
«Готово» — это runnable artifact, команда, цитата, метрика или рендер, а не уверенная фраза.
Технический pass — не product acceptance. Для product/UI: release-замеры, реальный сценарий, baseline и явный вердикт пользователя.
Если лагает или выглядит хуже baseline — чинить, а не добавлять фичи.
Для product — один milestone за раз; следующий не начинать без приёмки.
Проверять prerequisites; ставить только проверенные pinned-инструменты из официальных источников; глобальные установки/деструктив — только с разрешения.
Строить переиспользуемые «руки»: harness, скрипты, фикстуры, screenshot/CLI-утилиты. Тестировать их, документировать и держать в репозитории; неиспользуемые — удалять.
Инструкции пользователя важнее скилла: попросил быстро/прототип — убрать церемонии, оставить safety и evidence.

Что происходит

Понять outcome, аудиторию, quality bar и ограничения.
Проверить окружение: toolchain, команды, сервисы, display, credentials.
Спланировать только необходимое. Для swarm — brief, disjoint scopes, contracts, acceptance. Для direct/paired — без .swarm-бюрократии.
Сделать напрямую, с критиком или батчами воркеров.
Проверить технически, затем независимым критиком; для product — performance/UX/baseline.
Принять и интегрировать. Лид владеет shared-файлами и финальной проверкой.

Артефакты

Для swarm опционально: .swarm/brief.md, tasks/, reports/, reviews/. Они нужны для координации и восстановления, а не для отчётности ради отчётности. Для direct/paired их можно не создавать вообще.

Ограничения

workflow не обязателен: есть subagent — используем его, нет — работаем последовательно.
Число одновременных агентов ограничено runtime; не запускать oversubscribed fan-out.
Воркеры не устанавливают зависимости и не трогают live-системы.
Визуальные проверки — в изолированных display; общий рабочий стол не evidence.
Computer-use — крайний tier: один агент, одноразовый desktop/VM, не единственное evidence.
Токены — потолок, а не цель: резерв на verify/integration/polish; после фиксов — delta-review.
Для задачи, которую один агент делает за 15 минут, swarm не нужен.

Опциональные модули

Читать только по необходимости:

references/domains.md — адаптеры для кода/research/контента/данных/дизайна/ops.
references/prerequisites.md — preflight и политика установки.
references/visual-testing.md — изолированные display, скриншоты, computer-use.
references/product-quality.md — performance/UX/baseline/human acceptance.
evals/ — как проверять сам скилл (baseline vs with-skill).

Настройка

Проверка скоупа: node scripts/audit-scope.mjs --init перед стартом, затем node scripts/audit-scope.mjs.
Для swarm пишите brief/tasks сами; обязательных шаблонов больше нет.
Для директорий в plan.json используйте glob path/**, включая ещё не созданные папки.
Перед изменением скилла прочитайте evals/README.md; не считайте, что новая версия лучше старой без сравнения.