| 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.*
参考文档
标签
| 标签 | 类型 | 描述 |
|---|
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 进行分类时:
- 阅读所有评论以查找先前的分类注释
- 解析已经确立的内容
- 检查报告者是否已回答任何未解决的问题
- 向维护者呈现更新的图景: "这是我们停止的地方, 这是报告者自那以后说的内容"
- 从它停止的地方继续 /domain-model 会话 -- 不要重新问已解决的问题
