changes

.config/opencode/skills/dispatching-parallel-agents/SKILL.md

@@ -1,50 +1,38 @@
 ---
 name: dispatching-parallel-agents
-description: Dispatch focused subagents in parallel for genuinely independent problem domains
+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
 
-## Core Value
+Use this skill before parallel fan-out.
 
-When there are 2+ genuinely independent failures/problem domains, dispatch one focused agent per domain concurrently instead of serial investigation.
+## Isolation Test (Required)
 
-## When to Use
+Parallel lanes are allowed only when lanes do not share:
 
-Use when all are true:
-- You have multiple failures across separate domains.
-- Each domain can be investigated without shared context/state.
-- Agents can work without touching the same files or interfering.
+- files under active mutation
+- APIs or schemas being changed
+- verification steps that must run in sequence
 
-Do **not** parallelize when:
-- Failures may share a root cause.
-- You still need a single root-cause investigation first.
-- Agents would edit the same area and conflict.
+If any of these overlap, run sequentially.
 
-## Dispatch Pattern
+## Workflow
 
-1. Split failures into independent domains.
-2. Write one prompt per domain.
-3. Dispatch subagents concurrently with the `task` tool.
-4. Review results, integrate non-conflicting fixes, then run full verification.
+1. Define lanes with explicit scope, inputs, and outputs.
+2. Assign a single integrator (usually builder) for merge and final validation.
+3. Require each lane to provide verification evidence, not just code output.
+4. Integrate in dependency order.
+5. Run final end-to-end verification after integration.
 
-Example dispatch intent (tool-level wording):
-- `task`: "Investigate and fix failures in <domain A only>"
-- `task`: "Investigate and fix failures in <domain B only>"
+## Planner/Builder Expectations
 
-## Prompt Quality Requirements
+- Planner: design parallel lanes only when isolation is demonstrable.
+- Builder: load this skill before fan-out and enforce lane boundaries strictly.
 
-Each subagent prompt must include:
-1. **One clear problem domain** (single file/subsystem/failure cluster).
-2. **Self-contained context** (errors, failing tests, relevant constraints).
-3. **Explicit constraints** (what not to change; scope boundaries).
-4. **Explicit expected output** (root cause + files changed + validation run).
+## Red Flags
 
-## Verification and Quality Pipeline
-
-After subagents return:
-1. Check for overlapping edits or assumption conflicts.
-2. Run required verification for the integrated result (not partial checks).
-3. Send the feature through reviewer, then tester when behavior is user-facing.
-4. Do not claim completion without fresh verification evidence.
+- Two lanes editing the same contract.
+- Shared test fixtures causing non-deterministic outcomes.
+- Missing integrator ownership.