antfu-issue-triage

问题分类

检查当前仓库（gh repo view --json nameWithOwner）中的开放问题和 PR，并提出清理操作。由维护者决定；Agent 负责调查。

硬性规则

• 确认前只读。 用户批准操作表之前，绝不评论、添加标签、关闭或编辑。可以读取（gh issue view、gh api GET、gh search）。
• 每条评论都要说明由 Agent 自动生成。 在最后单独一行结尾（前面空一行）：🤖 *Automated by an agent.*
• 评论简短直白。 使用简单英语（如果有 simple-english 技能，则使用）：1-3 个短句，使用主动语态，不用行话，不说废话。针对每个条目单独撰写评论，不要重复使用固定模板。始终附上能够证明该操作合理的链接（PR、提交、发布版本或规范问题）。
• 只执行已批准的行。如果用户编辑或删除了某些行，严格按其修改执行。
• 保守处理：不确定时，建议 keep open（必要时添加标签），而不是关闭。除非用户提出要求，否则不要关闭有活跃维护者讨论、开放的关联 PR 或里程碑的条目。
• 使用普通连字符；不要使用 em dash 或 en dash。

工作流

1. 确定范围。 确认仓库和范围（默认：所有未关闭的条目；对于大型仓库，请询问是否限定数量、标签或时间范围）。批量获取：

   gh issue list --state open --limit 200 --json number,title,body,author,labels,createdAt,updatedAt,comments,reactionGroups,url,milestone
   gh pr list --state open --limit 200 --json number,title,body,author,labels,isDraft,reviewDecision,closingIssuesReferences,url,reactionGroups
   gh label list --limit 200 --json name,description
   

2. 了解标签。 阅读每个标签的名称和说明。仅应用已存在的标签。新标签（包括缺失时的 spam）应列入“标签”表，并且只有在获得批准后才能创建。查看维护者如何为类似条目添加标签（gh issue list --state all --label <l>）。将仓库的标签与下文“推荐标签”部分进行比较，并记录缺少的实用标签。
3. 映射引用。 从正文、评论和时间线中收集交叉引用（gh api repos/{owner}/{repo}/issues/{n}/timeline --paginate）：#123、URL、closes/fixes、关联的 PR、跨仓库链接。将关联条目视为一个整体。修复 PR 仍处于打开状态时，不要关闭对应问题。不要将相互关联的条目标记为彼此的重复项。
4. 检查每个条目：
   • 已修复/已实现。 搜索已合并的 PR 和提交（gh pr list --state merged --search "<keywords>"、git log -i --grep）、变更日志、文档和当前代码。找出包含修复的首个版本（git tag --contains <sha> --sort=version:refname | head -1）。在代码中核实，而不只是看标题。部分修复不算已修复：保持条目打开。
   • 重复项。 按症状或请求归类，而不是按措辞。使用有辨识度的文本搜索已打开和已关闭的问题（gh issue list --state all --search "<text>"）。选择一个主条目：关联 PR > 维护者回复 > 最佳复现步骤 > 最多反应 > 最早发布。将其余条目关闭并关联到主条目。
   • 垃圾内容。 需要有两个或更多强烈迹象：推广/SEO/加密货币链接、无关文本、重复发布相同内容、正文为空但含链接、新账号大量活动。拼写错误、简短文本、使用错误模板或非英语内容都不算垃圾内容。
   • 标签。 为未添加标签或标签不当的条目推荐现有标签。
   • 容易完成的事项。 维护者可以快速完成的条目：已获批准或 CI 通过且已准备就绪的 PR、改动明确的小型 PR、拼写或文档修复、复现清晰且修复简单的 bug，以及范围小且定义明确的请求。说明每项为何可以快速完成，并建议为其添加 low hanging fruit 标签。跳过受阻、含糊不清或工作量大的条目。
   • 需求度。 统计正向反应（👍 ❤️ 🎉 🚀）、负向反应、不同评论者人数、“+1”评论和合并处理的重复项。结合仓库规模评为 High / Medium / Low，并列出原始数据。旧条目近期仍有活动，说明它仍然受到关注。
5. 按下列表格提出计划，然后暂停并请求确认。本轮不要运行任何写入命令。
6. **仅执行获批的行，**一次一项：先评论，再添加标签，最后关闭。遇到首个 API 错误时停止并报告。结束时提供含链接的已完成/失败表格。
   • 每条命令只处理一个问题（针对该问题的评论、添加标签和关闭操作用 && 串联）。不要在脚本或循环中批量处理多个问题：批量写入命令可能会被权限分类器拦截。如果命令被拦截，不要尝试绕过。将命令拆分为逐条处理每个问题，并告知用户。
   • 先在单独的命令中创建获批的新标签。
   • 对于用户在表格之后新增的条目（例如“也关闭 #4”），按相同风格写一条简短的新评论，并在最终报告中展示。

