Use when work has genuinely independent streams or distinct builder, evaluator, domain, and integration roles that require bounded multi-agent command scaled from 5 to 100+ agents.
Instrucciones de origen · Vista previa de solo lectura
name
agent-teams-command
description
Use when work has genuinely independent streams or distinct builder, evaluator, domain, and integration roles that require bounded multi-agent command scaled from 5 to 100+ agents.
metadata
{"version":"8.1.0","updated":"2026-08-18","profile":"high-risk","assumes":"The runtime supports isolated workers, durable shared task lists, token budgeting, and explicit integration ownership.","conflicts_with":"Parallelism without pre-flight task lists, unbudgeted token burning, overlapping write ownership, or chat-only coordination."}
Agent Teams Command — 安德智能体集群指挥系统 (V8.1)
<skill_contract>
A mission with independently ownable workstreams, time SLA requirements, pre-flight task list, token budget, interfaces, permissions, and an integration owner.
An isolated worker fleet (5 to 100+ agents), typed IPC ledger, pre-allocated token ledger, serial integration, cleanup, and evidence receipts.
Pre-flight task list is 100% reconciled, integrated artifacts pass mission checks, token consumption is within TCLR boundaries, and cleanup gates pass.
<non_goals>Parallelism without a task list, unbounded token burn, overlapping writers, or worker self-certification.</non_goals>
Strategic intent and final integration remain serial; owned execution runs in dynamically scaled parallel squadrons (5, 10, 50, 100+ agents). Use the Ender lens for commander intent and squad autonomy, Palantir for operational objects/actions, and von Neumann for executable process architecture. Detailed patterns: references/ender-palantir-command-patterns.md; examples: references/classic-campaigns.md.
Usage Template
Provide: mission, time SLA, task list candidate, workstreams, scaling tier (5/10/50/100+), dependencies, acceptance criteria, token budget (ETC limit), permissions, runtime capabilities, and integration owner.
Workflow
Mission Intake & Scale Triage: Analyze mission complexity and select the smallest supported tier: Tier 1 (Squad: 5 agents), Tier 2 (Squadron: 10 agents), Tier 3 (Battle Group: 50 agents), or Tier 4 (Fleet: 100+ agents). If the runtime exposes fewer slots, cap the active fleet to that observed limit.
Pre-flight Task List & Token Gate: Generate structured task list with explicit owner, territory, expected output, verification command, and token budget (ETC).
Territory Mapping: Partition work into non-overlapping directories or git worktrees. Every worker gets strictly exclusive write boundaries.
<unknowns_gate>
If dependencies, write ownership, or verification commands are ambiguous, return NEEDS_INPUT or INSUFFICIENT_EVIDENCE. Do not launch parallel workers before pre-flight task list and token ledger are fully reconciled.
</unknowns_gate>
Launch Workers: Dispatch workers in parallel across isolated worktrees. Each receives a typed context_manifest containing only its objective, dependencies, territory, inputs, output schema, budget, and verifier.
Typed IPC & Command Board: Workers report state transitions (pending -> active -> review -> accepted -> closed) to shared command board.
Independent Verification: Evaluator and reviewer agents verify worker outputs against objective criteria. No worker self-certification.
Serial Integration & Join Gate: Integrator aggregates verified artifacts and receipts in dependency order. Do not merge private branch transcripts into the integration context. Run regression tests.
Durable Write-back & Cleanup: Persist execution receipts, update system logs, and clean up temporary worktree branches.
For high-risk operations or cross-repo modifications, require independent review and human approval. Prepare a rollback plan before applying writes.
Audit total token consumption against the mission-declared TCLR: verified tasks resolved per 10,000 effective tokens consumed. Higher is better; do not invent a universal threshold. Verify all workstreams reached accepted or closed state, no file ownership conflicts occurred, and the declared regression suite passed.
<retry_policy>
max_attempts: 2. Stop on repeated failure signature or NO_PROGRESS. If a worker stalls or fails, reassign territory or downgrade to serial execution rather than launching unbudgeted retries.
Return status, result (worker fleet summary, task resolution ledger, and verified artifacts), evidence (source receipts, lint receipts, and integration logs), unknowns, and next_action including approval or rollback when relevant.
Edge Cases
File Collision: Two workers attempt to modify the same file -> Integrator serializes execution and assigns one canonical owner.