Parallel Execution Optimizer
- 1.3k installs
- 238k repo stars
- Updated August 5, 2026
- affaan-m/ecc
parallel-execution-optimizer is an agent orchestration skill that maps dependency graphs, parallel lanes, and isolated writes so developers who need large tasks finished faster without merge conflicts can run concurrent
About
parallel-execution-optimizer is an ECC agent skill for safely speeding up large coding tasks by planning parallel execution lanes before any tool calls run. The workflow starts with goals and completion signals, splits work into channels labeled parallel, serial, or gated, batches independent reads and checks, and isolates writes by file, git worktree, branch, service, or dataset. Developers reach for parallel-execution-optimizer when repo scans, API checks, browser checks, build or test runs, and multi-worktree implementation batches can run at the same time without stepping on each other. The skill closes with a verification table that proves each lane succeeded instead of relying on a vague speed claim. It uses Read, Write, Edit, Bash, Grep, and Glob tools from the ECC toolkit.
- Converts urgency into a dependency graph before acting
- Creates a Lane Matrix that flags parallel, sequential, and gated work
- Runs independent reads, searches, API checks and verification lanes together
- Enforces isolated write surfaces using worktrees, branches or services
- Ends every run with a verification table instead of vague speed claims
Parallel Execution Optimizer by the numbers
- 1,280 all-time installs (skills.sh)
- +84 installs in the week ending Aug 5, 2026 (Skillselion tracking)
- Ranked #897 of 16,546 AI & Agent Building skills by installs in the Skillselion catalog
- Data as of Aug 5, 2026 (Skillselion catalog sync)
npx skills add https://github.com/affaan-m/ecc --skill parallel-execution-optimizerAdd your badge
Show developers this skill is listed on Skillselion. Paste this into your README.
| Installs | 1.3k |
|---|---|
| repo stars | ★ 238k |
| Last updated | August 5, 2026 |
| Repository | affaan-m/ecc ↗ |
How do you run parallel coding agents without write conflicts?
Dramatically accelerate large tasks by safely orchestrating concurrent agents, batched reads, and isolated writes.
Who is it for?
Developers orchestrating multi-agent or multi-worktree refactors where independent reads and checks can run concurrently but writes must stay isolated.
Skip if: Developers running a single sequential bug fix or any task where every step depends on the previous write completing first.
When should I use this skill?
User asks to parallelize agents, batch tool calls, use git worktrees for concurrent implementation, or accelerate large tasks without losing correctness.
What you get
Dependency graph, lane execution matrix, isolated write plan, and per-lane verification table
- Lane execution matrix
- Verification table
By the numbers
- Uses 7 core workflow steps from goal definition through verification-table closure
- Supports 6 ECC tools: Read, Write, Edit, Bash, Grep, and Glob
Files
并行执行优化器
当速度来自同时处理相互独立的工作时，使用此技能： 仓库巡检、文件读取、API 检查、浏览器检查、构建/测试通道、 部署回读，或多 worktree 的实现批次。
核心模式
行动之前，先把紧迫感转化为依赖图。
1. 定义目标和完成信号。 2. 把工作拆分成通道（lane）。 3. 给每条通道标注执行方式：并行、串行或门控。 4. 把相互独立的读取/检查放在一起执行。 5. 让写入按文件、worktree、分支、服务或数据集相互隔离。 6. 只有在证据表明各通道相互兼容后才合并。 7. 以一张验证表收尾，而不是一句模糊的"变快了"。
通道矩阵
在大规模推进之前，写一张紧凑的矩阵：
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只有当各通道的写入面互不冲突时，才并行运行。
执行规则
- 把文件读取、搜索、状态检查和元数据查询批量化。
- 对大型且互不相关的实现通道使用隔离的 worktree。
- 长时间运行的测试、构建、回填和部署放到独立会话中启动，
然后有节奏地主动轮询。
- 如果某条通道发现了会改变计划的阻塞点，暂停依赖它的通道
并更新矩阵。
- 除非用户明确要求持续运行的服务，绝不让后台进程存活超过本轮。
- 没有明确门控时，不要并行执行破坏性命令、数据迁移、对同一张表的写入，
或影响线上客户的部署。
输出形态
汇报时使用：
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失败模式
- 更多并发反而制造了相互冲突的编辑。
- 在给工具跑分，而不是在完成任务。
- 在正确性得到证明之前就把"快"当成"做完了"。
- 忘记轮询正在运行的会话。
- 用一句成功摘要掩盖被跳过的检查。
Related skills
Setup Matt Pocock SkillsScaffold the per-repo configuration that Matt Pocock’s engineering agent skills rely on so they understand the issue tracker, triage labels, and domain documentation la495k196k
Lark AppsConnect Claude, Cursor or custom agents directly to Lark (Feishu) for messaging, document automation, approval workflows and enterprise data access.402k
CavemanSlash token usage by roughly 75% while keeping every technical detail intact when working with Claude Code, Cursor or similar agents.391k94.7k
Lark Skill MakerQuickly turn any Lark/Feishu OpenAPI call or multi-step workflow into a reusable agent skill with its own SKILL.md.386k16k
Running Claude Code Via Litellm CopilotRun Claude Code at a fraction of the cost by routing requests through LiteLLM to the GitHub Copilot Chat API.270k72
Codex PetGenerate a complete Codex Pet spritesheet and metadata from one reference image without needing an OpenAI key or Codex Pro.246k10How it compares
Choose parallel-execution-optimizer over generic speed prompts when multiple independent verification or implementation lanes need explicit isolation rules before concurrent agent execution.
FAQ
When should parallel-execution-optimizer run before tool calls?
parallel-execution-optimizer should run before any parallel work when independent lanes exist—repo scans, API checks, browser checks, builds, tests, or multi-worktree patches. The skill converts urgency into a dependency graph and lane matrix so reads batch together and writes st
How does parallel-execution-optimizer prevent agent write conflicts?
parallel-execution-optimizer assigns each lane a write surface—file, git worktree, branch, service, or dataset—and keeps mutually dependent lanes serial or gated. Merging happens only after a verification table shows compatible, evidence-backed results across all parallel channel