Use when work has genuinely independent streams or distinct builder, evaluator, domain, and integration roles that require bounded multi-agent command.
npx skills add https://github.com/Mark393295827/third-brain-v7-skills --skill 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.
Provide: mission, non-goals, workstreams, dependencies, files/systems, acceptance criteria, permissions, review bandwidth, runtime capabilities, budget, and integration owner.
<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>
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.{task_id, state, artifact, evidence, decision, unknowns, dependency, next_action}. Messages change state; status chatter does not.state + evidence -> next action -> verifier -> next state | stop | escalate and checkpoint after each material action.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>
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.Return status, result (mission and integrated artifacts), evidence (task/integration/cleanup receipts), unknowns, and next_action including approval or rollback.
workers, not six; deterministic nodes remain scheduler-owned.
VERIFY_FAILED; reject incompatible artifacts rather than averaging reports.</skill_contract>
Create new skills, modify and improve existing skills, and measure skill performance. Use when users want to create a skill from scratch, edit, or optimize an existing skill, run evals to test a skill, benchmark skill performance with variance analysis, or optimize a skill's description for better triggering accuracy.
Guide for creating effective skills. This skill should be used when users want to create a new skill (or update an existing skill) that extends Claude's capabilities with specialized knowledge, workflows, or tool integrations.
Guide for creating effective skills. This skill should be used when users want to create a new skill (or update an existing skill) that extends Claude's capabilities with specialized knowledge, workflows, or tool integrations.
Replace with description of the skill and when Claude should use it.
Use when facing 2+ independent tasks that can be worked on without shared state or sequential dependencies
This skill should be used when the user wants to "create a skill", "add a skill to plugin", "write a new skill", "improve skill description", "organize skill content", or needs guidance on skill structure, progressive disclosure, or skill development best practices for Claude Code plugins.
Helps users discover and install agent skills when they ask questions like "how do I do X", "find a skill for X", "is there a skill that can...", or express interest in extending capabilities. This skill should be used when the user is looking for functionality that might exist as an installable skill.
Use when creating new skills, editing existing skills, or verifying skills work before deployment
Take mark393295827/agent-teams-command from the repository into ~/.claude/skills for personal
use, or into .claude/skills inside a project.
The agent identifies a skill by the name field in its header. Two skills with the
same name cannot sit side by side — one of them will be ignored.