agentleFS
vindreshsinghvindreshsingh/engineering-skills/skills/parallel-subagents/SKILL.md

parallel-subagents

Skill0 starsChanged 5 months agoMITView on GitHub

Dispatches independent tasks to parallel subagents and integrates their results for faster, focused execution. Use when a plan has multiple independent tasks, or a task is large enough to delegate to a fresh focused agent.

2 other projects use a version of this.

Adopted by

Most recently taken up by

The file

We split this skill into the rules it gives an agent

3 rules. About 0 are common, 3 are distinctive, and 0 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈3

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 0

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Don't use it to parallelize tasks that share state or have ordering dependencies — those stay sequential.

    line 19
  2. Distinctive:

    Separate independent from dependent work: Only dispatch tasks with no shared mutable state and no ordering dependency on each other.

    line 24
  3. Distinctive:

    No source-of-truth plan; lost track of what each agent did

    line 50

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Parallel Subagents

A subagent is a fresh, focused worker with its own clean context. Dispatching independent tasks in parallel is faster and keeps each agent's context lean — but a subagent starts cold, so a vague brief or a hidden dependency turns the speedup into a mess of conflicts and rework. Dispatch only what's truly independent, brief it completely, and verify what comes back.

When to Use

  • A plan ([[work-planning]], [[orchestrated-delivery]]) has multiple independent tasks
  • A task is large or self-contained enough to hand to a focused agent
  • You want to keep the main thread's context lean ([[context-curation]]) by offloading detail

Don't use it to parallelize tasks that share state or have ordering dependencies — those stay sequential.

Process

  1. Separate independent from dependent work. Only dispatch tasks with no shared mutable state and no ordering dependency on each other. If task B needs A's output, they are sequential — do not parallelize them.
  2. Write a self-contained brief per subagent. It cannot see this conversation. Include: the goal, the context/background it needs, the skill(s) to follow, the exact files/paths, and the acceptance criteria that define done.
  3. Constrain scope to one clear deliverable. One task, one outcome — don't let a subagent wander into adjacent work.
  4. Dispatch in parallel and collect results.
  5. Integrate and verify. Review each result against its acceptance criteria, resolve any conflicts at the integration points, and run the tests on the combined result — not just each piece.
  6. Keep the source-of-truth plan current — mark tasks done as their results land and verify.

Common Rationalizations

  • "Dispatch everything for speed." — Parallelizing dependent tasks creates conflicting edits and rework.
  • "The subagent already has the context." — It doesn't; it cold-starts. Put everything in the brief.
  • "I'll integrate without reviewing." — Unverified merges combine three plausible-but-wrong results into one bug.
  • "One big subagent task is fine." — Unscoped tasks wander; one deliverable per agent.

Red Flags

  • Tasks with hidden dependencies dispatched in parallel → conflicting changes
  • Briefs that assume conversation context the subagent never had
  • Subagent output merged without checking it against acceptance criteria
  • Combined result never tested as a whole
  • No source-of-truth plan; lost track of what each agent did

Verification

  • Only independent tasks were dispatched in parallel; dependent ones sequenced
  • Each brief was self-contained (goal, context, skill, paths, acceptance criteria)
  • Each subagent had one clearly scoped deliverable
  • Results were integrated and verified against acceptance criteria
  • The combined result passes its tests; the plan was kept current

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.