菜单
HotPlex issue 批量管理与合并 PR 交付。将分散的 GitHub issues 转化为一个合并 PR——对传统一个-issue-一个-PR 工作流的刻意替代，减少合并冲突和审查疲劳。覆盖 issue 优先级排列、批量修复规划与实施、ROI 计算。
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
| 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"} |
将分散的 GitHub issues 转化为一个合并 Pull Request。分析、排序、批量实施，一次交付。
核心模式：多个 issue → 一个分支 → 一个 PR → 一次合并
陷阱和反模式见
references/common-pitfalls.md（7 个常见错误，含 PR 冲突）。
Phase 1: 分析验证 → 呈现结果 → Phase 2: ROI 评分 → 呈现排名 → Phase 3: PR 冲突检查 + 选择 → 确认计划 → Phase 4: 实施
每个 Phase 结束后呈现结果让用户确认，再进入下一阶段。不要一口气跑完全部 Phase。
gh issue list --limit 100 --state open \
--json number,title,body,labels,state,author,createdAt,comments \
> /tmp/hotplex_issues.json
对每个 issue 检查四个维度：
标签体系（6 类 40+ 个标签，含 P0-P3 优先级、18 个模块标签、领域/状态/辅助/关闭原因）、关闭无效 issue 的完整流程见 references/label-taxonomy.md。
输出 /tmp/issue_analysis.md，向用户呈现：
等用户确认后进入 Phase 2。
三个维度（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
| 优先级 | ROI 范围 | 标签 |
|---|---|---|
| P0 | ≥ 80 | P0（紧急：生产故障/数据丢失/安全漏洞） |
| P1 | 50-79 | P1（关键：阻塞功能/每日影响） |
| P2 | 30-49 | P2（高：应尽快修） |
| P3 | 15-29 | P3（中：有空就修） |
检查 issue body 中的 #XX 引用识别依赖。被未解决依赖阻塞的标记 blocked 并降低优先级。
输出 /tmp/issue_ranking.md，向用户呈现按 ROI 排序的完整列表（含 I/U/E 分数），以及优先级分布统计。
边缘情况处理：
选择前必须排除已有 PR 覆盖的 issue，避免重复工作和合并冲突。
步骤：
| 级别 | 条件 | 处理 |
|---|---|---|
| 直接覆盖 | Issue 编号出现在 PR title/body 中 | 排除 |
| 文件重叠 | Issue 涉及的文件与 PR diff 重叠 | 排除或延后 |
| 安全可选 | 无重叠 | 可选 |
/tmp/pr_conflicts.md，向用户呈现排除结果从 3.0 的安全可选池中选 1-5 个 issue。优先顺序：高 ROI → 连贯性（同一模块/领域）→ 无阻塞依赖 → 总工作量 1-3 天。
连贯性很关键 — 不相关的 issue 混在一个 PR 里让审查、测试、回滚都更困难。
选择策略：
向用户呈现候选方案（含 ROI、类型、范围、预估工作量、PR 冲突排除说明），让用户选择或调整。确认后输出 /tmp/implementation_plan.md 进入 Phase 4。
详细指南见 references/implementation-guide.md（分支命名、commit 模板、PR 模板）。
快速概览：
git fetch origin main && git checkout main && git pull origin mainbatch/<theme>-issues-<numbers>type(scope): description，footer Fixes #XX）make lint && make testmake check（完整 CI：quality + build）标准：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 — 批量实施计划| 文件 | 内容 |
|---|---|
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 的单个关键问题
HotPlex 架构深度审计。覆盖架构分析、SOLID/DRY 合规、并发安全、性能优化、安全扫描、存量 issue 审计与清理。自动创建 GitHub Issue，支持 `/loop` 循环执行。**核心流程**：选定模块 → 静态分析 → 产出结构化发现 → 自动建 issue → 闭环修复。
HotPlex Worker Gateway 标准化发布流程。**立即使用此 skill**：当需要发布新版本、创建 GitHub Release、管理版本号、生成 Changelog、收集变更或验证版本一致性时。自动化版本发布流程，确保完整的变更记录和跨所有组件的版本统一。无论是在 main 分支正式发布，还是在 feature 分支准备发布材料，此 skill 都能指导你完成正确的流程。
HotPlex 二进制更新。完整工作流：构建 → 安装 → 服务重启 → 验证 → 错误处理和回滚机制。支持用户级和系统级服务，跨平台兼容（Linux/macOS/Windows）。
HotPlex Slack 与 Cron CLI 命令示例参考。当需要执行 hotplex slack 子命令（发消息、上传/下载文件、更新/定时消息、频道、书签、表情回复）或 hotplex cron 子命令（创建/列出/查看/更新/删除/触发/历史定时任务）时使用。
HotPlex 生产环境安装、配置、部署与故障排查。以 `hotplex doctor` 诊断驱动，覆盖 onboard 向导、4 种 Worker 配置、STT/TTS、系统服务。当用户提到安装、配置、部署、doctor、onboard、环境检查、setup、启动失败、连接问题、凭证错误、服务无法启动时触发——即使用户只是描述了运行异常，也应先跑 doctor 诊断再排查。
HotPlex 文档中心变更驱动巡逻。检测代码变更对文档的影响并执行精准维护：版本发布后审查、重大 PR 合并后检查、文档腐烂检测。先理解代码世界发生了什么变化，再判断文档世界需要哪些响应——像专业技术文档工程师一样思考，而非跑检查清单。