parallel-agentslisted

When you have several independent problems, investigating them one after another wastes time that could be spent in parallel. Hand each one to its own subagent with precisely the context it needs, let them work at once, then pull the results together. Each subagent should get exactly what you construct for it — never your whole session history — so it stays focused, and so your own context stays free for coordination. ## When this applies — and when it doesn't Dispatch in parallel when the problems are genuinely independent: different test files failing for different reasons, separate subsystems broken on their own, distinct bugs that can each be understood without the others. The test is whether fixing one could change another. If it can't, and they touch different code, they can run concurrently. Don't reach for this when: - The failures look related — fixing one might fix the rest. Investigate together first. - You'd need the full system in view to understand any of it. - You don't yet know what's broken (exploratory debugging — find the shape of the problem before fanning out). - The tasks share state or would edit the same files; concurrent agents there collide. ## The pattern **1. Split into independent domains.** Group the work by what's actually broken — "tool approval flow", "batch completion", "abort handling" — such that each group can be fixed without reference to the others. **2. Write a focused task per domain.** Each subagent prompt needs three things: