Skill v1.0.1

version: "1.0.1" name: dispatch description: Route a request to the right interlock skill, after one batched pre-flight that loads git state, OpenSpec status, open tasks and graph presence in a single pass. Use when you are not sure which skill applies, or at the start of a session to orient before doing anything else. license: MIT compatibility: Optional openspec CLI and git. Node.js >= 18 for the bundled interlock CLI. allowed-tools: Bash(git ) Bash(openspec ) Bash(interlock ) Bash(interlock-graph ) Read Glob metadata: type: routing

Figure out where the user actually is in the flow, then route. One cheap pre-flight beats an exploratory warm-up.

Step 0 — Pre-flight, batched

Run these in one turn, joined with ; not && — you want every answer regardless of which ones fail:

git branch --show-current; git status --short; git log --oneline -5
openspec --version
openspec list --json 2>/dev/null
interlock changes 2>/dev/null
ls -t .claude/handoff/explore-*.md 2>/dev/null | head -3
ls .claude/graph/GRAPH_REPORT.md .claude/graph/DOCS_DIGEST.md 2>/dev/null

That is Rules 2 and 3 of ${CLAUDE_PLUGIN_ROOT}/shared/TOOL-ECONOMY.md: read state, do not re-derive it. Do not traverse the tree to reconstruct what these already tell you.

The flow

graph → docs-digest → bootstrap        (once per repo)
/interlock:spec    explore → artifacts → review     ⟵ STOPS. Human reviews.
/interlock:ship    waves → verify → commit  (workflow, zero-touch; --strict adds review)
/interlock:mr      summary → merge request

The gap between spec and ship is deliberate. Never bridge it automatically — if a spec is ready, say so and let the user start ship. The user can bridge it themselves with /interlock:spec --continue, but that is theirs to ask for; routing never offers it.

ship is a dynamic workflow. /interlock:ship is a skill trampoline that launches it via the Workflow tool (scriptPath → workflows/ship.js). Invoke the skill interlock:ship (or call Workflow with that scriptPath yourself). Do not treat a missing Workflow-namespaced command as "ship does not exist" — the skill is the entry point. If the trampoline halts because the Workflow tool is unavailable, that is the runtime gap (v2.1.154+, Dynamic workflows on in /config); do not implement the loop inline.

Routing table

Prerequisite checks before routing:

• openspec --version printed no version — say so before routing. On command not found (or the shell's equivalent) the CLI is missing: give the install command npm install -g @fission-ai/openspec@latest. On any other error it is installed but does not run (usually a Node.js older than 20.19.0): quote the error, not the install line. Either way an empty openspec list here is the CLI, not an empty project, and spec and bootstrap both stop at their first command until it runs. ship still reads artifacts from disk.
• Routing to ship — run interlock validate <change> first. Not ready means route to spec, not ship. If a ship workflow already returned in this conversation, leftover boxes are a report, not a retry.
• Routing to spec with no explore brief and a question that spans subsystems — run explore first.
• Routing to anything that reads the graph when .claude/graph/ is absent — offer to build it once.

Ambiguity

When two routes fit, prefer the earlier phase. Exploring when you should have specced costs one turn; shipping when you should have specced costs a bad change and a review cycle.

When the request genuinely does not fit any skill, say so and handle it directly. Not everything is a workflow, and forcing an ordinary question through a skill is worse than just answering it.