github-triage

name	github-triage
description	通过基于标签的状态机对 GitHub issues 进行分类. 当用户想要创建 issue, 对 issues 进行分类, 审查传入的 bug 或功能请求, 为 AFK agent 准备 issues, 管理 issue 工作流, 提到 "整理 issue" 或 "GitHub 分类" 时使用.

GitHub Issue 分类

使用基于标签的状态机对当前仓库中的 issues 进行分类. 从 git remote 推断仓库. 对所有 GitHub 操作使用 gh.

AI 免责声明

在分类期间发布到 GitHub 的每条评论或 issue 必须在评论正文顶部, 任何其他内容之前包含以下免责声明:

> *This was generated by AI during triage.*

参考文档

• AGENT-BRIEF.md — 如何编写持久的 agent 简报
• OUT-OF-SCOPE.md — .out-of-scope/ 知识库如何工作

标签

标签	类型	描述
bug	类别	某些东西坏了
enhancement	类别	新功能或改进
needs-triage	状态	维护者需要评估此 issue
needs-info	状态	等待报告者提供更多信息
ready-for-agent	状态	完全指定, 准备好供 AFK agent 处理
ready-for-human	状态	需要人工实现
wontfix	状态	将不会采取行动

每个 issue 应该恰好有一个状态标签和一个类别标签. 如果 issue 有冲突的状态标签(例如同时有 needs-triage 和 ready-for-agent), 在执行任何其他操作之前标记冲突并询问维护者哪个状态是正确的. 提供建议.

状态机

当前状态	可以转换到	谁触发它	发生什么
unlabeled	needs-triage	技能(首次查看)	Issue 需要维护者评估. 技能在提出建议后应用标签.
unlabeled	ready-for-agent	维护者(通过技能)	Issue 已经很好地指定且适合 agent. 技能写 agent 简报评论, 应用标签.
unlabeled	ready-for-human	维护者(通过技能)	Issue 需要人工实现. 技能写简要评论总结任务, 应用标签.
unlabeled	wontfix	维护者(通过技能)	Issue 是垃圾邮件, 重复或超出范围. 技能用评论关闭(并为 enhancements 写 .out-of-scope/).
needs-triage	needs-info	维护者(通过技能)	Issue 指定不足. 技能发布分类注释, 捕获到目前为止的进展 + 向报告者提出的问题.
needs-triage	ready-for-agent	维护者(通过技能)	质询会话完成, 适合 agent. 技能写 agent 简报评论, 应用标签.
needs-triage	ready-for-human	维护者(通过技能)	质询会话完成, 需要人工. 技能写简要评论总结任务, 应用标签.
needs-triage	wontfix	维护者(通过技能)	维护者决定不采取行动. 技能用评论关闭(并为 enhancements 写 .out-of-scope/).
needs-info	needs-triage	技能(检测到回复)	报告者已回复. 技能将其呈现给维护者以重新评估.

Issue 只能沿着这些转换移动. 维护者可以直接覆盖任何状态(见下面的快速状态覆盖), 但如果转换不寻常, 技能应该标记.

调用

维护者调用 /github-triage, 然后用自然语言描述他们想要什么. 技能解释请求并采取适当的行动.

示例请求:

• "给我看看有哪些需要我注意的内容"
• "我们来看看 #42"
• "把 #42 移到 ready-for-agent"
• "有哪些已经准备好让 agents 接手?"
• "有没有未标记的 issues?"

工作流程: 显示需要注意的内容

当维护者请求概览时, 查询 GitHub 并呈现分为三个桶的摘要:

1.** 未标记的 issues** — 新的, 完全没有标签. 这些从未被分类过. 2.** needs-triage issues** — 维护者需要评估或继续评估. 3.** 有新活动的 needs-info issues** — 报告者自上次分类注释评论以来已评论. 检查评论时间戳以确定这一点.

显示每组的计数. 在每组内, 显示最旧的 issues 优先(等待时间最长的获得优先关注). 对于每个 issue, 显示: 编号, 标题, 年龄和 issue 正文的单行摘要.

让维护者选择要深入哪个 issue.

工作流程: 对特定 Issue 进行分类

步骤 1: 收集上下文

在向维护者呈现任何内容之前:

