next-ticket 是一个用于从项目工单库中挑选并认领下一张工单的技能。它的核心职责是：找到工单库、读取工单、选出唯一一张最值得现在处理的工单，并完成认领，从而让同时读取同一工单库的另一个会话得到不同的结果。
用途 该技能面向需要从工单库中决定“接下来做什么”的场景。它不负责执行工单本身，只负责挑选与认领；是否继续处理由用户决定。
主要能力
- 定位工单库：读取 tickets/store-config.md，该文件以仓库相对路径固定指明工单库位置。若配置指向 GitHub 场地，则工单库是该仓库在 efforts 跟踪 issue 下的 issue，应通过查询而非读取文件来获取。若项目在自身上下文中另行说明工单库位置，则以该说明为准。若两者都不存在，技能会先查找再询问；若确实不存在任何工单库，会明确说明，并提供两种建立方式：对已完成的 manifest 使用 ticket-up，或按约定手工编写工单。
- 选择 effort：当对话已围绕某个 effort 时，直接使用该 effort。否则从场地本身枚举 effort——文件库中的 tickets/<effort>/ 目录，或 GitHub 中单次开放 issue 查询所附带的 effort 标签。只有含开放工单的 effort 才可能被选中。优先选择已在进行的 effort（持有已认领工单或近期关闭过工单），因为完成优于开始。当多个会话同时工作时该信号会饱和，此时回退到按各 front 文件的目的地判断哪个 effort 当前最重要。若工单库配置中写明了固定的 effort 排序，则以该排序为准，但对话中正在讨论的 effort 仍然优先。
- 读取工单：只读取开放集合——该 effort 的工单目录（不读 done/ 归档），或跟踪器的开放 issue 查询——外加 front 文件中的目的地和任何优先级覆盖。只考虑就绪工单：开放、未认领、所有依赖已完成。按工单库声明的优先级规则排序，或按约定默认规则：urgent → unblocking → impact → cheap，其中 impact 在有 front 文件目的地时对照该目的地衡量。
- 命名唯一首选工单：给出标题、类型（shaped 表示直接构建；question 表示先弄清楚）、是否带有 Auto 授权（granted 表示无人值守自动化可端到端处理；ungranted 表示等待人工）、以及它携带的类型（若没有类型则明确说明其未携带类型——未类型化是工单的事实，而非缺失字段），并用一行说明为什么它排在首位，依据是使其登顶的规则。授权和类型都是关于“谁可以接手”的信息，绝不是选择输入——优先级规则不读取这两者。
- 认领并提议工作：在命名选择的同时写入认领标记（如 Claimed by: 行、assignee 或场地等价物），并报告已完成而非先询问。该写入是让两个会话得到不同工单的关键：就绪规则已将已认领工单视为被占用。所有场地都应认领，包括无法长期承载认领的场地，并说明刚做了什么，而不是暗示场地无法提供的排除。在共享跟踪器上认领对所有人有效；在文件库上认领只记录意图，供该检出目录的下一个读者参考，无法触达在其他位置工作的人。随后按类型提议工作：对 shaped 工单执行，对 question 工单开启弄清会话；并提议若这不是用户想要的工单则释放认领。
- 无就绪工单时：按同样判断尝试下一个 effort，再报告。说明查看了哪些 effort，并准确说明原因：所有开放工单被阻塞（列出阻塞边）、全部被认领（说明被谁认领）、或工单库为空。仅有阻塞工单的库通常意味着应完成或整理进行中的事项，并说明关闭哪张工单能释放最多。
使用方式 该技能通过读取工单库配置和工单文件来工作，不涉及安装命令或代码执行。使用时需确保项目存在工单库或按约定建立工单库。
适用场景 适用于需要从工单库中决定下一步工作、并希望避免多会话重复选择同一工单的项目。
限制
- 不负责执行工单，只负责挑选与认领。
- 文件库上的认领仅对当前检出目录有效，无法跨工作区同步。
- 若工单库不存在，技能不会自行创建，而是提供建立方式。
- 优先级规则不读取授权和类型，因此工单不会因类型被偏好或跳过。
- 关于收费、价格、平台等具体信息暂未提供。