spec-dispatch

Spec Dispatch

openspec queue -> wave plan -> agents -> verify -> tick -> commit.

openspec-apply-change walks tasks one at a time in one context. This replaces that loop only. Planning artifacts (proposal / specs / design / tasks) stay sequential and stay with you — never fan those out; they need whole-repo context and each depends on the last.

Everything here is substrate-independent. Inside Herdr (HERDR_ENV=1) subagents are panes per the Herdr instruction, and the mechanics — budget, split, start, brief, collect, blocked, cleanup — belong to herdr-dispatch. Outside it, dispatch the same waves with the Agent tool. Either way this skill owns only what is OpenSpec-specific.

Preconditions

test "${HERDR_ENV:-}" = 1        # decides the substrate only, never whether to proceed
openspec status --change "<name>" --json

Read applyRequires and isPlanningComplete. Tasks artifact missing -> send the user to /opsx:propose or /opsx:continue. Never author planning artifacts here.

Store-based work -> pass --store <id> on every openspec command and keep it sticky.

Read the Queue

openspec instructions apply --change "<name>" --json

Returns progress {total, complete, remaining} and tasks[] of {id, description, done}.

The list is flat. No dependency edges, no file ownership — the ## 1. Backend / ## 2. Frontend grouping in tasks.md is flattened away. This JSON alone cannot tell you what is safe to run concurrently, and two agents on one file silently clobber each other.

Make It Parallel-Safe at Authoring Time

Do not infer disjointness at dispatch. Force it when tasks are written, in the change root's openspec/config.yaml:

rules:
  tasks:
    - "Every task MUST declare `files:` listing the paths it will touch."
    - "Every task MUST declare `needs:` listing task ids it depends on (empty if none)."

These surface under rules in openspec instructions tasks --json, so the agent writing the tasks artifact is bound by them.