用途 resolve-issues-cx 是一个自动化 Issue 处理工作流，针对项目 GitHub 仓库中所有开放的 Issue 进行抓取、分类、分析与处理。它强调先报告、后执行：在用户明确批准之前，不会修改代码、关闭 Issue 或提交。
主要能力
- 仓库识别：通过 git remote get-url origin 解析 owner/repo。
- 分支约束：所有工作必须在当前 release/vX.Y.Z 分支上进行，禁止新建 fix/ 分支；若不存在发布分支，先按 /generate-release Phase 1 的步骤 1–5 创建。
- 全量抓取 Issue：采用两步法避免 JSON 输出被截断——先用 gh issue list 只取 Issue 编号，再逐条 gh issue view 获取完整元数据，并按最早优先排序。
- 分类：将 Issue 归为 Bug、功能请求、问题、其他，仅对 Bug 进行解决，其余在最终报告中注明跳过。
- 逐条深入分析 Bug：阅读正文与全部评论（包括机器人分诊评论和社区回应），提取错误信息、状态码、涉及的 provider/model，检查信息是否足以行动；对机器人标记的重复 Issue 不盲信，需独立核实。
- 处置判定：分为已修复关闭、重复关闭、过期关闭、需补充信息回应、用户配置问题回应、需要代码修复五类。
- 代码修复前调研：搜索代码库与网络、通读源文件、确认根因，并将方案写入 _tasks/features-vX.Y.Z/<ISSUE_NUMBER>-<short-description>.plan.md，包含概述、实施前检查清单和详细实施步骤。
- 报告与确认：向用户呈现汇总报告（Issue、标题、状态、拟采取动作/版本），等待 OK 后再继续；用户要求修改则调整方案并重新报告，拒绝则回滚意外改动并停止。
- 经批准后实施：按方案修改代码、运行 npm run test:all 确保全部通过、更新 CHANGELOG.md、以 fix: <description> (#<issue_number>) 格式逐条提交、推送发布分支、关闭已解决问题并附说明评论。
- 发布衔接：若项目需要自动发布或 PR，继续执行 /generate-release 工作流 Phase 1 的步骤 7–10；若没有提交任何修复，则跳过关闭与源码管理步骤直接结束。
使用方式 该技能以斜杠命令 /resolve-issues 形式调用。执行中把 // turbo 与 // turbo-all 视为使用 multi_tool_use.parallel 并行执行独立读取、检查与 GitHub 调用的指令。整个流程有硬性停顿点：初始报告/计划生成后必须等待用户明确批准，才能编辑代码、关闭 Issue 或提交。
适用场景 适合维护者在发布分支上批量梳理开放 Issue、区分需要修复的 Bug 与仅需回应的提问、对贡献者提交 PR 的修复遵循“必须合并其 PR、绝不关闭后自行重写”的策略，并按固定节奏整理修复与变更日志。
限制 不自动合并或发布版本，发布分支后续需通过 PR 合并到 main。禁止在未获批准时改动代码库。禁止使用 gh pr close 关闭与修复相关的贡献者 PR，除非仓库所有者明确要求。所有分析与修复必须限定在当前发布分支，不得创建独立修复分支。