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.
- Define the objective and done signal.
- Split work into lanes.
- Mark each lane as parallel, sequential, or gated.
- Run independent reads/checks together.
- Keep writes isolated by file, worktree, branch, service, or dataset.
- Merge only after evidence shows the lanes are compatible.
- 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.
1---2name: parallel-execution-optimizer3description: 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.4---5
6# Parallel Execution Optimizer
7
8Use this skill when speed comes from doing independent work at the same time:
9repo inspection, file reads, API checks, browser checks, build/test lanes,
10deploy readbacks, or multi-worktree implementation passes.
11
12## Core Pattern
13
14Turn urgency into a dependency graph before acting.
15
161. Define the objective and done signal.
172. Split work into lanes.
183. Mark each lane as parallel, sequential, or gated.
194. Run independent reads/checks together.
205. Keep writes isolated by file, worktree, branch, service, or dataset.
216. Merge only after evidence shows the lanes are compatible.
227. End with a verification table, not a vague speed claim.
23
24## Lane Matrix
25
26Before a large push, write a compact matrix:
27
28```text
29Lane | Can run in parallel? | Write surface | Risk | Verification
30Repo scan | yes | none | low | rg/git status outputs
31Backend patch | maybe | src/api | medium | unit tests
32Frontend patch | maybe | app/components | medium | browser screenshot
33Deploy readback | after build | remote service | high | live URL + logs
34```
35
36Only run lanes in parallel when their write surfaces do not collide.
37
38## Execution Rules
39
40- Batch file reads, searches, status checks, and metadata queries.
41- Use isolated worktrees for large unrelated implementation lanes.
42- Start long-running tests, builds, backfills, and deploys in separate sessions,
43 then poll them deliberately.
44- If a lane discovers a blocker that changes the plan, pause dependent lanes
45 and update the matrix.
46- Never let a background process outlive the turn unless the user explicitly
47 asked for a continuing service.
48- Do not parallelize destructive commands, migrations, writes to the same table,
49 or live customer-impacting deploys without an explicit gate.
50
51## Output Shape
52
53Use this when reporting:
54
55```text
56Parallel execution result:
57- Lanes run: 5
58- Lanes completed: 4
59- Blocked lane: deploy readback, waiting on DNS propagation
60- Fast path found: batched repo scan + focused tests
61- Verification: lint pass, unit pass, live smoke pass
62```
63
64## Failure Modes
65
66- More concurrency that creates conflicting edits.
67- Benchmarking the tool instead of the task.
68- Treating "fast" as done before correctness is proven.
69- Forgetting to poll running sessions.
70- Hiding skipped checks behind a success summary.
livelybug