agentleFS
Sign inStart free
OpenxIntelligenceOpenxIntelligence/Coding-Agent-Skills/dispatching-parallel-agents/SKILL.md

dispatching-parallel-agents

Skill4 starsChanged 25 days agoMITView on GitHub

Dispatch one focused agent per independent problem domain so investigations run concurrently. Use when facing 2+ independent tasks with no shared state — for example "spawn agents in parallel", "parallel debugging", "fan out tasks", "investigate multiple failures at once", or "distribute independent work across agents".

189 other projects use a version of this, 149 of them edited.

Adopted by

Most recently taken up by

Used with

Projects with it also use chinese-code-review, chinese-commit-conventions and 8 more.

Other files people use alongside this one.

Files found in the same public projects as a version of this one, more often than they turn up anywhere else. Each project counts once, large collections count for less, and this file's own repository is left out.
  • Leodorareluctant259Skill

    chinese-code-review

    中文代码审查规范——在保持专业严谨的同时，用符合国内团队文化的方式给出有效反馈

    Also in 8 projects that use this

  • Leodorareluctant259Skill

    chinese-commit-conventions

    中文 Git 提交规范 — 适配国内团队的 commit message 规范和 changelog 自动化

    Also in 8 projects that use this

  • obraSkill

    diagnosing-superpowers

    Use when a superpowers session went wrong and your human partner wants to know why — repeated work, ignored plans, stumbles, poor results, a skill that didn't fire, "it took too long", "why is it so expensive", "what is it doing" — or wants to build a bug report for the superpowers maintainers, for the current session or a past one identified by id or path, on any harness.

    Also in 19 projects that use this

  • kntismSkill

    condition-based-waiting

    Use when tests have race conditions, timing dependencies, or inconsistent pass/fail behavior - replaces arbitrary timeouts with condition polling to wait for actual state changes, eliminating flaky tests from timing guesses

    Also in 3 projects that use this

  • xfstudioSkill

    context-driven-development

    Use this skill when working with Conductor's context-driven

    Also in 3 projects that use this

  • EvezArtSkill

    analytics-dashboard

    User behavior tracking and analytics dashboards

    Also in 3 projects that use this

  • +3 more from Leodorareluctant259

The file

We split this skill into the rules it gives an agent

4 rules. 3 are common, 1 is distinctive, and 0 are very specific to this project.

  • 3

    Common

    Most of the 178 edited versions we read keep these.

  • 1

    Distinctive

    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. Common:

    When you have multiple unrelated failures (different test files, different subsystems, different bugs), investigating them sequentially …

    line 18
  2. Common:

    No shared state between investigations

    line 27
  3. Distinctive:

    Verify fixes don't conflict (did any two agents touch the same file?)

    line 64
  4. Common:

    Run the full test suite

    line 65

“Common” is measured: kept by at least 6 in 10 of the 178 edited versions of this file we could read. “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

Dispatching Parallel Agents

Contents

  • When to Use
  • When NOT to Use
  • The Pattern
  • Verification
  • References

Overview

When you have multiple unrelated failures (different test files, different subsystems, different bugs), investigating them sequentially wastes time. Each investigation is independent and can happen in parallel.

Core principle: dispatch one agent per independent problem domain. Let them work concurrently.

When to Use

  • 3+ test files failing with different root causes
  • Multiple subsystems broken independently
  • Each problem can be understood without context from the others
  • No shared state between investigations

When NOT to Use

  • Related failures — fixing one might fix others; investigate together first
  • Need full context — understanding requires seeing the entire system
  • Exploratory debugging — root cause is still unknown
  • Shared state — agents would interfere (editing same files, holding same locks)

See references/integration-examples.md for a decision flowchart.

The Pattern

1. Identify independent domains

Group failures by what's broken. If two failures sit in unrelated subsystems and fixing one cannot affect the other, they're independent domains.

2. Create focused agent tasks

Each agent gets:

  • Specific scope — one test file or subsystem
  • Clear goal — make these tests pass
  • Constraints — don't change other code
  • Expected output — summary of what was found and fixed

See references/prompt-template.md for the full template and common-mistake patterns.

3. Dispatch in parallel

Issue all Task(...) calls in a single tool batch so they run concurrently. Sequential dispatches defeat the purpose.

4. Review and integrate

When agents return:

  • Read each summary
  • Verify fixes don't conflict (did any two agents touch the same file?)
  • Run the full test suite
  • Integrate all changes

Verification

Confirm success with all of:

  • Every dispatched agent returned a summary (none silently failed)
  • No two agents modified the same file (or if they did, the merges are intentional)
  • Full test suite passes locally
  • Each original failure is now green
  • Spot-check at least one fix manually — agents can make systematic errors

References

  • references/prompt-template.md — agent prompt template, common mistakes
  • references/integration-examples.md — full worked example, decision flowchart, dispatch syntax

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.

Check your setup, free