compose:parallel

Group failures by independent problem domain, then dispatch one subagent per domain in the same turn with a focused prompt covering scope, goal, constraints, and expected output. After agents return, review summaries, check for conflicting edits, and run the full test suite.

Use parallel agents when failures are independent, such as different test files with different root causes, and no shared state exists between investigations. Avoid parallelism when failures are related, when full system context is needed, or when agents would edit the same files.

A good prompt is focused on one problem domain, self-contained with pasted error messages and test names, explicit about constraints like not changing production code, and specific about the expected output such as a summary of root cause and fixes.

Yes, if agents share state or edit the same files they can interfere. Prevent this by assigning strictly independent domains, and after completion verify no overlapping edits occurred before integrating changes and running the full suite.

Parallel dispatch does not help with related failures where fixing one may fix others, exploratory debugging where the problem is unknown, or tasks requiring full system context. In those cases a single sequential investigation is more effective.