affaan-m/ecc

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.

All-time #3420 Trending #2821 First seen May 25, 2026
8-week activity · all time api

Installation

$ npx skills add affaan-m/ecc --skill parallel-execution-optimizer

Similar popular skills

Related neighbors and high-traction skills in the same topics — useful to compare before installing.

Also in this package

Other skills from affaan-m/ecc · top by installs.

npx skills add affaan-m/ecc

Browse all from affaan-m/ecc

More details

Agent compatibility

Declared targets from SKILL.md / docs. Unmarked agents are not listed — the skill may still install via the CLI.

Claude Code Not declared
Cursor Not declared
Codex Not declared
GitHub Copilot Not declared
Windsurf Not declared
Gemini CLI Not declared
Cline Not declared
OpenCode Not declared

Repository health

Stars 254.3K
License LICENSE
Default branch main
Open issues 54
Status Active

Skill metadata

Parsed from SKILL.md frontmatter.

LicenseMIT
More metadata
origin
ECC

Package contents

Files included with this skill beyond the listing page.

  • skill md SKILL.md 2,633 B
  • docs SUMMARY.md 229 B

History

  1. First seen on skills.sh
  2. First recorded snapshot · 4,019 installs

SKILL.md

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.