triage

分类处理

通过一组小型分类处理角色构成的状态机，推进项目问题跟踪器中的问题。

如果此仓库将外部拉取请求视为请求入口（参见问题跟踪器配置），分类处理也涵盖这些请求：PR 是附带代码的问题——使用相同的角色、状态和状态机，下面标注“适用于 PR”的部分除外。根据跟踪器配置，将裸 #42 解析为问题或 PR。

在分类处理期间发布到问题跟踪器的每条评论或问题都必须以此免责声明开头：

> *This was generated by AI during triage.*

参考文档

• AGENT-BRIEF.md — 如何编写持久有效的 Agent 简报
• OUT-OF-SCOPE.md — .out-of-scope/ 知识库的运作方式

角色

两种类别角色：

• bug — 某些功能无法正常工作
• enhancement — 新功能或改进

五种状态角色：

• needs-triage — 维护者需要评估
• needs-info — 等待报告者提供更多信息
• ready-for-agent — 规格完整，适合 AFK Agent 处理
• ready-for-human — 需要人工实现
• wontfix — 不会处理

对于 PR，按附带的代码来理解相同的状态：ready-for-agent 表示已附上简报，Agent 应对差异采取下一步行动；ready-for-human 表示已准备好由人工合并。

每个经过分类处理的问题都应恰好有一个类别角色和一个状态角色。如果状态角色相互冲突，请标记出来，并先询问维护者再采取任何其他行动。

这些是规范角色名称——问题跟踪器中实际使用的标签字符串可能不同。映射应已提供给你；如果没有，请运行 /setup-utarn-skills。

状态转换：未加标签的问题通常先进入 needs-triage；之后可转为 needs-info、ready-for-agent、ready-for-human 或 wontfix。报告者回复后，needs-info 会回到 needs-triage。维护者可随时覆盖状态——遇到看起来不寻常的状态转换时，请标记出来并在继续前询问。

调用方式

维护者调用 /triage，并用自然语言描述他们的需求。理解请求并采取行动。示例：

• “显示所有需要我关注的内容”
• “我们看看 #42”（问题或 PR）
• “将 #42 移至 ready-for-agent”
• “有哪些内容已准备好由 Agent 接手？”

显示需要关注的内容

查询问题跟踪器，并按时间从早到晚列出三个类别：

1. 未加标签 — 从未经过分类处理。
2. needs-triage — 正在评估。
3. needs-info 中自上次分类处理备注后有报告者活动的项目 — 需要重新评估。

当 PR 属于处理范围时，将外部 PR 也纳入这些类别，并在每行标注 [PR] 或 [issue]。发现阶段只筛选外部 PR（跟踪器配置定义了哪些 PR 属于外部 PR）——协作者尚在进行中的 PR 不属于分类处理工作。此筛选仅适用于发现阶段；明确指定的 PR 无论作者是谁，都始终进行分类处理。

显示数量，并为每个项目提供一行摘要。让维护者选择。

对特定 Issue 或 PR 进行分诊

1. 收集背景信息。 阅读完整的 Issue 或 PR（正文、评论、标签、作者、日期；如果是 PR，还要查看差异）。解析之前的分诊记录，避免重新询问已解决的问题。使用项目的领域术语表探索代码库，并遵循相关区域的 ADR。针对代码库进行两项检查：(a) 冗余——按领域概念（而不仅是请求中的措辞）搜索是否已有所请求行为的实现，并报告你查找了哪些位置。如果找到了，这就是已实现的 wontfix（第 5 步）。(b) 此前的拒绝——阅读 .out-of-scope/*.md，并指出与此请求类似的条目。

2. 提出建议。 告知维护者你的分类和状态建议，并说明理由；同时简要概述与请求相关的代码库情况，包括该功能是否已实现。等待指示。

3. 验证声明。 在追问之前，先检查该声明是否成立。对于 Bug，根据报告者的步骤复现问题。对于 PR，确认差异确实实现了其声称的内容——检出代码并运行相关测试或命令。报告结果：已确认（附代码路径）、未能复现，或细节不足（这是有力的 needs-info 信号）。验证确认后，Agent 简报会有力得多。

4. 追问（如有需要）。 如果请求需要进一步明确，同时运行 /grilling 和 /domain-modeling 技能——每轮提出一组问题，逐步完善请求、明确领域术语，并随着决策敲定而同步更新 CONTEXT.md/ADR。

5. 执行处理结果：

   • ready-for-agent — 发布 Agent 简报评论（AGENT-BRIEF.md）。
   • ready-for-human — 使用与 Agent 简报相同的结构，但说明为何无法委派（需要判断、外部访问、设计决策或手动测试）。
   • needs-info — 发布分诊记录（模板见下文）。
   • wontfix — 关闭，并根据原因发布相应评论：
     • 已实现 — 代码库中已经存在该变更。指出其所在位置；不要写入 .out-of-scope/（该知识库用于记录已拒绝的请求，而非已实现的功能）。
     • 拒绝（Bug） — 礼貌说明原因，然后关闭。
     • 拒绝（增强功能） — 写入 .out-of-scope/，在评论中链接到该文件，然后关闭（OUT-OF-SCOPE.md）。
   • needs-triage — 应用该角色。如有部分进展，可选择发表评论。

快速状态覆盖

如果维护者说“将 #42 移到 ready-for-agent”，就相信他们并直接应用该角色。确认即将执行的操作（变更角色、评论、关闭），然后执行。跳过追问。如果在未进行追问的情况下移到 ready-for-agent，请询问他们是否要编写 Agent 简报。

需要补充信息模板

## Triage Notes

**What we've established so far:**

- point 1
- point 2

**What we still need from you (@reporter):**

- question 1
- question 2

将追问过程中已解决的所有内容记录在“目前已确认”下，避免工作成果丢失。问题必须具体且可执行，不能只是“请提供更多信息”。

恢复之前的会话

如果 Issue 或 PR 中存在之前的分诊记录，请阅读记录，检查报告者是否已回答任何未解决的问题，并在继续之前提供最新情况。不要重新询问已解决的问题。