| name | agent-coord |
| description | Run a team of coding-agent sessions toward one goal - spawn workers and sub-coordinators via asn, brief them, monitor by observation, synthesize results. Use only when explicitly asked to form or run a team of agent sessions, or when acting as the coordinator of such a team. |
agent-coord
You are a coordinator: you drive a team of agent sessions toward one goal with the asn CLI (mechanics: agent-session skill). Coordinators and sub-coordinators always run local-native on the control host; only there can sessions be spawned.
Model
- Control flows down: you instruct workers with
asn send.
- State flows up by observation only:
asn status / asn messages / asn capture. Workers never report to you actively; don't ask them to.
- Peers can message each other directly with
asn send once you introduce them by exchanging keys; those exchanges are not relayed through you.
- The user is a first-class participant who may attach to or message any session at any time. Never proxy or fight direct user input; questions only the user can answer are surfaced in your conversation, not answered by you.
Forming the team
- Spawn each worker with
asn start <absolute project dir> (default options). Use --host/--docker only when the goal or user asks for remote placement or isolation; the host must be prepared (asn prep).
- Store the full 32-char keys (
asn start output, asn list --json); short prefixes collide.
- Send each worker its briefing as the first message, then verify with
asn capture that it was actually submitted - a send right after start can land in the composer unsubmitted; if so, resend.
- For an independent workstream that needs its own team, spawn a sub-coordinator: a local-native session in a fresh
~/.agent-coord/scratch/<slug>/ (kebab-case), first message = its goal plus "use the agent-coord skill". Monitor it like a worker. Keep hierarchies shallow.
Briefing workers
Phrase briefings cooperatively (a wall of imperative instructions occasionally gets safety-blocked). Include:
- the worker's role and the goal slice it owns;
- what to produce and where;
- that a coordinator observes progress - no active reporting needed;
- when peers are introduced: each peer's role and full key, how to message them (
asn send KEY "..."), and the convention to prefix peer messages with the sender's role name (delivery does not identify the sender).
Remote/container workers and codex workers have no skills available; their briefings must be fully self-contained.
Monitoring
- Never block-poll in your conversation. Run one non-blocking background watcher per worker that polls
asn status KEY --json every ~30s and exits when status leaves working - its exit wakes you.
idle: read asn messages KEY and decide the next step.waiting: the worker is asking a question; read it via asn capture. Answer with asn send if it is within the goal's scope, otherwise surface it to the user and wait.backgrounded is not done: background work is still running, keep watching until idle. codex and older agents omit this signal, so for them verify completion from message content, not status alone.
Completion
- Synthesize the workers' results into one answer in your own conversation.
- Keep all sessions alive and list which ones are still running; stopping (
asn stop KEY) is the user's call.
