triage

分类处理

让问题和外部 PR 在分类处理角色的状态机中流转，进行分类、验证，必要时深入追问，并编写适合 Agent 使用的简报。当问题或外部 PR 需要分类、验证并整理成适合 Agent 使用的简报时使用。触发词：分类处理、分类处理待办列表、审查这些问题。

此技能从 mattpocock/skills（MIT）导入，上游为用户主动调用。

何时使用此技能

• 让问题和外部 PR 在分类处理角色的状态机中流转，进行分类、验证，必要时深入追问，并编写适合 Agent 使用的简报。
• 当问题或外部 PR 需要分类、验证并整理成适合 Agent 使用的简报时使用。
• 触发词：分类处理、分类处理待办列表、审查这些问题。

说明

分类处理

让项目问题跟踪器上的问题在一个由少量分类处理角色组成的状态机中流转。

如果此仓库将外部拉取请求视为一种请求来源（见问题跟踪器配置），分类处理也涵盖这些请求：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-matt-pocock-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 无论作者是谁，都必须进行分类处理。

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

对特定 Issue 或 PR 进行分诊

1. 收集上下文。 阅读完整的 Issue 或 PR（正文、评论、标签、作者、日期；如果是 PR，还要查看差异）。解析之前的分诊记录，避免重复询问已解决的问题。使用项目的领域术语表探索代码库，并遵循相关领域的 ADR。针对代码库执行两项检查：（a）冗余检查：按领域概念（而不只是请求中的措辞）搜索是否已有请求行为的实现，并报告搜索范围。如果找到了，则视为已实现的 wontfix（第 5 步）。（b）此前的拒绝记录：阅读 .out-of-scope/*.md，并指出其中与此请求相似的记录。

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

3. 验证问题陈述。 在详细追问之前，先检查问题陈述是否成立。对于 Bug，根据报告者提供的步骤复现。对于 PR，确认差异确实实现了其声称的功能：检出代码并运行相关测试或命令。报告结果：已确认（包括代码路径）、验证失败，或信息不足（这是强烈的 needs-info 信号）。经过确认的验证结果会让 Agent 任务说明更有力。

4. 详细追问（如有需要）。 调用 Skill 工具两次，分别用于 "grilling" 和 "domain-modeling"，每轮提出一组问题，逐步完善请求、明确领域术语，并在决策确定后同步更新 CONTEXT.md/ADR。

5. 应用处理结果：

   • ready-for-agent：发布 Agent 任务说明评论（AGENT-BRIEF.md）。
   • ready-for-human：采用与 Agent 任务说明相同的结构，但说明为何无法委派（需要判断、外部访问、设计决策或手动测试）。
   • needs-info：发布分诊记录（见下方模板）。
   • 对于 wontfix，关闭 Issue，并根据原因发布相应评论：
     • 已实现：代码库中已有此更改。指出实现位置；不要写入 .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 上有之前的分诊记录，请阅读记录，检查报告者是否已回答任何未解决的问题，并在继续前说明最新情况。不要重复询问已解决的问题。

示例

• 先将此技能应用于一个较小的范围，确认输出符合上述格式，再扩展到完整任务。
• 如果某一步需要从代码库或环境中获取事实，应自行查证，而不是询问用户。

最佳实践

• 保持上游流程完整；如有偏离，应明确记录，不要默默变通。
• 在此技能标记为用户决策的每个节点，都应停下来交还控制权。
• 优先选择小而可撤销的更改，并明确说明假设，不要将其隐去。

参考资料

• 上游技能：mattpocock/skills skills/engineering/triage/SKILL.md（提交 3cca18b，MIT）
• 配套文档：references/AGENT-BRIEF.md
• 配套文档：references/OUT-OF-SCOPE.md
• 项目标准：.agent-skills/skill-standardization/SKILL.md
• 验证脚本：.agent-skills/skill-standardization/scripts/validate_skill.sh