GitHub 陈旧问题清理

它解决什么问题

当仓库里的 issue 长期没有评论、更新或状态推进时，问题区会逐渐变成信息坟场：旧请求压着新缺陷，维护者很难判断哪些仍值得处理。这个技能面向的是 GitHub issue backlog 的周期性治理，而不是一次性批量删帖。它先识别超过 30 天未活动的 issue，再通过预警和人工确认控制清理节奏。

工作方式与关键步骤

核心流程可以拆成三个动作：

• 识别陈旧项：按“超过 30 天未活动”的规则扫描 issue。
• 生成候选清单：输出“可关闭候选清单”，供人工确认，而不是直接替人下结论。
• 降低误关风险：采用先评论预警、再关闭的路径，让关闭动作有可见痕迹。

长期运行时，建议先把数据源、刷新频率和输出格式固定下来，再逐步加入评分、告警或优先级判断。可以把它当作 stale 检测逻辑 + 执行提示词的自动化流程：一轮试跑用于验证规则，稳定版再按周运行。验收时至少确认原始链接、去重结果和最终摘要可追溯，并抽样核对结论。

适用边界与运行注意

它适合有明确 issue 管理责任的工程团队，尤其当积压规模已经影响响应质量时。正式接入账号、数据源或自动操作前，先确认权限边界；不要把未经验证的数据直接作为关闭决策。高风险动作默认应只生成建议或草稿，不直接执行。可观测性也需要跟上：保留运行日志、输入样例和最终输出，方便复盘与交付验收。