GitHub 问题证据优先分类

解决什么问题

GitHub 问题的自动分类容易踩几个坑：只看标题就贴标签，结果把外部用户的吐槽当成产品缺陷；忽略正文证据，误把配置错误、使用不当归类为 bug；缺少重复检查，同一个问题被反复开帖、多次标注；标签操作不受约束，要么漏标关键类别，要么顺手改了 issue 状态、做超出分类范围的仓库管理。triage-issue 技能把这些动作拉回「问题分类」的窄路径，避免分类变成开放式仓库操作。

核心能力与关键步骤

• 主体优先的证据检查：先读 GitHub issue 的正文，而不是先盯标题或已有标签。正文中的复现步骤、错误日志、受影响组件、版本信息才是判断依据；技能会核对这些内容是否真的指向该产品或仓库范围，再决定是否进入分类流程。
• 检查附近重复：在贴标签前，查看仓库内近期的 issue，尤其是同模块、同错误信息、同组件的条目，判断当前问题是否是已有问题的重复或衍生，减少重复跟踪成本。
• 受限的标签操作：只应用仓库预定义的、允许范围内的标签；不新建标签，不发明临时分类，不把模糊问题塞进宽泛类别。
• 不漂移到仓库管理：分类动作止步于读证据、查重复、贴允许的标签；不会顺手关闭 issue、合并 PR、修改代码、补充评论或执行其他仓库维护操作。

适用边界与注意点

• 需要 Claude Code 运行环境，以及目标 GitHub 仓库的访问权限；仓库如果提供 gh wrapper 或标签脚本，技能会按其约定操作标签。
• 证据检查依赖 issue 正文的信息质量。如果用户只写「用不了」，正文没有版本、步骤或日志，分类结果可能只能落到最宽泛的类别，无法进一步细分。
• 标签集合由仓库定义，技能不会突破这个边界；如果当前允许标签覆盖不了问题类型，宁可少标，也不会临时造标签。