skills: model-selection — per-role tier assignment for Agent dispatches

Per the maintainer's directive on 2026-06-10: "As the gardener, please
direct each role to be dispatched with the best model fit for the
job. That is, the model that is adequate to the task, for which any
more advanced model would be wasteful."

Lands skills/model-selection/SKILL.md as the canonical per-role
model assignment. Single source of truth: orchestrators (liaison,
steward, driver-lane, judges) read the skill at dispatch time and
pass the tier's model ID to Agent's model parameter.

Three tiers map to the Claude 4.X family:

- Opus (claude-opus-4-7): orchestrators (liaison, steward, gardener,
  evaluator, investigator), all three judges (solicitor, barrister,
  justice) plus appellate, designer, and four heaviest jurors
  (breaker, critic, saboteur, warden, skeptic).
- Sonnet (claude-sonnet-4-6): substantive engineering and curation
  with bounded scope (builder, assayer, fixer, weaver, shepherd,
  boatman, researcher, scout, botanist, major-general, groom,
  journalist, librarian, scholar) plus most jurors.
- Haiku (claude-haiku-4-5-20251001): mechanical roles whose dispatch
  body is dominated by deterministic substeps (monitor, review-queue,
  cleaner, conductor, timekeeper) plus three jurors
  (changeset-auditor, packager, fast-checker).

Adequacy beats parsimony per the maintainer's framing: when a role's
typical engagement straddles tiers, pick the tier whose adequacy is
reliable for the typical case. The shepherd's 2026-05-29
"I'll wait for the next monitor tick" incidents are explicit
evidence that Haiku is not adequate for that role despite its
mostly-mechanical surface; Sonnet is the right floor.

Per-role frontmatter was deliberately not used: a central table is
one diff to retarget when a new Claude version lands (Sonnet 5
etc.), where per-role frontmatter would drift across thirty-plus
files.

CLAUDE.md updates:

- § Dispatch contract step 2: the dispatch journal entry records the
  model tier in a new optional model: frontmatter field.
- § Dispatch contract step 3: the orchestrator passes the model
  parameter from skills/model-selection/SKILL.md.
- § Current inventory: skills list extended with model-selection.

Frontmatter updated date bumped to 2026-06-10 on CLAUDE.md.

Author: endolinbot

CLAUDE.md

@@ -1,6 +1,6 @@
 ---
 created: 2026-05-12
-updated: 2026-06-04
+updated: 2026-06-10
 author: gardener, liaison, builder
 ---
 
@@ -39,8 +39,8 @@ The first route is producer-consumer (any eligible consumer claims) and survives
 The orchestrator's job per dispatch:
 
 1. `DISPATCH_ROOT=$(skills/dispatch-worktree/dispatch-prepare.sh <role> <purpose-slug> [<owner>/<repo> <branch>])`.
