|
| 1 | +--- |
| 2 | +name: dispatch-start |
| 3 | +description: Start async-dispatch as the entrypoint for broad Codex root-chat work. Use when a user asks to run async, spawn chats, coordinate multi-repo or multi-slice work, start a Dispatch-managed goal, resume an existing Dispatch board or runtime, or decide whether a raw request should enter planning before implementation. |
| 4 | +--- |
| 5 | + |
| 6 | +# Dispatch Start |
| 7 | + |
| 8 | +## Overview |
| 9 | + |
| 10 | +Use this as the first Dispatch skill for a raw user goal. It decides whether the |
| 11 | +root can work directly, must resume existing Dispatch state, or must enter the |
| 12 | +goal -> draft -> board -> runtime planning path before any worker or child-chat |
| 13 | +launch. |
| 14 | + |
| 15 | +The important default is: no approved board means start the board phase, not |
| 16 | +root-only implementation. |
| 17 | + |
| 18 | +## Start Decision |
| 19 | + |
| 20 | +First inspect local state and the request: |
| 21 | + |
| 22 | +```bash |
| 23 | +async-dispatch snapshot |
| 24 | +``` |
| 25 | + |
| 26 | +Then choose one mode: |
| 27 | + |
| 28 | +- `resume-runtime`: a matching active runtime ledger already exists. Continue |
| 29 | + with `dispatch-root-runtime`. |
| 30 | +- `resume-board`: a matching board exists but is not approved or started. |
| 31 | + Present the board/draft for review before `board approve` or `runtime start`. |
| 32 | +- `planning-required`: the request is broad, async, multi-repo, multi-slice, or |
| 33 | + asks to spawn chats, but no approved board exists. |
| 34 | +- `root-only`: the request is small enough for the root chat, or the user |
| 35 | + explicitly asked for root-only execution. |
| 36 | + |
| 37 | +For `planning-required`, do not edit repos, create worker chats, or commit code. |
| 38 | +Start the Dispatch planning phase. |
| 39 | + |
| 40 | +## Missing State Recovery |
| 41 | + |
| 42 | +When Dispatch state is missing, report the recovery path instead of stopping at |
| 43 | +"no plan found." |
| 44 | + |
| 45 | +- No matching plan exists: keep using `dispatch-start`; create/refine the goal, |
| 46 | + draft a plan, and give the human the draft path plus approval choices. |
| 47 | +- Plan exists but no board exists: keep using `dispatch-start`; ask the human to |
| 48 | + approve or correct the draft, then run `plan ready` and `plan compile`. |
| 49 | +- Board exists but no runtime exists: keep using `dispatch-start`; ask the human |
| 50 | + to approve or correct the board, then run `board approve` and `runtime start`. |
| 51 | +- Runtime exists: hand off to `dispatch-root-runtime` for nodes, workers, |
| 52 | + receipts, idle/wake, and closeout. |
| 53 | +- Code work is ready inside an active runtime: use `dispatch-code-routing` |
| 54 | + before root edits or worker launches. |
| 55 | + |
| 56 | +For a missing plan, the human action must be concrete: |
| 57 | + |
| 58 | +```text |
| 59 | +Reply "approve draft" to compile the board, or reply with corrections such as |
| 60 | +"split core graph and runtime into separate phases" or "keep this root-only." |
| 61 | +``` |
| 62 | + |
| 63 | +## Planning Phase |
| 64 | + |
| 65 | +Create a durable goal and gather enough context to draft a real plan: |
| 66 | + |
| 67 | +```bash |
| 68 | +async-dispatch goal init --seed "..." |
| 69 | +async-dispatch context add <goalId> --note "..." |
| 70 | +async-dispatch goal refine <goalId> --statement "..." --purpose "..." --success-proof "..." --constraint "..." --why "..." |
| 71 | +``` |
| 72 | + |
| 73 | +Draft a human-readable plan before runtime work: |
| 74 | + |
| 75 | +```bash |
| 76 | +async-dispatch plan template human-draft --seed "..." |
| 77 | +async-dispatch plan draft <goalId> --from <draft.md> |
| 78 | +``` |
| 79 | + |
| 80 | +Present the draft or board shape to the user for review. Ask for approval or |
| 81 | +corrections, not whether planning should happen. Record corrections with: |
| 82 | + |
| 83 | +```bash |
| 84 | +async-dispatch plan decision <planId> --note "..." |
| 85 | +async-dispatch plan enrich <planId> --note "..." |
| 86 | +async-dispatch plan resolve <planId> --decision-id D001 --resolution "..." |
| 87 | +``` |
| 88 | + |
| 89 | +Only after the human-reviewed draft is ready: |
| 90 | + |
| 91 | +```bash |
| 92 | +async-dispatch plan ready <planId> --note "Human reviewed the draft." |
| 93 | +async-dispatch plan compile <planId> |
| 94 | +``` |
| 95 | + |
| 96 | +Do not approve the board on behalf of the user unless their latest message |
| 97 | +clearly approved the specific draft/board. After approval: |
| 98 | + |
| 99 | +```bash |
| 100 | +async-dispatch board approve <boardId> --note "Human reviewed the board." |
| 101 | +async-dispatch runtime start <boardId> |
| 102 | +``` |
| 103 | + |
| 104 | +## Runtime Handoff |
| 105 | + |
| 106 | +After `runtime start`, switch to `dispatch-root-runtime` for nodes, domain |
| 107 | +owners, workers, receipts, idle/wake, and closeout. Use `dispatch-code-routing` |
| 108 | +before code edits that might become root work, child chats, domain-owner chats, |
| 109 | +or worktree lanes. |
| 110 | + |
| 111 | +Launch workers only from approved runtime state with ownership, verification, |
| 112 | +stop conditions, and a root integration point recorded. |
| 113 | + |
| 114 | +## Output Contract |
| 115 | + |
| 116 | +For the first response after this skill triggers, report: |
| 117 | + |
| 118 | +```markdown |
| 119 | +## Dispatch Start |
| 120 | +Mode: planning-required | resume-runtime | resume-board | root-only |
| 121 | +Source state: [matching goal/plan/board/runtime or none] |
| 122 | +Goal: [short restatement] |
| 123 | +Next phase: [planning, board review, runtime, or root-only] |
| 124 | +Root action: [exact command or review step being performed now] |
| 125 | +Human review needed: [what the user must approve or correct before workers] |
| 126 | +Missing state action: [skill to continue with, exact command family, and concrete human reply] |
| 127 | +``` |
| 128 | + |
| 129 | +If the mode is `planning-required`, include a concise draft plan or the command |
| 130 | +sequence used to create one. If the mode is `root-only`, say why the request is |
| 131 | +small enough or quote the explicit root-only instruction. |
| 132 | + |
| 133 | +Never end a missing-plan response with only "review needed." Include the next |
| 134 | +agent action, the next human action, and the skill that owns the next phase. |
0 commit comments