PluginBench
Skill
Pass
Audit score 90

parallel-execution-optimizer

affaan-m/ecc

Speed up independent tasks through parallel work, concurrent agents, and isolated lanes without sacrificing correctness.

What is parallel-execution-optimizer?

This skill helps you execute multiple independent work streams simultaneously—such as repo inspection, file reads, API checks, and build/test lanes—while keeping writes isolated and maintaining correctness. Use it when you need to complete a large task faster by splitting it into parallel-safe dependencies.

  • Define objectives and split work into parallel, sequential, or gated lanes before executing
  • Batch file reads, searches, status checks, and metadata queries to run concurrently
  • Use isolated worktrees, branches, or services to keep writes from colliding
  • Run long-running tests, builds, and deploys in separate sessions with deliberate polling
  • Verify lane compatibility with evidence (test results, logs, screenshots) before merging results

How to install parallel-execution-optimizer

npx skills add null --skill parallel-execution-optimizer
Claude Code
Cursor
Windsurf
Cline

How to use parallel-execution-optimizer

  1. 1.Define your objective and the done signal (what proves success)
  2. 2.Create a lane matrix listing each work stream, whether it can run in parallel, what it writes to, and its risk level
  3. 3.Identify which lanes have non-colliding write surfaces and can run concurrently
  4. 4.Execute independent reads, checks, and searches together; start long-running tasks in separate sessions
  5. 5.Poll running sessions deliberately and pause dependent lanes if a blocker emerges
  6. 6.Merge results only after verification evidence (test passes, logs, screenshots) shows lanes are compatible
  7. 7.Report results with lane count, completion status, blockers, and verification outcomes

Use cases

Good for
  • Speed up multi-file refactoring by running independent component patches in parallel worktrees
  • Accelerate CI/CD by batching repo scans, unit tests, and integration tests in separate lanes
  • Parallelize API validation checks and browser smoke tests across multiple independent services
  • Run concurrent verification passes (lint, unit, integration, deploy readback) with gated merges
  • Reduce deployment time by running independent backend and frontend patches in isolated lanes
Who it's for
  • Backend and full-stack engineers optimizing build and test pipelines
  • DevOps and platform engineers managing multi-service deployments
  • Teams working on large refactors or migrations across multiple files or services
  • QA and verification engineers running parallel test suites

parallel-execution-optimizer FAQ

When should I use this skill instead of just running tasks sequentially?

Use it when you have independent work streams (different files, services, or datasets) that don't write to the same resources. The skill helps you identify which lanes are truly parallel-safe and how to verify they work together.

What happens if two lanes try to write to the same file?

The skill prevents this by isolating writes by file, worktree, branch, or service. If lanes do collide, keep them sequential or gated. Never parallelize destructive commands, migrations, or writes to the same resource without an explicit gate.

How do I know if my parallel execution actually worked?

Use a verification table with evidence: lint pass, unit test results, integration test logs, live URL checks, or deployment readback. Don't claim success until correctness is proven, not just speed.

What if a parallel lane discovers a blocker?

Pause dependent lanes immediately and update your lane matrix. Adjust the plan based on the new constraint rather than continuing with stale assumptions.

Can I use this for live customer-impacting deploys?

No, unless you have an explicit gate and verification step. Never parallelize destructive commands or customer-facing changes without proof of safety first.

Full instructions (SKILL.md)

Source of truth, from affaan-m/ecc.


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. metadata: origin: ECC 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.