gh-issues

• 你有一批范围明确的 bug issue 积压，希望在人工审查之前先进行自动化修复尝试。
• 你运行定时 CI/cron 流水线，希望 issue 能自动完成分类并提交 PR，无需人工干预（--cron 模式）。
• 你采用基于 fork 的贡献模式，需要将分支推送到你的 fork，并以上游仓库为目标创建 PR（--fork）。
• 你希望自动处理 PR 审查评论 — 使用 --reviews-only 让 gh-issues 扫描已开启的 fix/issue-* PR，并针对所请求的更改推送修复。

• 问题描述模糊、涉及架构设计或范围过大 — 该技能的子智能体会进行自信度自评，并跳过评分低于 7/10 的问题，但高度复杂的问题应手动处理。
• 您需要保证正确性 — 子智能体在可用时会运行测试，但自动生成的修复方案在合并到生产环境之前应经过人工审查。
• 您没有 GitHub 令牌（GH_TOKEN） — 没有该令牌，gh-issues 技能将无法对任何 GitHub API 进行身份验证。

最多 8 个子代理并发运行，每个子代理端到端处理单个问题：创建分支、分析代码、实施修复、执行测试、提交、推送以及开启 PR。每个代理拥有 60 分钟的时间预算，并内置置信度检查——若无法以 ≥7/10 的置信度处理某个问题，则自动跳过。

在 PR 开启后，Phase 6 会获取审查意见、内联评论、一般性 PR 评论，甚至包括嵌入式机器人审查（例如 Greptile）。对于需要执行操作的评论，系统会触发额外的子代理，自动检出分支、应用所请求的更改、推送更新，并以提交 SHA 回复每条评论。

传递 --fork user/repo 参数，可将所有分支推送到你的 fork 仓库，并从该 fork 向上游源仓库发起 PR —— 完全匹配标准的开源贡献工作流，无需拥有上游仓库的写入权限。

--cron 启用即发即忘的调度方式：编排器选取一个符合条件的 issue，启动一个子代理，然后立即退出——可以安全地每隔几分钟从 cron 任务中调用。--watch 使编排器保持运行，以可配置的时间间隔轮询新 issue 和审查评论。

在生成子智能体之前，该技能会检查以下内容：现有的已开启 PR、推送仓库中正在进行的分支，以及本地的认领文件（有效期为 2 小时）。这可以防止在重叠的定时任务或监听周期中，多个重复的子智能体争相处理同一个议题。

传入 --notify-channel 参数并附上 Telegram 频道 ID，即可接收包含 PR 链接和每个问题处理结果的最终摘要消息。系统仅发送最终结果，而不会发送中间状态更新。

从定时任务中运行 /gh-issues owner/repo --label bug --limit 10 --cron。每次调用会选取下一个未认领的缺陷 issue，生成一个子代理来实现修复，然后退出。随着时间推移，积压的问题会在无需人工干预的情况下逐步得到处理。

使用 /gh-issues upstream/project --fork myfork/project --label good-first-issue，让该技能从上游仓库获取 issue，将修复分支推送到你的 fork，并向上游开启 PR——完整遵循标准贡献者工作流。

将 /gh-issues owner/repo --reviews-only --cron 与您现有的 PR 流水线一起定时调度。每次运行时，系统会扫描所有开放的 fix/issue-* PR，查找尚未处理的 CHANGES_REQUESTED 审查或内联评论，选取第一个未处理的 PR，并启动一个 Agent 来应用所请求的更改并进行回复。

在冲刺计划会议期间运行 /gh-issues owner/repo --label enhancement --watch --interval 10。该技能会获取问题列表，询问您确认要处理哪些问题，启动代理程序，并每隔 10 分钟轮询一次新问题和审查反馈——持续呈现累积结果，直到您说"停止"为止。