AI 驱动的 GitHub Issues 自动修复系统，支持并行子代理生成 PR、处理代码审查，适合维护者批量处理 issue backlog。
说明：
## 核心用法
`gh-issues` 是一个全自动的 GitHub 问题修复编排器，采用”主代理分发任务 → 子代理并行执行”的架构。用户通过 `/gh-issues owner/repo` 触发后，系统执行六阶段流水线：参数解析、Issue 抓取、用户确认、前置检查、子代理并行修复、PR 审查处理。
**关键特性**：
– **智能过滤**：支持按 label、milestone、assignee 筛选，自动排除已存在 PR 的 issue
– **Fork 模式**：可在个人 fork 上工作，PR 指向上游仓库，适合外部贡献者
– **Cron 模式**：后台定时轮询，单 issue 顺序处理，适合长期无人值守运行
– **Watch 模式**：持续监控新 issue 和 PR 审查评论，自动响应
– **审查处理器**：自动识别 “changes requested”、行内评论、Greptile 等嵌入审查，生成修复提交
**执行流程**：主代理仅做编排，实际代码分析、修复、测试、提交流水线由独立的子代理完成，每个子代理有 60 分钟超时和独立 transcript。
## 显著优点
1. **并行效率**：最多 8 个子代理并发，批量处理积压 issue
2. **零 CLI 依赖**：纯 curl + GitHub REST API 实现，避免 gh CLI 安装问题
3. **防重复机制**：三层去重（PR 存在检查、分支存在检查、2 小时 claim 过期机制）
4. **审查闭环**：不仅开 PR，还能持续监控并自动处理 review comments
5. **通知集成**：支持 Telegram 渠道推送处理结果
## 潜在局限与风险
– **代码质量不可控**：子代理可能生成不符合项目规范的修复，依赖 confidence check（<7 分自动放弃）但仍有误判
– **测试覆盖盲区**：子代理尝试运行测试套件，但复杂项目的环境依赖可能无法正确识别
– **审查理解局限**：对模糊评论（"代码可以更好"）可能过度解读或忽略，仅处理明确指令型反馈
– **Token 泄露风险**：需配置 GH_TOKEN，虽有配置隔离但仍属高权限凭证
– **长时间运行风险**：watch/cron 模式可能产生大量分支和 PR，需人工定期清理
## 适合人群
– 开源项目维护者处理积压的 `good-first-issue`/`bug` 标签 issue
– 需要批量生成修复 PR 的安全研究团队
– 希望自动化处理标准化 issue（文档错误、简单 null pointer 修复）的开发者
## 常规风险
– 子代理可能推送未经充分测试的代码
– 自动回复审查评论可能被误认为 spam
– 复杂架构 issue 可能导致子代理超时或生成半成品 PR
– Fork 模式配置错误时可能推送到错误仓库
会员专属
