forge-orchestratelisted

# /forge orchestrate > **Status queries always hit the tracker. `plans/phases.yaml` is a stale cache.** See your project `CLAUDE.md` §Source of truth. The user-facing dispatch loop for forge's orchestrator. Drives one **round** per invocation: 1. List ready tasks (read-only) → 2. user approves → 3. claim + dispatch the selected tasks → 4. spawn worker subagents via the host's Task tool → 5. poll open questions for that run → 6. surface each to the user → 7. record answers → 8. ask user whether to continue with another round. No daemon. No automatic dispatch. The skill exits after each round; the user re-invokes `/forge orchestrate` to start the next round. Drift-routed questions, `drift_event_id`, and `routing_hint` are **dropped in v0.4** per `docs/plans/team-mode-minimum-architecture.md` §3. Workers emit plain questions only; the skill consumes them via `questions --open --json`. ## Preconditions - `.forge/settings.yaml` exists with a `tracker:` block - `plans/phases.yaml` exists and validates (run `/reconcile --pull` first if not) - `templates/worker-prompt.template.md` exists (shipped with the framework) ## Step 0 — Start a run A "run" is a single supervisor session. Every subsequent verb call needs the run_id so questions and dispatch records stay scoped to this session. ```bash forge orchestrate run start --json ``` Parse `data.run_id` and keep it in your skill context for the rest of the invocation. If you need a friendly name, pass `--name "<short label>"`.