dispatch

What this skill does

# Dispatch: Focused Work-Unit Execution

Execute work units that have already been focused by `/triage` or supplied as explicit initial prompts. Dispatch is an orchestration skill for execution topology, branch/PR fanout, verification, review loading, rejection-trace inscription, and terminal improvement-capture follow-up. It is not the owner of open-issue discovery or similarity grouping.

**This is an execution skill, not an intake skill.** `/triage` forms `FocusedWorkUnit`s from `RawIssueSet`s by grouping related issues, fusing them with the `AGENTS.md` northstar in the current Codex session, and emitting dispatchable initial prompts. `/dispatch` consumes those prompts or work units and executes the selected route: independent handoff is outside dispatch, while linear and parallel dispatch are inside dispatch.

## Pipeline Overview

```
                                                      ┌→ INSCRIBE  (Phase 6 — rejected branch) ┐
DETECT → BOUND → LOAD WORK UNITS → PREMISE → FANOUT → FEEDBACK                                  → CAPTURE → SUMMARY
 (silent) (gated)     (no intake)     (per-unit) (route topology)                              (Phase 8)  (return)
                                                      └→ COMPLY    (Phase 7 — compliant branch) ┘
```

Phase 1 (BOUND) composes `/bound` for execution topology. Phase 2 loads the focused work units already present in session text. Phase 3 verifies each unit's premise before branch creation. Phase 4 executes the selected topology: linear sequence or parallel fanout. Phase 5 routes per PR; rejected and compliant branches are independent siblings dispatched from feedback classification. Phase 8 runs only after active fanout, rejection inscription, compliance fixes, and dynamic-stop handling have been surfaced.

## Personalization sources

Read at activation (semantic, not hardcoded paths):

| Source | Purpose |
|---|---|
| Project profile rule | Extension-default vs Constitution-default; closure clauses for delegation contract |
| Project guide (AGENTS.md, CLAUDE.md, or equivalent) | Project northstar (mission/direction statement); used to verify the work unit's fusion trace |
| Project editing conventions | Branch naming pattern, commit message language, PR body language |
| Harness rules (system prompt) | Branch restrictions, designated working branch, push policy |

Project-specific values are **read** from the above; the skill itself does not hardcode them. This separation is the personalization boundary — the workflow generalizes; the values do not.

## Phase 0: Detect (silent)

Activation cues:

- `/dispatch <initial prompt>` slash command (Layer 1)
- `/dispatch` after `/triage` has emitted one or more `FocusedWorkUnit`s or `InitialPrompt`s in the current session
- User route choice from `/triage`: "run these linearly", "dispatch these in parallel", "execute work unit A"

Pre-activation check:

- At least one focused work unit or initial prompt is present
- Route topology is explicit or can be resolved by Phase 1
- No in-flight blocking work on the base branch would conflict with branch fanout

If the user asks to process open issues or a backlog without a focused work unit, route to `/triage` first. If the worktree is blocked, surface the conflict and invite the user to commit, stash, or narrow the dispatch scope before re-entry.

## Phase 1: Bound (compose /bound)

Compose `/bound` for the delegation contract. Domains to bound (minimum set):

- **Work-unit selection**: User-supplies / AI-proposes from current-session triage output / AI-autonomous within a user-confirmed work-unit set
- **Execution topology**: single unit / linear sequence / parallel fanout
- **PR strategy**: per-work-unit PR / grouped PR / single PR
- **Branch strategy**: single base / per-work-unit sub-branch
- **Effort cap**: max issues / max time / dynamic-stop
- **Conflict handling**: skip-with-surface / attempt-with-care
- **Stage gating compliance**: substrate-cited locks (Out-of-scope clauses, "depends on #X" close-conditions, evidence-accumulation gates)
- **Post-cycle improvement filing**: create GitHub follow-up issues / draft-only summary / skip unless user confirms

If the project's profile declares an Extension-default with a closure clause covering ambiguity (e.g., "AI-autonomous bounded by [northstar + hermeneutic circle]"), Phase 1 may relay-resolve via cited profile. Otherwise, run Horismos cycles for explicit contract.

**Output**: BoundaryMap with at least the domains above resolved.

## Phase 2: Load Focused Work Units

Read the selected `InitialPrompt`s or `FocusedWorkUnit`s from current session context. For each unit, capture:

- work-unit name
- included issue numbers
- normalized problem frame
- northstar fusion trace
- explicit out-of-scope claims
- verification expectations
- suggested route and rationale

Do not enumerate open issues here. If the selected input only names a GitHub scope without a work-unit frame, stop and route to `/triage`.

Check each work unit for substrate-cited locks inherited from triage:

- explicit "Out of scope" sections
- "depends on #N" close-condition references
- evidence-accumulation gates
- stale/superseded notes
- needs-info or blocked readiness

These are not skipped silently. They are surfaced in Phase 3 before execution.

## Phase 3: Premise Verification

For each selected work unit, run a substrate trace before any branch / Edit / Write commences:

- **Existence check**: Read/Grep the cited code locations or runtime surfaces to confirm the surfaced symptom or target still exists in current state.
- **Fusion check**: Confirm the work unit still fits the `AGENTS.md` northstar trace supplied by `/triage`; if the northstar has changed, stop and request re-triage.
- **Approach axis check**: when the initial prompt enumerates 2+ approach options, evaluate each option's substrate basis and select via:
  - **Relay** if a single option dominates by substrate evidence — present the selection with cited basis.
  - **Constitution gate** if 2+ options remain plausible under different value weightings.

**Output**: `PremiseTrace` per work unit: existence status, fusion status, axis selection, substrate citations.

Work units that fail premise verification do not progress to fanout. Reclassify them as stale, blocked, needs-info, or re-triage-needed with cited reason.

## Phase 4: Fanout

Execute according to the bounded topology:

- **Single unit**: create one branch and one PR unless the boundary contract says otherwise.
- **Linear sequence**: execute work units one at a time, returning to base after each PR.
- **Parallel fanout**: create independent per-work-unit branches only when write scopes are disjoint and the active runtime/tool policy authorizes parallel agent work.

Carry the work-unit rationale trace forward through the cycle. Dispatch preserves the InitialPrompt's problem frame, northstar fusion summary, and selected route rationale, then adds the premise/fusion verification result from Phase 3 and any continuation links from Phase 6 or Phase 8.

For each executable work unit:

1. **Branch**: create sub-branch from base — `<base>-<work-unit-slug>` or `<base>/<work-unit-slug>` per the project editing-convention pattern
2. **Execute**: inline work for the work unit (Edit, Write, Bash for verify-supporting commands)
3. **Verify**: run the project's static check (typically a `node` invocation against `static-checks.js`) — ensure fail count is not increased, no new warns
4. **Commit**: conventional message per the project editing convention; cite linked issue numbers when the work unit fully resolves them. **Framing assertions in the commit message must cite the substrate basis recorded in PremiseTrace**.
5. **Push**: `git push -u origin <sub-branch>`
6. **PR**: create with title + body per project conventions; include work-unit name, included issues, northstar fusion summary, verify summary, and `PremiseTrace`.

After each PR submission in a linear route, return