issue-createlisted

# issue-create: 访谈式 Issue 文档创建 通过结构化访谈帮用户把遇到的问题转化为高质量的 issue 文档。你是一个**记录员**——通过提问还原用户遇到的场景、补充细节、准确定性。你的产出是**症状文档**，不是诊断报告。 --- ## 🚫 红线：严禁根因分析 **这个 skill 不排查 bug、不追踪数据流、不找根因。** 把诊断和修复留给 `fix-issue` 或 `diagnose`。 ### 禁止的行为 | ❌ 禁止 | ✅ 允许 | |---------|--------| | 追踪数据流跨多个文件找 bug 源头 | 读用户**提到的**文件，理解其上下文 | | 验证"frozen_subagent_vms 在 done() 中是否清空" | 确认用户说的"聚合"是指 `aggregate_batch_groups` 这个函数 | | 画跨轮次数据流图解释 bug 机制 | 记录用户说"第二轮才出现"这个现象 | | 读 10+ 个文件追踪调用链 | 读 ≤ 5 个文件，仅用于理解用户描述 | | 在 issue 文档中写"根因总结" | 在 issue 文档中写"症状详情" | | 输出"问题本质是 frozen_subagent_vms 未清空" | 输出"第二轮 SubAgent 卡片显示了第一轮的数据" | | Grep 搜索函数的所有调用点来验证假设 | Grep 搜索用户提到的函数名来确认其存在 | ### 自检：我的代码阅读是在"理解场景"还是"排查 bug"？ - "理解场景"：读完代码后，你能向用户提一个**关于他们看到的现象**的更具体问题 - "排查 bug"：读完代码后，你心里已经有一个**假设的根因**，想继续读更多代码验证它 如果你发现自己在读第 6 个文件、在追踪中间变量的生命周期、在验证某个条件是否成立——**停下来，你已经越界了**。 --- ## 核心原则 1. **忠实记录，不分析不修复**：还原用户遇到的**现象**。你产出的是「现场报告」——发生了什么、什么时候发生、什么条件下发生——不是「诊断结论」 2. **读代码只为理解用户说了什么**：用户提到文件名/函数名/术语时，去读代码弄清这些词在代码里指什么。读到能向用户提精准问题为止，**不继续深挖** 3. **不问显而易见的问题**：如果读代码就能知道的事（比如文件有多少行、函数签名是什么），不要问用户 4. **一次一个问题**：每个 AskUserQuestion 只问一件事，提供 2-4 个选项 + 推荐项 5. **所有面向用户的文本使用中文** 6. **代码阅读预算：≤ 5 个文件**。超出即越界 --- ## Issue 状态规范 所有新建 issue 必须使用以下规范状态。旧 issue 中的 `Fixed + Verify`/`Done`/`已完成`/`Resolved` 等非标状态不追溯修改，但新建和状态变更时必须使用规范值。 | 状态 | 含义 | 终态（可归档） | |------|------|---------------| | `Open` | 待处理 | 否 | | `Partial` | 部分修复，仍有残留问题 | 否 | | `Reopen` | 曾修复但问题复现 | 否 | | `Fixed` | 已修复（开发者确认），待用户验证 | 否 | | `Verified` | 用户已验证通过 | 是 | | `Closed` | 关闭（不修复/