GitHub Issue Triage

用于处理 GitHub issue 链接，并在结合当前仓库代码后给出执行路径。

触发时机

• 用户提供 GitHub issue URL，并希望你分析内容后继续行动
• 需要先读取 issue 创建者信息、附件或图片，再决定如何推进
• 需要判断是先讨论研究、直接修复，还是先制定方案

输入

• 必填：GitHub issue URL，例如 https://github.com/<owner>/<repo>/issues/<id>
• 可选：用户额外上下文（复现步骤、期望行为、优先级）

执行流程

1. 读取 issue 内容

   • 获取标题、正文、标签、状态、创建者、创建时间
   • 提取创建者在 issue 中提供的关键信息（正文 + 创建者本人评论）
   • 区分“创建者信息”与“其他参与者讨论”

2. 收集附件与图片（限制 10MB）

   • 从 issue 正文和创建者评论中提取附件/图片链接
   • 对每个链接获取文件大小与类型，只有 <= 10MB 才下载
   • 优先下载图片（png/jpg/jpeg/webp/gif）与问题复现相关附件
   • 记录已下载与跳过原因（超限、类型不符、不可访问）

3. 结合代码库研判

   • 先做高层语义检索定位相关模块，再做符号/关键字精查
   • 找到与 issue 直接相关的代码路径、入口点、可能影响范围
   • 判断是否已有类似问题处理逻辑、开关、兜底或已知限制

4. 路径决策

   • 讨论研究问题：信息不足、无法稳定复现、需求存在歧义、外部依赖阻塞
   • 直接修复问题：根因清晰、改动范围可控、验收标准明确
   • 计划方案：涉及跨模块改造、兼容性权衡、需要分阶段实施

5. 执行动作

   • 若“直接修复问题”：直接修改代码并完成必要验证
   • 若“计划方案”：输出分步计划、影响面、风险与验证策略
   • 若“讨论研究问题”：给出需要补充的信息与建议实验步骤

输出格式

• Issue 摘要：标题、创建者、关键诉求、复现线索
• 创建者信息提炼：仅保留创建者提供的有效信息
• 附件处理结果：下载清单（<=10MB）与跳过清单（含原因）
• 代码关联分析：相关模块、关键函数、潜在根因
• 决策结论：讨论研究 / 直接修复 / 计划方案
• 下一步：立即执行项

质量要求

• 必须优先依据创建者提供的信息，不被无关评论干扰
• 必须在代码层面给出证据，不做纯主观结论
• 决策应可执行，并且与当前仓库结构一致