auto-issue-fixer

# auto-issue-fixer: Issue 全生命周期管理 单入口技能，覆盖 issue 的创建 → 修复 → 验证 → 归档全流程。你根据用户输入**自动判断阶段**并执行对应操作。 --- ## 阶段分发 收到用户输入后，**先判断阶段，再执行**： | 用户输入特征 | 阶段 | 动作 | |-------------|------|------| | 描述 bug/异常/性能/重构需求，无明确 issue 路径 | **创建** | 访谈 → 生成 issue 文档 | | 给出 `spec/issues/xxx.md` 路径或 issue 标题 + "修"/"fix" | **修复** | 读 issue → 改代码 → 更新文档 | | "验证"/"verify"/"好了"/"还是不行" + issue 引用 | **验证** | 定位 issue → 问反馈 → 更新状态 | | "归档"/"archive" + 可选 issue 引用 | **归档** | 扫描终态 issue → 移动 → 提炼认知 | **优先级**：如果用户输入同时匹配多个阶段（如 "修一下 xxx issue 然后验证"），按 创建→修复→验证→归档 的顺序逐一执行，每阶段完成后自动进入下一阶段。 --- ## 阶段一：创建（Create） ### 核心原则 你是记录员，不是诊断员。产出是**症状文档**，不包含根因分析。 | 允许 | 禁止 | |------|------| | 读用户提到的文件来理解术语 | 追踪数据流跨多个文件找 bug 源头 | | 记录用户观察到的现象 | 写"根因总结"或"问题本质" | | 搜索函数名确认其存在 | 搜索函数的所有调用点来验证假设 | | 阅读 ≤ 5 个文件 | 阅读第 6 个文件（越界了） | ### 1.0 历史 Issue 检查 收到用户描述后，**在提问之前**用 Grep 在 `spec/issues/` 中搜索相关关键词。找到匹配���告知用户，让其选择更新已有 issue 还是新建。 如果是更新已有 issue：追加新现象到「症状详情」，更新状态变更记录（Fixed→Reopen, etc.），不覆盖原有内容。 ### 1.1 理解初始描述 分析用户输入，提取提到的文件/模块/函数/错误信息。只读用户**提到**的文件来理解术语。 **第一轮提问**：扫描所有模糊点和缺失信息，将 2-4 个独立问题打包为一次 `AskUserQuestion` 调用（`AskUserQuestion` 支持 1-4 问，尽量用满）。各问题间相互独立、不依赖前一问的答案。优先覆盖以下维度： - **Bug**：复现频率、触发���骤、期望 vs 实际行为、环境 - **重构/技术债**：当前代码问题、期望改进方向 - **性能**：规模/负载条件、具体数据 - **安全**：风险描述、影响范围 > ⚠️ **必须批量提问**：每次 `AskUserQuestion` 至少问 2 个问题。一次只问一个问题会让用户反复等待，体验极差。如果当前只有 1 个模糊点，想想还有哪些维度没覆盖——总可以凑出第二个问题。不要问"能不能详细说说？"这种开放式问题。 ### 1.2 补充轮次 - 用户回复后，如果第一轮覆盖了所有关键信息 → 直接进入 1.4 自动定性 - 如果还有漏掉的维度或新暴露的模糊点 → 再打包 2-4 个问题为一轮 - 如果用户提到新文件，去读那个文件理解...