parallel-execution-optimizer

name	parallel-execution-optimizer
description	Use when the user wants a task done much faster through parallel work, concurrent agents, batched tool calls, isolated worktrees, or many independent verification lanes without losing correctness.
origin	Multiversal
tools	Read, Write, Edit, Bash, Grep, Glob

Parallel Execution Optimizer

Use this skill when speed comes from doing independent work at the same time: repo inspection, file reads, API checks, browser checks, build/test lanes, deploy readbacks, or multi-worktree implementation passes.

Core Pattern

Turn urgency into a dependency graph before acting.

1. Define the objective and done signal.
2. Split work into lanes.
3. Mark each lane as parallel, sequential, or gated.
4. Run independent reads/checks together.
5. Keep writes isolated by file, worktree, branch, service, or dataset.
6. Merge only after evidence shows the lanes are compatible.
7. End with a verification table, not a vague speed claim.

Lane Matrix

Before a large push, write a compact matrix:

Lane | Can run in parallel? | Write surface | Risk | Verification
Repo scan | yes | none | low | rg/git status outputs
Backend patch | maybe | src/api | medium | unit tests
Frontend patch | maybe | app/components | medium | browser screenshot
Deploy readback | after build | remote service | high | live URL + logs

Only run lanes in parallel when their write surfaces do not collide.

Execution Rules

• Batch file reads, searches, status checks, and metadata queries.
• Use isolated worktrees for large unrelated implementation lanes.
• Start long-running tests, builds, backfills, and deploys in separate sessions, then poll them deliberately.
• If a lane discovers a blocker that changes the plan, pause dependent lanes and update the matrix.
• Never let a background process outlive the turn unless the user explicitly asked for a continuing service.
• Do not parallelize destructive commands, migrations, writes to the same table, or live customer-impacting deploys without an explicit gate.

Output Shape

Use this when reporting:

Parallel execution result:
- Lanes run: 5
- Lanes completed: 4
- Blocked lane: deploy readback, waiting on DNS propagation
- Fast path found: batched repo scan + focused tests
- Verification: lint pass, unit pass, live smoke pass

Failure Modes

• More concurrency that creates conflicting edits.
• Benchmarking the tool instead of the task.
• Treating "fast" as done before correctness is proven.
• Forgetting to poll running sessions.
• Hiding skipped checks behind a success summary.