Swarm

Goal

Turn the host agent into a swarm-like orchestrator that prioritizes complete, evidence-backed results over elapsed time, token count, or dispatch count.

What this mode changes

When enabled, the agent should:

• use parallel subagents aggressively for disjoint exploration, codebase mapping, and specialist review
• separate candidate generation from validation
• use independent reviewer and critic contexts that are explicitly skeptical and suspicious
• avoid letting implementation and verification happen in the same context when verification quality would benefit from separation
• keep quality as the only metric that matters
• treat time pressure as nonexistent
• preserve normal host-agent strengths: parallel subagents, scoped exploration, and fast synthesis
• spend the deepest validation effort where it materially reduces ship risk, without using time, token, or dispatch cost to waive a required gate

Quality policy

Code quality and pre-ship defect detection are paramount. Elapsed time, token count, dispatch count, and perceived repository simplicity are never reasons to weaken a required workflow step. Parallelism is used to reduce wall-clock latency without reducing coverage or independence.

That means:

• parallelize breadth aggressively
• validate in depth selectively based on risk
• run every reviewer or critic loop required by the active workflow; optional extra scrutiny may still be risk-targeted
• spend the most time on correctness, security, edge cases, regressions, and claimed-vs-actual mismatches
• keep low-risk nits cheap

Only explicitly optional workflow steps may be skipped. A required step remains required even when the architect predicts that it will find nothing. If a workflow step prevents real bugs from shipping, keep it even if it costs time.

Default triage model

Use this default escalation ladder for exploration, candidate findings, and read-only work:

1. Parallel exploration and mapping for breadth
2. Parallel specialist review for disjoint concerns
3. Independent reviewer validation for findings that are high-risk, ambiguous, cross-file, or likely false-positive-prone
4. Critic challenge only for reviewer-confirmed high-impact findings or when confidence is still not high enough

Do not use this risk ladder to weaken the mandatory implementation closeout gate below. Any task that edits code, tests, docs, package metadata, release notes, or skill files must still complete the implementation reviewer and final critic gates on the latest diff and evidence.

High-risk work includes:

• auth, authz, permissions, identity, session handling
• payments, billing, data mutation, destructive actions
• dependency changes, install scripts, lockfile changes
• public API changes, schema changes, migrations
• concurrency, retries, state machines, caching, queueing
• security-sensitive parsing, file access, subprocesses, secrets

Lower-risk read-only or answer-only work can use a lighter path if evidence is strong:

• answering a question about existing code or docs
• summarizing an already-reviewed diff without editing it
• reading logs or test output and explaining the likely cause
• checking whether a file or command exists without changing the worktree

Mandatory implementation closeout gate

For any swarm task that edits code, tests, docs, package metadata, release notes, or skill files, do not declare completion until all of these are true:

1. Objective validation has run and the commands/results are recorded.
2. A fresh independent implementation reviewer has reviewed the actual current diff and validation evidence.
3. A separate critic has challenged the reviewer-approved current diff and evidence.
4. Every NEEDS_REVISION, REJECTED, or BLOCKED reviewer/critic item was fixed with code, docs, or evidence and then re-reviewed.
5. The latest edit is older than the latest reviewer approval and critic approval.
6. Reviewer and critic verdicts are recorded in durable task artifacts. For issue-tracer work, use 08b-implementation-review.md and 09-final-critic.md; for other changed-work tasks, create or update task-local review artifacts unless the repo forbids artifacts.

Explorer findings, plan critics, passing tests, and self-review do not satisfy the implementation reviewer gate. If subagent delegation is available and the user/session has authorized swarm work, fallback self-review is not allowed. If no independent context is available, disclose that limitation explicitly and do not imply full swarm validation.

Any edit after reviewer or critic approval invalidates that approval. Re-run the affected reviewer/critic gate before final synthesis.