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 个具体选项。不要问"能不能详细说说？"。 ### 1.2 场景还原 根据问题类型，只问**用户能直接观察到**的维度： - **Bug**：复现频率、触发步骤、期望 vs 实际行为、环境 - **重构/技术债**：当前代码问题、期望改进方向 - **性能**：规模/负载条件、具体数据 - **安全**：风险描述、影响范围 每个 AskUserQuestion 一次一问，2-4 个选项。 ### 1.3 补充细节 - 根据前两轮反馈，补充提问遗漏的现象细节 - 如果用户提到新文件，去读那个文件理解术语 - 不问代码能直接回答的问题（文件有多少行等） ### 1.4 自动定性与评级 自动判定，不询问用户： | 类型 | 条件 | |------|------| | Bug | 异常行为、错误信息、崩溃、与预期不符 | | 安全 | 数据泄露、注入、权限绕过等 | | 性能 | 耗时、吞吐量、内存、卡顿 | | 重构 | 结构性改进目标（拆分、解耦、...