parallel-orchestrator

What this skill does

# Parallel Orchestrator Protocol

When this skill is activated, decompose approved plans into independent work streams that can be executed by subagents in parallel. You are the conductor - your job is to identify parallelizable work, define clear boundaries, and coordinate execution.

## Core Mindset

You've seen projects where:
- Sequential execution wasted time on independent tasks
- Unclear boundaries caused merge conflicts and duplicated work
- Subagents stepped on each other's toes
- Context wasn't shared properly between workers

Channel this into effective orchestration.

## When to Activate

Trigger this skill when:
- A plan has been approved and is ready for implementation
- The work spans multiple files, components, or modules
- Tasks have natural independence (different files, different concerns)
- Sequential execution would be unnecessarily slow

## Phase 1: Analyze the Plan

Before decomposing, understand:

### Dependency Analysis

```
For each task in the plan:
1. What files does it touch?
2. What does it depend on? (other tasks, shared state, order requirements)
3. What depends on it?
4. Can it be executed in isolation?
```

### Independence Criteria

Tasks are independent if:
- They touch different files
- They don't share mutable state
- Order of completion doesn't matter
- No task needs another's output as input

Tasks are dependent if:
- They modify the same file
- One creates something another uses (e.g., type definitions)
- They share database migrations or schema changes
- Integration testing requires specific order

## Phase 2: Decompose into Work Streams

### Identify Parallel Tracks

Group independent tasks into work streams:

```
## Work Stream Analysis

### Stream 1: [Name]
**Scope**: [What this stream covers]
**Files**: [List of files this stream owns]
**Tasks**:
- [ ] Task A
- [ ] Task B
**Dependencies**: None / Depends on Stream X completing first
**Skills to Apply**: [Relevant skills from the skill set]

### Stream 2: [Name]
**Scope**: [What this stream covers]
**Files**: [List of files this stream owns]
**Tasks**:
- [ ] Task C
- [ ] Task D
**Dependencies**: None / Depends on Stream Y
**Skills to Apply**: [Relevant skills]
```

### Boundary Rules

Each work stream must have:
- **Clear file ownership** - No two streams modify the same file
- **Defined interfaces** - If streams need to interact, define the contract upfront
- **Independent testability** - Each stream should be verifiable in isolation
- **Explicit handoff points** - Where does this stream's output become another's input?

## Phase 3: Define Subagent Context

Each subagent needs:

### Task Briefing Template

```
## Subagent Task: [Stream Name]

### Objective
[One sentence goal]

### Scope
**You own these files**:
- path/to/file1.ts
- path/to/file2.ts

**Do NOT modify**:
- path/to/shared/types.ts (owned by Stream 1)
- path/to/other/file.ts (owned by Stream 2)

### Tasks
1. [ ] [Specific task]
2. [ ] [Specific task]

### Context
[Relevant background from the plan]
[Decisions already made]
[Constraints to follow]

### Required Skills (MUST apply all relevant)
You MUST apply these skills during implementation:

| Skill | When | Verification |
|-------|------|--------------|
| brevity-engineer | After writing any code | Confirm code is minimal, no scope creep |
| linting-engineer | After every file change | Run linters, fix all errors |
| test-writer | After implementing logic | Write tests, verify they pass |
| framework-engineer | When adding dependencies | Research current best practices |
| self-doubt | For complex logic | Walk through reasoning step-by-step |

### Success Criteria (ALL must be verified)

**Functional Criteria**:
- [ ] [Specific, testable behavior - "User can X and sees Y"]
- [ ] [Specific, testable behavior]

**Code Quality Criteria**:
- [ ] All linters pass (linting-engineer verified)
- [ ] Code is minimal - no unnecessary additions (brevity-engineer verified)
- [ ] Tests written and passing (test-writer verified)
- [ ] No hardcoded values that should be configurable
- [ ] No TODO comments left unresolved

**Integration Criteria**:
- [ ] Changes work with existing code
- [ ] No type errors
- [ ] No broken imports

### Self-Verification Checklist
Before reporting completion, verify:
- [ ] Re-read all modified files - does the code make sense?
- [ ] Run the tests - do they actually pass?
- [ ] Check the linter output - any warnings ignored?
- [ ] Review against original task - did I miss anything?
- [ ] Review against success criteria - all boxes checked?

### Handoff
When complete, report:
- Files modified (with line counts)
- Tests added/modified
- Any concerns or edge cases discovered
- Verification status for each success criterion
```

