codeply-cli 0.5.1 → 0.5.2

package/skills/parallel-execution-optimizer/SKILL.md

@@ -1,74 +1,74 @@
----
-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.
-license: MIT
-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:
-
-```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.
+---
+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.
+license: MIT
+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:
+
+```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.