blacksmith-orchestrate

Blacksmith Orchestrate

Decide which tasks run, in what order, at what depth, by which model, in which worktree — then dispatch one forge run per task.

Overview

This is a wrapper around forge, not a fork of it. It never reimplements a forge step: every task it dispatches runs the ordinary twelve-step forge workflow, and everything this skill adds is a decision about those runs — which ones may run at the same time, how deep each one goes, and where each one's work lives.

Nine numbered steps, split by one gate, deliberately mirroring forge's shape:

Part 1 — Plan (1–5):     normalize → materialize → analyze → schedule → [GATE] battle plan
Part 2 — Execute (6–9):  provision → dispatch waves → relay → close-out

  gate held: no worktree is created and no forge Part 2 runs until "yes, forge them"

Step	Action
1	Parse the invocation; split orchestrator flags from pass-through forge flags; route the work source into a canonical task list
2	Materialize refs — spec-file and free-form routes get real issue refs via /to-tickets, or synthetic T1..Tn IDs if the user declines filing
3	Analyze — route each task to the plan-sourced path or the scout fan-out
4	Build the collision graph, triage matrix and worktree grouping → scheduling waves
5	[GATE] one battle plan, one approval
6	Provision worktrees; write the run ledger
7	Dispatch waves — one agent per task at its assigned model tier and forge depth
8	Relay — prove a blocker's changes are on the dependent's base, rebase, release
9	Close-out — aggregate report, PR list, worktree cleanup reminders, self-evolution

Forge's hard floors are inherited unchanged, and orchestrating many runs never relaxes them: every run's Step 12 /goal verification still has to pass before that run assembles a commit, and no dispatched run ever writes back to the source issue or ticket it was dispatched for — that stays with the user under every flag combination, afk included. That is narrower than "never writes to a tracker": Step 2 files new issues via /to-tickets for the plan and free-form routes, including under automode, exactly as forge's own Step 10 sanctions filing spin-off issues it did not author — see references/entry-routes.md. Whether a dispatched run may also commit and open a PR for its own task is a separate question, resolved three ways: by default, the Step 5 "yes, forge them" approval is the Step 12 commit-and-PR selection forge requires, granted once for every task the approved plan named (see Step 7); under automode without afk, nobody made that selection, so every dispatched run stops at its own Step 12 plan-only output, exactly as a standalone automode forge run does, and nothing is pushed; afk is the single sanctioned exception, authorizing unattended commit-and-PR as well as the blocking-PR merge it already governs — it is labelled that way everywhere it appears, so the exception stays auditable instead of becoming a quiet contradiction. Terminal PRs and worktree cleanup stay with the user under every flag combination, afk included.