Catalog
affaan-m/parallel-execution-optimizer

affaan-m

parallel-execution-optimizer

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.

New~624Updated Jul 14, 2026

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.
Files1
1 files · 1.0 KB

Select a file to preview

Overall Score

82/100

Grade

B

Good

Safety

88

Quality

81

Clarity

85

Completeness

74

Summary

The Parallel Execution Optimizer skill teaches AI agents how to decompose complex tasks into independent, parallelizable lanes to accelerate work while maintaining correctness. It provides a structured dependency-graph approach, lane matrix templates, and execution rules to prevent race conditions, conflicting edits, and premature success claims.

Detected Capabilities

file readbash executionrepository inspectionparallel task orchestrationdependency graph analysisstatus polling

Trigger Keywords

Phrases that MCP clients use to match this skill to user intent.

speed up slow tasksparallel work lanesbatch independent checksmulti-worktree deploymentconcurrent verificationreduce total wall time

Use Cases

  • >Accelerate multi-stage repo inspection, linting, and test discovery by batching independent reads and checks in parallel
  • Deploy and verify changes faster by running isolated backend and frontend implementation lanes concurrently with separate write surfaces
  • Speed up long-running builds and test suites by polling them in background sessions while continuing other work
  • Prevent parallelization pitfalls like conflicting edits, skipped checks, and correctness shortcuts by following the lane matrix and gating rules
  • Organize complex multi-service deployments using worktree isolation and deliberate merge verification between lanes

Quality Notes

  • Excellent use of concrete structure — the Lane Matrix template is immediately actionable and models the exact decision point agents need
  • Clear separation of when parallelization is safe (independent reads, isolated write surfaces) versus dangerous (destructive commands, shared table migrations)
  • Strong failure modes section explicitly warns against the most common pitfalls: conflicting edits, premature success claims, and forgotten background processes
  • The Core Pattern (7-step process) is well-ordered and gives agents a deterministic way to decompose tasks before acting
  • Output shape section provides a structured reporting template so agents know what 'done' looks like and what evidence to collect
  • Execution Rules are precise and risk-aware — the skill does not encourage reckless parallelization; it teaches when it is safe
  • No concrete code examples for common patterns (e.g., how to implement a polling loop, how to merge results after lanes complete) — guidance is high-level architectural
  • Could benefit from an explicit section on metrics or heuristics: 'Lane X is worth parallelizing if it saves > 2 seconds' or 'Use worktrees only if implementation is > 200 lines'
  • No explicit guidance on cost of parallelization overhead (context switching, coordination, merge conflicts) versus benefit — agents should know when serial is faster
Model: claude-haiku-4-5-20251001Analyzed: Jul 14, 2026

Reviews

Add this skill to your library to leave a review.

No reviews yet

Be the first to share your experience.

Version History

  1. v1.1

    Content updated

    ✦ AINo behavioral changes detected.

    2026-07-14

    Latest
  2. v1.0

    2026-05-25

    View This VersionInitial version

Use affaan-m/parallel-execution-optimizer in your dev environment

Command Palette

Search for a command to run...