Wave Executor Skill

Execution Model

You are the coordinator. You do NOT implement — you orchestrate. Your job:

1. Dispatch subagents for each wave
2. Wait for ALL agents in a wave to complete
3. Review their outputs
4. Adapt the plan if needed
5. Dispatch the next wave
6. Repeat until all waves complete

Design Philosophy

This harness exists to enable multi-agent coordination at scale — not by removing friction, but by making it visible, classifiable, and recoverable.

The wave-executor is process scaffolding around LLM agents. It handles task breakdown, scope enforcement, circuit breaker guards, and recovery patterns. Unlike direct chat with an agent, it trades flexibility for safety and repeatability across a bounded execution envelope.

Every harness creates friction. The goal is not minimum friction — it is useful friction that prevents higher-cost problems downstream.

Friction we accept:

• Wave planning overhead and wave-scope.json pre-dispatch setup
• Per-wave quality gates before proceeding
• Worktree isolation costs for parallel agents
• Turn-limit constraints that stop runaway agents early

Friction we prevent:

• Agent scope violations (PreToolUse hooks block out-of-scope file edits)
• Cascading failures (circuit breaker + spiral detection halt broken agents before they propagate damage)
• Silent partial completion (STATUS line requirement forces explicit reporting)
• Untracked carryover work (session-end plan verification catches unresolved tasks)

The harness does not hope agents self-correct. It detects stagnation patterns — pagination-spiral, turn-key-repetition, error-echo — classifies them into the Error-Class Taxonomy defined in circuit-breaker.md, and re-scopes mechanically. Review logic lives in wave-loop.md § "Review Agent Outputs".

Platform Note

State files live in the platform's native directory: .claude/ for Claude Code, .codex/ for Codex CLI, .cursor/ for Cursor IDE. All references to .claude/ below should use the platform's state directory. Shared metrics (sessions.jsonl, learnings.jsonl) live in .orchestrator/metrics/ — both platforms read and write there. See skills/_shared/platform-tools.md for tool mappings.

Phase 0: Bootstrap Gate

Read skills/_shared/bootstrap-gate.md and execute the gate check. If the gate is CLOSED, invoke skills/bootstrap/SKILL.md and wait for completion before proceeding. If the gate is OPEN, continue to the Pre-Execution Check.

Session-start only: This gate check runs ONCE at the start of /go execution — before the first wave. It does NOT run before each wave step. Repeating the check per wave would add latency with no safety benefit, since bootstrap.lock is immutable within a session.

Phase 0.5: Parallel-Aware Preamble

Skip silently when persistence: false in Session Config.

Before Phase 1, run the parallel-aware preamble per skills/_shared/parallel-aware-preamble.md. The preamble detects other active sessions in the worktree-family via findPeers(repoRoot, { mySessionId }), classifies the caller's mode via classifyMode(callerMode) against the exclusivity-matrix, and fires the appropriate AUQ on conflict.

Outcome handling:

• PASS_THROUGH → continue to Phase 1
• EXCLUSIVE_BLOCKED → exit Phase 0 cleanly per the AUQ outcome
• PROMOTION_OFFER → user picks Worktree-Promotion (see parallel-aware-auq.md outcome-handling — calls enterWorktree()), in-place + Deviation, or Abbrechen

For session-end specifically: the preamble is DETECTION-ONLY. The lock-release path in later phases keeps its current behavior — releasing the OWN session's lock requires no matrix consultation.

Implementation reference: skills/_shared/parallel-aware-preamble.md § Implementation. AUQ reference: skills/_shared/parallel-aware-auq.md.

Pre-Execution Check

Before starting the first wave (Discovery role):

1. git status --short — ensure clean working directory (commit or stash if needed)

2. Verify no parallel session conflicts (unexpected modified files)

3. Confirm the agreed plan is still valid (no new critical issues since planning)

4. Verify jq is installed — run command -v jq. If not found, warn the user: "⚠ jq is not installed. Scope and command enforcement hooks will be DISABLED. Install jq (brew install jq / apt install jq) to enable security enforcement." Do NOT proceed with waves until user acknowledges.

5. Read Session Config: Parse Session Config per skills/_shared/config-reading.md. Store result as $CONFIG. Extract these fields:

   • persistence (default: true), enforcement (default: warn), isolation (default: auto)
   • agents-per-wave (default: 6), max-turns (default: auto), pencil (default: null)

   Execution Config shortcut: If the session-plan output contains an ### Execution Config section, its execution-level fields (waves, agents-per-wave, isolation, enforcement, max-turns) take precedence over $CONFIG. Session-level fields (persistence, pencil) always come from $CONFIG. If the Execution Config section is missing, use $CONFIG alone.

6. Initialize session metrics (if persistence enabled): Prepare a metrics tracking object for this session:

   • session_id: <branch>-<YYYY-MM-DD>-<HHmm> (HHmm from started_at — ensures uniqueness across multiple sessions per day)
   • session_type: from Session Config
   • started_at: ISO 8601 timestamp
   • waves: empty array (populated after each wave) This object lives in memory during execution — it is written to disk by session-end.

Pre-Execution: User Instructions

If the user provided additional instructions with /go (e.g., /go focus on API endpoints), apply them as a priority modifier:

1. Incorporate into agent prompts: Add a "Priority Focus:" section to each agent's prompt that includes the user's instructions verbatim
2. Do NOT override the plan: User instructions adjust emphasis within the existing plan, they do not replace it. If the instructions conflict with the plan, note the conflict and follow the plan.

Example: If user said /go focus on API endpoints, each agent prompt includes:

**Priority Focus (from user):** focus on API endpoints

Pre-Wave 1a: Capture Session Start Ref

Before dispatching Wave 1, capture the current commit as the session baseline:

SESSION_START_REF=$(git rev-parse HEAD)

Store this value for use throughout the session — it is needed by the simplification pass (Quality wave) and session-reviewer dispatch to determine which files changed during this session. Include it in the coordinator's context, NOT in individual agent prompts.

Pre-Wave 1b: Initialize STATE.md

Skip this section entirely if persistence: false.

Before dispatching Wave 1, write <state-dir>/STATE.md with YAML frontmatter and Markdown body:

---
schema-version: 1
session-type: feature|deep|housekeeping
branch: <current branch>
issues: [<issue numbers from plan>]
started_at: <ISO 8601 timestamp with timezone>
status: active
current-wave: 0
total-waves: <from session plan>
---

## Current Wave

Wave 0 — Initializing

## Wave History

(none yet)

## Deviations

(none yet)

Create the <state-dir> directory if needed (mkdir -p <state-dir>) before writing. This file is the persistent state record — other skills and resumed sessions read it.

Pre-Wave 1b Extension: Docs Tasks Persistence (A3 / #230)

After writing the base STATE.md frontmatter above, conditionally persist the docs tasks block emitted by session-plan:

Condition: BOTH of the following must be true:

1. The session plan contains a ### Docs Tasks (machine-readable) section with a YAML code block.
2. $CONFIG."docs-orchestrator".enabled is true.

If either condition is false