ring:dispatching-parallel-agents

Dispatching Parallel Agents

Safety Notice

This listing is imported from skills.sh public index metadata. Review upstream SKILL.md and repository scripts before running.

Copy this and send it to your AI assistant to learn

Install skill "ring:dispatching-parallel-agents" with this command: npx skills add lerianstudio/ring/lerianstudio-ring-ring-dispatching-parallel-agents

Dispatching Parallel Agents

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

Decision flow: Multiple failures? → Are they independent? (No → single agent) | Independent? → Can work in parallel? (No/shared state → sequential) | Yes → Parallel dispatch

Use when: 3+ test files with different root causes | Multiple subsystems broken independently | Each problem understood without others | No shared state

Don't use when: Failures related (fix one might fix others) | Need full system state | Agents would interfere

The Pattern

  1. Identify Independent Domains: Group failures by what's broken (File A: approval flow, File B: batch behavior, File C: abort). Each domain independent.

  2. Create Focused Agent Tasks: Each agent gets: specific scope (one file/subsystem), clear goal (make tests pass), constraints (don't change other code), expected output (summary of findings/fixes).

  3. Dispatch in Parallel: Task("Fix agent-tool-abort.test.ts")

  • Task("Fix batch-completion.test.ts")
  • Task("Fix tool-approval-races.test.ts")
  • all concurrent.
  1. Review and Integrate: Read summaries → verify no conflicts → run full test suite → integrate all changes.

Agent Prompt Structure

Good prompts are: Focused (one problem domain), Self-contained (all context included), Specific output (what to return).

Example: "Fix 3 failing tests in agent-tool-abort.test.ts: [list tests + expected behavior]. Timing/race issues. Read tests → identify root cause → fix (event-based waiting, not timeout increases). Return: Summary of findings and fixes."

Common Mistakes

❌ Bad ✅ Good

Too broad: "Fix all tests" Specific: "Fix agent-tool-abort.test.ts"

No context: "Fix race condition" Context: Paste error messages + test names

No constraints: Agent refactors everything Constraints: "Do NOT change production code"

Vague output: "Fix it" Specific: "Return summary of root cause and changes"

When NOT to Use

Related failures (fix one might fix others) | Need full context | Exploratory debugging | Shared state (same files/resources)

Real Example

Scenario: 6 failures across 3 files after refactoring. Decision: Independent domains → parallel dispatch. Results: Agent 1 (timeouts → events), Agent 2 (event structure bug), Agent 3 (async wait). All independent, no conflicts, suite green. 3 problems solved in time of 1.

Key Benefits

Parallelization (simultaneous) | Focus (narrow scope) | Independence (no interference) | Speed (3 → 1 time unit)

Verification

After agents return: Review summaries → check for conflicts → run full suite → spot check for systematic errors.

Blocker Criteria

STOP and report if:

Decision Type Blocker Condition Required Action

Independence check Problems share state or files STOP and use sequential investigation instead

Minimum threshold Fewer than 3 independent failures STOP and investigate directly without parallel dispatch

Conflict detection Agent changes would overlap STOP and re-partition domains

Context requirements Problem requires full system context STOP and use single agent investigation

Cannot Be Overridden

The following requirements CANNOT be waived:

  • Problems MUST be verified independent before parallel dispatch - shared state means sequential

  • Minimum 3 failures REQUIRED for parallel dispatch - fewer means direct investigation

  • Each agent MUST have focused scope (one file/subsystem) - broad scope is FORBIDDEN

  • Agent prompts MUST include constraints about what NOT to change

  • Full test suite MUST run after integrating all agent changes

Severity Calibration

Severity Condition Required Action

CRITICAL Dispatched agents for related/connected failures MUST stop and switch to sequential investigation

CRITICAL Agent changes conflict with each other MUST re-partition domains and re-dispatch

HIGH Agent prompt lacks scope constraints MUST add specific "do NOT change" constraints

HIGH Skipped post-integration test suite MUST run full test suite before completion

MEDIUM Agent prompt lacks expected output format Should add specific output requirements

LOW Could optimize domain partitioning Fix in next iteration

Pressure Resistance

User Says Your Response

"Just dispatch agents for all failures, don't analyze" "MUST verify independence first. Related failures need sequential investigation to avoid conflicts."

"Two failures is enough for parallel dispatch" "CANNOT dispatch for fewer than 3 failures. Direct investigation is faster for 1-2 problems."

"Skip the verification step, agents finished successfully" "MUST run full test suite after integration. Agent success doesn't guarantee no conflicts."

"Give agents broad scope to fix more issues" "Focused scope prevents interference. MUST limit each agent to one file/subsystem."

Anti-Rationalization Table

Rationalization Why It's WRONG Required Action

"These failures look independent enough" Looking independent ≠ verified independent; check for shared state MUST verify independence before dispatch

"Dispatching for 2 failures saves time" Overhead of parallel dispatch exceeds benefit for <3 failures MUST investigate directly if fewer than 3

"Agents can figure out their own scope" Unclear scope causes agents to interfere with each other MUST provide explicit scope and constraints

"Test suite passed for each agent" Individual success doesn't catch integration conflicts MUST run full suite after integration

"Re-partitioning is too much work" Conflicting changes create more work than re-partitioning MUST re-partition if domains overlap

Source Transparency

This detail page is rendered from real SKILL.md content. Trust labels are metadata-based hints, not a safety guarantee.

Related Skills

Related by shared tags or category signals.

Automation

ring:testing-agents-with-subagents

No summary provided by upstream source.

Repository SourceNeeds Review
Automation

ring:testing-skills-with-subagents

No summary provided by upstream source.

Repository SourceNeeds Review
Automation

ring:using-finops-team

No summary provided by upstream source.

Repository SourceNeeds Review