parallel-execution-optimizer

# 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. Also use it when homogeneous work repeats unchanged preparation between records, even if the record operations must remain sequential. ## 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: ```text 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. ## Bounded Homogeneous Work Reuse preparation when a finite group of records shares accepted invariant inputs, such as a mapping and tool contract. This reduces repeated discovery and task setup; it does not require concurrent writes. 1. Define the bounded record set, owner-defined completion unit, ordering, exclusions, done signal, accepted mapping/contract version, and replanning conditions. Check selection coverage against the accepted source criteria; validating selected records alone does not prove the set is complete. 2. Discover shared sources and prepare invariant inputs once. Record their versions and validity conditions; reuse them only while those conditions hold. 3. Before each record's effect, check its current version, permissions, prerequisites, and exact intended effect. Shared preparation is not shared authorization. Require a conditional write against the checked version, a transaction that detects intervening changes, or a lock held across the check and write. Stop on a conflict; if no such protection is available, do not write. 4. Verify the actual outcome for that record. Carry forward its evidence and the remaining-work set after each verified success. An attempted write is not a verified success; reconcile an uncertain outcome before any retry. 5. Keep a group with one executor where the actual admission contract permits it. If admission requires separate write kinds or stages, preserve those boundaries and prepare the next permitted stage from verified returned keys and versions; do not widen an assignment or bypass an approval for speed. 6. Continue within the same bounded task while the contract and prerequisites remain valid. Create a separate task or review when a real dependency, changed contract, or risk requires it, rather than after every success. ### Planner/Executor Example The following is a synthetic walkthrough, not a measured runtime benchmark or an executed connector test. Records A, B, and C are independent and use the same accepted mapping M1 and tool contract T1. Writes stay sequential. ```text Planner: group = [A, B, C] shared = accepted mapping M1 + tool contract T1 + source references verified = {} remaining = [A, B, C] Executor for A: confirm shared inputs are still valid read A's current version; check permission and prerequisites determine exact effect; apply with the same conflict protection; verify outcome carry forward verified = {A: outcome evidence}, remaining = [B, C] Executor for B, then C: reuse shared preparation and carried state repeat each record's version, permission, prerequisite, effect, outcome checks remove a record from remaining only after verifying its success Replan: if T1 changes to T2, pause dependent work and review the changed contract if B's prerequisite fails, leave B unresolved and review that dependency preserve A's verified evidence; refresh only inputs invalidated by the change ``` Carry-forward state should identify the group, shared input versions and validity conditions, per-record verified outcomes, unresolved/uncertain effects, remaining records, completed-work exclusions, and the next required check. On resumption, revalidate inputs that may have changed; do not replay completed effects merely because a new executor takes over. Treat a new user request or changed scope as a new contract. ### Resume After a Connector Change For a synthetic handoff, suppose A is completed and excluded from further changes, B failed with a confirmed absence of effects, C was never attempted, and D has an ambiguous outcome. Carry those per-operation states and evidence into the new connector route. Keep A excluded. Reconcile D before considering a retry; rebuild the executable set from unresolved work that is still authorized, including B and C only after their checks pass. Validate the new tool contract and preserve the exact intended effects. Do not rebuild the original batch as executable or erase earlier deviations because a later attempt succeeds. ### Evaluation Criteria Use the walkthrough to check that ordinary successes advance A → B → C without repeating unchanged source discovery or full task preparation. Confirm that a changed contract or failed prerequisite still triggers the relevant review, per-record checks remain intact, and unverified outcomes stay unresolved. On a connector change, confirm completed exclusions survive, failed/unattempted work requires current authorization, and ambiguous effects are reconciled first. Report what was actually executed separately from this proposed evaluation. Do not infer latency improvements or ECC/connector fault attribution from this example. For an already-ready group, retain readiness, handoff, and first-action times in the existing journal. Separate required checks and approval waits from coordinator waiting; client-side call overlap does not prove backend concurrency or throughput improvement. If a dependent step in GROUP_A is denied, hold it while authorized independent GROUP_B can proceed. Preserve chronological ordering within the owner's completion unit and all excluded records/intervals. Test a selection spelling variant and an excluded record against the accepted criteria; retain omitted eligible work and overflow before any unprepared write. Check that a version conflict or unavailable conflict protection produces no write. These remain proposed synthetic checks, not executed live-system results. ## Output Shape Use this when reporting: ```text 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.