42 lines
2.1 KiB
Markdown
42 lines
2.1 KiB
Markdown
---
|
|
name: dispatching-parallel-agents
|
|
description: Safely parallelize independent lanes with isolation checks, explicit ownership, and single-agent integration
|
|
permalink: opencode-config/skills/dispatching-parallel-agents/skill
|
|
---
|
|
|
|
# Dispatching Parallel Agents
|
|
|
|
Use this skill before parallel fan-out.
|
|
|
|
## Isolation Test (Required)
|
|
|
|
Before fan-out, verify that no two lanes share:
|
|
|
|
- **Claimed Files/Areas** under active mutation (paths or named workflow surfaces from the lane-claim entries)
|
|
- APIs or schemas being changed
|
|
- **Sequential verification dependencies** (verification steps that must run in order across lanes)
|
|
|
|
Overlapping claimed files/areas or sequential verification dependencies **forbid** parallel fan-out. Run those lanes sequentially.
|
|
|
|
## Workflow
|
|
|
|
1. **Builder creates lane-claim entries** in the execution note before fan-out, recording for each lane: `Owner`, `Status` (→ `active`), `Claimed Files/Areas`, `Depends On`, and `Exit Condition`.
|
|
2. Run the isolation test above against the claimed files/areas and dependencies. Abort fan-out on any overlap.
|
|
3. Define lane scope, inputs, and outputs for each subagent.
|
|
4. Assign a single integrator (usually builder) for merge and final validation.
|
|
5. Each lane must return **compact verification evidence** in the shared shape (`Goal`, `Mode`, `Command/Check`, `Result`, `Key Evidence`, `Artifacts`, `Residual Risk`) — not just code output.
|
|
6. Integrate in dependency order; update lane statuses to `released` or `done`.
|
|
7. Run final end-to-end verification (`full` mode) after integration.
|
|
|
|
## Planner/Builder Expectations
|
|
|
|
- **Planner**: define intended lanes and claimed files/areas in the approved plan when parallelization is expected.
|
|
- **Builder**: load this skill before fan-out, create or update lane-claim entries in the execution note, mark them `active`/`released`/`done`/`blocked`, and enforce lane boundaries strictly.
|
|
- Claims are advisory markdown metadata, not hard runtime locks. Do not invent lockfiles or runtime enforcement.
|
|
|
|
## Red Flags
|
|
|
|
- Two lanes editing the same contract.
|
|
- Shared test fixtures causing non-deterministic outcomes.
|
|
- Missing integrator ownership.
|