ai-workflow-skill/skills/orch/references/leader-dispatch-and-launch-checklist.md

Leader Dispatch-And-Launch Checklist

Use this checklist when the leader wants durable orch scheduling plus a Codex sub-agent worker.

Goal

Keep orch as the control plane and use a leader-side bridge to launch a worker sub-agent only after dispatch succeeds.

Recommended Flow

1. initialize the shared DB once through skills/inbox/assets/inbox --db PATH --json init
2. create the run and tasks with run init, task add, and dep add
3. find dispatchable work with ready
4. save the dispatch response:

./assets/orch --db ./coord.db --json dispatch --run RUN_ID --task TASK_ID --execution-mode analysis > TMPDIR/dispatch.json

5. render a standardized worker brief:

./assets/orch-worker-brief --dispatch-json TMPDIR/dispatch.json --db ./coord.db > TMPDIR/worker-brief.txt

6. spawn one worker sub-agent with:
   • injected skills/inbox/
   • the generated worker brief
   • the repository defaults from AGENTS.md
     • model: gpt-5.4
     • reasoning effort: xhigh
     • fork_context: true first
7. while the worker runs, keep the leader on:
   • orch wait
   • orch status
   • orch blocked
   • orch answer
   • orch retry
   • orch reassign

Worker Launch Rules

• the worker should use skills/inbox/, not skills/orch/
• the worker should claim only the exact thread_id from the dispatch result
• if worktree_path exists, the worker should do all repository writes only inside that worktree
• the worker should send progress, blocked questions, success, and failure through inbox

Why This Layer Exists

• orch remains portable and durable
• worker launch stays outside the core CLI
• the same dispatch contract can later support Codex sub-agents, codex exec, daemons, or operator UI launchers