swarm-implement

name	swarm-implement
description	Execute complex implementation work with a swarm-like workflow: parallel exploration, scoped planning, objective validation, mandatory independent implementation review for changed work, and final critic approval. Use for feature work, bug fixes, refactors, and multi-file changes.

/swarm-implement

Use this skill for implementation work when you want a fast, high-quality swarm workflow rather than a single-threaded assistant.

Purpose

Complete real coding tasks while preserving speed and adding swarm-style quality discipline.

Core operating model

Use this execution ladder:

1. Explore in parallel.
2. Build a scoped plan.
3. Implement in small, coherent units.
4. Run objective validation.
5. For any worktree edit, use independent reviewer validation on the latest diff and evidence.
6. For any worktree edit, use a separate final critic after reviewer approval.
7. Synthesize and report what changed, what was verified, and what remains risky.

Command Namespace

Swarm commands always use /swarm <subcommand>. Never invoke bare subcommand names that collide with host commands such as /plan, /reset, /checkpoint, or /status.

High-risk work

Always use the deeper validation path for auth, permissions, payments, destructive actions, dependency changes, public APIs, schemas, migrations, concurrency, queues, retries, state machines, caching, file access, subprocesses, parsing, secrets, security-sensitive logic, and large cross-file refactors with correctness risk.

Recommended workflow

Phase 0 - Establish scope

Determine the exact task scope first:

• what changed or needs to change,
• what files are likely involved,
• what success looks like,
• what must not be broken,
• what verification is required.

If the task is unclear, ask targeted questions or create a short written plan before coding.

Phase 0a - Parallel work check

Load and follow file:.swarm/bundled-skills/parallel-work-check/SKILL.md. Then, before starting implementation on an existing branch:

1. Fetch remote state and compare with local (git fetch plus HEAD hashes).
2. If parallel swarm work is detected on the target branch, read the new commits, decide whether to integrate, supersede, or proceed, and document the decision.
3. Prefer the parallel work unless you can clearly articulate why your approach is better.

Phase 0b - PR branch checkout pre-flight

When implementation or review-scoping work depends on explorer agents reading a PR branch or commit range, complete this before Phase 1 explorer dispatch:

1. Verify the working tree is clean with git status --porcelain. If uncommitted changes exist, you (the orchestrator) must handle them before Phase 1 dispatch — use prepare_pr_workflow_checkout (the controller-owned path; it preserves every dirty path — including untracked files when called with no paths argument — and returns a recovery command), or a git worktree (see running-tests skill precedent). Note: git branch tmp/save-<topic> only moves the HEAD ref — it does not record or preserve uncommitted working-tree changes, so do not rely on it to save dirty work. Never delegate git stash, git reset, git checkout -- ., or git restore to subagents — these are worktree-global operations that destroy sibling agents' in-flight work under parallel execution.
2. Fetch and check out the PR head branch locally. Explorer agents read files from the working tree (Read/Glob/Grep), not from git history, so a stale checkout makes them inspect the base branch.
3. Pass the exact commit range (base_ref..head_ref) in every explorer delegation so agents have revision context for targeted git show inspection.

Phase 1 - Parallel exploration

Launch parallel subagents for disjoint investigation tasks such as repository mapping, locating existing patterns, finding tests/contracts, side-effect analysis, and dependency or migration checks. Keep the main context focused.

Subagent prohibition — must reach every subagent prompt: Include this line verbatim in every subagent dispatch prompt: "You are a subagent sharing a worktree with sibling agents. You MUST NOT run git stash, git reset, git checkout -- ., git restore, or any other worktree-global destructive git command. These destroy sibling agents' in-flight work without error."

Phase 2 - Plan

Create a concrete implementation plan before editing for any non-trivial task. Include files to change, intended behavior, risks, validation commands, and whether reviewer and critic passes are required.

Phase 3 - Implement in scoped units

Implement in coherent, reviewable chunks. Follow existing repository patterns.

