---
name: multi-agent-loop
description: "Используй когда Standard/Full задача затрагивает код, generated files, runtime sync, 2+ независимых tracks, долгие build/test ожидания или высокий риск scope drift. Триггеры: `/multi-agent-loop`, `$multi-agent-loop`, «сабагенты», «parallel agent work», «reviewer loop», «Wave Mode», «Work Orders»."
---

# Multi-Agent Loop

Используй этот skill как workflow overlay, а не как замену `AGENTS.md`, `Research → Plan → STOP → GO`, safety guard или verification gate.

Цель: главный агент остаётся orchestrator, а маленькие `xhigh` сабагенты помогают на чекпоинтах ловить drift, blockers и параллельную работу.

## Wave Mode / Work Orders

Wave Mode — optional execution overlay для задач, где есть `2+` независимых tracks или реальная параллельная поверхность. Это не новый обязательный task-contract и не постоянная команда агентов.

В каждом Standard/Full `plan.md` добавляй `### Wave Fit Check`:
- `Wave: yes/no`;
- `Signals`;
- `Reason`;
- `Subagents`.

Это короткая adoption-развилка, а не отдельный audit. Если `Wave: yes`, добавь `### Wave / Work Orders`. Если `Wave: no`, reason должен показать, почему single-track flow достаточен.

Orchestrator всегда владеет:
- целью и `Task ID`;
- plan, safety и approval boundaries;
- integration между tracks;
- финальной verification и closeout.

Для каждого Work Order фиксируй:
- `Track`;
- `Role`;
- `Owned files`;
- `Inputs`;
- `Deliverable`;
- `Verification`;
- `Handoff`.

Ownership относится только к mutating scope: reading files never requires a lock. Если два tracks претендуют на одни `Owned files`, это plan revision или explicit handoff, не silent parallel editing.

Cross-contour или async handoff идёт через существующий `Dashboard/Task Handoff/*.md`. Same-task coordination stays in `plan.md` / `log.md`. Не создавать `LOCKS.md`, `outbox/`, durable mailbox, `.omx`, tmux/HUD/team runtime или keyword routing для v1.

## Compact examples

Хороший `Wave: yes`:

```text
Wave: yes
Signals: code/integration, generated files, 3 disjoint tracks
Reason: process wording, validator/tests and generated sync can move independently.
Subagents: no real subagents; no explicit parallel agent work permission.
```

Хороший `Wave: no`:

```text
Wave: no
Signals: checked; single narrow text change, no generated/runtime sync, no long checks.
Reason: one file and one verification path; Work Orders would add ceremony.
Subagents: not applicable.
```

Плохие Wave patterns:
- overlapping `Owned files` без plan revision или explicit handoff;
- locks for reading files;
- real subagents without explicit `parallel agent work`;
- `готово` without test/build/diff/manual evidence.

В `log.md` closeout добавляй:

```text
Wave result: used/not used/not applicable; helped/friction; next adjustment
```

## Когда включать

Включай для Standard/Full задач, если есть хотя бы один сигнал:
- кодовые изменения;
- generated files или runtime sync;
- несколько независимых веток работы;
- `2+` независимых tracks;
- долгие build/test ожидания;
- повышенный риск scope drift;
- user explicitly mentions multi-agent, subagents, reviewer loop, delegation or parallel agent work.

Не включай для обычных текстов, draft mode, коротких ответов, мелких локальных правок и рутинного Auto-flow.

## Recommendation gate

Если задача подходит под loop, но пользователь не дал явного разрешения на `subagents`, `delegation` или `parallel agent work`, один раз до исполнения скажи:

```text
Рекомендую включить $multi-agent-loop: reviewer/explorer на gpt-5.4-mini xhigh. Реальных сабагентов я не запускаю без явного разрешения; чтобы включить, напиши: “Используй parallel agent work”.
```

