From session-orchestrator
Orchestrates multi-wave session execution with role-based subagents, quality gates, plan adaptation, and progress tracking. Core engine for feature and deep sessions.
How this skill is triggered — by the user, by Claude, or both
Slash command
/session-orchestrator:wave-executoropusThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
You are the **coordinator**. You do NOT implement — you orchestrate. Your job:
You are the coordinator. You do NOT implement — you orchestrate. Your job:
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-scope.json pre-dispatch setupFriction we prevent:
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".
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. Seeskills/_shared/platform-tools.mdfor tool mappings.
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.
Do NOT proceed past Phase 0 if GATE_CLOSED. There is no bypass. Refer to `skills/_shared/bootstrap-gate.md` for the full HARD-GATE constraints.Session-start only: This gate check runs ONCE at the start of
/goexecution — before the first wave. It does NOT run before each wave step. Repeating the check per wave would add latency with no safety benefit, sincebootstrap.lockis immutable within a session.
Skip silently when
persistence: falsein 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 1EXCLUSIVE_BLOCKED → exit Phase 0 cleanly per the AUQ outcomePROMOTION_OFFER → user picks Worktree-Promotion (see parallel-aware-auq.md outcome-handling — calls enterWorktree()), in-place + Deviation, or AbbrechenFor 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.
Before starting the first wave (Discovery role):
git status --short — ensure clean working directory (commit or stash if needed)
Verify no parallel session conflicts (unexpected modified files)
Confirm the agreed plan is still valid (no new critical issues since planning)
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.
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.
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 Configstarted_at: ISO 8601 timestampwaves: empty array (populated after each wave)
This object lives in memory during execution — it is written to disk by session-end.If the user provided additional instructions with /go (e.g., /go focus on API endpoints), apply them as a priority modifier:
Example: If user said /go focus on API endpoints, each agent prompt includes:
**Priority Focus (from user):** focus on API endpoints
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.
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.
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:
### Docs Tasks (machine-readable) section with a YAML code block.$CONFIG."docs-orchestrator".enabled is true.If either condition is false → omit the docs-tasks field entirely. Do NOT write an empty key (docs-tasks: []). Absence means "no docs tasks planned this session" — downstream consumers (session-end Phase 3.2) treat absence the same as an empty list.
When the condition is met, parse the YAML block from the session plan's ### Docs Tasks (machine-readable) section and append the following field to the STATE.md YAML frontmatter (alongside the base fields above):
docs-tasks:
- id: <task id from plan>
audience: <user|dev|vault>
target-pattern: <glob pattern from plan>
rationale: <rationale string from plan>
wave: <wave number the task is assigned to>
status: planned
Each entry's status is initialized to planned. session-end Phase 3.2 (Docs Verify) writes the terminal value per task: ok (diff is substantive), partial (diff region contains <!-- REVIEW: source needed --> markers), or gap (no matching diff). wave-executor does NOT perform intermediate status updates — planned remains until session-end runs.
Schema note:
schema-version: 1now includes the optionaldocs-tasksarray. The field is backwards-compatible — its absence is a valid schema-version-1 STATE.md meaning "no docs tasks planned". Readers MUST treat a missingdocs-taskskey identically todocs-tasks: [].
Ownership clarification: session-plan does NOT write STATE.md directly. The wave-executor owns ALL STATE.md writes — initialization here (Pre-Wave 1b) is the canonical write point for
docs-tasks. session-plan only emits the source### Docs Tasks (machine-readable)block for the coordinator to consume. Seeskills/_shared/state-ownership.mdfor the full ownership matrix.
Consumer cross-reference: session-end reads
STATE.mdfrontmatter'sdocs-tasksfield (if present) during Phase 3.2 Docs Verify — seeskills/session-end/SKILL.md. The field is also readable by the docs-writer agent if it needs to know which tasks were planned for the current session.
Ownership: STATE.md is owned by the wave-executor. Only the wave-executor writes to it (initialization + post-wave updates). session-end reads it for metrics extraction and sets
status: completed. session-start reads it only for continuity checks (Phase 0.5). No other skill should write to STATE.md.
Read and follow wave-loop.md in this skill directory for the complete wave execution loop, including agent dispatch, output review, plan adaptation, progress updates, and scope manifest creation.
The coordinator (you) is responsible for updating per-task mission status in STATE.md as tasks progress through the wave. Use setMissionStatus(stateContent, taskId, status) from scripts/lib/state-md.mjs and write the result back to STATE.md immediately.
Per-task transition rules (coordinator fires these, NOT wave-loop.md):
| Transition | When to fire |
|---|---|
brainstormed → validated | User runs /go to approve the wave plan (all items simultaneously) |
validated → in-dev | Agent for that wave-plan item is dispatched via Agent() tool |
in-dev → testing | Quality wave begins and this item's implementation wave completed without failure |
testing → completed | Quality-Lite gate passes (green) for this task's wave — coordinator confirms item done |
Any → brainstormed | Item is discarded, re-planned, or rolled back |
Important scoping notes:
wave-loop.md dispatch/review logic. Do NOT modify wave-loop.md to add mission-status calls.wave-loop.md is NOT modified by #340 — the transitions listed above are called by the coordinator after observing the wave-loop outcomes.id appears in the ### Wave-Plan Mission Status (machine-readable) block emitted by session-plan. Invent no new IDs.## Mission Status body section, setMissionStatus creates it automatically (see scripts/lib/state-md.mjs).readMissionStatus(stateContent, taskId) from the same module returns the current status string for a task (or null if not found), useful for guard-checking before transitions.Backward compat: STATE.md files without a ## Mission Status section are valid — absence means no status tracking was started. The helpers are no-throw on bad input.
Reference: See
circuit-breaker.mdin this skill directory for MaxTurns enforcement, spiral detection, recovery protocol, and worktree isolation configuration. Apply those rules during every wave dispatch and post-wave review.
Claude Code's Agent tool with isolation: "worktree" changes process.cwd() into the agent's worktree and does not restore it on agent return. Without discipline, the coordinator's subsequent Edit/Write/Bash calls silently route to a worktree branch — producing data loss when the worktree is later pruned.
Rules for the coordinator (this is YOU during wave execution):
restoreCoordinatorCwd() from scripts/lib/worktree.mjs. wave-loop.md § 2 makes this explicit.cd inside a subshell (cd /path && cmd) or rely on git -C /path <cmd>. Do not assume CWD.git rev-parse --show-toplevel to confirm which tree is currently active.cd into a worktree in the coordinator's top-level shell. If you need to inspect a worktree, use git -C <wt-path> ... or spawn a subshell.Every mid-wave user decision — pause/continue, scope changes, plan revisions, routing between alternate tracks, confirming a risky recovery step, picking between recommendations — MUST go through the AskUserQuestion tool. Inline markdown-list "choose 1/2/3" questions in chat prose are forbidden: the user reliably misses them in the dense wave-execution stream. See .claude/rules/ask-via-tool.md for the full rule (AUQ-001 through AUQ-005).
Mechanics:
AskUserQuestion is a deferred tool in Claude Code. On the first coordinator decision point in a session, call ToolSearch with "select:AskUserQuestion" once to load its schema, then call the tool. Do not skip the question to avoid the load.(Recommended) in the label. Each option carries a one-line description stating the trade-off.AskUserQuestion is not available inside dispatched subagents. If an agent surfaces a decision back to you, ask the user via AskUserQuestion from the coordinator turn — do not let the agent emit a prose question.Applies to every interaction point in wave-loop.md that currently says "inform the user", "propose revised plan", "ask the user whether to…", or "report specific mismatches to user" when a choice is implied.
Each agent prompt MUST include:
docs/plans/<feature>.md for the wave's tasks (see skills/write-executable-plan/SKILL.md), include the path in each agent's prompt and instruct the agent to follow the plan's 5-step structure verbatim.circuit-breaker.md.claude/rules/verification-before-completion.md.Each agent prompt MUST NOT include:
Wave-executor agents may propose memory entries (learnings) mid-session via the memory.propose CLI. The coordinator surfaces proposals at session-end Phase 3.6.3 (skills/session-end/SKILL.md) for AUQ-confirm before promoting them to learnings.jsonl with _provenance: agent-proposed@<wave-id>. Conservative safety model: max memory.proposals.quota-per-wave (default 5) per wave, memory.proposals.confidence-floor (default 0.5).
Agent prompt boilerplate — when dispatching an Impl-Core / Impl-Polish / Quality agent in a session where memory.proposals.enabled: true (default), include this block in the agent's prompt so the capability is discoverable:
## Memory Proposal Capability (optional)
During this wave, you may propose a learning to the session's memory via the CLI:
SO_WAVE_AGENT=1 node scripts/memory-propose.mjs \
--type <one of: workflow-pattern|anti-pattern|pattern|recurring-issue|fragile-file|effective-sizing|proven-pattern|mode-selector-accuracy|hardware-pattern|autopilot-effectiveness> \
--subject "one-line title (max 100 chars, no newlines)" \
--insight "your discovery paragraph (max 2000 chars)" \
--evidence "concrete proof: code citation / log excerpt / commit ref (max 5000 chars)" \
--confidence <0.5 to 1.0>
MUST prefix with `SO_WAVE_AGENT=1` — without it the CLI returns exit 3 `rejected-wrong-context`. The env-var is the per-process guard that distinguishes wave-executor agents from coordinator-context invocations.
Exit code 0 = queued (the coordinator will present at session-end via AskUserQuestion); 1 = quota-exceeded; 2 = rejected-low-confidence (below floor 0.5); 3 = rejected-wrong-context (STATE.md not active OR SO_WAVE_AGENT != "1"); 4 = error (arg validation or internal).
Use ONLY when you find a recurring pattern, anti-pattern, or constraint worth carrying into future sessions. The coordinator confirms each proposal before it lands in learnings.jsonl. Do NOT over-propose — quota is bounded per wave.
Skip injection when:
memory.proposals.enabled: false in Session Config, ORAudit trail: the hooks/pre-bash-memory-propose-audit.mjs hook logs every CLI invocation to .orchestrator/metrics/events.jsonl with the value of --insight / --subject / --evidence redacted (privacy-by-default).
Cross-reference: PRD F2.1 / issue #501 / agents/memory-proposal-collector.md (coordinator-side AUQ rendering reference doc) / scripts/lib/memory-proposals/{schema,store,collector,sink}.mjs (the modules).
Housekeeping sessions use a simplified single-wave execution model instead of the multi-wave role-based dispatch:
session-type: housekeeping, total-waves: 1)wave-scope.json — scope enforcement is not needed for low-risk housekeeping tasksstatus: completed — that write is reserved for session-end per state-ownership contract (skills/_shared/state-ownership.md). Leave status: active./close)Focus: git cleanup, SSOT refresh, CI fixes, branch merges, documentation. End with a single commit summarizing all housekeeping work.
| Situation | Action |
|---|---|
| Agent times out | Re-dispatch with smaller scope |
| Agent produces broken code | Add fix task to next wave |
| Tests fail after wave | Diagnose in next wave, don't skip |
| Merge conflict between agents | Resolve manually, document |
| TypeScript errors introduced | Track count, run Full Gate per quality-gates by Quality wave |
| New critical issue discovered | Inform user, add to Impl-Polish+ roles if fits scope |
| Agent edits wrong files | Revert via git, re-dispatch with stricter scope |
| New critical issue discovered with broken behavior | Apply skills/debug/SKILL.md Iron Law 4-phase investigation before proposing a fix |
When wave-executor is invoked as sessionRunner from scripts/lib/autopilot.mjs::runLoop, the value it returns to the loop drives the post-session kill-switches (spiral, failed-wave, carryover-too-high). The loop reads schema-canonical fields off the returned object — absent fields are treated as "no signal" (forward-compatible: an older or partial implementation simply does not trip the post-session gates).
// Returned by sessionRunner({mode, autopilotRunId}) — superset of session-record schema.
{
session_id: string, // required (used since Phase C-1)
agent_summary?: { // schema-canonical (session-schema.mjs)
complete?: number,
partial?: number,
failed?: number, // > 0 → kill-switch: failed-wave
spiral?: number, // > 0 → kill-switch: spiral
},
effectiveness?: { // schema-canonical (session-schema.mjs)
planned_issues?: number, // 0 → carryover gate is no-op (avoids div-by-zero)
carryover?: number, // / planned > carryoverThreshold → carryover-too-high
completion_rate?: number,
completed_issues?: number,
},
usage?: { // schema-canonical (autopilot token-budget kill-switch, #355)
output_tokens?: number, // cumulative output tokens for this session; absence → 0 (forward-compat)
total_tokens?: number, // alternative name accepted as fallback
},
}
autopilot_run_id propagation: when wave-executor is invoked under autopilot, args.autopilotRunId is the loop-level run id. The per-iteration sessions.jsonl record MUST carry autopilot_run_id: <id> so retros can join autopilot.jsonl ↔ sessions.jsonl without schema changes. Manual sessions write null or omit the field — readers treat both identically per the v1 additive convention. See skills/session-end/session-metrics-write.md.
After the Finalization wave completes successfully:
persistence: true, suggest invoking /close to finalize the session. If persistence: false, note that the session is complete (no STATE.md to close — session-end would be a no-op)./close handles that with proper verificationWhen the inter-wave Quality-Lite checkpoint invokes vault-sync, it should prefer --mode=diff over full enforcement so the coordinator sees only regressions introduced by the current wave — not pre-existing issues that were already present at session start.
Preferred checkpoint invocation (once a baseline exists):
VAULT_DIR=<vault-dir> bash skills/vault-sync/validator.sh --mode diff
The diff JSON block ({ new_errors, resolved_errors, baseline_count, current_count, schema_hash }) is emitted to stdout. The coordinator parses it and surfaces a compact summary in the inter-wave checkpoint output. Focus on new_errors only — resolved_errors are informational.
First-run bootstrap: if no baseline file exists at <vault-dir>/.orchestrator/metrics/vault-sync-baseline.json, the coordinator runs --mode=baseline once before the next wave starts, then switches to --mode=diff for all subsequent checkpoints.
Schema migration: when the vendored schema in validator.mjs changes, the schema-hash in the existing baseline won't match. The validator falls back to full enforcement and emits a WARN to stderr. The coordinator must re-run --mode=baseline manually before resuming diff-mode checkpoints.
Configuration: diff-mode is enabled by default once a baseline exists. To force full enforcement at any checkpoint, set vault-sync.mode: full in Session Config or pass --mode full explicitly.
Cross-reference: baseline file shape, diff output schema, and schema-hash mismatch handling are documented in
skills/vault-sync/SKILL.md§ Modes (#327).
After each wave, run the Quality-Gate. If verification-auto-fix.enabled: true
in Session Config, the gate uses runQualityGateWithRetry() from
scripts/lib/quality-gate.mjs which dispatches up to max-retries (default 2)
fixer-agent dispatches on failure.
import { runQualityGateWithRetry } from '../../scripts/lib/quality-gate.mjs';
const result = await runQualityGateWithRetry({
maxRetries: config['verification-auto-fix']?.['max-retries'] ?? 2,
repoRoot: process.cwd(),
dispatchFixer: async ({ failures, correctiveContext, changedFiles }) => {
// Coordinator dispatches a code-implementer fixer subagent here with:
// - failures (gate + output)
// - correctiveContext (from .orchestrator/current-session.json)
// - changedFiles (since last green SHA)
// Subagent's task: fix the failing gate, never broaden scope.
await dispatchFixerSubagent({ failures, correctiveContext, changedFiles });
},
});
result.ok === true → Wave green, proceed to next wave or session-end.result.ok === false → Hard abort.
.orchestrator/metrics/verification-failures/<ts>.json (diagnostics bundle — automatic, redacted per redactDiagnosticsBundle()).appendDeviationOnDisk() — see wave-loop.md § STATE.md Deviation — Auto-Fix Result.result.attempts > 1 → Coordinator logs a Deviation in STATE.md via appendDeviationOnDisk(): auto-fix used N retries to clear Wave <wave>.verification-auto-fix.enabled: false (default) → fall back to single-shot
quality-gate, abort on first failure (current behavior preserved per PRD § 3
Gherkin negative path).verification-auto-fix.max-retries: 0 → equivalent to disabled.When goal-integration.enabled: true with seam inter-wave-fixloop in Session Config, the coordinator may surface ONE advisory /goal command at the inter-wave fix-loop seam to anchor continuation across the auto-fix retries — see wave-loop.md § "##### /goal Continuation Anchor" for the gate conditions, suggested command, and the LM-008 cross-reference. The advisory never alters gate semantics: runQualityGateWithRetry()'s exit-code result remains the judgment, and the hard-abort + diagnostics-bundle path after max-retries is unchanged. Default off → zero behaviour change.
The fixer-agent prompt MUST include a reminder of .claude/rules/testing.md § "Test Quality — False-Positive Prevention"
"test-the-mock" anti-pattern. A fix that makes tests green by mocking out the
real failure is a regression vector. The fixer prompt should explicitly say:
"Do NOT change test mocks to make tests pass. Fix the actual code defect."
After each quality-gate PASS, the coordinator refreshes the session-lock heartbeat via the post-wave STATE.md step. See wave-loop.md § 3a. Post-Wave: Update STATE.md — step 5 contains the updateHeartbeat instruction and best-effort framing. The sessionId passed to updateHeartbeat is the session identifier established by session-start Phase 1.2 acquire() and stored in .orchestrator/session.lock (its session_id field); it matches the STATE.md frontmatter session: field written during Pre-Wave 1b initialization.
Optional, best-effort operator-side observability: the coordinator pushes lightweight per-agent status at three anchors (dispatch, agent-end, wave-end rollup) via scripts/lib/agent-status.mjs, gated on persistence: true. A push NEVER blocks a wave. The tmux --with-status-pane flag (skills/tmux-layout/SKILL.md) renders the live feed. See wave-loop.md § 3a-bis. Agent-Status Telemetry for the exact anchors and invocation.
When an agent's task scope includes vault paths (~/Projects/vault/ or vault subdirectories such as 40-learnings/, 50-sessions/, 03-daily/, 01-projects/), the wave-executor injects a deterministic frontmatter-schema snippet into the agent's prompt. This eliminates the recurring failure class where agents guess at enum values for type, status, or tags.
See wave-loop.md § Pre-Dispatch: Frontmatter-Guard Injection for the exact contract. The snippet generator is scripts/lib/frontmatter-guard.mjs (skill: skills/frontmatter-guard/).
An opt-in bounded-concurrency cursor-based pull loop that replaces the default Promise.all() fan-out for agent dispatch. Controlled by three Session Config fields under the worker-pool object:
| Field | Type | Default | Description |
|---|---|---|---|
worker-pool.enabled | boolean | false | When false (default), the existing single-message parallel Agent() dispatch is used (backward-compatible). When true, runWavePool() from scripts/lib/wave-executor/pool.mjs is used instead. |
worker-pool.max-parallel | integer | value of agents-per-wave | Maximum concurrent workers in the pool. Falls back to agents-per-wave when unset. Useful for capping concurrency below agents-per-wave on memory-constrained hosts. |
worker-pool.drain-timeout-ms | integer | 10000 (10 s) | When an abort signal fires mid-run (e.g., a MAX_HOURS kill-switch), workers are sent SIGTERM via their per-worker AbortController and the pool waits at most this many milliseconds before returning partial results. |
Backward compatibility: worker-pool.enabled defaults to false. All existing sessions that omit the worker-pool block behave identically to before — full Promise.all() fan-out, all agents start simultaneously. No migration required.
When to enable: use worker-pool.enabled: true when agents-per-wave is high (≥ 8) and the host is memory-constrained, or when you want to observe incremental agent completion rather than waiting for all agents to finish before inter-wave checks begin.
run_in_background: true during waves — you lose coordination abilityagents-per-waveAskUserQuestion (see .claude/rules/ask-via-tool.md)wave-loop.md § Auto-Commit Checkpoint) is coordinator-only and fires only after Quality-Lite PASS. Agents report STATUS lines; the coordinator decides whether and when to commit. Subagent commits bypass the quality gate, skip the STATE.md deviation log, and violate parallel-session isolation (PSA-004 in .claude/rules/parallel-sessions.md).Auto-commit vs. coordinator-snapshot: these two features are complementary, not competing.
coordinator-snapshot.mjs (wave-loop.md § Pre-Dispatch Coordinator Snapshot) fires before agent dispatch as a stash-based working-tree backup — it protects uncommitted coordinator state from worktree merge-back collisions.git stash incidents (V3.3 RESCUE incident, GitLab #214).Both are gated on persistence: true. Neither replaces the other. The snapshot is pre-dispatch insurance; the auto-commit is post-gate durability.
npx claudepluginhub kanevry/session-orchestrator --plugin session-orchestratorCreates structured wave execution plans with role-based agent assignment, dependency ordering, and checkpoints after user alignment. Activated automatically after session-start Q&A phase.
Monitors context window health during multi-step agent tasks to ride peak quality for high-fidelity output and prevent drift in long-running sessions or complex refactors.
Resumes interrupted Maestro sessions using existing active-session files and shared phase tracking. Use to continue multi-agent orchestration workflows after interruptions.