Autopilot Triage

Autopilot Triage

Vet a pool of open issues against the autonomy rubric and, after your confirmation, tag the ones that qualify with the autopilot-queued label. /autopilot-batch later reads that label and runs the batch. This is the vet half of the triage → run split; the two are decoupled on purpose — triage once (cheap, start-of-day), run the batch whenever and from wherever.

The autopilot-queued label is membership only: it means "vetted and pending," nothing more. Tier is decided at run time by your --merge opt-in, never encoded in it. The build model rides on a separate, pre-existing label (model: fable / model: opus / model: sonnet) that issue triage assigns — this skill reports that label, it does not assign one.

Where this runs

Run from the target application repository — you need the issues and the code, because vetting scope means looking at what a fix would actually touch. Triage is read-only except for the label writes it makes after your confirm.

Arguments

• (no args) — vet all open issues.
• [label-or-filter] — narrow the candidate pool, e.g. a phase label or chore / fix. Passed through to gh issue list --label.

The autonomy rubric

An issue qualifies for autopilot when all hold:

• Complete spec — clear acceptance criteria; you could hand it off with no back-and-forth.
• Bounded scope — a few files, one subsystem, a known pattern to follow (the positive exemplar: a "localize these hardcoded strings" i18n issue).
• No product / UX / design decision — nothing that needs your judgment about what to build.
• Testable — its resolution can be proven by the suite (or a targeted inline check).

An issue is disqualified when it trips any of /autopilot's own escape-hatch triggers — the same guardrails, applied before the run instead of during it:

• a new DB column / migration, a changed model association, an altered public route, a new dependency, or an event-status-lifecycle change;
• a thin or ambiguous spec, or one that conflicts with the code;
• multiple subsystems, a real design choice, or anything you'd want to review mid-flight.

When a candidate is borderline, disqualify it — a false negative costs you one manual issue; a false positive burns an unattended run on something that should have stopped. State a one-line reason for every skip; those reasons are useful signal.

For each qualifying issue, also note — as a preview, not a commitment:

• Build model — report the issue's model: label if it has one; that label is what /autopilot-batch will actually build with (see ~/.claude/docs/model-selection-strategy.md). If it has none, preview the rubric fallback the batch will use instead — Opus for data-model / security / ambiguous / cross-cutting; Sonnet for bounded pattern-work (i18n / views / config / a single test / CRUD / docs) — and mark it as a preview, not a fact. Either way this is so you can eyeball and adjust before the run. (A --merge opt-in overrides both at run time: merge issues are always Fable-built, because the merge go/no-go runs at the build model and the merge floor is Fable.)

• Missing model: label in an adopted repo — flag it. Check adoption once per run:

  gh label list --json name --jq '[.[].name | select(startswith("model: "))]'

  A non-empty result means the repo has adopted the convention, so a queued issue without a model: label is a triage gap — worth fixing, but never a reason to skip the issue. The batch treats it as Opus by convention via the rubric. Do not apply the label yourself: model tiering is assigned when the issue is triaged, and quietly stamping a tier here would launder a guess into the record. Point the gap at /model-triage --maintenance, which is the skill that owns that write.

• Merge-tier candidate? — flag issues that look safe for --to merge (confined to config / locales / views / copy; no migration / route / dependency). These are suggestions you opt into with --merge at run time; the batch defaults everything to --to pr.

Your task