mikeparcewski/wicked-garden-swarm
skills/swarm/SKILL.md
Parallel verification-swarm orchestration playbook: fan out N scoped subagents over N units of work (repos / modules / files), then run a SEPARATE verifier wave that re-derives each result from a clean state — self-graded "done" is rejected. Composes the crew agents, the qe semantic-reviewer, /wicked-garden:prove, wicked-vault attestation, and the worktrees + deliberate skills rather than reinventing them. This is multi-AGENT parallel execution+verification; for independent multi-MODEL perspectives use jam:council instead. Use when: multi-unit / fan-out work ("review every repo", "resolve the backlog with proof", "apply this across all modules", "audit each service"), high-blast-radius changes that need independent verification, or any run where a claimed "done" must be re-derivable from receipts.
$ install --global
skillsauthnpx skillsauth add mikeparcewski/wicked-garden wicked-garden-swarmInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
Security Scan Results
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
3
Scanners Passed
9
Scanners in report
Clean
TrivyContainer and dependency vulnerability scanner
95%
Clean
SemgrepStatic code analysis for vulnerabilities
95%
Clean
mcp-scan (Snyk)Model Context Protocol security validation
95%
Skipped
Snyk (dep)Open source security scanning
50%
Skipped
Socket.devSupply chain security analysis
50%
Skipped
VirusTotalMulti-engine malware detection
50%
Skipped
CrowdStrikeAdvanced threat intelligence
50%
Skipped
OSV-ScannerOpen Source Vulnerability database check
50%
Skipped
OWASP Dep-Check
50%
Last scanned: Jul 13, 2026, 8:06 AM153.8s6 files scanned
SKILL.md
- name:
- wicked-garden-swarm
- context:
- fork
- description:
- |
- Parallel verification-swarm orchestration playbook:
- fan out N scoped
- semantic-reviewer, /wicked-garden:
- prove, wicked-vault attestation, and
- perspectives use jam:
- council instead.
- Use when:
- multi-unit / fan-out work ("review every repo", "resolve the
- status:
- stable
- phase_relevance:
- ["build", "test", "review"]
- archetype_relevance:
- ["build", "review", "migrate", "modernize", "incident"]
Swarm — parallel verification swarm
Orchestrate N units of work in parallel (one scoped subagent per unit), then independently verify every result with a separate wave of agents that re-derive "done" from a clean state. The swarm's value is not the parallelism — it's that no agent grades its own work. A claimed "tests pass" / "done" that can't be re-derived from receipts is rejected.
Swarm vs council.
jam:councilgets independent multi-model opinions on one decision (different vendors answer the same scaffold). Swarm gets parallel multi-agent execution + verification over many units. Use council to decide; use swarm to execute-and-prove. They compose: run a council inside the verify wave for a high-stakes verdict (seerefs/independent-verification.md).
Compose, don't reinvent
This skill is orchestration prose. Every primitive it needs already exists in the garden — reference these, do not duplicate them:
| Need | Use (existing garden piece) |
|------|------------------------------|
| Per-unit implementer subagent | wicked-garden-crew-implementer fork skill (skills/crew-implementer/) — already does parallel-when-independent + evidence |
| Per-unit recon subagent | wicked-garden-crew-researcher fork skill (skills/crew-researcher/) — read-only context gathering |
| Independent semantic verdict | wicked-garden-qe-semantic-reviewer fork skill (skills/qe-semantic-reviewer/) — independent-by-construction; refuses to attest its own work |
| Fallback reviewer | wicked-garden-crew-reviewer fork skill (skills/crew-reviewer/) — reviewer-separation + external-review rules baked in |
| Re-derive a claim (the receipt) | /wicked-garden:prove (run + freeze evidence + gate; fail-closed) |
| Hard-gate independent sign-off | /wicked-garden:prove --with-attestations → wicked-vault attest (evaluator ≠ creator, G10) |
| Blast-radius / scope lens | wicked-garden:deliberate (lens 2 + 3) and /wicked-garden:search:blast-radius |
| Per-unit isolation + commit hygiene | wicked-garden:worktrees (dangling-commit trust-but-verify) |
| Phase shape per unit | wicked-garden:archetype refs (build / review / migrate) |
| Multi-model verdict in a wave | wicked-garden:jam:council |
The wave loop
0. recon → parallel researcher agents → concept catalog + per-unit profiles
synthesize → fit-matrix + relevance tiers
checkpoint → ONE structured scope question to the user (skip under full latitude)
1. implement → N parallel implementer agents (one per unit, self-contained brief)
each writes DETAILED artifacts to disk, returns a ~150-word summary
2. verify → M parallel verifier agents (SEPARATE from implementers)
re-run from clean state, read the ACTUAL diff, render PASS/FAIL/PARTIAL
3. receipts → /wicked-garden:prove per claim; hard gates add --with-attestations
4. ship → branch per unit, conventional commits, CI-green, independent review,
clean merge tree, tag-driven release (only when asked)
Each numbered step has a ref. Waves hand off via disk artifacts, never via the orchestrator's context — that is what keeps the parent lean and the run auditable.
Orchestrator hygiene (the parent context stays lean)
- Detail to disk, summary to context. Subagents write the full profile / plan / diff / receipt to the scratch dir and return ≤150 words. Never let a subagent dump raw output into your context.
- One message, many Task calls for each wave — that is what makes it
parallel. A serial run with no documented
serial_reasonis a protocol miss (same rule thewicked-garden-crew-implementerfork skill enforces). - Background long/external work and synthesize on completion rather than blocking the wave.
- The verifier is a different agent than the implementer. If the same agent
type did the work, the verdict is a self-grade — the
wicked-garden-qe-semantic-reviewerfork skill and the vaultattestboth refuseevaluator == creator.
The two reusable briefs
The mechanics that make this repeatable are the briefs handed to each wave.
Both live in refs/fan-out.md (implementer) and refs/independent-verification.md
(verifier) as copy-paste templates. The shape:
- Implementer brief (per unit): read THIS unit's own rules/conventions → impact analysis (blast radius) BEFORE changing → implement with in-scope tech-debt cleanup only (no opportunistic refactor sprawl) → functionally test proportional to blast radius → write artifacts to disk → return a concise summary.
- Verifier brief (per unit): ignore the implementer's prose → re-run the suite/build from clean → read the ACTUAL diff → check over-claims (e.g. a claimed "pre-existing failure" must actually fail on the BASE commit) → render PASS / FAIL / PARTIAL → write the authoritative receipt.
Honest marking (no padding)
Mark every finding GAP / PARTIAL / ALREADY-COVERED. Surface
reverse-transfers and "you're already ahead of this" honestly. A short true
list beats a long speculative one. Record considered-and-rejected items
explicitly so they read as weighed, not missed. Details in
refs/receipts-and-evidence.md.
Recon-first, then checkpoint
Before an expensive fan-out, run the recon wave and synthesize a fit-matrix +
relevance tiers, then checkpoint scope with the user in a single structured
question. Under an explicit goal / full latitude, proceed without asking.
Full procedure in refs/recon-synthesis.md.
Disk-artifact layout (waves hand off here)
A scratch dir (the worked example this playbook was distilled from used
.cross-pollination/) with a top synthesis/index doc, per-unit
profile/plan/review/receipt files, and a deferred-items log. Exact tree in
refs/recon-synthesis.md §layout and refs/receipts-and-evidence.md.
Refs
- refs/recon-synthesis.md — recon wave, fit-matrix, relevance tiers, the single checkpoint question, scratch-dir layout
- refs/fan-out.md — parallel implementer wave + the implementer brief template, impact analysis, in-scope cleanup
- refs/independent-verification.md — the verifier wave + the verifier brief template, isolation, over-claim kills, PASS/FAIL/PARTIAL
- refs/receipts-and-evidence.md — verbatim receipts, prove/vault/wicked-testing composition, honest GAP/PARTIAL/ALREADY-COVERED marking
- refs/ship-discipline.md — branch-per-unit, conventional commits, CI-green gate, independent review + resolve, clean merge tree, tag-driven release
Related Skills
mikeparcewski/wicked-garden-engineering-conformance-reviewer
development
VerifiedTrustedCommunity
Pattern-conformance agent-half: evaluates a produced artifact or diff against a set of architectural/design pattern rules from the conformance-rule store (wicked_governance schema). Returns structured findings with rule ID, severity, and rationale — the deterministic half (mechanical rule recall) is done by the guard pipeline; this is the semantic evaluation step. Triggered by: the guard_pipeline `outgov_pattern` check (session-close), or explicitly by an engineering review when WICKED_OUTGOV_RULES_DIR is populated. NOT a replacement for the full `engineering` review skill — focuses only on conformance to stored Pattern rules; architecture and code-quality checks live in the `engineering` skill. Semantic evaluation reuses `wicked-garden-qe-semantic-reviewer` as the designated agent-half evaluator (per garden#983 spec). This skill is the orchestrating wrapper that loads applicable Pattern rules and delegates the per-rule semantic judgment to qe-semantic-reviewer.
8SKILL.mdUpdated Jul 22, 2026
mikeparcewski/wicked-garden-domain
tools
VerifiedTrustedCommunity
The FOUNDATIONAL domain-model capability: extract a codebase's domain — testable business rules (with confidence + provenance), entities, requirements — as a schema-conformant model on the estate graph. The workers annotate the store; wicked-core reads it and builds the requirements graph, coverage-gating fail-closed. Steers three fork workers. A shared substrate, not a modernization tool. The `modernize` archetype DERIVES from it; build / migrate / review / specify / explore consume the SAME domain model — none OWN it. Understanding a codebase's domain is upstream of almost everything else garden does. Use when: "extract the business rules / domain model from this codebase", "build a requirements graph from the code", "what does this system actually require", "reverse-engineer the domain before we build/port/migrate". Works on ANY codebase (modern or legacy) — the value is the domain model, not the porting. NOT the code transform itself (that is the archetype consuming this model). This skill produces the DOMAIN MODEL, not new code.
8SKILL.mdUpdated Jul 15, 2026
mikeparcewski/wicked-garden-domain-modeler
development
VerifiedTrustedCommunity
Domain-graph fork worker for the modernize archetype. Groups the estate's Louvain communities into business domains, attaches each requirement to its cluster (advisory cluster_id provenance), and invokes wicked-core's domain-graph build (which reads the annotated estate store, recomputes coverage fail-closed, and builds the requirements graph) — then validates core's output against the vendored schema. Use when: dispatched by wicked-garden-domain after rule extraction to turn a flat rule set into cluster-keyed domains; "group these into domains", "build the requirements graph", "translate clusters into a domain model". NOT for mining the rules themselves (that is domain-extractor) or threat-modeling (that is domain-coverage).
8SKILL.mdUpdated Jul 15, 2026
mikeparcewski/wicked-garden-domain-extractor
tools
VerifiedTrustedCommunity
Rule-extraction fork worker for the FOUNDATIONAL domain-model capability. Mines testable business rules from a codebase — each with a numeric confidence and a provenance{source, ref, source_kinds} — and annotates them into the estate store so wicked-core can build the domain-model requirements graph (coverage-gated). This is a substrate, not a modernization tool: the `modernize` archetype DERIVES from it, and build / migrate / review / specify / explore can consume the same domain model — none OWN it. Use when: dispatched by wicked-garden-domain to mine the business_rules of a codebase (or a module); "extract the domain rules", "what does this system require", building the requirements half of a domain model. NOT for grouping into domains (that is domain-modeler) or judging coverage (that is domain-coverage — a seat-distinct evaluator).
8SKILL.mdUpdated Jul 15, 2026