factory-tickets

factory-tickets

此技能的作用

factory-tickets 是软件工厂的只读个人工作清单引擎。它能立即提供实时且可执行的活跃队列概览，并按照「下一步行动」而非抽象状态进行分类。

它通过与跟踪器无关的集成层（factory-mission/references/tracker-integration.md），直接对接外部问题跟踪器和 PR 托管平台（GitHub、GitLab、Linear、Jira）。

---

何时使用

• 在会话开始时或规划当天工作时，准确了解接下来有哪些事项需要你关注。
• 查看自己的哪些拉取请求已可合并、受阻，或正在等待你提供审核反馈。
• 找出尚未分配且未受阻的工单（spec-gated），这些工单已可执行。

何时不使用：

• 更改工单状态、受理人或正文（此技能严格只读）。
• 执行或实施任务（请改用 factory-mission）。

---

操作流程

1. 提供方与身份发现

1. 发现当前使用的跟踪器提供方和凭证（factory-mission/references/tracker-integration.md）。
2. 确认已通过身份验证的用户登录名。将搜索范围限制为：
   • 由已通过身份验证的账户创建的拉取请求。
   • 分配给已通过身份验证的账户（或明确指定的其他登录名）的工单。

2. 双数据源分页查询

不要逐个轮询条目。执行两次分页搜索（通过 MCP 或 CLI），每个数据源一次往返，获取全部活跃条目：

1. 拉取请求搜索：获取用户的未关闭 PR，包括：草稿状态、审核决定、未解决的讨论串、具名检查状态以及可合并性。
2. 问题搜索：获取分配给用户的未关闭问题，包括：标题、描述、状态、标签、里程碑以及关联的项目信息。

3. 匹配证据（与跟踪器无关）

一个 PR 通常会交叉引用多个工单。只有存在明确证据时，才将拉取请求与工单关联：

• 由跟踪器本身建立的关闭链接。
• 根据仓库约定，在分支名称中包含工单编号。
• PR 标题明确写出工单编号。 如果不存在明确证据，则将关联单元格留空。切勿仅凭文本提及进行猜测。

4. 分类下一步行动（按下一步行动划分）

将检索到的每个条目准确归入以下一个优先级分类。按已分配的分类呈现，不要在排版时重新分类：

1. 活跃拉取请求（轮到我）：下一步行动应由用户执行的拉取请求：
   • Merge — 必需检查全部通过，且人工批准已完成。可合并的 PR 排在最前（优先级最高）。
   • Address Review Feedback — 审核者要求进行修改。
   • Fix failing check: <name> — 必需的 CI 检查失败（按名称报告，不汇总）。
   • Answer N comment threads — 存在未解决的审核者问题。
   • Finish Draft — PR 仍处于草稿状态。
2. 活跃拉取请求（轮到对方）：正在等待外部操作的拉取请求：
   • Awaiting Review — 已准备好审核，但受邀审核者尚未回复。
   • Awaiting CI — 必需检查仍在运行。
3. 已合并，工单仍未关闭：关闭此工单的 PR 已合并，但看板上的工单仍处于未关闭状态。行动：验证后关闭。
4. 现在可接手（待办事项）：未关闭的问题，其生命周期为 spec-gated，自动化门控为 agent-can-execute，且没有拉取请求认领这些问题。（若为空，请明确显示「无」。）
5. 等待他人处理：存在尚未解决的「被以下事项阻塞」依赖的未关闭问题，并注明阻塞工单。

注：史诗和父级问题应按规则放在下方的附录中，显示子项数量和进度。它们绝不能混入活跃任务列表。

---

不变量与安全约束

1. 严格只读：此技能在物理层面无法编辑、评论、创建或修改任何工单、标签、受派人或看板字段。这里没有 gh 或 glab 写入命令。
2. 不缓存：每次运行都会实时获取数据。缓存或过时的队列还不如没有。
3. 不猜测汇总状态：如果某项作业只是被取消或跳过，绝不要根据汇总的“失败”提交状态报告检查状态。请读取并指出确切的失败上下文。
4. 报告未解析词语：如果用户请求中包含查询解析器无法识别的词语，请勿将其舍弃。在表格下方列出“未解析词语”部分，让用户知道哪些词语被忽略。