gh-issues

核心用法

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

核心用法

gh-issues 是一个 GitHub 问题自动化处理 Skill，支持完整的 Issue-to-PR 工作流：

基础命令结构：

/gh-issues [owner/repo] [flags]

关键功能场景：
1. 单次处理：/gh-issues myorg/repo --label bug --limit 5 — 抓取 5 个 bug 标签 issue，派生子代理修复并提 PR
2. Fork 模式：/gh-issues upstream/repo --fork myuser/repo — 从上游拉 issue，推到自己 fork 提 PR
3. 守护模式：/gh-issues --watch --interval 10 — 持续轮询新 issue 和 PR review 评论
4. 仅处理 Review：/gh-issues --reviews-only — 跳过 issue 修复，只检查并响应 PR 评论
5. 定时任务：/gh-issues --cron — 无阻塞模式，单 issue 顺序处理，适合 CI/CD

参数亮点：

• --label, --milestone, --assignee 精准过滤
• --model glm-5 指定子代理模型
• --notify-channel -100xxxx 结果推送 Telegram
• --dry-run 预览不执行
• --yes 全自动确认

显著优点

1. 完整闭环：Issue → 分析 → 修复 → 测试 → Commit → Push → PR → Review 响应，全链路自动化
2. 智能防重：三层去重机制 — 检查已有 PR、检查远端分支、基于时间的 claims 文件，避免重复处理
3. Fork 友好：支持从上游仓库读 issue，推到自己 fork，再提 PR 回上游，符合开源贡献规范
4. 并发控制：正常模式 8 并发子代理；Cron 模式单任务串行，兼顾效率与资源
5. Review 智能解析：区分 "LGTM" 等无效评论与 actionable feedback，支持 Greptile 等嵌入式评论解析
6. 安全设计：仅使用 curl + GitHub REST API，不依赖 gh CLI；Token 多源读取带优先级；无敏感信息硬编码

潜在缺点与局限性

1. Token 权限要求高：需要 repo 完整权限以创建分支、推送代码、提 PR，误配置可能导致非预期写操作
2. 子代理质量依赖：复杂 issue 可能因理解偏差导致错误修复；虽然设置了置信度检查（<7 分跳过），但仍有误判风险
3. 测试覆盖有限：依赖子代理自动发现测试命令，对非标准项目结构（如无 package.json/Makefile）可能测试失败
4. Review 处理局限：目前仅支持代码级 comment 响应，无法处理设计层面的分歧或需要人工决策的冲突
5. Watch 模式状态持久化：claims/cursor 文件依赖本地磁盘，多实例部署时需自行协调
6. 仅支持 GitHub：GitLab、Gitee 等平台需适配

适合人群

• 开源项目维护者：批量处理 good-first-issue、依赖更新类 issue
• 中小型团队：缺乏专职 QA，需要自动化回归 bug 修复
• 个人开发者：维护自己的多仓库，减少重复劳动
• CI/CD 集成：配合 --cron 实现定时巡检和自动修复

常规风险

| 风险项 | 等级 | 说明 |

|--------|------|------|

| Token 泄露 | 中 | GH_TOKEN 需妥善保管，Skill 仅从环境变量/配置文件读取，不传输到子代理日志外 |

| 误删代码 | 低 | 子 agent 强制 `cleanup: keep` 保留分支，且要求最小化修改，可人工复核 |

| 循环触发 | 低 | Watch 模式有 PROCESSED_ISSUES 集合，PR 处理有 comment ID 去重，避免循环 |

| API 限流 | 低 | 高频轮询可能触发 GitHub rate limit，建议合理设置 `--interval` |

| 恶意 Issue 利用 | 极低 | 通过 label/milestone 过滤可降低风险；置信度检查拒绝模糊指令