Не спрашивай повторно на каждый tool call. Если пользователь не даёт разрешение, продолжай обычный flow и при необходимости сделай inline reviewer-check.

Это platform permission boundary для реальных сабагентов, а не общий manual-invocation requirement для skill/check работы.

Обычный `GO` сам по себе не считается разрешением на реальные сабагенты, если в нём нет явной фразы про `subagents`, `delegation` или `parallel agent work`.

## Native subagents vs OMX team

Codex native subagents и OMX/tmux team — разные runtime surfaces.

- `$multi-agent-loop` может использовать только bounded in-session subagents, которые главный агент запускает, ждёт и интегрирует внутри текущей сессии.
- OMX `team` / tmux / HUD / mailbox runtime не является Codex App default, не включается через обычный `GO` и требует отдельного operator decision.
- Не переносить `.omx` state, durable team workers или keyword routing в этот loop.

## Model routing

Default для всех small-model сабагентов:
- model: `gpt-5.4-mini`
- reasoning effort: `xhigh`

Роли:
- reviewer: `gpt-5.4-mini`, `xhigh`;
- explorer: `gpt-5.4-mini`, `xhigh`;
- worker: `gpt-5.4-mini`, `xhigh`, только для bounded/disjoint задач.

Escalate to full `gpt-5.4` only if:
- задача архитектурная или high-risk;
- mini нашёл blocker, который требует сильного reasoning;
- два mini-прохода дают слабый или противоречивый результат;
- task scope слишком связан, чтобы безопасно делегировать mini-worker.

Если нужная mini-модель недоступна, используй ближайшую доступную mini-модель с максимальным reasoning. Если subagents недоступны или platform/developer instructions не разрешают их запуск, выполни reviewer-check inline главным агентом.

## Checkpoint cadence

Не запускай reviewer после каждого tool call. Запускай на смысловых чекпоинтах:
- после research/plan на сложных задачах;
- после крупного edit-pass;
- во время долгих build/test ожиданий, если есть полезная параллельная работа;
- перед финальной verification.

## Reviewer contract

Дай reviewer минимум нужного контекста:
- Task ID;
- цель и acceptance criteria;
- текущий план/TODO;
- active Wave / Work Orders, если они есть;
- что уже изменено или проверяется;
- известные ограничения и out-of-scope.

Попроси reviewer вернуть только:
- `Progress to goal`;
- `Blockers`;
- `Parallel candidates`;
- `Scope drift`;
- `Recommendation`.

Reviewer may add `Architectural Status: CLEAR | WATCH | BLOCK` when reviewing a plan or checkpoint:
- `CLEAR` means no blocker/watch item found by reviewer; it is not `GO` and not execution approval.
- `WATCH` means execution may continue only after the watch item is copied into plan risks/checks/acceptance criteria or current TODO.
- `BLOCK` means stop execution until the blocker is resolved or explicitly descoped.

Reviewer не должен редактировать файлы, approve-ить execution, выдавать `GO`, менять task scope или предлагать действия, которые обходят `GO`, safety guard, approval boundaries или live-system constraints.

## Delegation rules

Главный агент держит critical path и интеграцию. Не делегируй urgent blocking work, если следующий шаг главного агента зависит от результата.

Explorer получает read-only вопрос и возвращает короткий ответ с путями/фактами.

Worker получает bounded write scope только если:
- файлы или модуль явно отделены от других работ;
- задача не требует архитектурного решения;
- нет риска конфликтов с чужими изменениями.

Всегда сообщай worker:
- он не один в кодовой базе;
- нельзя откатывать чужие изменения;
- нужно работать только в назначенном scope;
- нужно перечислить изменённые файлы в финале.

Не запускай двух workers на один write scope.

## Inline fallback

Если сабагенты недоступны, сделай короткий inline reviewer-pass:

```text
Progress to goal:
Blockers:
Parallel candidates:
Scope drift:
Architectural Status:
Recommendation:
```

Затем продолжай обычный verification gate.