Dev Orchestrator

Coordinate multi-task development prompts by detecting tasks, confirming the plan with the user, dispatching one isolated agent per task, and consolidating their results into a single report.

Workflow

The orchestration runs in five phases. Phase 1 always runs; Phases 2–4 run only when two or more independent tasks survive Phase 1; Phase 5 runs after Phase 4 only when the completed work produced testable artifacts (code or repo state changes). Phase 0 (opt-in) runs ahead of Phase 1 when the prompt references an issue-tracker ticket.

Agent dispatch is host-agnostic. Every task — parallel or sequential, code-touching or doc-only, worktree-mode or not — is dispatched as an isolated agent with its own session, own working directory, scoped tool list, and an orchestrator-awaited completion. The contract and the per-host primitive (Claude Code Task with run_in_background: true, Cursor SDK Agent.create / Agent.prompt, etc.) live in references/dispatch-contract.md. SKILL.md says "dispatch an agent"; that reference documents what that means operationally.

For end-to-end scenario walkthroughs (input prompt → phase-by-phase trace → exact reports the user will see), see references/workflow.md — covers doc-only fan-out, mixed code/doc fan-out, soft-sequenced waves, worktree mode (single + multi-subtask), worktree --no-merge opt-out, and hard-chained merges, plus a Phase 2 confirmation cheatsheet and a recovery checklist.

Phase 0: Ticket Resolution (opt-in)

Phase 0 fires before Phase 1 whenever the prompt references an issue-tracker ticket — Linear / Jira ([A-Z]+-\d+, e.g. ABC-42), GitHub Issues (#123 or owner/repo#123), or a Notion page URL — or when the user explicitly passed --ticket <id>. When no reference is detected, Phase 0 is a no-op and the existing flow runs unchanged.

When fired, the orchestrator resolves the ticket via the matching MCP tool (mcp__linear__get_issue, mcp__jira__get_issue, mcp__github__get_issue, or mcp__notion__get_page — confirm the tool is registered before calling) and extracts a normalized envelope (title, state, description, parsed acceptance_criteria, labels, url). The envelope is prepended to the prompt body — the bare ticket reference is stripped — so Phase 1 classification sees the ticket's acceptance criteria as natural split anchors. When worktree mode is also on, the resolved ticket id becomes the integration branch name (ticket/<TICKET-ID> by default, or <prefix>/<ticket-id>-<slug> when a --prefix / --slug override is captured) — every per-task worktree provisioned in Phase 3 is branched off that integration branch, and Phase 4.5 hands the integration branch off to agent-pr-creator for the protected-base PR.

Detection patterns, tracker disambiguation (Linear vs Jira), the full MCP fetch contract, per-tracker extraction rules, failure handling (missing MCP / 404 / permission denied / closed ticket / mixed batches), the optional .dev-orchestrator.yml config, and a worked end-to-end example all live in references/ticket-resolution.md.