/next-ticket

name: next-ticket
description: 'Read the project''s Ticket store, choose the single best Ticket for the human-plus-AI session to work on now, claim it, and present it with the reason it leads. Use when asking what''s next, what should I work on, or pulling the next Ticket from the backlog. Selection stops after presentation; execution belongs to run-ticket or the person holding the claim.'

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), and every state a Ticket is in and every move it makes, a pick and its claim among them, is `../ticket-up/references/AUTOMATED_EXECUTION.md` → *Transitions* — read that section too.

**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.

When the candidates span more than one effort and the project has a North Star (`NORTH_STAR.md` at the repository root, or wherever the project's context file says it lives), read its goal and measures and its principles: the *Goal*, *How we know* and *Principles* sections, or, in a North Star of the older nine-field form, its `Winning, and the number watched` and `Never` fields. The goal and its measures are what the efforts' destinations are weighed against — the cross-effort measure the front files alone don't supply — and a candidate whose work would cross a principle is surfaced with that clash rather than picked. When it consulted the North Star, the why-line says so. Without a North Star, or with its goal and measures still empty, compare exactly as below; within one effort nothing changes either way.

**Read the strategy signposts on every pick**, whatever the scope. Where the project's North Star lists its strategy choices in force with signposts — a `Revisit when` condition after a title — read each condition at the source it names. Report one that reads as met, with its record's title, as a choice the person may want to reopen; report one whose source you cannot read, with that source. Selection does not assign strategic revision: report the evidence for the owner or an already assigned delegate, and change neither the record nor the list.

**Choose by delay loss.** Take candidates only from the open set in scope and keep only ready Tickets, as *Transitions* defines them, reading each deferred Ticket's `Revisit when` source on every pick. Name each deferred Ticket whose source you cannot read, with its source, in your report. Selection never edits the line; changing it needs a separate assignment and applicable authority, not an observation of its source. Read bounded recent closed history, including a file store's `done/` archive, only when an explicit priority override needs it as ranking evidence. A Ticket is everything its venue holds for it, not the item body alone; the venue reference names those surfaces. Read every candidate whole, not just the ones already looking strong — attached context is part of what ranks a Ticket, so reading it only for front-runners lets the ranking decide what informs the ranking. 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 w