parallel-execution-optimizer

<objective>
The parallel-execution-optimizer skill transforms sequential workflows into concurrent execution patterns, dramatically reducing wall-clock time for phases with multiple independent operations.

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.
</objective>

<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>

<workflow>
<step number="1">
**Identify independent operations**

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)
  </step>

<step number="2">
**Analyze dependencies**

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)
```

</step>

<step number="3">
**Group into batches**

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)
  </step>

<step number="4">
**Execute parallel batches**

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](references/execution-patterns.md) for detailed examples.
</step>

<step number="5">
**Aggregate results**

After each batch completes:

- Collect results from all parallel operations
- Check for failures or blocking issues
- Decide whether to proceed to next layer
- Aggregate findings into unified report

Failure handling:

- If any operation blocks (critical security issue), halt pipeline
- If operations have warnings (minor performance issue), continue but log
- If operations fail (agent error), retry individually or escalate
  </step>
  </workflow>

<phase_specific_patterns>
<optimize_phase>
**Operation**: Run 5 quality gates in parallel

**Dependency graph**:

```
Layer 0 (parallel - 5 operations):
  1. security-sentry → Scan for vulnerabilities, secrets, auth issues
  2. performance-profiler → Benchmark API endpoints, detect N+1 queries
  3. accessibility-auditor → WCAG 2.1 AA compliance (if UI feature)
  4. type-enforcer → TypeScript strict mode compliance
  5. dependency-curator → npm audit, outdated packages

Layer 1 (sequential - 1 operation):
  6. Generate optimization-report.md (aggregates Layer 0 findings)
```

**Time savings**:

- Sequential: ~15 minutes (3 min per check)
- Parallel: ~5 minutes (longest check + aggregation)
- **Speedup**: 3x

See [references/optimize-phase-parallelization.md](references/optimize-phase-parallelization.md) for implementation details.
</optimize_phase>

<ship_preflight>
**Operation**: Run 5 pre-flight checks in parallel

**Dependency graph**:

```
Layer 0 (parallel - 5 operations):
  1. Check environment variables (read .env.example vs .env)
  2. Validate production build (npm run build)
  3. Check Docker configuration (docker-compose.yml, Dockerfile)
  4. Validate CI configuration (.github/workflows/*.yml)
  5. Run dependency audit (npm audit --production)

Layer 1 (sequential - 1 operation):
  6. Update state.yaml with pre-flight results
```

**Time savings**:

- Sequential: ~12 minutes
- Parallel: ~4 minutes (build is longest operation)
- **Speedup**: 3x

See [references/ship-preflight-parallelization.md](r