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