11 added, 5 removed. Audit A to A.
---
name: next-ticket
- description: 'Read the project''s Ticket store, choose the single best Ticket 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.'
+ 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).
**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.
- **Choosing the effort.** A store holding several still gets an answer rather than a question back. When the conversation is already about one effort, that's the one. Otherwise enumerate the efforts from the venue itself — the `tickets/<effort>/` directories in a file store, or the effort labels attached to a single open-issues query in GitHub; no index of efforts is kept anywhere, and only efforts with open tickets can win. Start in the one already in flight — holding a claimed ticket, or one closed recently — because finishing beats starting, and this needs nothing written down. That signal saturates once several sessions work the store at once: every effort someone is on holds a claim, so it stops singling one out. Nothing breaks when it does — fall through to the destinations below and judge, exactly as you would with nothing in flight. With nothing in flight, read each front file's destination and judge which effort matters most now — the priority rule below ranks tickets inside an effort and cannot rank efforts against each other. Say which effort you picked and why, so one word redirects it. A store that wants its efforts ranked the same way every time says so in its store config; a stated order replaces the judging above it, in-flight rule included, since someone wrote it down on purpose. It doesn't override the conversation — an effort you're already talking about is still the one.
+ **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.
- **The read.** Read only the open set — the effort's ticket directory (never its `done/` archive), or the tracker's open-issue query — plus the front file for the destination and any priority override; closed history costs nothing. Ready tickets only — open, unclaimed, all dependencies done. Order them by the store's stated priority rule, or the convention's default: urgent → unblocking → impact → cheap, with impact measured against the front file's destination when one exists. 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 it waits for a person), its type when it carries one (and say plainly that it carries none when it doesn't — untyped is a fact about the ticket, not a missing field), and a one-line why-this-one grounded in the rule that put it on top. Grant and type are both information about who can take the pick, never selection inputs — the priority rule reads neither, so a ticket is never preferred or passed over for the type it carries.
+ **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** in the effort you picked, try the next effort by the same judgment before reporting — nothing ready means nothing ready anywhere, and say which efforts you looked through. Then 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 thing to do is finish or tidy something in flight — say which ticket closing would free the most.
+ **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.
- - Rank by the priority rule — it is the contract, and the why-line cites it.
+ - 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.