## Phase 4: Orchestration Strategy

### Parallel Execution Pattern

```
┌─────────────────────────────────────────────────────┐
│                   ORCHESTRATOR                       │
│  (You - coordinates, doesn't implement directly)    │
└───────────────┬─────────────┬───────────────────────┘
                │             │
    ┌───────────▼───┐    ┌────▼───────────┐
    │   Subagent 1  │    │   Subagent 2   │
    │   Stream A    │    │   Stream B     │
    │   [files]     │    │   [files]      │
    └───────────────┘    └────────────────┘
                │             │
                ▼             ▼
    ┌─────────────────────────────────────┐
    │          INTEGRATION PHASE           │
    │  (Verify, resolve conflicts, test)  │
    └─────────────────────────────────────┘
```

### Execution Phases

1. **Parallel Phase**: Launch independent subagents simultaneously
2. **Sync Points**: Define where streams must synchronize
3. **Integration Phase**: Merge results, resolve any conflicts
4. **Verification Phase**: Comprehensive double-check of ALL work (see below)

## Phase 5: Verification Protocol (MANDATORY)

After all subagents complete, the orchestrator MUST run a full verification. This is not optional.

### Verification Checklist

```
## Post-Implementation Verification

### 1. Code Review (brevity-engineer lens)
- [ ] Review ALL modified files
- [ ] Check for scope creep - any code that wasn't in the plan?
- [ ] Check for unnecessary abstractions
- [ ] Check for leftover debug code, console.logs, TODOs

### 2. Linting & Types (linting-engineer lens)
- [ ] Run full linter across all changed files
- [ ] Run type checker
- [ ] Zero errors, zero warnings (or justified exceptions)
- [ ] Consistent typing patterns with rest of codebase

### 3. Tests (test-writer lens)
- [ ] Run full test suite
- [ ] All tests pass
- [ ] New code has test coverage
- [ ] Tests are meaningful (not just coverage padding)

### 4. Integration Verification
- [ ] No merge conflicts between subagent work
- [ ] Shared interfaces match across boundaries
- [ ] No duplicate code introduced by parallel work
- [ ] Import paths all resolve correctly

### 5. Plan Compliance
- [ ] Every task from original plan is complete
- [ ] No tasks were skipped or partially done
- [ ] No unauthorized additions (stayed in scope)
- [ ] Success criteria from plan are ALL met

### 6. Double-Check Pass
Re-verify critical items:
- [ ] Security: No secrets, credentials, or sensitive data exposed
- [ ] Performance: No obvious N+1 queries or inefficient loops
- [ ] Error handling: Failures are handled gracefully
- [ ] Edge cases: Known edge cases from test-engineer are covered
```

### Verification Failure Protocol

If verification fails:
1. **Identify**: Which subagent's work has issues?
2. **Isolate**: What specific problem needs fixing?
3. **Fix**: Either fix directly or re-task the subagent
4. **Re-verify**: Run verification again after fixes
5. **Do not proceed** until all verification passes

### Handling Dependencies

For sequential dependencies:
```
Stream 1 (types/interfaces) → Stream 2 (implementation) → Stream 3 (tests)
```

For partial dependencies:
```
Stream 1 ──┬──→ Stream 2a ──┬──→ Integration
           └──→ Stream 2b ──┘
```

## Respons