/orchestrate

name: orchestrate
description: "Internal, invoked from the orchestration context: tier classification, delegation model table, and phase-owner dispatch rules for sizing and dispatching implementation work."
user-invocable: false

Orchestrate — Tier, Delegation and Dispatch

On-demand depth for sizing work and dispatching agents. The tier table and the delegation model table apply when `orchestration.mode` is `workflow`. In `schema` mode the schema alone governs process, so skip the tier and model-table content — but the phase-owner dispatch rules and the explicit-`model` rule below still apply, with the model chosen by judgment.

Tier Classification

Classify every piece of work into a tier before starting — the tier determines how much process to apply.

<!-- BEGIN GENERATED:tier-classification | source: claude-plugins/task-orchestrator/_fragments/tier-classification.md · regen: node claude-plugins/task-orchestrator/_fragments/generate.mjs --> | Criteria | Tier | Pipeline | |----------|------|----------| | 1-2 files, known fix, no migration/new API | **Direct** | Orchestrator edits, tests, reviews inline | | 3-10 files, single logical unit, clear or explorable scope | **Delegated** | Single subagent, separate review agent | | 11+ files, multiple independent work streams, dependency edges | **Parallel** | Worktree agents, full pipeline |

**Force-UP signals** (bump tier regardless of file count):

• Database migration → min Delegated
• New public API surface → min Delegated
• Multiple independent work streams → Parallel
• User says "let's plan" / collaborative language → min Delegated

**Force-DOWN signals:**

• User says "just fix it" / "quick" → Direct (unless complexity contradicts)
• Schema tag is `default` or absent → eligible for Direct

<!-- END GENERATED:tier-classification -->

Tier Pipeline Summary

| Step | Direct | Delegated | Parallel | |------|--------|-----------|----------| | Plan mode | skip | optional | required | | Queue notes | none required | fill per schema | fill per schema | | Implementation | orchestrator inline — no subagent, no delegation table | single subagent | parallel worktree agents | | Review | inline (orchestrator) | separate agent | separate agent |

Review applies only when the item's schema declares review-phase notes; otherwise work advances straight to terminal — detect via `newRole` and skip review dispatch.

**Multi-item dispatch:** when post-plan-workflow's four-part condition holds (two or more unblocked leaf items, a resolvable rootId, filled queue notes, protocol rules listed), dispatch goes through `/task-orchestrator:run-wave`; otherwise hand-dispatch.

Delegation

> **Project convention, not a plugin requirement.** The specific model assignments and the > MCP-write batching threshold below are tuned for this repository. Projects using this skill > should treat them as sensible defaults and adjust to their own model availability and tooling — > what transfers is the *principle* (match model to task weight; keep the orchestrator's context > lean), not the exact table values.

| Task type | Model | |-----------|-------| | MCP bulk ops, materialization, simple queries | `haiku` | | Code reading, implementation, test writing | `sonnet` | | Architecture, complex tradeoffs, multi-file synthesis | `opus` |

**Always set `model` explicitly** on every Agent dispatch — defaulting wastes opus tokens or under-powers complex work.

Dispatching an item's phase owner

Applies only to the agent that OWNS the phase being entered — the implementer entering work, the reviewer entering review — never test author, planning seats, or the docs seat (those keep the Delegation table above).

Read the profile for the phase you are dispatching INTO, not the item's current phase:

• If the orchestrator already performed the transition (e.g. dispatching the reviewer after advancing the item into review), read `dispatch` off that `advance_item` call's success result — it reports the profile for `newRole`, the phase being dispatched into.
• If the agent will perform its own phase entry (the agent-owned-phase protocol: the implementer is dispatched while the item is still in queue, and calls `advance_item(start)` itself to enter work), `get_context(itemId=...)` returns only the profile for the item's CURRENT role (queue) — not the work-phase profile needed for dispatch. Read `query_items(operation="schema", itemId=...)`'s per-phase `dispatch.work` map instead.

When that profile names an `agent`, dispatch with `subagent_type` set to that `dispatch.agent`. Regardless of whether `agent` is set, ALWAYS still pass `model` explicitly: `dispatch.model` if the profile sets one, otherwise the Delegation table's value above (or your own judgment in `schema` mode) — both shipped agents (`task-orchestrator:implementer`, `task-orchestrator:reviewer`) ship `model: inherit`, and Claude Code resolves the per-invocation Agent-tool `model` first, then the agent's own frontmatter, where `inherit` means the main conversation's model — omitting `model` silently runs the phase owner on the orchestrator's own model instead of the intended assignment.

`effort` has no Agent-tool parameter of its own. In Claude Code it is honored only through the dispatched agent definition's own frontmatter `effort` field, so a profile's `effort` is advisory unless `agent` also names a definition carrying that `effort` — to change effort, point `agent` at a definition with that effort. (A client that calls the model API directly may apply a profile's `effort` field itself.) This rule is for the phase OWNER only — auxiliary dispatches on the same item (test author under `needs-test-author`, planning seats, the docs seat) keep the Delegation table; a work-phase dispatch profile names the phase owner, not every work-phase dispatch.

For a **seat-aware** item (its schema declares `seats:`), read every seat's profile — including the test author and planning seats — from the resolved `dispatchBySe