/dispatching-workflows

name: ring:dispatching-workflows
description: "Executing a phased plan in rolling waves where each phase runs as one multi-agent workflow harness: the supervisor elaborates the phase into tasks against the real landed code, launches a workflow that implements with TDD and runs mandatory in-harness review plus an adversarial contrarian pass (and researchers when the phase hits an unknown) before returning verified work, then reviews it, checkpoints with the user, and rolls to the next phase. Use when each wave should be a reviewed multi-agent harness, not a lone subagent. Skip when one supervised subagent per wave suffices (ring:executing-plans) or the full gated cycle is wanted (ring:running-dev-cycle)."

Dispatching Workflows

When to use

• A phased plan exists (typically from ring:writing-plans) and you want each phase executed by a **multi-agent harness**, not a single subagent
• You want review and an adversarial contrarian pass baked **inside** every wave — verified work returns, unverified work does not
• Work benefits from phase checkpoints and supervisor course-correction between phases

Skip when

• One supervised subagent per wave is enough → ring:executing-plans (lighter; the supervisor reviews after the wave returns)
• Production work needing the full gated specialist roster and Gate 0/8/9 → ring:running-dev-cycle
• No plan exists yet → ring:writing-plans first
• Plan covers multiple independent subsystems → split into separate plans before executing

Sequence

**Runs after:** ring:writing-plans (consumes and updates its living plan document) **Alternatives:** ring:executing-plans (one supervised subagent per wave — lighter), ring:running-dev-cycle (full gated specialist cycle — heavier)

Related

**Companion skills:** ring:writing-plans (Task Format + phase-epic-task hierarchy used during elaboration), ring:test-driven-development (RED→GREEN per task, inside the harness), ring:committing-changes (closes each task with a signed atomic commit), ring:reviewing-code (the full 9+ reviewer pool — run it at plan close or for a high-stakes phase)

---

The loop: **elaborate the current phase into tasks against the real landed code → launch the phase as one workflow that implements, reviews, and contrarian-verifies internally → the workflow returns verified work → review it as supervisor → phase checkpoint → roll to the next phase → repeat.** The main agent stays the supervisor; the workflow is a multi-agent harness, not a lone implementer. The plan document is the living source of truth — elaboration writes tasks back into it.

**Announce at start:** "Using ring:dispatching-workflows to execute this plan phase-by-phase as reviewed multi-agent workflows."

How this differs from the sibling skills

| Skill | Wave unit | What runs the wave | Where review happens | |-------|-----------|--------------------|----------------------| | ring:executing-plans | phase or epic | **one** supervised subagent | supervisor reviews **after** the wave returns | | **ring:dispatching-workflows** | **phase** | a **multi-agent workflow harness** | **inside** the harness (mandatory) — verified work returns | | ring:running-dev-cycle | task/epic/phase cadences | gated specialist orchestration | Gate 8 full reviewer pool, per epic |

If you do not need an in-harness multi-agent pass, use ring:executing-plans — it is cheaper and simpler.

The Harness (what runs inside one phase workflow)

Author one workflow per phase. Its stages, in order:

1. **Research (conditional)** — only when the phase introduces an unknown (a new library, an unfamiliar pattern, an external contract). A researcher agent resolves it and feeds findings to the implementers. Skip when the phase is well-understood. 2. **Implement** — the phase's tasks, in dependency order. Each task uses ring:test-driven-development (failing test first, capture RED, then GREEN) and closes with a signed atomic commit via ring:committing-changes. Tasks in a phase usually depend on each other → run them sequentially; parallelize only truly independent tasks, and then with `isolation: 'worktree'` so they don't collide on files. 3. **Review (MANDATORY)** — the relevant Ring reviewer agents, in parallel, over the phase diff. **Compose the existing reviewers via `agentType`** (`agent(prompt, {agentType: 'ring:logic-reviewer', schema})`) — do not re-implement them, and do not re-list the roster here. Pick by what the phase touched (see ring:reviewing-code for the roster and the triggers for conditional specialists). Review is read-only. 4. **Contrarian (MANDATORY)** — adversarial verifiers whose job is to **refute** the wave's claims, not confirm them: that tests actually ran, that the implementation matches each task's vision, that no scope was smuggled in, that no simpler correct approach was ignored. Prompt them to default to *refuted* when uncertain. This is a **role**, not a Ring agent — it lives in the harness prompt. 5. **Synthesize** — PASS only if review surfaced no Critical/High **and** the contrarian refuted nothing. Otherwise the harness self-heals once (fix → re-review), and if still not clean **returns `ISSUES`** rather than looping unbounded. Return a structured report: `status`, `commits`, `findings`, `refutations`.

**Review depth scales with the phase** — pick the reviewers the diff warrants; do not run all 12 every phase. The full ring:reviewing-code pool is the supervisor's call at plan close or for a high-stakes phase, not a per-phase default.

Workflow skeleton (Claude Code Workflow tool)

export const meta = {
  name: 'phase-wave',
  description: 'Implement one plan phase, then review + contrarian-verify before returning',
  phases: [{ title: 'Implement' }, { title: 'Review' }, { title: 'Contrarian' }],
}

const TASKS     = args.tasks      // dispatch-ready tasks the supervisor elaborated this phase
const REVIEWERS = args.reviewers  // Ring reviewer agentTypes picked for this phase's diff

// 2. Implement —