核心用法
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 模式配置错误时可能推送到错误仓库