/pl-dispatch

name: pl-dispatch
description: "PL (Project Lead) role sub-skill for opening and scheduling journeys. Loaded ONLY through the pl core routing table; NEVER auto-load from context, never invoke directly."
requires:
  programs:
    - {name: reach, min_version: "2.0"}
    - {name: heartbeat, min_version: "1.0"}
  harness:
    - {slot: 4.shell, need: required}
    - {slot: 4.file-read-write, need: required}
    - {slot: 4.background-processes, need: required}

PL · Dispatch — opening and scheduling journeys

Scripts named below run as `bash "${PL_SKILL_DIR}/scripts/<name>.sh" ...`, where `PL_SKILL_DIR` is the absolute path of the `pl` skill directory; set it in the same Bash call. When you write text that an executor will read, the executor has no `PL_SKILL_DIR`: substitute the absolute path of the pl skill's `scripts` directory for `<PL_SKILL_DIR>` when you write the dispatch.

Sub-skill of the PL role. The pl core skill invokes this EXPLICITLY when a new journey opens (the owner asks for a dispatch prompt or to open work; "owner" means whoever owns the work, often the user), when scheduling is decided (what's next / what to schedule while the owner is away), or when parallelism/capacity is in question. Core iron rules bind unchanged: never write product code; never trust report prose — disk over words; the owner is addressed in the user's own language, while agent-to-agent text uses the project's working language (English by default). Canonical scripts: the pl skill's `scripts/`; canonical references: the pl skill's `references/`. The workspace layout (`TODO.md`, `ai-doc/ACTIVE/PL/`, ledger paths) is documented once, in the pl core's State files section; the words mission, registry, ledger, journal, fence, class, close-audit, quiet hours and the rest of the vocabulary are defined in the pl core's Terms.

Writing the dispatch (owner asks for a dispatch prompt or to open work)

Read the pl skill's `references/dispatch-template.md` and write a dispatch prompt the owner can **copy as one block**. Hard requirements: the mission header is the first non-empty line, and the dispatch names the journey id and the charter path.

**Then the second line depends on which kind of agent this is (core Iron rule 6).** For an **executor that authors or edits deliverables and works from a charter**, the next non-empty line is exactly one bare skill invocation naming the charter: `/deliver <charter>` for Claude and Cursor, `$deliver <charter>` for Codex, with no task text on that line; a direct worker skill there is an illegal dispatch. When `deliver` is not installed, the entry instruction is the one the charter names. The spawner does not check this line; a wrong or missing entry launches and the executor starts work outside the charter — verify the line yourself before spawning. For an **operational runner** — the job executes something already written and authors nothing — there is **no `deliver` line at all**; the dispatch names the command, the working directory, and the artifact that proves it ran. Writing a `deliver` entry into an operational dispatch is the defect this split exists to stop.

**Include a finite estimate and a test scope in the dispatch.** Use available prior runtimes to estimate preparation, implementation, the affected tests, and reporting. When historical timing is unavailable, state a provisional estimate and its uncertainty; do not suspend development to build or repair an estimator. Tests cover only the changed behavior and direct consumers. By default do not add unrequested gates or run the full suite or evaluations; propose them to the owner as a question. Neither the dispatcher nor a default final-gate instruction may authorize them. The estimator (`agentic-time-estimate`) is used only when installed; clock times quoted to the owner come from `sno report-time` when installed, otherwise from `date` in the owner's zone, never from arithmetic.

**Charter authorship is never a spawnable deliverable.** A charter records OWNER decisions; it forms only in owner-participating dialogue (the `charter` skill). A dispatch whose task is "write/fix the charter" is illegal by construction (the spawned agent will invent the decisions the owner never made); nothing mechanical catches a charter path in a fence — the PL reads the fence before spawning and refuses it. The scope fence names the territories of parallel sessions; **new journey = new session**, never reuse old context; ban `git add -A` (when the project uses git); the close has three parts (journal, the charter's report, the ledger closed line); the last line names the next baton.

**Journey id**: any short unique id the PL picks — the board row's id printed by `bash "${PL_SKILL_DIR}/scripts/todo.sh" add ...` (for example `b-0007`), or a plain `j-1` for work without a board row. Use that one id everywhere: callsign claim, convergence series, fence filename and the Reach `X-Work` header. The ledger lines for the journey (`routed` at opening, `closed` at the end) are written by the PL by hand (`bash "${PL_SKILL_DIR}/scripts/todo.sh" close ...` adds its own `board_closed` line for the board row); the PL verifies them at close.

**Dispatch prompt goes to disk first**: save to `ai-doc/ACTIVE/PL/dispatch/<journey_id>.md` (create the directory if it is absent) before framing it for the owner to copy — the verbatim intent and scope fence become citable; audits and conflict checks run against this file, not against conversational memory.

**Layer routing (automatic by default; the owner can veto with one word)**: the default is three layers — a planning session produces the plan, a separate executor session writes code and tests, then the planning session accepts the result without having watched the build (blind acceptance). **A two-layer pass (one session plans and runs to the end) requires ALL four**: ① the charter is not a greenfield product or a cross-repo integration (those are always three-layer); ② the workload is mechanica