mirror of
https://github.com/affaan-m/everything-claude-code.git
synced 2026-06-12 03:03:23 +08:00
feat: publish ECC 2.0 skill pack surfaces
This commit is contained in:
72
skills/parallel-execution-optimizer/SKILL.md
Normal file
72
skills/parallel-execution-optimizer/SKILL.md
Normal file
@@ -0,0 +1,72 @@
|
||||
---
|
||||
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.
|
||||
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:
|
||||
|
||||
```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.
|
||||
|
||||
## 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.
|
||||
Reference in New Issue
Block a user