"dispatching-parallel-agents": Fix Test Failures in Parallel
機械翻訳 / Machine-translated
機械翻訳 / Machine-translated
Original article: テスト失敗を並行で直す「dispatching-parallel-agents」 (cccskills)
Skill page: dispatching-parallel-agents
Key Takeaways
Installing dispatching-parallel-agents enables agents like Claude Code to investigate and fix multiple test failures in parallel. It's a pattern for delegating failures with different root causes to separate sub-agents. This article explains how to divide responsibilities, write instructions, and integrate fixes. Installation steps and example prompts are also included.
When you present multiple test failures and make a request, the agent groups the problems by domain and assigns each to a sub-agent. Sub-agents are auxiliary agents that operate in a separate context from the original conversation. A request might look like this:
After a large refactoring, 6 tests across 3 test files are failing. If the causes are separate, please split them by file and fix them in parallel.
The agent first groups failures by "what is broken." The idea is to break them into units — like interrupt handling, batch completion behavior, and tool-approval race conditions — where fixing one won't affect the others.
It then drafts instructions for each responsible agent, specifying the target test files and goals, the areas not to touch, and what to report back.
Instructions for all three agents are sent together in a single response. Calling multiple sub-agents in one response makes them run in parallel; calling them one at a time makes them run sequentially.
Once results come back, the agent reviews each summary and checks whether any two agents edited the same code. After that, the full test suite is run before the changes are merged.
In the real example included in the skill, three agents each returned distinct fixes: one replaced a fixed wait time with an event-based wait, another corrected a bug in the event structure, and a third added a completion wait for an asynchronous process. There were no conflicts between the fixes, and the full test suite passed.
This skill is a pattern for parallel processing of mutually independent problems, with one agent per problem domain. Multiple failures that would take a long time to investigate sequentially can be tackled simultaneously. The workflow is divided into four stages.
The first decision is whether the failures are related to each other. Failures where fixing one is likely to fix the others are grouped and handled by a single agent. If failures are independent but share files or resources, they are assigned sequentially rather than in parallel.
Instructions for each agent are structured around four elements: scope, goal, constraints, and reporting. The scope is a single test file or subsystem. The goal might be "make this test pass," and a constraint might be "don't change any other code."
Sub-agents do not inherit the history of the original conversation, so all necessary information must be written into the instructions.
The skill also includes a comparison of bad and good examples of instructions. The key points are summarized in the table below.
| Aspect | Bad Example | Good Example |
|---|---|---|
| Scope | "Fix all the tests" | "Fix agent-tool-abort.test.ts" |
| Context | "Fix the race condition" | Paste the error message and test name |
| Constraints | No constraints stated | "Don't change production code" / "Fix tests only" |
| Reporting | "Just fix it" | "Return a summary of the cause and the changes made" |
The instruction template also includes a line like "don't just extend the timeout — find the real cause." This is a way of writing instructions that prevents superficial fixes.
There is also a defined process for review once work comes back. First, read each summary to understand what changed, then check whether multiple agents edited the same code.
Next, run the full test suite to confirm that all fixes work together. The final step is manually spot-checking some of the changes. Agents can repeat the same type of mistake, so this check is never skipped.
There are two ways to install: via a command, or by asking an agent to do it. To use the command, run the following:
npx skills add https://github.com/obra/superpowers --skill dispatching-parallel-agents
This command lets you choose which agent to install for, such as Claude Code or Codex. If you want to review the contents before installing, send the following message directly to your agent:
次の Agent Skill をインストールしてください。
https://github.com/obra/superpowers/tree/main/skills/dispatching-parallel-agents
まず SKILL.md と付属ファイルの中身を確認し、不審な処理(外部への送信、認証情報の読み取りなど)がないことを確かめてから、Claude Code なら ~/.claude/skills/dispatching-parallel-agents/、Codex なら ~/.agents/skills/dispatching-parallel-agents/ に配置してください。
The installation location depends on whether you want to use the skill across all projects or only in a specific one.
| Agent | All Projects | Specific Project Only |
|---|---|---|
| Claude Code | ~/.claude/skills/ | .claude/skills/ in the project |
| Codex | ~/.agents/skills/ | .agents/skills/ in the project |
The source is obra/superpowers.
Write your prompt with the situation as-is — the failing tests or the bugs you're seeing. Including error messages and test names lets you pass context into each agent's instructions.
Tests are failing in 3 files. Please organize the failures by root cause, and for those that are independent, split them among separate agents and investigate in parallel.
The agent groups failures by problem domain and decides whether they are independent. If they are, it writes instructions for each agent and sends them in parallel; if they are related, it returns a plan to investigate them together with a single agent.
Please have separate agents fix the login screen bug and the CSV export bug. Before starting, define the scope of changes allowed and what you want each to report back.
With this kind of prompt, instructions covering scope, goal, constraints, and reporting are presented for each agent first. Then the two agents run simultaneously, each returning a summary of the cause and the changes made.
Review the 3 fixes that came back, and if there are no conflicts, run the full test suite and then integrate them.
The agent reads each summary and checks whether any agents edited the same code. It confirms the full test suite results before merging the changes, then spot-checks some of the changes for review.
Before using this skill, confirm that the problems are truly independent. Parallel fixing only applies to problems that can be understood without waiting for other investigation results and that do not touch the same files or resources. The following situations are not suitable:
A prerequisite is an environment that can run multiple agents in parallel.
The skill contains only one file, SKILL.md, and is licensed under MIT. It is a good idea to open SKILL.md and read through it before installing.
Always review fixes from parallel work before integrating them. Even if each agent's tests pass individually, combining them may cause failures. Make running the full test suite and spot-checking a condition for integration.
The same obra/superpowers repository includes skills that can be used before and after parallel fixing.
systematic-debugging is a skill for investigating the cause of bugs and test failures using reproduction steps, logs, and recent changes. Use it at the stage when the cause is not yet clear, then move to parallel fixing once independent problems have been identified.
subagent-driven-development is a skill for delegating an implementation plan to separate agents per task. It is suited for dividing up new implementation work rather than bug fixes.
finishing-a-development-branch is a skill for verifying all tests after implementation is complete and proceeding to merge or Pull Request creation. It can be used as a finishing step after integrating parallel fixes.
It applies when there are two or more independent tasks with no shared state or ordering dependencies. A rough guideline given is a situation where 3 or more test files are failing for separate reasons.
No. Exploratory investigations where it is not yet clear what is broken are out of scope. Investigate the cause first, and use this skill once the problems have been broken down into independent pieces.
You can install it in the Codex installation location. However, the workflow assumes an environment capable of running multiple agents in parallel.
dispatching-parallel-agents is a pattern for fixing multiple failures with different root causes by dividing them among dedicated agents and working on them simultaneously. The flow is defined — from assessing independence, to writing four-point instructions, to reviewing before integration. If test failures are piling up and there isn't enough time to fix them one by one, give this a try. See the cccskills page for more details.
This article is a reprint of the cccskills feature "テスト失敗を並行で直す「dispatching-parallel-agents」."
Details about the skill and installation instructions can be found on the cccskills dispatching-parallel-agents page.