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 — 规格完整，可交给非活跃状态的 Agent 处理
• ready-for-human — 需要由人来实现
• wontfix — 不会处理

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

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

这些是规范角色名称——问题跟踪器中实际使用的标签字符串可能不同。相应的映射应该已提供给你；如果没有，请运行 /setup-leandrocfe-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 中存在之前的分诊记录，请阅读记录，检查报告者是否已回答任何未解决的问题，并在继续之前提供最新情况。不要重新询问已解决的问题。