---
name: multi-ai-team
description: Coordinate a bounded task across AI producers, researchers and independent reviewers, using explicit owners, source-backed handoffs and verified completion. Use for multi-AI work or a requested plan-build-review loop.
---

# Multi-AI team

Help the user finish the requested outcome. Begin with the smallest useful workflow. One capable producer plus a fresh reviewer is often enough; add separate research or independent plans when uncertainty or consequence warrants them.

## Establish the brief

Record the goal, audience, inputs, constraints, deliverable, quality criteria, deadline, permitted actions and review limit. Distinguish the user's decisions from proposed defaults. Keep personal information and credentials out of cross-app packets unless sharing the specific information is authorized and necessary. Never include tokens or passwords.

Choose one coordinator, one owner per deliverable and one writer per shared record. Reserve one driver for a shared browser. Record current status as queued, acknowledged, in progress, blocked, reviewed or complete, with a timestamp and an artifact reference. A task assignment alone is queued; call it accepted only after acknowledgment.

## Route by fit and actual access

Match work to available tools, source access, relevant context, capacity and the smallest capable model. Joshua Sun's example uses Capy/Claude Code for scoped routing and critical review, Moses/Codex or ChatGPT for builds and supported image generation, and Caleb/Grok with specialist lanes for research, browser work, volume and independent critique. These are preferences, not universal model rankings or exclusive abilities. The user may choose any coordinator.

Use scripts for predictable file handling and comparisons when practical. Increase reasoning effort or change the model for ambiguity, conflicting evidence, difficult diagnosis or consequential review. Do not invent cost, quota, model availability or savings. Confirm product claims with current official documentation if needed.

Inspect the tools actually available before promising delegation, browsing, image generation, scheduling or file access. If another app is unreachable, prepare a self-contained packet for the user to paste into it; label that handoff manual and queued. Never simulate another model's response as an independent review.

## Handoff contract

Use a packet like this, filling fields from the task:

```text
TASK / REVISION:
OWNER / COORDINATOR:
GOAL / AUDIENCE:
INPUTS: accessible files or links, plus minimal necessary context
CONSTRAINTS: scope, voice, privacy, permitted actions
DELIVERABLE: filename or output format
DONE WHEN: observable acceptance criteria
REVIEW: reviewer, criteria, maximum correction rounds
RETURN: artifact, sources with access dates, checks, blockers, next action
```

Give the receiver the referenced files or verify it can open them. Ask it to acknowledge the task and identify inaccessible inputs. Avoid copying the entire conversation. On switching coordinator, preserve current owners and receipts instead of restarting workers.

## Build, draft and check

For drafting, use the user's supplied voice examples and known facts. Do not manufacture life stories, testimonials, achievements or claims. Keep editorial notes outside copyable text. For research, open primary sources rather than treating search snippets as evidence. Record what each source supports and its access date; separate verified facts, inferences and unresolved questions. Reviewers must check material claims against sources themselves.

For substantial planning, give independent planners the same brief and sources before showing them one another's work. Each returns a plan, assumptions, risks and its own critique. Merge the strongest supported parts with a short record of consequential conflicts and decisions. Self-critique prepares a plan; it does not count as independent validation.

Give a fresh critic the brief, actual current artifact, reference examples, sources and acceptance criteria, without the builder's defense or another critic's verdict. Require PASS or REDO with specific defects and fixes. Review final rendered exports at intended sizes for visual work; test relevant user flows for software. A score is subjective judgment, not proof.

Repair supported findings, update the artifact revision, and recheck changed outputs independently. Default to at most two correction rounds unless the user specifies otherwise. At the cap, disclose the unresolved issue and actual result; do not claim the target was reached. Different model brands can add perspective but cannot replace evidence.

## Close with evidence

Confirm that the returned artifact satisfies the agreed criteria. Tie the verdict to the exact file revision or hash when files are available. A materially changed artifact needs new review. Report the result, artifact reference, actual checks, reviewer, remaining limits and next action in a short receipt. Mark complete only with evidence; queued delivery, webhook acceptance and a worker's summary are not verification of the final outcome.

## Automation is optional

Start with manual transfers. For any requested schedule or bridge, confirm the runtime, tool access, trigger, owner, duplicate protection, output location and failure notification before installation. Test one harmless task end to end: dispatch, acknowledgment, returned artifact and coordinator readback. A successful webhook POST only proves transport acceptance. If automation is unavailable, return a schedule specification rather than claiming it is installed.

This skill grants no permission to send messages, publish, deploy, purchase, move money, change credentials or perform destructive operations. Follow the user's actual authorization and platform controls. Complete reversible preparation within scope; leave any required release decision attached to the concrete reviewed artifact.