Purpose

Before launching agents to work in parallel, verify that their write scopes do not overlap, define explicit lane boundaries, and establish conflict detection rules — so that concurrent agent work can be merged cleanly without data loss, silent overwrites, or corrupted artifacts.

When to use

• Two or more agents are about to run concurrently and at least one writes files.
• A merge or integration step is approaching after parallel work branches.
• A previous parallel run resulted in conflicting edits, lost changes, or broken builds.
• The orchestrator needs to decide which tasks can safely parallelize and which must serialize.
• Splitting a ticket or task into parallel lanes and need to define boundaries.

Do NOT use when

• All concurrent agents are read-only (no write conflicts possible).
• Only one agent is running at a time (sequential execution).
• The task is debugging a failure that already happened (use

  multi-agent-debugging

  ).
• The concern is agent performance, not safety (use watchdog or monitoring skills).

Operating procedure

1. Enumerate all active agents. List every agent that will run concurrently. Output as:

   | Agent | Task Description | Mode (read/write) | Status |

   .
2. Declare write scopes. For each writing agent, list every file path, directory, database table, or API endpoint it may modify. Use glob patterns where appropriate. Output as:

   | Agent | Write Scope (glob) | Scope Type (file/db/api) |

   .
3. Build the conflict matrix. Cross-reference write scopes pairwise. For each pair of writing agents, check if any glob patterns overlap. Output as:

   | Agent A | Agent B | Overlapping Scope | Conflict? |

   .
4. Classify each conflict. For every overlap found, classify as:
   • HARD_CONFLICT — both agents write to the exact same file/line range. Must serialize.
   • SOFT_CONFLICT — agents write to the same directory but different files. Can parallelize with a post-merge verification step.
   • NO_CONFLICT — scopes are fully disjoint.
5. Assign lane boundaries. For each agent, write a lane specification:

   | Agent | Allowed Write Paths | Forbidden Write Paths | Shared Read Paths |

   . Every file must appear in exactly one agent allowed-write lane or be read-only for all.
6. Define merge-safety checks. For SOFT_CONFLICT lanes, specify a post-merge verification:
   • Run

     git diff --name-only

     between the two branches to confirm no unexpected overlaps.
   • Run the project build and test suite after merge.
   • Check file checksums for any shared config files.
7. Establish runtime conflict detection. Define what happens if an agent violates its lane:
   • Log the violation with: agent ID, file path, timestamp, operation attempted.
   • Halt the violating agent immediately (do not allow the write to proceed).
   • Notify the orchestrator to decide: retry with corrected scope, serialize, or abort.
8. Emit the lane assignment plan. Produce the final document with all lane boundaries, conflict classifications, and merge-safety rules.
9. Validate isolation post-run. After all agents complete, run a final check:
   • Verify no file was modified by more than one agent (check git blame or file timestamps).
   • Confirm build and tests pass on the merged result.

Decision rules

• If any HARD_CONFLICT exists, those agents MUST serialize — no exceptions.
• SOFT_CONFLICTs are acceptable only if post-merge verification is defined and will be run.
• Shared configuration files (package.json, Cargo.toml, etc.) require explicit lock assignment to exactly one agent; others must treat them as read-only.
• When in doubt, serialize. The cost of a lost write is always higher than the cost of waiting.
• Lane boundaries are immutable once agents launch — no mid-run scope expansion.

Output requirements

1. Agent Inventory — table of all concurrent agents and their modes.
2. Write Scope Declarations — per-agent list of all paths they will modify.
3. Conflict Matrix — pairwise comparison with conflict classification.
4. Lane Assignment Plan — per-agent allowed/forbidden write paths.
5. Merge Safety Rules — post-merge verification steps for each soft conflict.
6. Violation Protocol — what happens if an agent writes outside its lane.

References

• references/delegate-contracts.md

  — write-scope clauses in delegation contracts.

• references/checkpoint-rules.md

  — checkpoints before and after parallel execution.

• references/failure-escalation.md

  — escalation when a lane violation is detected.

Related skills

• manager-hierarchy-design

  — for structuring who assigns and enforces lanes.

• multi-agent-debugging

  — for post-mortem when parallel work produced conflicts.

• panel-of-experts

  — for parallel read-only analysis that does not need lane safety.

• long-run-watchdog

  — for monitoring agents that may exceed their lane due to stalls.

Failure handling

• If an agent cannot declare its write scope upfront, refuse to parallelize it — serialize until the scope is known.
• If a lane violation is detected mid-run, halt only the violating agent, not the entire system.
• If post-merge verification fails, identify the conflicting files, roll back the later write, and re-run that agent with a corrected scope.
• If two agents both legitimately need to write the same file, escalate to the orchestrator to redesign the task split rather than allowing concurrent writes.