推荐标签

通用标签。优先映射到仓库中已有的标签（含义相同、名称不同）。绝不重命名或删除已有标签。

分组	标签	含义
类型	bug、enhancement、documentation、regression	条目的类型。regression：仅在新版本发布后出现。
分类状态	pending triage、needs reproduction	条目当前卡在哪个环节。
处理结果	duplicate、invalid、wontfix、spam	关闭条目的原因。
优先级	p1-chore、p2-nice-to-have、p2-edge-case、p3-minor-bug、p3-significant、p4-important、p5-urgent	条目的重要程度。说明：p5 会影响大多数用户，需要立即发布修复；p4 会破坏文档中说明的行为；p3 属于边缘情况或高优先级增强；p2 是锦上添花或有变通方法；p1 不会改变任何行为。
贡献	low hanging fruit	维护者可以快速完成。
背景	has workaround、bug: upstream、<platform> only（例如 windows only）	有助于后续读者了解情况的额外信息。
区域	feat: <area>（仓库的每个主要模块一个）	涉及代码的哪个部分。根据仓库目录、文档和过往问题确定区域。
机器人	bot: maybe、bot: likely	疑似来自机器人或 LLM 的内容，但还不足以认定为垃圾信息。

规则：

• 确保每个标签都填写了说明。如果已有标签没有说明，且其含义明确，请建议补充说明。
• 仅建议有助于本仓库问题分类的标签：处理已发现条目所需的标签，或填补明显缺失的标签（例如，许多问题都缺少复现步骤，却没有 needs reproduction 标签）。不要建议整个列表中的所有标签。
• 优先选择少量有实际问题集群作为依据的 feat: <area> 标签，而不是大量推测性标签。
• 创建标签属于写入操作。请在 Labels 表格中将其列为 (new label) 行，并注明名称、颜色（与仓库配色方案一致）、说明和适用条目。仅在获得批准后创建（gh label create <name> --description "..." --color <hex>），并在应用到条目之前创建。

评论

简短、友好且具体。以下是语气示例（请勿照抄）。每条评论最后一行都应是通知：

• 已修复：

  This was fixed in #456, released in v1.2.0. Please upgrade to get it. If it still happens, comment with a repro and we will reopen.
  
  🤖 *Automated by an agent.*
  

• 重复项：

  This is a duplicate of #123. Please follow that issue. Tell us if it is different and we will reopen.
  
  🤖 *Automated by an agent.*
  

• 垃圾信息：

  Detected as a spam. Sorry if this was a mistake. Let us know and a maintainer can bring it back.
  
  🤖 *Automated by an agent.*
  

各类型的规则：

• 已修复： 链接到 PR 或提交，并说明如何处理（升级、启用某个选项或使用某个 API）。关闭为已完成。
• 重复项： 指明规范问题，并邀请作者在情况不同时重新打开。关闭为 not planned。
• 垃圾信息： 添加 spam 标签。说明该内容被检测为垃圾信息，不要解释原因。如果判断有误，请致歉，并说明可以恢复该条目。将判断依据写在表格中，而不是评论里。关闭为 not planned。

操作表

三张表，行号供用户回复“应用 1-5，跳过 3”。在表格中显示完整评论文本。

1. 关闭

#	条目	原因	链接（修复 / 规范链接）	评论

Reason 为 fixed、duplicate 或 spam。标记为垃圾信息的行还要添加 spam 标签，相关理由应保留在此表中，而不是写在评论里。

2. 标签

#	条目	添加	原因

low hanging fruit 条目也放在这里。对于仓库中尚不存在的标签，添加一行，条目写 (new label)，并填写标签名称、描述、颜色以及将使用该标签的条目。获批的新标签会先创建（gh label create），然后再应用。

3. 需要关注（不执行写入操作）

#	条目	需求	反应 / 评论	备注

将最值得优先检查的条目放在顶部，并按重要性排序：需求量高、回归问题或会导致构建失败的错误、安全报告、涉及安全或等待时间较长的 PR，以及存在活跃但尚未答复讨论的条目。在“备注”中说明原因。low hanging fruit 条目也放在这里，排在上述条目之后，并说明处理为何快捷。

除非收到要求，否则不要仅因 PR 过期而将其关闭；应改为添加标签或标记。