| name | hotplex-issue-manager |
| description | HotPlex issue 批量管理与合并 PR 交付。将分散的 GitHub issues 转化为一个合并 PR——对传统一个-issue-一个-PR 工作流的刻意替代，减少合并冲突和审查疲劳。覆盖 issue 优先级排列、批量修复规划与实施、ROI 计算。 |
| metadata | {"compatibility":"Requires gh CLI, Go 1.26+, golangci-lint, make"} |
HotPlex Issue Manager
将分散的 GitHub issues 转化为一个合并 Pull Request。分析、排序、批量实施，一次交付。
核心模式：多个 issue → 一个分支 → 一个 PR → 一次合并
陷阱和反模式见 references/common-pitfalls.md（7 个常见错误，含 PR 冲突）。
工作流
Phase 1: 分析验证 → 呈现结果 → Phase 2: ROI 评分 → 呈现排名 → Phase 3: PR 冲突检查 + 选择 → 确认计划 → Phase 4: 实施
每个 Phase 结束后呈现结果让用户确认，再进入下一阶段。不要一口气跑完全部 Phase。
Phase 1: 分析与验证
1.1 获取与分析
gh issue list --limit 100 --state open \
--json number,title,body,labels,state,author,createdAt,comments \
> /tmp/hotplex_issues.json
对每个 issue 检查四个维度：
- 完整性 — 能否根据描述实施？（清晰问题陈述、复现步骤/验收标准）
- 有效性 — 是真正的 issue 还是模糊不清？
- 重复性 — 搜索关键词，是否已被报告或修复？
- 技术可行性 — 是否符合现有架构？有无阻塞性依赖？
1.2 标签与关闭（Admin 专属）
标签体系（6 类 40+ 个标签，含 P0-P3 优先级、18 个模块标签、领域/状态/辅助/关闭原因）、关闭无效 issue 的完整流程见 references/label-taxonomy.md。
1.3 呈现阶段结果
输出 /tmp/issue_analysis.md，向用户呈现：
- 总数统计：分类标签数、关闭无效数、剩余有效数
- 按模块/领域分组的 issue 概览
- 发现的重复、无效、已修复 issue
等用户确认后进入 Phase 2。
Phase 2: ROI 评分
2.1 评分公式
三个维度（1-10）：
影响力 (I)：10=关键bug/安全/数据丢失，7-8=高影响bug/重大功能，5-6=可感知改进，3-4=小幅，1-2=锦上添花
紧急度 (U)：10=生产故障/阻塞发布，7-8=每日影响，5-6=应尽快修，3-4=有空就修，1-2=无截止日期
工作量 (E)（反向 — 越高越容易）：10=琐碎1-2h，7-8=容易半天，5-6=中等1-2天，3-4=困难3-5天，1-2=极难1+周
ROI = (I × U × E) / 10 最大值 = 100
2.2 优先级与依赖
| 优先级 | ROI 范围 | 标签 |
|---|
| P0 | ≥ 80 | P0（紧急：生产故障/数据丢失/安全漏洞） |
| P1 | 50-79 | P1（关键：阻塞功能/每日影响） |
| P2 | 30-49 | P2（高：应尽快修） |
| P3 | 15-29 | P3（中：有空就修） |
检查 issue body 中的 #XX 引用识别依赖。被未解决依赖阻塞的标记 blocked 并降低优先级。
2.3 呈现排名
输出 /tmp/issue_ranking.md，向用户呈现按 ROI 排序的完整列表（含 I/U/E 分数），以及优先级分布统计。
边缘情况处理：
- 全是低 ROI（< 15）：告知用户当前无高价值 issue，建议关注意愿驱动的重构
- 只有 0-1 个有效 issue：跳过批量模式，直接实施或告知无需批量
- 用户指定了具体 issue 编号：只分析指定 issue，跳过全量扫描
Phase 3: PR 冲突检查 + 选择
3.0 PR 冲突检查（必须，在选择前执行）
选择前必须排除已有 PR 覆盖的 issue，避免重复工作和合并冲突。
步骤：
- 获取 open PR 及其覆盖的 issue 编号和 diff 文件
- 对每个候选 issue 做三级评估：
| 级别 | 条件 | 处理 |
|---|
| 直接覆盖 | Issue 编号出现在 PR title/body 中 | 排除 |
| 文件重叠 | Issue 涉及的文件与 PR diff 重叠 | 排除或延后 |
| 安全可选 | 无重叠 | 可选 |
- 输出
/tmp/pr_conflicts.md，向用户呈现排除结果
3.1 从安全可选池中选择
从 3.0 的安全可选池中选 1-5 个 issue。优先顺序：高 ROI → 连贯性（同一模块/领域）→ 无阻塞依赖 → 总工作量 1-3 天。
连贯性很关键 — 不相关的 issue 混在一个 PR 里让审查、测试、回滚都更困难。
选择策略：
- 保守（2 个）：排名第1的 P1 + 1 个高 ROI P2
- 平衡（3-4 个）：1 P1 + 2 P2 + 1 P3
- 激进（5 个）：全部 P1 + 顶级 P2，仅当工作量 ≤ 3 天且高连贯性
3.2 呈现选择方案，等用户确认
向用户呈现候选方案（含 ROI、类型、范围、预估工作量、PR 冲突排除说明），让用户选择或调整。确认后输出 /tmp/implementation_plan.md 进入 Phase 4。
Phase 4: 实施与交付
详细指南见 references/implementation-guide.md（分支命名、commit 模板、PR 模板）。
快速概览：
- 准备仓库 —
git fetch origin main && git checkout main && git pull origin main
- 创建批量分支 —
batch/<theme>-issues-<numbers>
- 按序实施 — 每个 issue 一个原子 commit（
type(scope): description，footer Fixes #XX）
- 每步验证 —
make lint && make test
- 最终集成测试 —
make check（完整 CI：quality + build）
- 推送并创建 PR — 一个 PR 关闭所有 issues
标准：Go 1.26+ | golangci-lint | TDD | ≥80% 覆盖率 | Conventional commits | 原子提交
输出产物
/tmp/hotplex_issues.json — 原始 issue 数据/tmp/issue_analysis.md — Phase 1 分析结果/tmp/issue_ranking.md — Phase 2 ROI 排名/tmp/pr_conflicts.md — Phase 3 PR 冲突检查/tmp/implementation_plan.md — 批量实施计划- 一个合并 PR — 最终交付物
Reference 文件
| 文件 | 内容 |
|---|
references/label-taxonomy.md | 标签体系（6 类 40+ 个标签，含 P0-P3、18 个模块标签）、关闭无效 issue 流程、质量检查 |
references/common-pitfalls.md | 7 个常见陷阱与对策（含 PR 冲突） |
references/implementation-guide.md | Phase 4 完整指南：仓库准备、分支创建、commit 模板（含全部 scope）、PR 模板 |
references/example-session.md | 完整演练：从 20 个 issues 到合并 PR |
references/troubleshooting.md | 8 个常见问题的诊断和解决方案 |
适用范围
适用于：2-5 个相关 issue、触及相似代码区域、1-3 天可完成、想减少合并冲突和审查开销
不适用于：完全不相关的 issue、总工作量 > 3 天、有复杂难解的依赖、需要立即 hotfix 的单个关键问题
