# Skill: Parallelize AI agent work safely using lane mapping and read/write isolation

> Before executing any multi-step task, build a lane map that identifies which chunks can run simultaneously and which must be sequential, then enforce write isolation to prevent file conflicts. Applies when speed matters and the work has independent parts.

Source: sodigi·learn — vibecoding/delaem-parallelno · https://sodigi.io/learn/vibecoding/delaem-parallelno

## When to use
- A pre-publish check involves multiple independent inspections (lint, tests, screenshot, link check).
- A feature has several independent sub-tasks that touch different files or concerns.
- Long background tasks (builds, test suites, deploys) are blocking other work.
- You need to run reads or searches across many files at once.

## Core rules
- Draw the lane map BEFORE doing anything. Speed comes from smart splitting, not from telling the agent to "go faster."
- Golden rule: read in a crowd, write one at a time. Any number of agents can read simultaneously. Two agents editing the same file will create a conflict.
- Tag every lane as one of: parallel (safe to run now), sequential (depends on another lane), or "wait for signal" (requires explicit confirmation before starting -- deletes, migrations, prod deploys).
- Long tasks (tests, builds, deploys) go to the background; check back for results later.
- Always verify background task results -- an agent that says "all running!" may have a silently crashed process among them.
- End with a verification table: which lane passed, which failed, what was checked. "Seems to work" is not a result.
- Dangerous operations (bulk deletes, database migrations, production deployments) are never parallelized. Always require explicit confirmation.

## Procedure
1. List all sub-tasks required to complete the goal.
2. For each sub-task, answer: does it read or write? Which files/systems does it touch?
3. Mark tasks that touch the same file as sequential. Mark everything else as parallel-eligible.
4. Tag destructive/dangerous tasks as "wait for signal" -- do not start without explicit confirmation.
5. Fire all read-only and non-overlapping tasks as a batch simultaneously.
6. Send long-running tasks (tests, builds) to the background.
7. After all lanes complete, collect results and produce a verification table: lane name, pass/fail, what was checked.

## Ready-to-use prompt
```
I need to quickly check the project before publishing. First lay out a lane plan -- do not rush into action.

1. Split the work into independent lanes. For each one say: can it run in parallel, what does it touch, and how do we know it passed.
2. Run all read-only and check-only lanes at once: reviewing files, searching the code, checking status.
3. Start long checks (tests, build) in the background and come back for the results later.
4. Do not delete, edit, or publish anything without my separate explicit confirmation.
5. At the end, give me a table: which lane passed, which failed, and exactly what you checked.
```

## Pitfalls
- Telling the agent to "go faster" with no plan -- speed requires the lane map first.
- Two agents editing the same file in parallel -- guaranteed conflict; writes must be isolated.
- Parallelizing dangerous operations (deletes, migrations, prod deploys) -- never do this without confirmation.
- Starting background tasks and not checking their results -- a process may fail silently while the agent reports "done."
- Accepting "all good!" with no verification table -- always demand specifics: what passed, what failed.
- Marking a dependent task as parallel -- if step B requires step A's output, they cannot run at the same time.