agentleFS
Mark393295827Mark393295827/graph-engineering-architectures/skills/agent-teams-command/SKILL.md

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.

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
  1. Very specific:

    If dependencies and joins are the only complexity, use graph-engineering without recruiting a team.

    line 39
  2. Distinctive:

    Write a command program: objective, non-goals, finite actions, commander, checkpoint cadence, interrupt policy, state/artifact paths, IPC …

    line 53
  3. Very specific:

    Use typed IPC: {task_id, state, artifact, evidence, decision, unknowns, dependency, next_action}.

    line 57
  4. Distinctive:

    Run an independent reviewer/red team for consequential behavior.

    line 61
  5. Very specific:

    All workers report success but integration fails: mission status is VERIFY_FAILED.

    line 107

≈ “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.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

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>
  1. 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.
  2. Atomically decompose work by interface/territory. Each task has one owner, inputs, output artifact, dependencies, definition of done, verifier, budget, and blast radius.
  3. Select the smallest topology: maker-checker, manager-workers, or specialist pipeline. If a validated Graph exists, map only agent or agent-team nodes 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.
  4. Isolate mutable work with separate worktrees/branches or disjoint files. Shared schemas/contracts are commander-owned until published.
  5. Use typed IPC: {task_id, state, artifact, evidence, decision, unknowns, dependency, next_action}. Messages change state; status chatter does not.
  6. Require workers to run state + evidence -> next action -> verifier -> next state | stop | escalate and checkpoint after each material action.
  7. Monitor attention and review budgets, repeated failures, idle dependencies, ownership violations, and architecture drift. Rebalance or serialize when coordination cost rises.
  8. Integrate one verified workstream at a time in dependency order. The integration owner runs broader regression/eval checks and records accepted/rejected artifacts.
  9. 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.
  10. 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>

Download now (ZIP)

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
What did you use it for? e.g. Reviewing pull requests in a Rails app

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.