The dispatching-parallel-agents skill, reviewed

What it tells the agent to do

1. Group the failures into independent domains, e.g. one test file or subsystem each
2. Write a focused, self-contained prompt per domain: scope, goal, constraints, expected output
3. Issue all subagent dispatches in the same response so they run in parallel
4. Read each returned summary and check whether agents edited the same code
5. Run the full test suite, spot check the fixes, then integrate the changes

Lines worth reading

Straight from the file, with why each one matters.

1. line 3Use when facing 2+ independent tasks that can be worked on without shared state or sequential dependencies

   Says when but not what. The words 'parallel' and 'subagent' appear only in the name.

2. line 77Multiple dispatch calls in one response = parallel execution. One per response = sequential.

   The one mechanical fact that makes the whole skill work, stated in a single line.

3. line 110Do NOT just increase timeouts - find the real issue.

   A sharp rule against the classic flaky-test cop-out, built into the sample prompt.

4. line 373+ test files failing with different root causes

   The description says 2+, the body says 3+. A small mismatch in the threshold.

5. line 167Agents can make systematic errors

   A frank reminder that the subagents' summaries are claims to verify, not facts.

Watch out for

• Low

  Subagents may 'fix' tests by loosening expectations. The template allows this without asking them to flag it.

  line 108Adjusting test expectations if testing changed behavior

The scorecard

• TriggerSays when to use it
  6/10

  Clear on when, silent on what it does. Lacks 'parallel' and 'subagents'.

• FocusOne clear job
  8/10

  One job: fan out independent problems, then reunite the results.

• LeanLight to load
  7/10

  168 lines, but the when-to-use and verification sections each appear twice.

• ConcreteSteps you can follow
  7/10

  Real prompt template and dispatch example. Few checks beyond 'run full suite'.

• SafeSafe to run
  9/10

  No commands, network or secrets. Only a slight test-weakening loophole.

How it could be better

1. Say what the skill does in the description

   The agent decides from the description alone, and right now it never mentions subagents or parallel dispatch.

   Add

   description: Dispatches one subagent per independent problem in a single response so they run in parallel, then reviews and integrates their results. Use when facing 2+ independent tasks, such as several test files failing for unrelated reasons, with no shared state or sequential dependencies.

   Copy

2. Merge the duplicated sections

   'When to Use' overlaps 'When NOT to Use', and 'Review and Integrate' overlaps 'Verification', costing context for nothing.

   Add

   ## When NOT to Use
   - Related failures: fixing one might fix others
   - Exploratory debugging: you don't know what's broken yet
   - Shared state: agents would edit the same files or resources
   
   ## Verification
   1. Review each summary
   2. Check whether agents edited the same code
   3. Run the full suite
   4. Spot check: agents can make systematic errors

   Copy

3. Make subagents flag weakened tests

   Changing test expectations can hide real bugs, so the parent agent should see every such change explicitly.

   Add

   If you change any test expectation, list each one in your summary with the old value, the new value and why the behavior legitimately changed.

   Copy

4. Pick one threshold, 2+ or 3+

   The description and the 'Use when' list disagree on how many independent problems justify fanning out.

   Add

   - <N>+ test files failing with different root causes

   Copy