菜单
Read the project's ticket store and name the single best ticket to work on now, with the reason. Use when picking up work, asking what's next, what should I work on, or pulling the next task or ticket from the backlog.
默认使用会先检查来源的 Prompt；你也可以切换为直接命令，或下载本地副本。
决定是否安装前，请先阅读 SKILL.md，以及 SkillsMP 当前展示的配套文件。
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
直接命令不会经过审查 Prompt；运行前请先检查来源。
npx skills add https://github.com/doodledood/claude-code-plugins --skill next-ticket命令会保持在同一行。复制前请横向滚动并检查完整内容。
想先保存到本地？可下载 SkillsMP 当前能够提供的文件。
End-to-end autonomous execution: figure-out → define → do, chained without manual approval gates. Use when you want to define and execute without intervention during planning, when the user asks for autonomous or end-to-end work, says just build it, or asks to tend or babysit a PR.
Author-side PR lifecycle babysitter and companion to review-pr. Use when the user wants to tend an existing GitHub PR through CI, review threads, description sync, mergeability, auto-fixes, or asks to babysit a PR with or without an existing manifest.
Manifest executor. Works through Deliverables verifying every Acceptance Criterion and Global Invariant. Use when executing a manifest, running a plan, implementing a defined task, or when the user asks to run, execute, implement, or ship a manifest-backed plan.
正在显示 SKILL.md
| name | next-ticket |
| description | Read the project's ticket store and name the single best ticket to work on now, with the reason. Use when picking up work, asking what's next, what should I work on, or pulling the next task or ticket from the backlog. |
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. Check for a store config first (store-config.md in the ticket-up skill directory, else at a store root like tickets/store-config.md) — it names the venue. Without one, look for tickets/<effort>/ directories in the project. A GitHub-venue config means the store is that repo's issues under the effort's tracking issue; query instead of reading files. 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.
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), and a one-line why-this-one grounded in the rule that put it on top. Multiple efforts with stores → ask which, or read the one the conversation is about.
Then offer, don't act. Offer to claim it for the user (write Claimed by:, assign the issue), and — by kind — to start executing a shaped ticket or open a figure-out session for a question ticket. Picking is this skill's whole job; working it is the user's call.
When nothing is ready, 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.