Swarm explore

Skill blakecyze/swarm/skills/swarm-explore

Use when the user wants to map a large codebase, gather context from many files at once, or investigate a problem space in parallel. Read-only fan-out. Never writes.From its SKILL.md

Install

npx -y skills add blakecyze/swarm --skill swarm-explore

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

1 stars1 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

SKILL.md

3.4 KB, as published. Nobody here has run it

swarm-explore

Fan out read-only investigation across many slices at once, then synthesise. This is the highest-value swarm pattern and the safest, because reading in parallel has no side effects. Use it to build context fast: map an unfamiliar codebase, trace how a feature works across many files, or gather evidence for a question from many sources.

The principles from swarm-principles apply. This skill is strictly read-only.

The hard rule

Explore never writes. No edits, no commits, no file creation beyond the synthesis report. Each subagent is briefed read-only. If the investigation reveals work to do, that is a separate skill's job: /swarm-improve to capture it as plans, or /swarm-refine to harden a specific artefact.

When this earns its keep

Reading is embarrassingly parallel. Ten agents each mapping a different module return in the time one agent maps one. The merge (synthesising findings) is usually cheap because findings are additive, not competing. This is the pattern where fan-out most reliably wins.

Process

Define the question. What are we trying to learn? "How does auth work here" is answerable. "Look at the code" is not. Sharpen it.
Slice the search space. By module, by directory, by concern, by source. Each slice should be investigable without the others.
Check the cost ceiling. More than 5 slices means confirm or batch into waves.
Brief each subagent read-only. Give it: the question, its slice (explicit paths), the report format, and the read-only boundary. Ask each to report findings, not raw dumps. A subagent that returns 2000 lines of pasted code has failed. It should return what it learned.
Synthesise. Collect the reports, reconcile overlaps, resolve contradictions (two agents disagree means dig in), and produce one coherent map.

Subagent brief template

Read-only investigation. Do not edit, create, or commit anything.
Question: <the sharpened question>
Your slice: <explicit paths or sources>
Report back:
- Key findings relevant to the question (prose, not code dumps)
- Specific file:line references for anything important
- Anything surprising or contradictory
- What you could NOT determine from your slice
Keep it under <N> lines. Learnings, not transcripts.

Output format

## Exploration: <the question>

**Slices:** <N> agents across <what>

### What we found
<synthesised answer to the question, in prose>

### Map
- <area> — <what it does> (`file:line`)
- <area> — <...>

### Contradictions / open questions
- <where agents disagreed, or what none could determine>

### Cost
<N> agents, roughly <M>x a single read pass.

Failure modes to avoid

Slices that overlap heavily. You pay N times to read the same files. Slice by disjoint paths.
Subagents returning raw code instead of findings. Brief them to synthesise.
Letting an "explore" quietly become an "edit". The moment a change is warranted, stop and hand off.
Fanning out a question one agent could answer by reading three files. Not everything needs a swarm.