--- description: Run a batch of tasks through their pipelines in dependency-correct order — resolve a set, topo-sort, run each via task-pipeline.yaml, emit a batch report role: planner argument-hint: "--tasks [--feature ] [--mode ] [--keep-going] [--auto] [--agent ] [--json] [--wrap] [--next] [--continue] [--worktree []] [--no-summary]" allowed-tools: ["Bash", "Read", "Skill"] --- # Dev Runall Wraps the **sp:spur-dev** skill. ## Argument Flags | Flag | Description | Default | | --- | --- | --- | | `--tasks` `` | Task selector to run. | required | | `--feature` `` | Restrict to a feature. | omitted | | `--mode` `` | Batch execution order. | sequential | | `--keep-going` | Continue past per-task failures. | off | | `--auto` | Skip objective HITL gates. | off | | `--agent` `` | Who runs each task's pipeline stages. Interactive sequential omit/`inline` uses the host-session driver with unified inline semantics (task 0687 — see below)). `auto`, a name, parallel mode, and headless invocation use subprocesses. The opt-in `fleet` selector (0942) maps each task run to `executor: 'fleet'` so `agent.run` stages dispatch through the fleet control plane (ADR-126) instead of a subprocess. | omit | | `--json` | Emit structured JSON. | off | | `--wrap` | Run the wrap hop **once for the batch** over the `done` subset only (Step 6 of execution-batch.md): `vars.feature` is passed only when every frozen task is `done`/`cancelled`; an empty done subset skips the wrap with a reason. The `--agent` selector is preserved into the `/sp:dev-wrap` handoff when supplied; omission remains omission. | off | | `--next` | Chain-to-completion via the next-router. | off | | `--continue` | Resume an interrupted batch. | off | | `--worktree` `[]` | Run the batch in an isolated git worktree; FF-merge on success, retain on failure. Bare `--worktree` creates a fresh tree; `--worktree ` adopts an existing worktree by name/path/branch. | off | | `--no-summary` | Skip the measured execution summary (one row per task run: time, wait, tool calls, total / non-cached tokens) printed after the batch report. | off (summary printed) | | `--concurrency` `` | Parallel-mode worker bound: at most `` task pipelines run at once (task 0931); a dependent starts only after its in-set dependencies are integrated onto the base ref. No-op in sequential mode (ignored). | 2 | For shared semantics, see the [flag glossary](../skills/spur-dev/references/flag-glossary.md). ## Usage ``` /sp:dev-runall --tasks [--feature ] [--mode ] [--keep-going] [--auto] [--agent ] [--json] [--wrap] [--next] [--continue] [--worktree []] [--no-summary] ``` Flags: `--tasks ` (required — explicit WBS list, status pseudo-list, `feature:`, or `ready`), `--feature ` (sugar for `feature:`; when the effective selector is feature-derived, `dev-runall` runs `spur feature check --strict --json` **once** before resolving tasks — a non-zero strict check aborts the batch with verdict `aborted` and the structured findings, before any task pipeline action, task 0510 R2; scoped: `L4.scenario-unverified` (the expected pre-run state of any not-yet-run feature) is reported verbatim but does not abort — any other strict error aborts), `--mode` `` (default `sequential`; `parallel` fans out a proven-independent subset — see `execution-batch.md` § Parallel isolation), `--concurrency ` (parallel-mode worker bound — at most task pipelines at once, default 2; a dependent task starts only after its in-set dependencies are **integrated** onto the base ref), `--keep-going` (batch failure policy — skip a failed task's in-batch dependents, continue independents; default halts on first failure), `--auto` (sets `profile=auto` on each per-task run, skipping the HITL approve gate), `--agent ` (names who runs the pipeline's stages — interactive sequential omit/`inline` uses the host driver; `auto` or a name is merged into each per-task `vars.agent` and `vars.implementAgent`; `fleet` maps each task run to `executor: 'fleet'` instead (fleet dispatch, 0942); parallel mode retains isolated subprocesses, ADR-047), `--json` (emit the report as JSON), `--wrap` (trigger `wrapup-pipeline.yaml` after the batch completes), `--next` (chain each task to terminal status, then run the wrap hop **once for the batch** — see below), `--worktree` `[]` (run the batch in an isolated git worktree — FF-merge onto the base ref on full success, retain intact on any failure/halt/non-FF; bare form creates a fresh tree, `` form adopts an existing worktree by name/path/branch; see `execution-batch.md` § Worktree isolation). **`--worktree` and parallel mode.** `--worktree --mode parallel` is **rejected** — parallel mode already isolates each task in its own worktree (see `execution-batch.md` § Parallel isolation), and reuse mode (`--worktree `) has no per-task meaning. Run parallel batches without `--worktree`, or run them sequentially with it. **`--worktree` corpus visibility.** While the batch runs in a worktree, corpus writes (task statuses, kanban) land in the worktree copy; your main tree still shows pre-run statuses until the FF-merge on success. This is expected, not a bug. **`--next` (batch-once wrap).** `--next` is chain-to-completion with propagation. On `dev-runall`, each task in the batch runs its `task-pipeline.yaml` to terminal status (the pipeline already drives precheck → implement → test → review → approve → verify → record → done); when the batch is complete, the wrap hop runs **once for the batch** — mirroring the batch-once shippable gate `dev-verifyall` uses — rather than once per task. Without `--next`, `--wrap` is wrap-without-chaining (the single batch wraps without advancing the feature lifecycle). **was: `--next` deliberately omitted; the old no-`--next` rationale argued against the old per-task-transition meaning and does not carry.** **Three orthogonal axes** (do not confuse): `--keep-going` = batch failure policy (does a failure halt the batch or skip dependents?); `--continue` = resume from checkpoint against the batch's original frozen identity — persisted plan membership, worktree marker, identity-filtered checkpoints as hints (execution-batch.md § Batch continuation, task 0919); `--next` = chain each task to terminal status + batch-once wrap. See `dev-operations.md` § runall for the full distinction. ## Implementation - Apply the [inline-default execution-surface contract](../skills/spur-dev/references/cross-cutting.md#inline-default-execution-surface). Interactive sequential omit/`inline` keeps the orchestrator in the host session through the [inline pipeline driver](../skills/spur-dev/references/inline-pipeline-driver.md); the resolved selector applies uniformly — eligible `agent.run` stages dispatch once to a native subagent with host fallback (0508). `--agent auto`, a name, or parallel mode retains the isolated per-task workflow boundary. - Apply the [shared startup contract](../skills/spur-dev/references/cross-cutting.md#shared-startup-contract-task-0814-r1r3r4r6r7r8) — bootstrap checklist, quick readiness before isolation, workflow inventory before YAML, comprehensive checks at owning boundaries (task 0814 R1/R3/R4/R7/R8). - Interactive sequential omit/inline: `Skill(skill="sp:spur-dev", args="runall-inline $ARGUMENTS")`. - Explicit executor or parallel mode: `Skill(skill="sp:spur-dev", args="runall $ARGUMENTS")` → `sp:super-planner` agent. - After the batch report, print the [execution summary](../skills/spur-dev/references/dev-operations.md#execution-summary) over every attempted run unless `--no-summary`.