next-ticket

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.

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 Winning, and the number watched and Never fields: winning is 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 Never 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 winning field still empty, compare exactly as below; within one effort nothing changes either way.

Choose by delay loss. Take candidates only from the open set in scope and keep only ready Tickets: open, unclaimed, all dependencies done. 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.