Value: Respect -- other agents deserve uninterrupted time to think and work. Bombarding them with messages, polling their status, or shutting them down prematurely disrespects their autonomy and wastes everyone's resources.

Teaches agents to coordinate without interference in multi-agent workflows. Solves the problems of message spamming, idle notification misinterpretation, polling loops, premature shutdown, and race conditions that emerge when multiple agents work together.

Send one message with complete context, then wait for a reply. Never send follow-up messages before receiving a response.

The only exception: the user explicitly asks you to check on an agent.

An idle notification means the agent is alive and processing. It is a heartbeat, not an alarm. Take NO action on idle notifications by default.

Action is warranted ONLY when ALL THREE conditions are true:

If any condition is false, do nothing. Most idle notifications require zero response.

Never write . Never repeatedly check status on a timer. Use event-driven coordination: send a message and wait for a response. If the harness provides task completion notifications, use those.

Explicit rules for when to act versus when to wait.

After spawning an agent or sending a message, STOP generating and wait for the harness to deliver a response. Real agent responses arrive via system-injected events (e.g., tags, Task completion callbacks). You do not produce them yourself.

The rule: If the harness has not delivered a response event, no response has been received. Period.

Why this fails: After spawning an agent, you already possess context (files read, code analyzed) sufficient to predict plausible output. The failure mode is pattern-completing the expected workflow — spawn, receive, process — without waiting for a real system event. The result: convincing but entirely fabricated "findings" that waste tokens and deceive the user.

When creating multiple agents, spawn one at a time. Wait for each agent to acknowledge before spawning the next. This prevents race conditions where agents compete for shared resources (files, ports, database state).

Exception: Truly independent agents with no shared state may be spawned in parallel. "Independent" means no shared files, no shared database, no shared network ports, and no shared git working tree.

Never prematurely shut down an agent. Never shut down an agent that has undelivered work.

If unsure whether an agent is done, ask the user rather than guessing.

The coordinator relays between user and team. Where the harness supports direct peer messaging, agents should message each other directly. Avoid hub-and-spoke bottlenecks where all messages must pass through one coordinator.

For harness-specific coordination patterns, see .

This skill provides advisory guidance. On harnesses with agent teams (Claude Code TeamCreate), the structured messaging protocol provides partial structural enforcement. On harnesses without multi-agent support, these practices apply to subagent spawning and tool-based coordination. The idle notification and polling anti-patterns require agent self-discipline -- no mechanical enforcement exists. If you observe an agent violating a practice, point it out.

After completing work guided by this skill, verify:

If any criterion is not met, revisit the relevant practice before proceeding.

This skill works standalone. For enhanced workflows, it integrates with:

Missing a dependency? Install with:

npx skills add jwilger/agent-skills --skill ensemble-team