mstack-backlog-triage

mstack 待办分类

你需要阅读跟踪器中的未处理议题，判断每个议题的类型和处理时机，并将结果交给后续流程。输出内容包括一张分类表；只有用户逐字批准后，才会在跟踪器中发表评论并更改标签。你不编写规格说明、代码或计划：需要规格说明的议题交给 mstack-write-specs，需要诊断的 Bug 交给 mstack-diagnose，暂不处理的议题则交给此主机的 mstack 审查工作流。

主机工具

角色	Claude Code	Codex
提问工具	AskUserQuestion	在聊天中进行编号提问，然后等待回复
子代理工具	Agent	如果会话有 Agent 工具，则使用该工具；否则自行完成步骤
技能文件夹	加载此技能时显示的基本目录	此 SKILL.md 所在的文件夹
gh 命令	直接运行	作为已批准（提权）的命令运行，因为沙盒会关闭网络
<scratch>	会话的临时文件夹，位于仓库之外	${TMPDIR:-/tmp}/mstack-triage-<repository name>

此技能中的文件

文件	使用时机
references/triage-rules.md	第 3 至 6 步：证据、重复项搜索、分类、建议、路由、表格
references/drafting.md	第 7 和第 8 步：评论、标签、批准、发布
scripts/list-open-issues.sh	第 2 步，在 GitHub 上使用

基本原则

1. 全部阅读。 阅读范围内每个未处理议题的完整正文和所有评论。议题列表中的标题不能作为证据；如果已有评论回答了某个议题，不得再次提出新的建议。
2. 每项判断都要有证据。 每个分类和建议都要引用作出判断的依据：复现、搜索、评论或代码路径。无法核实的事实必须作为问题提出，不能猜测。
3. 未搜索重复项，不得列入「当前批次」。 只有在完成重复项搜索并确认没有重复项后，议题才能进入当前批次。
4. 先起草、展示，再发布。 用户必须先批准确切文本和标签变更；只有在展示草稿的消息之后，才能将内容写入跟踪器。
5. 各司其职。 不编写规格说明、代码、计划，也不发布版本，只负责路由工作。

1. 开始

在一条消息中重述目标，并使用提问工具提出问题。请求中已经回答的问题可跳过。

1. 处理哪些议题？ 跟踪器和筛选范围：所有未处理议题（建议），或用户指定的标签、里程碑或搜索条件。
2. 下一批要处理多少项？ 当前批次可纳入的议题数量。如果能查看团队近期的处理进度（过去几周关闭的议题），则建议一个数量；否则建议 5 项。
3. 起草跟踪器更新吗？ 询问是否起草评论和标签变更以供批准（建议），还是只输出表格。

2. 收集

1. 先阅读仓库自己的规则（CONTRIBUTING、AGENTS.md、CLAUDE.md、.github/ISSUE_TEMPLATE/ 下的议题模板），因为这些规则可能定义有效报告的标准和标签含义。

2. 在 GitHub 上列出范围内所有未处理议题，并确认列表完整：

   bash <skill-folder>/scripts/list-open-issues.sh <owner/repo> <scratch>/open-issues.json
   

   该脚本会保存正文和评论，并在保存的议题数与仓库中的未处理议题数不一致时失败，因为 gh issue list 默认最多返回 30 项，却不会说明这一点。对于筛选范围，应筛选已保存的列表，而不是重新列出议题。然后用 gh issue view <n> --repo <owner/repo> --json number,title,body,labels,comments,author,createdAt,updatedAt,url 完整阅读每个议题。

3. 对于其他跟踪器，如果会话中有其 CLI 或连接工具，则使用该工具。否则，请用户导出或粘贴议题，并说明分类仅涵盖所提供的内容。

4. 对于较大的待办列表，将议题分组并分别交给新的子代理；每组一个，并提供此技能的参考资料，要求各子代理提供带有证据的表格行。你负责合并各行、进行跨议题的重复项比对，并最终整理出表格。

3. 收集证据

对于每个问题，按照 references/triage-rules.md › 每个问题的证据，收集相关证据：信息是否完整、在成本较低时为 Bug 快速复现、是否已实现，以及此前是否被否决。

4. 检查重复项

对于每个问题，包括已关闭的问题，按照 references/triage-rules.md › 重复项搜索执行重复项搜索。也要相互比较开放问题。在表格的最后一列记录你执行的搜索。

5. 分类并提出建议

按照 references/triage-rules.md，为每个问题指定一个类别、一项建议（now、next 或 defer）、一个路由，以及一行附有证据的理由。根据价值、成本和影响排序，将最多达到步骤 1 中批次大小的事项列为 now。需要先编写规格或进行诊断的问题列为 next，并指定相应路由。

6. 呈现表格

严格按照 references/triage-rules.md › 分类表格中的定义，展示分类表格，随后列出总数和无法完整分类的问题。当用户提出要求时，将表格保存到指定文件，以便后续交付工作流读取。起草跟踪器更新前，请用户更正表格中的任何行。

7. 起草跟踪器更新

当用户希望起草更新时（步骤 1，问题 3），按照 references/drafting.md 起草评论和标签更改，检查每份草稿，并将它们放在一个编号列表中供用户审批。然后等待。

8. 发布已批准的内容

严格按照 references/drafting.md › 发布中的命令，只发布用户批准的内容。逐一回读每个问题，并报告更改内容及失败情况。

9. 交接

按以下顺序报告：

1. 用一行说明目标和结果：已分类的问题数量，以及列为 now、next、defer 或建议关闭的问题数量。
2. 分类表格或其路径。
3. 已发布的内容，以及已起草但未获批准的内容。
4. 各路由的下一步，交由用户选择：
   • now 行：针对当前主机的 mstack 审查工作流（在 Claude Code 中使用 mstack-codex-review-workflow，在 Codex 中使用 mstack-claude-review-workflow），并将表格作为工作项；
   • 路由至 mstack-write-specs 的行：每个问题编写一份规格，从该问题开始；
   • 路由至 mstack-diagnose 的行：每个 Bug 编写一份诊断，从该行列出的缺失信息开始。

然后停止。除非用户要求，否则不要启动任何工作流。