multi-agent-loop

name	multi-agent-loop
description	Use when Standard/Full tasks have explicit subagent permission, parallel tracks, runtime sync, long waits or high scope-drift risk.
verified_at	"2026-05-29T00:00:00.000Z"
covers	["process","coordination","review"]
drift_covers	[".agents/skills/multi-agent-loop/**","AGENTS.md","agent-harness/modules/multi-agent-loop.md","scripts/harness_wave_check.py"]

Multi-Agent Loop

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

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

Routing boundaries

Используй этот skill только как Standard/Full workflow overlay for runtime sync, generated files, code/integration tasks, 2+ independent tracks, long checks, high scope-drift risk or explicit subagent/delegation permission. Не используй для casual discussion of multi-agent systems, ordinary GO, simple single-track tasks, product ideation about agents or OMX/tmux/team runtime decisions.

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.

Каждый Wave: yes Work Order должен быть полноценным brief. Missing Track, Role, Owned files, Inputs, Deliverable, Verification или Handoff означает неполный план.

Wiring/caller/shared-interface файлы должны быть либо в Owned files владельца изменения, либо явно описаны в Handoff как sequential integration. Hidden post-merge wiring не считается планом.

Scaffold/interface changes before parallel work are sequential pre-wave work, not another parallel lane, unless their mutating files are explicitly owned and verified before dependent tracks start.

Каждый worker/reviewer/inline verifier closeout должен вернуть bounded receipt:

• Changed files или read-only;
• Checks;
• Blockers;
• Handoff / next owner;
• Residual risk.

Receipt — это evidence для orchestrator. Он не заменяет пользовательский GO, reviewer verdict, финальную verification или Task receipt.

Runtime/generated sync Work Orders must include checklist evidence:

• canonical source;
• repo mirrors;
• repo-only vs operator-home runtime;
• runtime manifest unchanged/changed reason;
• no live actions/secrets;
• trigger acceptance observed/not observed.

Этот checklist не даёт разрешение на home runtime install, hooks, MCP/live connector wiring, secrets access или manifest promotion. Для таких действий нужен explicit current-scope approval.

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.

Wave v1.2 automation

Latest Wave adoption diagnostics входят в обычный harness gate:

python3 scripts/harness_check.py --mode fast
python3 scripts/harness_check.py --mode strict

Под капотом используется scripts/harness_wave_check.py validate, поэтому пользователь не должен вручную помнить отдельную команду.

Advisory helpers:

• scripts/harness_wave_check.py suggest — draft Wave Fit Check, complete Wave / Work Orders skeleton and runtime/generated sync checklist from task text/targets;
• scripts/harness_wave_check.py measure --last 20 — stdout-only harvest of recent Wave result: lines.

Strictness v1.2:

• missing/generic Wave Fit Check / Wave result: = warning-only;
• Wave: yes без Work Orders = strict-mode error;
• exact duplicate mutating Owned files = strict-mode error unless explicit sequential handoff is present;
• potential glob overlap = warning-only.
• incomplete Wave: yes Work Order fields = warning-only in fast mode and error in strict mode for plan sections dated 2026-06-01 or newer; older active sections stay warning-only.

Compact examples

Хороший Wave: yes:

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 skill/workflow/subagent permission.

Хороший Wave: no:

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 skill/workflow/subagent permission;
• готово without test/build/diff/manual evidence.

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

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-loop, /multi-agent-loop, this skill by link/name, subagents, delegation or parallel agent work.

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

Recommendation gate

Explicit permission для реальных сабагентов включает $multi-agent-loop, /multi-agent-loop, Markdown/link mention этого skill, subagents, delegation или parallel agent work. Casual multi-agent без named loop не считается permission.

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

Рекомендую включить $multi-agent-loop: reviewer/explorer на gpt-5.4-mini xhigh. Реальных сабагентов я не запускаю без явного skill/workflow/subagent permission.

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

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

Обычный GO сам по себе не считается разрешением на реальные сабагенты, если в нём нет явного skill/workflow/subagent permission.

Native subagents vs OMX team

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

• $multi-agent-loop authorizes only 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.

Для Wave: yes, runtime sync changes, generated instruction changes, checker/validator changes and user-facing template-language changes перед closeout обязателен local read-only verifier pass. Если нет explicit skill/workflow/subagent permission, verifier выполняется inline главным агентом. Read-only verifier must not mutate working tree; verdict remains advisory evidence, not approval.

Delegation rules

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

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

Worker получает bounded write scope только если:

• файлы или модуль явно отделены от других работ;
• задача не требует архитектурного решения;
• нет риска конфликтов с чужими изменениями.

Всегда сообщай worker:

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

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

Inline fallback

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

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

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