• 阅读完整的 issue: 正文, 所有评论, 所有标签, 谁报告的, 什么时候
• 如果有先前的分类注释评论(来自以前的会话), 解析它们以了解已经确立的内容
• 探索代码库以建立上下文 -- 了解与 issue 相关的领域, 相关接口和现有行为
• 阅读 .out-of-scope/*.md 文件并检查此 issue 是否匹配或类似于先前拒绝的概念

步骤 2: 呈现建议

告诉维护者:

• *类别建议: * bug 或 enhancement, 附带推理
• *状态建议: * 此 issue 应该去哪里, 附带推理
• 如果它匹配先前的超出范围拒绝, 浮出那个: "这类似于 .out-of-scope/concept-name.md — 我们之前拒绝了这个, 因为 X. 你仍然有同样的感觉吗? "
• 你在代码库中发现的相关内容的简要摘要

然后等待维护者的指示. 他们可能:

• 同意并要求你应用标签 → 执行
• 想要充实它 → 开始 /domain-model 会话
• 用不同的状态覆盖 → 应用他们的选择
• 想要讨论 → 进行对话

步骤 3: Bug 重现(仅限 bugs)

如果 issue 被归类为 bug, 在开始 /domain-model 会话之前尝试重现它. 这将根据代码库而有所不同, 但尽你最大努力:

• 阅读报告者的重现步骤(如果提供)
• 探索代码库以了解相关代码路径
• 尝试重现 bug: 运行测试, 执行命令或跟踪逻辑以确认报告的行为
• 如果重现成功, 向维护者报告你发现的内容 -- 包括你观察到的特定行为以及它在代码中的起源位置
• 如果重现失败, 也报告 -- bug 可能是环境特定的, 已经修复或报告可能不准确
• 如果报告缺乏足够的细节来尝试重现, 注明 -- 这是 issue 应该转到 needs-info 的强烈信号

重现尝试为 /domain-model 会话和 agent 简报提供信息. 已确认的重现与已知的代码路径使简报更强大.

步骤 4: /domain-model 会话(如果需要)

如果 issue 在准备好供 agent 处理之前需要充实, 请访谈维护者以建立完整的规格. 使用 /domain-model 技能.

步骤 5: 应用结果

根据结果:

• ready-for-agent — 发布 agent 简报评论(见 AGENT-BRIEF.md)
• ready-for-human — 发布评论总结任务, 分类期间确立的内容以及为什么需要人工实现. 使用与 agent 简报相同的结构, 但注明它不能委托给 agent 的原因(例如需要判断, 外部系统访问, 设计决策或手动测试).
• needs-info — 发布分类注释, 包含到目前为止的进展和向报告者提出的问题(见下面的需要信息输出)
• wontfix (bug) — 发布礼貌评论解释原因, 然后关闭 issue
• wontfix (enhancement) — 写入 .out-of-scope/, 发布链接到它的评论, 然后关闭 issue(见 OUT-OF-SCOPE.md)
• needs-triage — 应用标签. 如果有部分进展需要捕获, 可选择留下评论.

工作流程: 快速状态覆盖

当维护者明确告诉你将 issue 移动到特定状态时(例如 "move #42 to ready-for-agent"), 信任他们的判断并直接应用标签.

仍然显示你将要做什么的确认: 将添加/删除哪些标签, 以及你是否会发布评论或关闭 issue. 但完全跳过 /domain-model 会话.

如果在没有 /domain-model 会话的情况下移动到 ready-for-agent, 询问维护者是否想要写简要的 agent 简报评论或跳过它.

需要信息输出

将 issue 移动到 needs-info 时, 发布捕获访谈进展并告诉报告者需要什么的评论:

## 分类备注

**到目前为止我们已经确认的内容:* *

- point 1
- point 2

**我们仍然需要你(@reporter)提供的内容:* *

- question 1
- question 2

在"到目前为止我们已经确认的内容"中包含在 /domain-model 会话期间解决的所有内容 -- 这项工作不应该丢失. 向报告者提出的问题应该是具体和可操作的, 而不是模糊的("请提供更多信息").

恢复先前的会话

对已经有来自先前会话的分类注释的 issue 进行分类时:

1. 阅读所有评论以查找先前的分类注释
2. 解析已经确立的内容
3. 检查报告者是否已回答任何未解决的问题
4. 向维护者呈现更新的图景: "这是我们停止的地方, 这是报告者自那以后说的内容"
5. 从它停止的地方继续 /domain-model 会话 -- 不要重新问已解决的问题