swarm-implement

name	swarm-implement
description	Execute complex implementation work with a swarm-like Claude Code workflow: parallel exploration, scoped planning, selective deep validation, and independent reviewer/critic checks where risk justifies them. Use for feature work, bug fixes, refactors, and multi-file changes.

/swarm-implement

Use this skill for implementation work when you want Claude Code to behave like a fast, high-quality swarm rather than a single-threaded assistant.

Purpose

Complete real coding tasks across many projects while preserving Claude Code 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. Use independent reviewer validation where the risk justifies it.
6. Use critic challenge only for high-impact or still-ambiguous results.
7. Synthesize and report what changed, what was verified, and what remains risky.

This is not a slow full-swarm recreation. This is a speed-preserving, quality-maximizing workflow.

Quality and speed policy

• Quality and pre-ship defect detection are paramount.
• Speed still matters.
• Parallelism is the default speed lever.
• Deep validation is concentrated where bugs are expensive.
• Low-risk work should stay lightweight when extra depth would not materially improve quality.
• High-risk work must always get the deeper validation path.

High-risk work

Always use the deeper validation path for:

• auth, authz, identity, sessions, permissions
• payments, billing, money movement, destructive actions
• dependency changes, install scripts, lockfile changes
• public API changes, schema changes, migrations
• concurrency, queues, retries, state machines, caching
• file access, subprocesses, parsing, secrets, security-sensitive logic
• 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 a small number of targeted questions or create a short written plan before coding.

Phase 1 — Parallel exploration

Launch parallel subagents for disjoint investigation tasks such as:

• repository mapping for relevant subsystems
• locating existing patterns to follow
• finding tests, schemas, contracts, and integration points
• identifying likely side effects and touched modules
• checking dependency or migration implications

Do not use the main thread for broad repo reading if subagents can do it. Keep the main context focused.

Phase 2 — Plan

Create a concrete implementation plan before editing for any non-trivial task. The plan should include:

• files to change
• intended behavior
• risks and likely regressions
• validation commands
• whether reviewer and critic passes will be required

Phase 3 — Implement in scoped units

Implement in coherent, reviewable chunks. Avoid giant speculative rewrites. Follow existing repository patterns unless there is a strong reason not to.

Phase 4 — Objective validation

Always run the strongest objective checks available for the task:

• tests
• lint
• typecheck
• build
• targeted repro scripts
• 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 is:

• high-risk
• cross-file
• behavior-sensitive
• likely to hide edge-case bugs
• security-sensitive
• likely to produce false confidence from the implementation context

Reviewer responsibilities:

• inspect the implementation with fresh context
• look for correctness bugs, edge cases, regressions, claim-vs-actual mismatches, and test blind spots
• be hyper-critical and suspicious
• default to disbelief until evidence supports the change
• identify whether issues are CONFIRMED, DISPROVED, UNVERIFIED, or PRE_EXISTING when useful

Phase 6 — Critic challenge

Use a critic subagent only when needed:

• reviewer found high-impact issues
• confidence is still borderline
• the change touches high-risk systems
• the implementation appears polished but may hide requirement drift or false confidence

Critic responsibilities:

• challenge reviewer-confirmed findings
• look for severity inflation, weak evidence, missing sibling-file checks, and poor actionability
• prefer removing weak claims over adding noise

Phase 7 — Final synthesis

In the main thread, summarize:

• what changed
• what was verified
• what reviewers found
• what critic challenged
• final remaining risks
• whether the task is actually complete

Hard rules

• Do not let implementation context self-approve high-risk work.
• Do not skip reviewer validation for high-risk work.
• Do not skip objective verification because the code looks right.
• Do not let perceived repo size or task size compress the workflow.
• If quality and speed conflict, quality wins.
• If extra validation does not materially improve quality, keep the path lightweight.

Suggested subagent prompts

Explorer-style

Use for broad discovery:

• map the assigned subsystem quickly
• identify likely files, patterns, contracts, tests, and risks
• return a concise actionable summary
• do not edit code

Reviewer-style

Use for implementation validation:

• review the implementation with fresh context
• be hyper-critical and suspicious
• look for edge cases, regressions, hidden coupling, and claimed-vs-actual mismatches
• verify whether the tests actually prove behavior
• return only high-signal findings

Critic-style

Use for final challenge:

• challenge high-impact conclusions
• check whether findings are overclaimed or weakly evidenced
• challenge severity and actionability
• look for what the previous layer may have missed

Use across many repos

This skill is intentionally project-agnostic. It should adapt to each repository by exploring first, following local patterns, and scaling validation depth to actual risk.