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.
disable-model-invocation: true
/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:
- Explore in parallel.
- Build a scoped plan.
- Implement in small, coherent units.
- Run objective validation.
- Use independent reviewer validation where the risk justifies it.
- Use critic challenge only for high-impact or still-ambiguous results.
- 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.
