skills/agent-swarm/SKILL.md

name, description, whenToUse

name	description	whenToUse
agent-swarm	Use when a large task splits into 8+ independent units, or when a risky deliverable needs an independent critic across software, research, content, data, design or operations. Not for small, sequential or tightly coupled work.	The task is broad or risky enough that parallel workers or a fresh verifier change the outcome; one agent would take hours and the units can be described without stepping on each other.

Agent Swarm

A small orchestration core, not a mandatory methodology. Use the lightest mode that meets the risk; the user keeps the stack, scope and pace.

Choose the mode

Mode	Use when	What it adds
Direct	one unit, fast feedback, low blast radius	nothing
Paired critic	medium task, design decision, risky change	one independent review
Swarm	8+ independent units or breadth dominates	ownership, parallel workers, verifier

If the units share one screen, one design language or one mutable artifact, do not swarm. Use one implementer and one critic; parallel panel writers produce incoherent UI.

Invariants

1. Outcome before process. Agree on what “done” means and how it will be checked. Do not create .swarm/ files, task cards or reports just to look organized.
2. One owner per artifact. In a swarm, every path/artifact belongs to one writer. Shared files and contracts belong to the lead/integrator.
3. Packets, not transcripts. A worker gets a self-contained brief, its scope, the contract and the acceptance checks — never the lead's full conversation.
4. Independent verification. The author does not verify their own work. A fresh context checks the artifact, not the worker's summary. Verification is required for risky or product work; a trivial direct change may only need a command and a read-back.
5. Evidence before claims. “Done” means a runnable artifact, a passing command, a citation, a metric or a rendered result — not a confident sentence.
6. A technical pass is not product acceptance. For product/UI work, measure the release build, run a real scenario, compare with the baseline and get the user's verdict. If performance/UX was not measured, the product gate is not_run, not pass.
7. Do not add features to hide bad quality. If it is laggy, visually worse or harder to use than the baseline, fix the slice before expanding scope.
8. One milestone at a time. For product work, do not start M1/M2 while M0 is still rough or explicitly “not usable”.
9. Safety and trusted tools. Check prerequisites before work. Prefer existing, project-local, pinned tools; use official package managers/registries and lockfiles. Verify the source, license, release and checksum/signature when possible. No curl | sh, random binaries, unpinned “latest” or unvetted AI-suggested packages. Ask before sudo, global/system installs, destructive actions, deployments or irreversible changes. Workers never install or touch live systems; they return blocked with the exact missing item.
10. Build leverage. If a harness, script, fixture, screenshot tool or dev utility will be reused, build it, test it, document it and keep it in the repo. Prefer one small reliable tool over a pile of one-off commands. A broken or untrusted tool is worse than no tool; delete tools nobody uses.
11. User overrides. Direct user instructions beat this skill. If the user asks for speed, a prototype or “just do it”, drop the ceremony — keep only the safety and evidence that still matter.

Loop

1. Understand the outcome, audience, quality bar and constraints. Ask only when the answer changes the result.
2. Check the environment: toolchain, commands, services, display, credentials. If a required item is missing, check whether a small project-local harness/tool can remove the blocker; install only trusted, pinned tools. If it cannot be resolved safely, ask before starting.
3. Plan only as much as the risk requires. For a swarm, write a one-page brief, disjoint scopes, frozen contracts and acceptance checks. For direct/paired work, skip the ceremony.
4. Work. Direct, paired or batched workers. Keep files small enough that each worker reads only what it needs; use available concurrency, not a fixed wave number.
5. Verify. Technical checks first, then a fresh critic. For product work, add release performance, UX scenario, baseline comparison and the user's explicit verdict.
6. Accept and integrate. The lead owns shared files, final checks and the report. No next milestone without acceptance (or an explicit waiver).

If you swarm

Optional, for resumability and coordination — not a requirement for every task:

• .swarm/brief.md — goal, quality bar, commands, conventions, hazards;
• .swarm/contracts.md — only interfaces that cross a task boundary;
• .swarm/tasks/Txx.md — one page per unit;
• .swarm/reports/Txx.json — structured evidence, if the lead needs to triage many workers;
• .swarm/reviews/Vxx.md — independent verdict and findings.

Use the available concurrency directly. If workflow/subagent is unavailable, work sequentially with the same brief and scopes; never relaunch an oversubscribed fan-out. There are no mandatory templates: write a one-page brief and cards yourself, or use the bundled evals/ only to test the skill.

Optional modules

Read only what applies:

• references/domains.md — software, research, content, data, design, operations.
• references/prerequisites.md — preflight, install/approval policy.
• references/visual-testing.md — isolated displays, screenshots, computer-use limits.
• references/product-quality.md — performance/UX/baseline/human acceptance.
• evals/ — how to test this skill itself (baseline vs with-skill, trigger checks).

Signals

• Workers ask the same question or edit the same file → the plan or contracts are underspecified.
• Reports are long on prose and short on evidence → the task card lacks a check.
• The lead reads more tokens than the workers produce → waves or reports are too large.
• The same defect repeats → fix the brief, not the worker count.
• The product compiles and passes tests but feels worse than the previous version → stop adding features and run the product gate.
• You are creating process artifacts that nobody will read → delete them and do the work.
• You are changing this skill without evidence → run evals/README.md against a no-skill baseline; keep the change only if it improves quality/time without over-orchestration.