Coordinate live teammates with ak:team

Use ak:team when independent teammate sessions need to coordinate through a lead, shared work state, and direct messages. The Skill keeps decomposition, ownership, integration, verification, shutdown, and cleanup with the lead.

Choose ak:team for live collaboration

Use ak:team when

• Three or more independent workstreams benefit from separate contexts.
• Reviewers need distinct specialties and their findings must be reconciled.
• Debuggers need to challenge competing, testable hypotheses.
• A cross-layer implementation can be split into non-overlapping ownership.
• Teammates need ongoing direct communication rather than one final handoff.

Choose another workflow when

• One focused test, lint, scout, or review can return directly to the caller. Use an ordinary subagent or the owning Skill.
• The work is a sequential plan-to-code-to-test chain.
• Jobs need live runtime diversity, headless capture, resumable state, and an arbiter. Use ak:orchestrate.
• Several writers need the same files and cannot be separated safely.

Prepare the runtime and workspace

Before you start:

• Complete Onboarding, and confirm Engineer Kit is installed for the runtime and scope you are using.
• Verify the live runtime exposes team creation, shared work, delegation, messaging, waiting, shutdown, and cleanup.
• Define one outcome, acceptance criteria, project instructions, report or plan destination, and Git authority boundary.
• Split implementation files into non-overlapping ownership before spawning writers.
• Use a Git repository when implementation teammates need worktrees.

Current capability names, parameters, model routing, limits, permissions, isolation, and cleanup behavior must be discovered during the run.

Run the Skill

/ak:team review "Review the checkout change for security, accessibility, and failure-path coverage; return evidence only" --reviewers 3 --delegate

/ak:team review "Review the checkout change for security, accessibility, and failure-path coverage; return evidence only" --reviewers 3 --delegate

Describe the team clearly

A useful team request includes:

• Outcome: State the combined result the lead must deliver.
• Workstreams: Name independent research angles, review focuses, hypotheses, or implementation groups.
• Ownership: Give each writer distinct files or globs.
• Dependencies: State which verification or integration work waits for which implementation scopes.
• Evidence: Define the report, diff, test, or finding format required from each teammate.
• Authority boundary: State whether commits, pushes, merges, external services, credentials, destructive actions, or deployment are allowed.

Teammates do not inherit the lead's full conversation. Each receives only the workspace, instructions, active requirements, ownership, dependencies, and acceptance criteria needed for its scope.

Understand the team lifecycle

1. The lead decomposes the request. It creates genuinely independent work with explicit outputs and non-overlapping ownership.
2. The lead discovers and creates the team. Missing lifecycle capability stops the workflow; it does not trigger a hidden substitute.
3. The lead registers shared work. Every item receives acceptance criteria, dependencies, an owner, and a durable destination.
4. The lead spawns teammates. Independent scopes run concurrently. Concurrent writers use requested isolation when available and still keep distinct ownership.
5. The lead coordinates through live state and messages. Idle means waiting, not completion. Stale owners are contacted before reassignment.
6. The lead integrates only completed prerequisites. In delegate mode, an assigned teammate performs implementation commands and integration work.
7. The lead verifies the combined result. Completion messages are handoffs, not proof; integrated checks and review still run.
8. The lead shuts down and cleans up. It requests graceful shutdown, waits for acknowledgement or a blocked handoff, then uses the live cleanup capability.

Keep approval and safety with you

Worktree isolation does not replace ownership and is not an operating-system sandbox. If two teammates need the same file, stop and restructure the work or assign one integration owner.

--delegate constrains the lead; it does not expand teammate authority. State whether teammates may commit or push. Never infer publication, deployment, credential use, destructive changes, or access to unrelated files from a team request or worktree flag.

With plan approval enabled, teammates remain read-only until the lead accepts their scope, ownership, validation, risks, and rollback notes through the live approval surface.

Verify the result

A complete team run should provide:

• Shared work items with owners, dependencies, status, and acceptance criteria.
• One bounded report or change set per teammate.
• Evidence-based review findings or debugging hypotheses, including disagreements that were resolved or preserved.
• Integrated tests and review for implementation work.
• An explicit documentation-impact decision for the cook template.
• A final synthesis with completed, blocked, and reassigned work plus unresolved questions.
• Graceful teammate shutdown and live team cleanup, or the exact cleanup error and current recovery guidance.

Treat teammate messages as progress evidence. Only shared state, inspected artifacts, and integrated verification establish completion.

Troubleshoot or continue

Compare ak:orchestrate for captured headless jobs, or continue with the Engineer Kit overview and Runtime adapters.

Know the current limits

• Only supported adapters project the Skill, and it requires a live team surface. Codex does not project it; other runtimes abort when required live capabilities are missing.
• Model lists, limits, permissions, isolation, display modes, memory, resume, and cleanup behavior are runtime-owned and must be inspected live.
• Persistent teammate memory is used only when the runtime exposes it and project policy permits it.
• Parallelism helps only when scopes are independent; coordination can cost more than short sequential work.