Model Triage

Model Triage

Roll the per-issue model-selection convention into a repository: tier each open issue, then apply the model: labels, the board's Model field, and any body callouts — all behind a single approval gate. The convention, its heuristic, and the manual runbook this encodes live in ~/.claude/docs/model-selection-strategy.md; the label vocabulary lives in ~/.claude/docs/label-taxonomy.md.

This is a rollout tool, not a routine one. Model labels are assigned at issue creation alongside the type label. Run this skill once when adopting the convention in a repo that already has open issues, and after that only in maintenance mode when drift has accumulated.

Where this runs

From the target repository's checkout — you need the issues and the code, because tiering an issue means judging what a fix would actually touch. If you must run from elsewhere, every gh issue call needs --repo <owner>/<name>; without it the command silently targets whatever repo you are standing in.

Arguments

• (no args) — full rollout: tier every open issue that should carry a label.
• --maintenance — sweep mode: tier only issues missing a label, reconcile label ↔ board-field drift, and refresh stale label descriptions. Leaves existing label assignments alone unless an issue's scope has visibly changed.

The tiering heuristic

Assign a tier by asking what a wrong answer costs and how far the reasoning reaches. Full treatment in the strategy doc; the working summary:

• Fable (flagship) — a wrong answer would silently corrupt canonical/persistent data with no error surface. This is the insurance case, and only that case. Expect it rare, and expect each one to have a nameable reason. (Multi-module reasoning with non-obvious ripple used to qualify here too; Opus 5 absorbed it and the clause was cut on 2026-07-27.)
• Opus (workhorse) — well-specified features with a test scaffold and a contained blast radius; migrations / data-model; thin specs; security-adjacent work. The default when you genuinely can't tell.
• Sonnet (light) — docs, a single regression test, i18n / copy, mechanical pattern-following where the spec leaves little to interpret and failure is visible.

Lean one tier down for docs/tests, one tier up for anything touching data integrity.

Calibration: ComixDistro's settled pass was 4 Fable / 32 Opus / 25 Sonnet across 61 issues — roughly 6% flagship — but that pass was tiered under the older two-clause flagship bar. Under the tightened bar expect ~2–3%. Either way, a pass landing far above is not discriminating, it is just burning limit headroom. Check the two calibration references in the strategy doc — and the note on which rules they were measured under — before presenting.

Issues that get no tier

Some issues have nothing to build directly, and a tier on them is noise:

• epics and tracking issues — the children carry the tiers
• content hubs — durable reference/index issues
• qa reports — the tech issue derived via /qa-triage carries the tier

Call these out explicitly as deliberate exclusions rather than silently skipping them; an unexplained gap looks identical to an oversight.

Your task

Step 0 — Preflight

Establish that everything the apply step needs exists, and stop early if it doesn't:

1. Token scope — gh auth status must list project in the token scopes. If it's missing, stop: the user must run gh auth refresh -s project interactively. You cannot grant it for them.

2. Locate the board — gh project list --owner <OWNER>; capture the project number and node ID (PVT_…). If the repo has no board, the label pass can still proceed — say so and skip the field work rather than stopping.

3. Labels exist — gh label list. Create any missing ones from the taxonomy, exactly as specified there:

   gh label create "model: fable"  --color B60205 --description "Recommended model: Fable 5 (reserve for silent-data-corruption stakes)"
   gh label create "model: opus"   --color FBCA04 --description "Recommended model: Opus 5 (well-scoped features, refactors)"
   gh label create "model: sonnet" --color 0E8A16 --description "Recommended model: Sonnet (docs, single tests, mechanical edits)"

   Also check the descriptions of labels that already exist. A description names the model current at the time the label was created, so a repo adopted before a model release carries a stale one indefinitely — gh label create won't touch it and no other step will either. Compare against the strings above and repair any mismatch:

   gh label list --json name,description --jq '.[] | select(.name | startswith("model: ")) | "\(.name)\t\(.description)"'
   gh label edit "model: opus" --description "Recommended model: Opus 5 (well-scoped features, refactors)"

   Report each repair as drift fixed, not as a label created.

4. Model field exists — gh project field-list <N> --owner <OWNER> --format json. If absent, create it once:

   gh project field-create <N> --owner <OWNER> \
     --name "Model" --data-type SINGLE_SELECT --single-select-options "Fable,Opus,Sonnet"

5. Board membership — gh project item-list <N> --owner <OWNER> --limit 200 --format json. Diff against the open-issue list; an issue not on the board cannot receive a field value. Note the strays now so the apply step can gh project item-add them first. Trust item-list over any claim an issue body makes about its own board membership.

Report the preflight result compactly: what existed, what you created, what needs adding to the board.

Step 1 — Gather

• gh issue list --state open --limit 200 --json number,title,labels,body.
• In --maintenance mode, narrow to issues with no model: label — plus any whose scope has visibly changed since labeling.