parallel-execution-optimizer

Traditional sequential execution wastes time:

• /optimize runs 5 quality checks sequentially (10-15 minutes)
• /ship runs 5 pre-flight checks sequentially (8-12 minutes)
• /implement processes tasks one-by-one despite no dependencies
• Prototype screens generated sequentially when all could run in parallel

This skill analyzes operation dependencies, groups independent work into batches, and orchestrates parallel execution using multiple Task() agent calls in a single message. The result: 3-5x faster phase completion with zero compromise on quality or correctness.

<quick_start> <basic_pattern> When you detect multiple independent operations, send a single message with multiple tool calls:

Sequential (slow):

• Send message with Task call for security-sentry
• Wait for response
• Send message with Task call for performance-profiler
• Wait for response
• Send message with Task call for accessibility-auditor
• Total: 15 minutes

Parallel (fast):

• Send ONE message with 3 Task calls (security-sentry, performance-profiler, accessibility-auditor)
• All three run concurrently
• Total: 5 minutes </basic_pattern>

<immediate_use_cases>

1. /optimize phase: Run 5 quality checks in parallel (security, performance, accessibility, code-review, type-safety)
2. /ship pre-flight: Run 5 deployment checks in parallel (env-vars, build, docker, CI-config, dependency-audit)
3. /implement: Process independent task batches in parallel layers
4. Design variations: Generate multiple mockup variations concurrently
5. Research phase: Fetch multiple documentation sources concurrently </immediate_use_cases> </quick_start>

Scan the current phase for operations that:

• Read different files/data sources
• Don't modify shared state
• Have no sequential dependencies
• Can produce results independently

Examples:

• Quality checks (security scan + performance test + accessibility audit)
• File reads (spec.md + plan.md + tasks.md)
• API documentation fetches (Stripe docs + Twilio docs + SendGrid docs)
• Test suite runs (unit tests + integration tests + E2E tests)

Build a dependency graph:

• Layer 0: Operations with no dependencies (can run immediately)
• Layer 1: Operations depending only on Layer 0 outputs
• Layer 2: Operations depending on Layer 1 outputs
• etc.

Example (/optimize):

Layer 0 (parallel):
  - security-sentry (reads codebase)
  - performance-profiler (reads codebase + runs benchmarks)
  - accessibility-auditor (reads UI components)
  - type-enforcer (reads TypeScript files)
  - dependency-curator (reads package.json)

Layer 1 (after Layer 0):
  - Generate optimization-report.md (combines all Layer 0 results)

Create batches for each layer:

• All Layer 0 operations in single message (parallel execution)
• Wait for Layer 0 completion
• All Layer 1 operations in single message
• Continue through layers

Batch size considerations:

• Optimal: 3-5 operations per batch (balanced parallelism)
• Maximum: 8 operations (avoid overwhelming system)
• Minimum: 2 operations (below 2, parallelism has no benefit)

Send a single message with multiple tool calls for each batch.

Critical requirements:

• Must be a single message with multiple tool use blocks
• Each tool call must be complete and independent
• Do not use placeholders or forward references
• Each agent must have all required context in its prompt

See references/execution-patterns.md for detailed examples.