orchestrate

name	orchestrate
description	Multi-task coordination: parent+subtask decomposition, parallel dispatch planning, dependency-graph navigation, and cross-task scope assessment. Use when: 'decompose mt#X', 'break this down into subtasks', 'coordinate mt#A and mt#B', 'dispatch in parallel', 'dependency order', "what's the order for...", 'run X Y Z in parallel'. Does NOT own single-task lifecycle transitions — those belong to /plan-task, /implement-task, and /verify-task.
user-invocable	true

Orchestrate

Multi-task coordination skill. Handles parent+subtask decomposition, parallel dispatch planning, dependency-graph navigation, and cross-task scope assessment.

This skill does NOT own single-task lifecycle transitions:

• Planning and investigation → /plan-task
• Implementation and sessions → /implement-task
• Verification and merge → /verify-task

Triggers

This skill activates on multi-task coordination verbs:

• "decompose mt#X"
• "break this down into subtasks"
• "coordinate mt#A and mt#B"
• "dispatch in parallel"
• "dependency order"
• "what's the order for…"
• "run X Y Z in parallel"

This skill does NOT trigger on single-task verbs: "start working on", "implement mt#X", "investigate mt#X" — those belong to the phase skills above.

Arguments

Optional: one or more task IDs (e.g., /orchestrate mt#123 or /orchestrate mt#A mt#B mt#C). If no task IDs are given, the skill works from context provided by the user.

Coordination concerns

0. Restate plan check (pre-action, mandatory)

Before any tool call that advances the coordination plan, check whether the user has previously given multi-step direction AND the current prompt contains action-now language. If both trigger conditions hold, invoke /restate-plan before proceeding.

Trigger conditions (both must hold):

• Sequencing direction in prior turn(s): the user has used first, before, after, then, numbered steps, prerequisite, wait until, or multi-clause direction (X, then Y).
• Action-now in current turn: the current prompt contains do it now, proceed, go, start, why not do it now, do it, go ahead.

When both fire, invoke /restate-plan (or walk its 3-step process inline) BEFORE the first tool call that advances the plan. The 3 steps: (1) restate the plan one line per step in user-facing output, (2) identify the next step explicitly, (3) flag any skipped step — STOP and confirm if skipping a user-named prerequisite.

This guards against the action-bias-driven step-compression failure mode (PR #1073 / mt#1783 originating incident; decision-defaults.mdc §Multi-step direction execution corpus rule). See /restate-plan for the full skill text. Skip the check when there's only a single-step direction or when the prior turn had no sequencing keywords — see the skill's "When NOT to invoke" section for exclusions.

0a. Disambiguate-next check (multi-next-step chain-walk junctions)

Before chain-walking on a brief affirmative ("proceed", "continue", "go", "ok"), check whether the task-graph junction has multiple unblocked sibling/child tasks. If so, invoke /disambiguate-next to surface the choice in user-facing output before walking to a specific next task.

Trigger conditions (both must hold):

• Task-graph junction: a task just transitioned to DONE / merged, OR a parent task's child completed, OR the agent is at any point where >1 sibling/child task is in a walkable state (TODO + spec-substantive, READY, or unblocked).
• Brief affirmative: the current user prompt is a short approval token without disambiguating content.

When both fire:

1. Enumerate walkable siblings/children via mcp__minsky__tasks_children <parent> (if parent exists) or from recent conversation context.
2. If count ≥ 2: invoke /disambiguate-next (or walk its 4-step process inline). Surface the options compactly in user-facing output BEFORE the first tool call that walks to a specific task.
3. If count = 1: walk directly (sibling memory 4b83ff51-… governs).

Exception: if the prior agent turn explicitly recommended a specific next task and the user's brief affirmative immediately follows, the recommendation IS the disambiguation — walk to the recommended task without re-surfacing.

This guards against the multi-next-step chain-walk-on-affirmative failure mode (2 recurrences 2026-05-12: mt#1772 scope-creep + mt#1768/mt#1773 wrong-child-pick). See /disambiguate-next for the full skill text, including the stakes-filter sub-check and phase-labeling guidance.

Phase-labeling guidance (preventive — apply when filing subtasks in concern B). When labeling multi-phase parents, use VALUE PROPOSITIONS (skills-setup phase, stack-install phase) not letters (phase A, phase B). Letter-labels are semantically empty and force the agent to re-derive ordering from the task graph at chain-walk time, which is where the originating mt#1768/mt#1773 wrong-child-pick failure happened.

A. Pre-decomposition: sweep for parallel work

Before creating any subtasks or sibling tasks, check whether parallel work already exists. This prevents duplicate effort and coordination collisions.

Per feedback_check_parallel_work_before_decomposing: this sweep is required for ANY tasks_create call for a bug-fix or decomposition, not just sibling-task creation. Three recurrences (mt#1192/mt#1199, mt#1068/mt#1240, mt#1261/mt#1281) established this as a mechanical rule.

Sweep procedure:

1. Call mcp__minsky__tasks_list with status: "IN-PROGRESS" to find active work.
2. Call mcp__minsky__tasks_list with status: "TODO" to find planned work.
3. Call mcp__minsky__tasks_search with keywords from the task title or domain area.
4. Check mcp__minsky__tasks_children if decomposing an existing parent task — subtasks may already be filed.
5. If overlapping tasks are found, surface them to the user before creating anything:

Parallel work detected:
- mt#X (IN-PROGRESS): "<title>" — same domain/files
- mt#Y (TODO): "<title>" — may conflict

Recommend: coordinate with mt#X before filing new subtasks, or subsume the scope if
mt#X's criteria are a strict subset.

A.1 Epic re-entry: audit for decomposition staleness

When opening or referencing an epic that already has children — i.e., the intent is "coordinate / plan / pick the next thing" against a parent task with a non-empty child set — run the epic-decomposition-staleness audit to surface TODO/PLANNING children that may have been substantively delivered by a more recent DONE sibling. This is the Shape C complement to §A's parallel-work sweep (§A catches duplicate filings; §A.1 catches stale decomposition).

Per feedback Epic-decomposition-children go stale when parent ships major delivery (memory id 4bc8ee1f-1eee-4561-a865-73c067e48d2e): when an epic ships a "Sprint-A"-style major delivery, decomposition children filed pre-delivery often become substantively superseded but remain TODO indefinitely. The 2026-05-11 mt#1552 audit found 7 such instances in a single sweep.

Audit procedure:

1. Invoke the audit:
   • Primary: mcp__minsky__epic-decomposition_audit({ epic: "mt#<id>" }) — surfaces (todoChild, deliveringSibling) pairs with scope-overlap signals (file paths, identifiers, keywords). Returns EpicAuditResult with the candidate set grouped by todo-child id.
   • Alternative (if the MCP server has not yet picked up the v0.1 build): run MINSKY_POSTGRES_URL=... bun scripts/calibrate-epic-decomposition-staleness.ts mt#<id>.
2. For each flagged TODO/PLANNING child, read its spec briefly and confirm the failure mode it targets is structurally addressed by the delivering sibling.
3. If superseded: close as CLOSED-superseded via mcp__minsky__tasks_status_set with status: "CLOSED" and a pointer to the delivering task in the closure reason. If not: leave open and note the false positive.
4. The detector emits ≤2 false positives per epic in calibration (mt#1552), so bulk-close is operator-judgment driven, not automated.

When to invoke (heuristic): any time the user names an epic ID with a coordinating verb — "decompose mt#X", "what's next on mt#X", "plan mt#X family," etc. — and the epic has at least one DONE child within the last 30 days. If unsure, run the audit; the cost is one command and a brief read of the candidate list.

Out of scope (v0.1): the detector is within-epic only. Cross-epic supersessions (e.g., a sibling under a different umbrella delivering scope) are not surfaced and remain a manual-judgment concern.

A.2 DAG filing: wave-by-wave with dependsOn, not bulk-create-then-wire

When filing a multi-task graph that carries real dependency edges (e.g., an umbrella + N children where some children depend on others), the default pattern is wave-by-wave filing with dependsOn populated at tasks_create time — NOT bulk-create-then-bulk-wire.

The anti-pattern: tasks_create for every node in parallel batches with NO deps, then tasks_deps_add for every edge in a final batch. The two-phase shape looks faster (more parallelism on the API calls) but has worse atomic-failure semantics: if the deps-add phase fails mid-flight (network glitch, validation rejection, race), the umbrella has N children but partial-or-zero dependency edges. Recovery requires manually inspecting which edges landed and replaying the missing ones — exactly the silent half-shipped state the recovery-layer discipline (CLAUDE.md §Work Completion > Recovery layer spec discipline) prohibits.

The correct pattern leverages tasks_create's existing dependsOn parameter:

Wave 0: file root task alone (no deps).
        → `tasks_create(title="Umbrella mt#1234")`

Wave 1: file tasks whose deps are ALL in Wave 0, with dependsOn populated.
        → `tasks_create(title="Phase 1a", parent="mt#1234", dependsOn=[])` (no deps within the wave)
        → `tasks_create(title="Phase 1b", parent="mt#1234", dependsOn=[])`

Wave 2: file tasks whose deps are ALL in Waves 0-1, with dependsOn populated.
        → `tasks_create(title="Phase 2 — needs 1a + 1b", parent="mt#1234", dependsOn=["mt#1235", "mt#1236"])`

Continue until DAG is complete.

Why wave-by-wave is the default:

• Atomic per wave. Each wave's tasks_create calls succeed or fail atomically per task; the dependency edge is part of the same call. No "task exists but edge doesn't" state.
• Failure recovery is local. If wave 2 fails, waves 0 and 1 are already complete with correct edges. Replay only the failed wave.
• No re-traversal cost. The deps-add phase in the bulk pattern requires looking up the IDs of just-created tasks to wire edges; wave-by-wave already has the IDs in hand from the prior wave.

Trade-off (be honest):

• Bulk-create-then-wire is fewer turns total (more parallelism per phase) but worse failure semantics.
• Wave-by-wave is roughly the same wall-clock at typical DAG sizes (3–10 tasks, 1–3 waves) but cleaner failure semantics.
• For trivial DAGs (single parent + N independent children with no inter-sib deps), the patterns converge — both reduce to one wave of tasks_create calls with no edges to wire. The discipline matters when the graph has inter-sibling dependencies.

When this fires: tasks_create calls for 2+ related tasks where at least one sibling depends on another, OR an umbrella with children that have inter-sibling edges. The signal is "multi-task filing with tasks_deps_add calls planned afterward" — surface the wave structure first, file with dependsOn populated, never queue deps-add as a separate phase.

B. Subtask decomposition before dispatch

For any non-trivial multi-phase task, decompose into subtasks first. Never dispatch subagents directly against a monolithic task with multiple phases.

Per feedback_subagent_decomposition_first: 5/5 non-trivial subagent dispatches on 2026-04-22 hit turn limits mid-implementation. Pre-decomposition via tasks_create --parent was the only reliable fix.

Decomposition procedure:

1. Read the task spec: mcp__minsky__tasks_spec_get with the parent task ID.
2. Identify independent phases or components from the spec's Success Criteria and Scope.
3. For each phase, call mcp__minsky__tasks_create with parent: "<parent-id>":
   • Title: scoped to the phase (e.g., "Implement X for mt#N")
   • Description: the specific success criteria for this phase
   • Status: "TODO"
4. Verify children were created: mcp__minsky__tasks_children with the parent ID.
5. Surface the decomposition to the user before dispatching:

Decomposed mt#N into:
- mt#N.1: "<phase-1-title>"
- mt#N.2: "<phase-2-title>" (depends on mt#N.1)
- mt#N.3: "<phase-3-title>"

Dependency order: mt#N.1 → mt#N.2 → mt#N.3

To implement each subtask, use /implement-task mt#N.1

Sizing guideline: each subtask should be bounded to 8–12 files of change. If a subtask touches more than 12 files, decompose it further before dispatch.

C. Parallel dispatch: file-overlap analysis

Before dispatching parallel subagents, verify they do not share files. Parallel agents writing to the same file produce merge conflicts that block both branches.

Per feedback_parallel_subagent_dispatch_pattern: file-overlap analysis upfront (before any parallel dispatch) is mandatory. Failure to do this produces conflicts that burned a session- and-a-half in documented cases (e.g., PR #763, mt#1216 mid-iteration).

File-overlap analysis procedure:

1. For each candidate parallel task, read its spec and identify the files it will touch. Use mcp__minsky__tasks_spec_get + mcp__minsky__session_grep_search to map out the expected file set.
2. Build a file-set matrix:

Task	Expected files
mt#A	src/domain/foo.ts, tests/…
mt#B	src/adapters/bar.ts, …
mt#C	src/domain/foo.ts, …

3. Check for intersections across rows.

4. Branch on overlap:

   No overlap → dispatch all tasks in parallel. Provide the user with a prompt template for each subagent (use mcp__minsky__session_generate_prompt).

   Overlap detected → do NOT dispatch in parallel. Present the conflict:

File overlap detected:
- mt#A and mt#C both touch src/domain/foo.ts

Safe parallelism: mt#A ∥ mt#B (no shared files)
Must serialize: mt#C after mt#A (shared: src/domain/foo.ts)

Recommended order: dispatch mt#A ∥ mt#B first, then mt#C after mt#A merges.

Evidence gate on dispatch (mt#2488)

tasks_dispatch requires a structured premise, validated at the tool boundary before the subtask + session are created. A dispatch without a well-formed premise is BLOCKED — this generalizes the session_pr_merge forceBypass evidence gate and retires the R7 failure (a fix subagent dispatched on a misdiagnosed cause). Supply all three:

• premiseClaim — the load-bearing assumption this dispatch rests on (for greenfield work, state that as the claim, e.g. "spec fully specifies the acceptance criteria").
• premiseFalsifier — the cheapest check that would disprove the claim if it were false.
• premiseEvidence — the result of actually running that check (the outcome, not a promise to run it).

One-call dispatch: new OR existing tasks (mt#2657)

tasks_dispatch collapses the dispatch pipeline into a single call for BOTH task shapes — this is the default path; prefer it over hand-rolling the manual sequence below for either shape:

• New task (title + instructions): creates the task, optionally wires parentTaskId, starts the session, and generates the prompt.
• Existing task (taskId + instructions, no title/parentTaskId): walks the task's current status to READY (TODO -> PLANNING -> READY, skipping steps already satisfied), starts the session, and generates the prompt — replacing the manual 5-call pipeline (tasks_status_set PLANNING, tasks_status_set READY, session_start, session_generate_prompt, then the Agent call) that pre-filed tasks (e.g. the audit-burndown shape) previously required.

Both modes return { taskId, sessionId, sessionDir, prompt, suggestedModel, agentType } in one response — no more duplicating the ~4-5KB generated prompt across a separate session_generate_prompt result AND the Agent call's prompt param.

Collapsing the calls does NOT bypass any guard — they're composed in-band:

• The TODO -> PLANNING -> READY walk reuses the exact same setTaskStatusFromParams function tasks_status_set calls, so an invalid transition (wrong kind, BLOCKED/CLOSED task, etc.) still fails the call with the same error tasks_status_set would raise.
• The bind/advance spec-read guard (check-task-spec-read.ts) now ALSO matches mcp__minsky__tasks_dispatch when it carries an existing taskId — dispatching a task whose spec was never surfaced in this session's transcript is denied before the call runs, exactly as a manual tasks_status_set/session_start pair would be. Read the spec (tasks_spec_get) before dispatching an existing task; new-task mode is not guarded (there is no pre-existing spec to have skipped reading).
• The dispatch premise gate (premiseClaim/premiseFalsifier/premiseEvidence, mt#2488) applies to both modes unchanged.

When existing-task mode returns a failure instead of a session: the task's current status is outside TODO/PLANNING/READY (e.g. IN-PROGRESS from a prior partial dispatch, or BLOCKED). Resolve the status manually (tasks_status_set) before retrying — one-call dispatch only auto-walks the pre-implementation portion of the status machine.

D. In-flight iteration: branch-divergence check

The pre-dispatch sweep in §A catches sibling work that's already filed/merged at decomposition time. This rule extends that to the review-iteration window — once a PR is open and iterating with minsky-reviewer[bot], sibling tasks may merge to main and create a real conflict that no MCP tool can resolve.

Apply when coordinating any task that is IN-REVIEW with multi-round reviewer iteration. Per feedback_check_branch_behind_main_during_iteration: PR #763 (mt#1190) burned a session-and-a-half because mt#1216 merged mid-iteration touching the same file, and session_update then aborted on the conflict (mt#1303 gap, see Error recovery below).

Procedure: every 2-3 reviewer rounds OR when iteration has spanned >30 minutes:

1. mcp__minsky__git_log with ref: "task/mt-X" and limit: 5 — record the branch HEAD.
2. mcp__minsky__git_log with ref: "origin/main" and limit: 5 — note recent main commits.
3. If main has advanced and the branch's base ancestor hasn't moved, run mcp__minsky__session_update early — before more iteration commits stack up — so any conflicts surface while you still have buffer.
4. If session_update aborts on conflict, that's the mt#1303 gap. Do not loop with different flags (skipConflictCheck, force, noStash all abort identically). See "Error recovery → session_update aborts on conflict without markers" below.

Pattern recognition for high-risk siblings: tasks named [same area] polish / QoL bundle / calibration are the most likely to touch overlapping files mid-iteration. When dispatching alongside such a sibling, expect to apply this check more often.

Error recovery

Operational realities that bit prior multi-task workflows hard. Each entry names the symptom, the root cause, and the recovery path. These supplement the per-skill error handling — they are surfaced at the orchestration layer because the recovery often spans skill boundaries (e.g., bypass-merge after the reviewer bot cannot APPROVE).

Scope qualifier: the recovery actions in the table below operate on a single session/branch. This skill documents the plan (what to do, in what order, with what cost). The actual call site is the appropriate phase skill — /implement-task for branch-mutating recovery during the IN-PROGRESS window, /verify-task for merge-flow recovery during the IN-REVIEW window. Do not invoke session mutations directly from this skill's flow.

Remote naming: the procedures assume the upstream remote is origin and the trunk branch is main — Minsky sessions are created with this convention. If a session is configured against a different remote name (e.g., upstream), substitute accordingly.

Symptom	Root cause	Recovery path
session_update reports "Content conflicts detected" but working tree is clean (no <<<<<<< markers)	mt#1303 tooling gap: the tool aborts the merge cleanly on conflict and reverts the merge state. There is currently no MCP path to leave conflict markers for manual resolution. Direct git merge is hook-blocked. Looping with skipConflictCheck / force / noStash all abort identically.	When content compatibility is achievable but git's 3-way merge sees overlapping edits: (1) mcp__minsky__session_exec git reset --hard origin/main (carve-out is allowed); (2) use mcp__minsky__session_write_file to rewrite the conflicting file(s) with the desired final content; (3) mcp__minsky__session_commit; (4) mcp__minsky__git_push with force: true. Cost: this loses the multi-commit history of the branch — the PR effectively becomes a single squashed commit. Acceptable for feature PRs; loses signal for debugging-trail PRs. Escalate to the user if blocking — they can run git merge outside hook scope.
minsky-reviewer[bot] silent for >5 min after a follow-up push that addressed BLOCKING findings	mt#1110-class webhook-miss-on-subsequent-push reliability gap. Distinct from CI not firing (which is a separate webhook/CI-trigger problem). Same-App-identity APPROVE block does NOT apply here — that's a structural gate; this is a reliability gate.	(1) Confirm push reached GitHub: mcp__minsky__session_pr_get, check head.sha. (2) Try an empty commit to wake the webhook: mcp__minsky__session_commit with noFiles: true and noStage: true, then push. (3) If still silent, escalate via gh api PUT /repos/.../pulls/N/merge (merge_method=merge, never squash) — only after BLOCKING findings are addressed and remaining gap is the missing reviewer signal. (4) After bypass merge, manually clean up the session: mcp__minsky__session_delete. (5) Track the instance in the agent-memory file at ~/.claude/projects/-Users-edobry-Projects-minsky/memory/project_mt1110_calibration_data.md (create if absent — see other project_* and feedback_* files in the same directory for the format). See /merge-coordination step 7a and feedback_gh_api_bypass (same directory).

Dispatch watchdog and resume protocol (mt#2646)

During the mt#2607 burndown (~14 implementer dispatches, 2026-07-06/07), 5 dispatches ended without a usable completion report: two stalled silently mid-review-convergence for 6.5h, one died with uncommitted work and no handoff, one died on a 529 API error mid-convergence, two stopped cleanly but pre-convergence. Every case required manually noticing the silence, probing session state by hand, and improvising recovery. This section mechanizes that probe-and-recover sequence.

Heartbeat reminder while coordinating (mt#2824). This watchdog covers a DISPATCHED SUBAGENT's silence (>=30 min, no activity). The ORCHESTRATING agent's OWN silence during a coordination stretch — repeated probe calls, dependency checks, dispatch calls across several tasks with no interstitial prose — is a separate concern: emit a one-line heartbeat at least every 10 minutes or 15 tool calls, per user-preferences.mdc §Progress heartbeats during tool-only stretches. When the coordination stretch ends, the turn-end report follows the Tier-1 contract in communication-contract.mdc (what happened / what you need to know / what's next) rather than a per-task narrative recap.

Detection: the dispatch watchdog

A cockpit cadence sweep (startDispatchWatchdogSweeper, src/cockpit/dispatch-watchdog.ts) checks every 5 minutes for subagent_invocations rows that are still in flight (dispatched, not yet Stop-classified) whose task is IN-PROGRESS or IN-REVIEW, and flags any with no activity (no commit on the session branch, no related system_events row — e.g. a PR event, no fresher dispatch signal) for 30 minutes (DISPATCH_WATCHDOG_STALE_MS, tunable). The flagged set is written to a local cache and injected into every turn via the inject-dispatch-watchdog.ts UserPromptSubmit hook — you do not need to poll for this; a stalled dispatch surfaces as additionalContext automatically. Treat a "DISPATCH WATCHDOG" warning as the trigger to run the probe below before assuming the dispatch is dead.

Auto-recovery: call tasks.dispatch-recover, then act on its status (mt#2831)

Do NOT hand-roll a probe-then-decide sequence for a flagged (or suspected-stalled) dispatch. Call mcp__minsky__tasks_dispatch-recover with the flagged taskId. Server-side, this command cannot spawn a harness subagent itself (the Agent tool only exists in YOUR — the orchestrating agent's — context), so it never dispatches anything. Instead it does the detect/classify/prepare work and hands you back what to do:

• Captures session state — git-diff presence (dirty-file count, commits-ahead-of-base) and .minsky/sessions/<id>/handoff.md presence — via the same probe shape mt#2646's session.status probe:true uses.
• Classifies the outcome per the subagent-outcome taxonomy: committed-no-pr, partial-committed-handoff-written, partial-uncommitted-no-handoff, or crashed-no-output.
• Enforces the 2-attempt bound SERVER-SIDE by reading the latest invocation's attemptNumber — a 3rd recover call for the SAME dispatch chain refuses and returns an escalation package instead of a prompt. The bound does not depend on you remembering to stop retrying.
• Records the attempt in subagent_invocations with retry linkage (resumedFromInvocationId / attemptNumber).

Branch on the returned status:

1. "healthy" — recent activity below the stale window; a false-positive flag. Do nothing. This is the acceptance-test case for "don't kill a healthy long-running dispatch."
2. "recover" — redispatch the returned continuationPrompt VERBATIM via the Agent tool into the SAME session (the result's sessionId/sessionDir) — do not edit the prompt, do not start a new session. The prompt already carries classification-specific guidance (commit uncommitted work first, drive an existing PR to convergence, re-implement from scratch, etc.) — you do not need to re-derive the recovery strategy yourself.
3. "escalate" — the 2-attempt bound is reached. Do NOT call tasks.dispatch-recover a third time for this chain; surface the returned escalation summary (both attempts' state) to the operator and stop.
4. "not-in-flight" / "no-dispatch" — nothing to recover (the dispatch already has a terminal outcome, or never existed).

This replaces the prior ad hoc probe-then-decide sequence (a separate session.status probe:true read, then a manual SendMessage-vs-fresh-dispatch judgment call) — the classification and the continuation prompt are now computed server-side, not re-derived per incident.

Scope note (Covers / Does NOT cover, per the mt#2831 spec). Covers API drops and watchdog stalls. Does NOT cover semantically-wrong-but-alive work (a subagent actively committing but going in the wrong direction — that's the reviewer's job, minsky-reviewer[bot]) or rate-limit storms (repeated rate-limited outcomes are SubagentDispatchTracker.getEscalation()'s "daily" tier's job — check it before treating a stale-but-silent dispatch as dead; per memory 5f2154cd, "long-paused subagent != dead subagent").

Dependency graph navigation

When the user asks "what's the order for mt#A, mt#B, mt#C" or similar, use mcp__minsky__tasks_deps_tree to read the dependency graph and surface a concrete execution order.

Navigation procedure:

1. Call mcp__minsky__tasks_deps_tree for each task in the set.
2. Build a topological sort from the dependency edges.
3. Surface the ordering as a numbered list with rationale:

Execution order for mt#A, mt#B, mt#C:

1. mt#B — no dependencies, unblocked
2. mt#A — depends on mt#B (must wait for mt#B to merge)
3. mt#C — depends on mt#A and mt#B (must be last)

Independent tasks that can run in parallel: none (linear dependency chain)

If no dependencies exist between tasks, confirm they are all unblocked and parallel dispatch is safe (subject to file-overlap check in §C above).

Dispatch handoff

After decomposition and/or ordering, hand off to the appropriate phase skills:

• For each subtask that is TODO and needs planning:

  "Run /plan-task mt#N.1 to investigate and bring it to READY."

• For each subtask that is READY and needs implementation:

  "Run /implement-task mt#N.1 to start development."

• For each task that is IN-REVIEW:

  "Run /verify-task mt#N.1 to verify and close out."

Do NOT call session_start, session_pr_create, or any single-task lifecycle primitive directly. This skill's responsibility ends at surfacing the coordination plan and handing off to the appropriate phase skill.

Post-merge deploy verification across an epic

When an epic's subtasks land code that runs in a deployed service, the agent driving the epic should verify each merge's deploy succeeded — Railway redeploys are not "the build checks passed, we're done." A Dockerfile breakage, missing env var, or container-start crash shows up post-merge and won't be caught by pre-merge CI. Use the platform-neutral MCP tools that wrap the deployment platform (Railway is the v1 concrete adapter; v2 candidates: Vercel, Cloudflare Pages, Fly.io, etc.).

After any subtask merge that touches deployed code, call mcp__minsky__deployment_wait-for-latest to block on the auto-deploy and surface the terminal status. On FAILED / CRASHED, call mcp__minsky__deployment_logs for the failed deployment ID and surface the build/runtime failure to the user. See docs/deployment-platforms.md for the abstraction and /implement-task step 10 for the single-task variant.

Key constraints

• Never call session_start directly. Session creation belongs to /implement-task.
• Never call session_pr_create directly. PR creation belongs to /implement-task.
• Never set task status directly. Status transitions belong to the phase skills.
• Always sweep for parallel work before decomposing. This is a mechanical pre-check, not optional.
• Always analyze file overlap before parallel dispatch. Two agents on the same file produce conflicts.
• Decompose before dispatch. Monolithic tasks dispatched to subagents hit turn limits.
• File DAGs wave-by-wave with dependsOn populated, never bulk-create-then-bulk-wire. Two-phase filing leaves orphan-edge state on mid-flight failure; tasks_create's dependsOn parameter is the right primitive. See §A.2.