declare_scope discipline. Before every coder or test-engineer delegation (and before every retry), call declare_scope({ taskId, files, replace_existing: true }) with the exact workspace-relative file list the delegated agent may modify — including generated or lockfile paths the change will produce (for example, dist/*, package-lock.json, or bun.lock). Direct and shell writes are both scope-enforced. If the file list is not completely obvious, declare the containing workspace-relative directories instead. Treat SCOPE_CONFLICT, SCOPE_BINDING_EXPIRED, SCOPE_BINDING_AMBIGUOUS, and SCOPE_WORKSPACE_MISMATCH as architect-owned recovery signals: reconcile the named scope sources or lane root, replace the declaration, then redispatch. Never instruct the delegated agent to bypass the gate or switch write mechanisms.

Smallest justified scope on SCOPE_CONFLICT (issue #1994 S4). The replacement declaration must be the SMALLEST justified scope: first reconcile what the delegation actually intends to write (the task's files vs the conflicting scope source named in the diagnostic), then narrow the conflicting lower-precedence source to a subset of that list — repair stale plan scope with save_plan and/or the delegation's FILE: lines — and only then re-declare exactly that file list; re-declaring alone leaves the non-subset relation and reproduces the same SCOPE_CONFLICT. Split the task into separate delegations if the conflict reveals two disjoint write sets. NEVER resolve a SCOPE_CONFLICT by widening to a plan-inferred superset: auto-widening over-authorizes writes and hides an inaccurate plan or delegation prompt behind a bigger scope. This matches the execute skill's scope-recovery contract ("Do not widen scope just to make the sets agree"); a save_plan scope repair is a bookkeeping change covered by the critic-gate plan-freeze rule.

If the project exposes sast_scan with capture_baseline, capture the phase-scoped SAST baseline before first coder delegation so later scans fail only on new findings rather than pre-existing infrastructure noise.

Phase 4 - Objective validation

Run the strongest objective checks available for the task: tests, lint, typecheck, build, targeted repro scripts, and local runtime verification where relevant. If you cannot verify it, do not claim it is done.

Phase 5 - Independent reviewer validation

Use an independent reviewer subagent when the task edits code, tests, docs, package metadata, release notes, or skill files. The reviewer must inspect the actual current diff and validation evidence after implementation. Any later edit invalidates approval and requires re-review.

Reviewer responsibilities:

• inspect the implementation with fresh context,
• look for correctness bugs, edge cases, regressions, claim-vs-actual mismatches, and test blind spots,
• default to disbelief until evidence supports the change,
• classify issues as CONFIRMED, DISPROVED, UNVERIFIED, or PRE_EXISTING when useful,
• verify that at least one regression test in the diff has falsification evidence when the task claims regression coverage: the fix was temporarily removed or bypassed, the test failed for the expected reason, the fix was restored, and the test passed again. If no regression test is applicable, the reviewer must record why,
• return APPROVE, NEEDS_REVISION, or BLOCKED.

NEEDS_REVISION or BLOCKED blocks completion until fixed and re-reviewed.

Phase 6 - Critic challenge

Use a critic subagent after independent reviewer approval for any task that edits code, tests, docs, package metadata, release notes, or skill files. The critic must challenge the reviewer-approved current diff and evidence. Any later edit invalidates critic approval and requires another critic pass.

Phase 7 - Final synthesis

Before calling work complete, verify:

• objective validation ran and results were recorded,
• the independent reviewer approved the latest diff and evidence,
• a separate critic approved after reviewer approval,
• every NEEDS_REVISION or BLOCKED item was fixed and re-reviewed,
• no edit occurred after the latest reviewer/critic approval,
• no behavior is unwired or deferred without explicit user instruction.

Adapter notes

Runtime-specific adapter skills in .claude/skills/swarm-implement/ and .agents/skills/swarm-implement/ must stay thin and delegate to this canonical .opencode workflow.