-2. Write a `dispatch` journal entry naming the role, repo (when applicable), task, and `DISPATCH_ROOT`.
-3. Invoke `Agent` with a prompt that names `DISPATCH_ROOT` explicitly.
+2. Write a `dispatch` journal entry naming the role, repo (when applicable), task, `DISPATCH_ROOT`, and the model tier the dispatch will use (per `skills/model-selection/SKILL.md`, recorded as a `model:` field on the dispatch entry's frontmatter).
+3. Invoke `Agent` with a prompt that names `DISPATCH_ROOT` explicitly, and pass the model tier from `skills/model-selection/SKILL.md` as the `model` parameter (the model that is adequate to the task; the table makes the choice canonical so it does not drift across thirty-plus role files).
 4. On return, write a `result` journal entry and `skills/dispatch-worktree/dispatch-teardown.sh "$DISPATCH_ROOT"`.
 
 The dispatch prompt itself should:
@@ -141,6 +141,6 @@ The constraint covers both **event-level** surveillance (the standing-monitor da
 ## Current inventory
 
 - Roles: `liaison`, `steward`, `monitor`, `review-queue`, `boatman`, `researcher`, `builder`, `assayer`, `cleaner`, `solicitor`, `barrister`, `justice`, `appellate`, `fixer`, `weaver`, `shepherd`, `conductor`, `designer`, `scout`, `botanist`, `major-general`, `gardener`, `evaluator`, `groom`, `investigator`, `journalist`, `librarian`, `scholar`, `timekeeper`. The prior `general-contractor` posture was retired 2026-06-03 per the maintainer's directive ("I have dismantled the contractor. The role has not been working and I would like to reconstruct it on the driver."); its design-queue-walk + slot-refill function is reconstructed as a deterministic `garden-design-poller` systemd service per `skills/design-poller/SKILL.md`, which posts jobs that driver lanes claim. The `researcher` (added 2026-06-03) precedes every designer and builder dispatch by default: orchestrators (liaison, steward) dispatch it with the proposed downstream prompt, inline its `## Library and project references` section, and only then dispatch the actual designer or builder. See each orchestrator's *Researcher precedence on designer and builder dispatches* section. The prior single `judge` role split into three on 2026-05-21: `solicitor` (designer work; design panel), `barrister` (builder work; first code-panel round), `justice` (fixer work; code-panel re-runs); `roles/judge/AGENT.md` is retained as a redirect. The `appellate` lands the same day to appeal `follow-up` and `acknowledge` dispositions on small-and-in-context items into `summary-fix` before un-draft. Plus the jury-seat roles dispatched by the three judges: a code panel for source-touching PRs and a design panel for design-only PRs (paths under `<project>/designs/`). See each judge's role file under `roles/<solicitor|barrister|justice>/AGENT.md` for the panel composition; the orchestrator never dispatches a juror seat directly.
-- Skills: `journal-sync`, `self-improvement`, `em-dash-style`, `relative-paths`, `no-latin-shorthand`, `agent-termination`, `rule-elision-test`, `inbox-drain`, `autonomous-loop-pacing`, `github-activity-poll`, `pr-ci-watch`, `review-queue-poll`, `rebase-before-followup`, `review-feedback-followup-commits`, `pr-review-thread-replies`, `pr-formation`, `pr-handoff`, `pr-creation-flow`, `pr-dependency-graph`, `pr-dependency-topo-sort`, `yarn-lock-separate-commit`, `pre-pr-checklist`, `regression-evidence`, `coverage-driven-testing`, `adversarial-tests`, `saboteur-adversarial-review`, `panel-review`, `ci-status-summary`, `ci-runtime-comparison`, `conflict-resolution`, `cherry-pick-followup`, `rebase-hygiene-audit`, `worktree-per-pr`, `process-documents`, `prompt-section-discovery`, `benchmark-comparative-report`, `verify-upstream-state-before-pinning`, `reactji-acknowledgment`, `changeset-discipline`, `rename-discipline`, `monitor-arming`, `context-library`, `journalism`, `dispatch-worktree`, `scheduling`, `velocity-recalibration`, `roadmap-projection`, `dependency-graph-maintenance`, `groom-open-questions`, `design-queue-drift-check`, `design-to-pr-pipeline`, `garden-ab-evaluation`, `merged-pr-feedback-watch`, `library-lookup`, `retcon`, `design-dependency-walk`, `stacked-pr-build`, `gap-revealing-build`, `at-mention-surveillance`, `job-board`, `pre-push-gates`, `node-lts-window-watch`, `panel-hints`, `frozen-base-branch`, `node-parity-test`, `test-title-spec-spelling`, `design-poller`, `cleaner`, `gardener-inbox-error-reporting`, `driver-pr-creation-state-machine`, `driver-design-only-pr-workflow`, `driver-gardener-workflow`, `driver-librarian-workflow`, `prompt-on-failure-capture`, `activity-feed-watcher`. The driver workflow skills are the script-orchestrated PR-creation flow's agent context (per [designs/driver.md](designs/driver.md)); the executable counterparts live under `scripts/`. The `driver-gardener-workflow` and `driver-librarian-workflow` skills (added 2026-06-04) extend the driver pool to non-PR roles via role-prefixed lanes (`gardener-1`, `librarian-1`, etc.) per `designs/driver.md` § Role-prefixed lanes. Per-project monitor reaction skills (`monitor-endo`, `monitor-endo-but-for-bots`, `monitor-agoric-sdk`, `monitor-cosgov`, `monitor-garden`) live alongside but are configuration for the `monitor` role rather than independently reusable procedures. `monitor-garden` is the only one whose dispatched subagent runs as `liaison` rather than `monitor`; see that skill's *Dispatch role asymmetry* for why.
+- Skills: `journal-sync`, `self-improvement`, `em-dash-style`, `relative-paths`, `no-latin-shorthand`, `agent-termination`, `rule-elision-test`, `inbox-drain`, `autonomous-loop-pacing`, `github-activity-poll`, `pr-ci-watch`, `review-queue-poll`, `rebase-before-followup`, `review-feedback-followup-commits`, `pr-review-thread-replies`, `pr-formation`, `pr-handoff`, `pr-creation-flow`, `pr-dependency-graph`, `pr-dependency-topo-sort`, `yarn-lock-separate-commit`, `pre-pr-checklist`, `regression-evidence`, `coverage-driven-testing`, `adversarial-tests`, `saboteur-adversarial-review`, `panel-review`, `ci-status-summary`, `ci-runtime-comparison`, `conflict-resolution`, `cherry-pick-followup`, `rebase-hygiene-audit`, `worktree-per-pr`, `process-documents`, `prompt-section-discovery`, `benchmark-comparative-report`, `verify-upstream-state-before-pinning`, `reactji-acknowledgment`, `changeset-discipline`, `rename-discipline`, `monitor-arming`, `context-library`, `journalism`, `dispatch-worktree`, `scheduling`, `velocity-recalibration`, `roadmap-projection`, `dependency-graph-maintenance`, `groom-open-questions`, `design-queue-drift-check`, `design-to-pr-pipeline`, `garden-ab-evaluation`, `merged-pr-feedback-watch`, `library-lookup`, `retcon`, `design-dependency-walk`, `stacked-pr-build`, `gap-revealing-build`, `at-mention-surveillance`, `job-board`, `pre-push-gates`, `node-lts-window-watch`, `panel-hints`, `frozen-base-branch`, `node-parity-test`, `test-title-spec-spelling`, `design-poller`, `model-selection`, `cleaner`, `gardener-inbox-error-reporting`, `driver-pr-creation-state-machine`, `driver-design-only-pr-workflow`, `driver-gardener-workflow`, `driver-librarian-workflow`, `prompt-on-failure-capture`, `activity-feed-watcher`. The driver workflow skills are the script-orchestrated PR-creation flow's agent context (per [designs/driver.md](designs/driver.md)); the executable counterparts live under `scripts/`. The `driver-gardener-workflow` and `driver-librarian-workflow` skills (added 2026-06-04) extend the driver pool to non-PR roles via role-prefixed lanes (`gardener-1`, `librarian-1`, etc.) per `designs/driver.md` § Role-prefixed lanes. Per-project monitor reaction skills (`monitor-endo`, `monitor-endo-but-for-bots`, `monitor-agoric-sdk`, `monitor-cosgov`, `monitor-garden`) live alongside but are configuration for the `monitor` role rather than independently reusable procedures. `monitor-garden` is the only one whose dispatched subagent runs as `liaison` rather than `monitor`; see that skill's *Dispatch role asymmetry* for why.
 
 The `liaison` and `steward` are the two top-level orchestrator postures. When a user is in the loop (this terminal session), the liaison runs with excess authority and asks before acting. When the garden runs in the bot sandbox under safe bot credentials with no user present, the steward runs with bounded authority and may act on its own. Multiple stewards can run concurrently across hosts (and even within one host) and share work load via the journal's job board (`journal/jobs/`); the claim race resolves contention without a dedicated peer-role posture. Focused, parallelized PR-pipeline work that used to live in the retired `general-contractor` posture is now scripted: the `garden-design-poller` systemd service (per `skills/design-poller/SKILL.md`) walks the project's roadmap branch on a cadence and posts `build` jobs to the role-specific board, and driver lanes (per `designs/driver.md`) claim and advance them through the chain. The maintainer's framing on 2026-06-03: "I have dismantled the contractor. The role has not been working and I would like to reconstruct it on the driver." See `roles/liaison/AGENT.md` § Posture and `roles/steward/AGENT.md` § Posture for the two-posture contract.