next-ticket

Find the store, read it, name one ticket. The store follows the ticket convention (../ticket-up/references/TICKET_CONVENTION.md — read it if the convention isn't already in context).

Finding the store. Read tickets/store-config.md — one fixed, repo-relative location naming the venue. A GitHub-venue config means the store is that repo's issues under the efforts' tracking issues; query instead of reading files. A project that deliberately keeps its store elsewhere says so in its own context file, already loaded when you run. Without either, look before asking: if no store exists anywhere, say so plainly and offer the two ways one appears — ticket-up on a finished manifest, or writing tickets by hand under the convention — since a project with no work tracked yet needs a store, not a question about which kind. Where something is there, don't assume which venue it is, not even when tickets/<effort>/ directories are sitting in front of you, since a project whose store moved to a tracker usually still has them. Ask, showing what you found so the answer is cheap to give, and write it to tickets/store-config.md so it's asked once.

Set the candidate scope. A bare invocation answers rather than asking which effort. When the conversation is already about one effort, scope to that effort. A store that deliberately declares an effort order uses that order; it is explicit operator policy and wins over the default. Otherwise enumerate every effort with open Tickets from the venue itself — tickets/<effort>/ in a file store, or effort labels on one open-issues query in GitHub — and compare their ready Tickets together. Read each relevant front file's destination and priority override so delay loss is judged against what that effort is trying to reach. No effort index or derived next-state file is kept.

Choose by delay loss. Read only the open set in scope — never a file store's done/ archive — and keep only ready Tickets: open, unclaimed, all dependencies done. Apply an explicit store or effort priority override where it reaches; otherwise use the convention's expected-delay-loss rule. Compare the strongest candidates by what project value is lost while each waits for the other's constrained human attention. Include ongoing or expiring harm, durable benefit that starts later, downstream work whose earliest useful start actually moves, and delayed information that worsens or postpones a material decision. Do not turn those into saved scores.

This picker allocates a human-plus-AI session, not unaided human implementation. Estimate only the interactive human attention needed until the human-dependent uncertainty, taste, or authority is resolved; do not charge routine implementation an AI can continue afterward. Do not infer days from traditional feature size or apply a fixed agent-speed multiplier. When plausible runtimes are short enough that their difference does not materially change delay loss, treat them as equal; shorter work is only a tiebreak. Continuity with an effort already in flight is also only a tiebreak.

Auto is not intrinsic priority. It matters only when project context or configured automation establishes that unattended capacity is actually available soon enough to take that Ticket. In that case, similarly valuable work needing human interaction can beat Auto work the unattended runner can take, but non-Auto never gets a hard preference and an Auto Ticket still wins when its delay loss is larger. Auto alone proves authority, not that a runner exists. Type is never a selection input.

Name the single top Ticket: its title, kind (shaped means build it; question means figure it out first), whether it carries the Auto grant (granted means unattended automation may take it end to end; ungranted means unattended automation may not), its type when it carries one (and say plainly that it carries none when it doesn't), and a one-line why-this-one grounded in the concrete delay loss or explicit override that put it on top. Never fabricate a numerical score to justify the choice.

Claim it, then present it. Write the claim as part of naming the pick — a Claimed by: line, an assignee, the venue's equivalent — and report it as done rather than asking first. That write is the whole reason two sessions get different Tickets: the readiness rule already treats a claimed Ticket as taken, so a pick that leaves no trace means everyone reading this store names the same one. Claim on every venue, including the ones that cannot carry it far, and say which you just did rather than implying an exclusion the venue cannot provide — on a shared tracker the claim holds against everyone, while on a files store it records intent for the next reader of this checkout and reaches nobody working in another. Present the complete Ticket and offer only to release the claim if this was not the Ticket the user wanted. Do not execute it, invoke run-ticket, or choose a workflow on the user's behalf; selection and execution are separate actions.

When nothing is ready, inspect every effort in the active scope before reporting. Say exactly why: every open Ticket blocked (name the blocking edges), everything claimed (name by whom), or the store is empty. A blocked-only store usually means the useful move is to finish or tidy something already in flight — say which close would release the greatest expected downstream delay loss, not merely the largest dependent count.

Gotchas

• Surface a claimed ticket that looks abandoned ("claimed by X, untouched; a tidy pass could release it") and leave the reassignment to a person.
• The why-line is the audit trail: name the concrete value lost by waiting or the explicit override, not an old category label or invented score.