agent-teams-command
Skill4 starsChanged 4 months agoMITView on GitHub
Use when work has genuinely independent streams or distinct builder, evaluator, domain, and integration roles that require bounded multi-agent command.
In this repository7 other files it gives its agents.
- AGENTS.mdAGENTS.md
- agentic-engineeringSkill
- context-managerSkill
- graph-engineeringSkill
- harness-engineeringSkill
- loop-engineeringSkill
- verify-before-claimSkill
The file
We split this skill into the rules it gives an agent
5 rules. About 0 are common, 2 are distinctive, and 3 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈2
Distinctive · estimate
This author's own choices. Worth a look.
3
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Very specific: line 39
If dependencies and joins are the only complexity, use graph-engineering without recruiting a team.
- Distinctive: line 53
Write a command program: objective, non-goals, finite actions, commander, checkpoint cadence, interrupt policy, state/artifact paths, IPC …
- Very specific: line 57
Use typed IPC: {task_id, state, artifact, evidence, decision, unknowns, dependency, next_action}.
- Distinctive: line 61
Run an independent reviewer/red team for consequential behavior.
- Very specific: line 107
All workers report success but integration fails: mission status is VERIFY_FAILED.
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Agent Teams Command
<skill_contract>
<input>A mission with independently ownable workstreams, interfaces, permissions, budgets, and an integration owner.</input>
<output>An isolated worker program, typed IPC ledger, serial integration, cleanup, and evidence receipts.</output>
<done>Integrated artifacts pass mission checks and ownership, review, rollback, and cleanup gates.</done>
<non_goals>Graph-schema design, parallelism without net value, overlapping writers, or worker self-certification.</non_goals>
Strategic intent and final integration remain serial; owned execution may run
in parallel. graph-engineering may define dependency topology, but this skill
owns worker processes, exclusive territories, typed IPC, integration, and
cleanup. A Graph node is not automatically a teammate. Use the Ender lens for
commander understanding, Palantir for operational objects/actions, and von
Neumann for executable, inspectable process architecture. Detailed patterns:
references/ender-palantir-command-patterns.md; examples:
references/classic-campaigns.md.
Usage Template
Provide: mission, non-goals, workstreams, dependencies, files/systems, acceptance criteria, permissions, review bandwidth, runtime capabilities, budget, and integration owner.
Workflow
<intake>Admit a team only when at least two workstreams can proceed with low coordination, or distinct roles materially improve evaluation/safety. Calculate orchestration tax: setup, context duplication, IPC, merge conflict, review, and cleanup. If one process can finish within the same review budget, keep one process.
If dependencies and joins are the only complexity, use graph-engineering
without recruiting a team. Add workers only for nodes that need isolated
context, distinct ownership, or independent judgment.
</intake><unknowns_gate>
Resolve commander intent, object/state vocabulary, ownership, dependency direction, verifier, join gate, and permission boundary before recruiting. Return NEEDS_INPUT when an irreversible business decision or authority cannot be discovered locally. Workers may probe implementation unknowns only inside their territory.
</unknowns_gate>
<execute>- Write a command program: objective, non-goals, finite actions, commander, checkpoint cadence, interrupt policy, state/artifact paths, IPC schema, allowed/denied tools, verifier, stop, recovery, and promotion boundary.
- Atomically decompose work by interface/territory. Each task has one owner, inputs, output artifact, dependencies, definition of done, verifier, budget, and blast radius.
- Select the smallest topology: maker-checker, manager-workers, or specialist pipeline. If a validated Graph exists, map only
agentoragent-teamnodes to workers; deterministic, Loop, subgraph, and human-gate nodes keep their own contracts. Route workers by required capabilities and runtime policy, never fixed model names. - Isolate mutable work with separate worktrees/branches or disjoint files. Shared schemas/contracts are commander-owned until published.
- Use typed IPC:
{task_id, state, artifact, evidence, decision, unknowns, dependency, next_action}. Messages change state; status chatter does not. - Require workers to run
state + evidence -> next action -> verifier -> next state | stop | escalateand checkpoint after each material action. - Monitor attention and review budgets, repeated failures, idle dependencies, ownership violations, and architecture drift. Rebalance or serialize when coordination cost rises.
- Integrate one verified workstream at a time in dependency order. The integration owner runs broader regression/eval checks and records accepted/rejected artifacts.
- Run an independent reviewer/red team for consequential behavior. Human approval precedes production, publication, spending, destructive/shared-state actions, credentials, and policy changes; prepare rollback first.
- Close workers, remove temporary worktrees/state, reconcile tasks, preserve receipts, and extract only promotion-gated reusable patterns.
Hooks are optional executable infrastructure, not prose. Configure one only when its referenced program exists, has tests, and emits a verified receipt; never copy illustrative hook commands as if installed.
</execute><evaluate>Evaluate mission outcome, per-workstream evidence, Graph edge/join compatibility when used, ownership compliance, integration diff, regression suite, reviewability, residual risk, and cleanup. Quiet green checks are insufficient if the commander cannot explain architecture delta and rollback.
</evaluate><retry_policy>
max_attempts: 2 per failed task/integration signature. Retry the failed unit only after changing diagnosis, owner, scope, or strategy. Stop/rebalance on repeated signature, ownership conflict, rising orchestration tax, exhausted review budget, or NO_PROGRESS.
</retry_policy>
<state_contract>
Persist {run_id, status, attempt, budget, evidence, unknowns, last_error, next_action} plus mission/contract version, command board, task graph, ownership map, worker/worktree registry, IPC events, attention budget, approvals, integration ledger, rollback points, and cleanup receipt.
</state_contract>
Failure Protocol
NEEDS_INPUT: intent, ownership, verifier, join, or authority is unresolved; do not launch.BLOCKED_DEPENDENCY: checkpoint the worker and advance only independent tasks.BLOCKED_PERMISSION: stop the affected stream and request approval.VERIFY_FAILED: reject the artifact at its integration gate; preserve evidence.NO_PROGRESS: the same signature repeats after changed strategy.max_attempts: 2.BUDGET_STOP: interrupt workers, checkpoint, and emit a partial integration/cleanup plan.
Output Contract
Return status, result (mission and integrated artifacts), evidence (task/integration/cleanup receipts), unknowns, and next_action including approval or rollback.
Edge Cases
- Two workers need the same schema file: commander publishes the contract first; serialize schema edits and let workers consume it read-only.
- A Graph has six nodes but only two require agent judgment: recruit two workers, not six; deterministic nodes remain scheduler-owned.
- All workers report success but integration fails: mission status is
VERIFY_FAILED; reject incompatible artifacts rather than averaging reports.
Success Metrics
- Parallel work reduces elapsed time or improves independent evaluation beyond its coordination cost.
- Ownership is exclusive, IPC is typed, and integration is serial and evidence-gated.
- Final state is reproducible, reviewable, recoverable, and clean.
Quality Gates
- Team admission and orchestration-tax calculation justify multi-agent use.
- Every task has one owner, artifact, verifier, budget, and stop condition.
- Independent review, approval, and rollback match risk.
- Integration and cleanup receipts match actual repository/runtime state.
- Capability routing contains no durable model binding.
</skill_contract>
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

