菜单
issue 流程阶段 1——通过对话把问题落成可复现、可追溯的 {slug}-report.md，并判定走标准路径还是快速通道。只问现象不猜根因。触发：用户说"提个 issue"、"记录这个 bug"、"我发现一个问题"。issue 工作流的起点。
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
维护 `.kflow/architecture/` 这份只记现状的系统地图，三种模式 update / check / backfill。触发：用户说"刷新 architecture"、"做架构检查"、"补这个模块的架构文档"、"方案和代码对得上吗"，或 feature 阶段需要先做架构动作。不写未来规划（走 k-roadmap）。
feature 流程阶段 3——验收闭环：对照 design 核实现 + 回写 architecture / requirement / roadmap，最后产出 {slug}-acceptance.md。触发：用户说"功能写完了验收一下"、"做最后检查"、"准备 merge"、"出验收报告"。前置依赖 k-feat-impl 完成。
feature 流程阶段 1——为新功能起草 {slug}-design.md 作为后续实现和验收的唯一输入，拍板后抽出 checklist。触发：用户说"开始设计方案"、"写 design doc"、"准备实现 XX"，前提是已知道做什么、为谁、怎么算成功。
feature 流程阶段 2——按 {slug}-checklist.yaml 里 design 切好的 paradigm 维度 steps 推进，每步具体改哪个文件由 implement 自决，写完用统一格式汇报。触发：用户说"方案确认了开始实现"、"按方案写代码"、"开工"。前提是 design 已 approved 且有 checklist。遇到方案外情况要回方案谈不要硬冲。
issue 流程阶段 2——读 report + 读代码定位根因、评估风险，给用户 2-3 个修复方案让 TA 拍板。这一步不改代码。触发：用户说"分析这个 bug"、"找根因"、"定位问题"，且已有 {slug}-report.md。
issue 流程阶段 3——按已确认根因和方案定点修复、验证、写 {slug}-fix-note.md 落档。两个入口：标准路径从 analyze 来，快速通道从 report 直接来。触发：用户说"开始修 bug"、"按分析修"、"动手改代码"。只动方案声明的文件，不顺手优化。
| name | k-issue-report |
| description | issue 流程阶段 1——通过对话把问题落成可复现、可追溯的 {slug}-report.md，并判定走标准路径还是快速通道。只问现象不猜根因。触发：用户说"提个 issue"、"记录这个 bug"、"我发现一个问题"。issue 工作流的起点。 |
开始任何判断或动作前，先读取 .kflow/attention.md；缺失则视为骨架不完整，提示先补齐或运行 k-onboard。
这一阶段做两件事：把用户脑子里的问题落成结构化记录 + 判断走标准路径还是快速通道。
核心原则：只记现象不记根因。用户说"我觉得是 XX 组件的问题"——记下"用户怀疑 XX 组件"作为线索，但不顺着聊根因。根因要在阶段 2 通过实际读代码确认，不靠脑子里猜。混进根因猜测的报告会带偏阶段 2，让分析人围着错误线索绕。
共享路径与命名约定看
.kflow/reference/shared-paths.md和k-issue的"文件放哪儿"。
k-feat.kflow/issues/，有同类问题先和用户确认是新建还是更新{文件}:{行号}、修复改动小 1-2 处、无跨模块影响风险）→ 告诉用户"我已看到问题所在，可以走快速通道：直接告知根因和修复方案，你确认后我立刻修，修完你验证，只写一份 {slug}-fix-note.md"。同意后触发 k-issue-fix（快速通道模式）currentDate）。目录不存在就创建。快速通道也要建 issue 目录，{slug}-fix-note.md 放那按顺序逐个问，不一次抛 5 个——一次抛多个用户只回最容易的，深的就漏了。每问做一次模糊度检查，不通过继续追问。
期待具体的异常表现："点击提交按钮后弹出了空白弹窗" 比 "提交功能有问题" 有用一百倍。
模糊信号："有时候会出错"、"感觉不对" → 追问"具体什么时候"、"具体什么不对"。
红线：不要让用户描述根因。出现"应该是因为 XXX"——记现象，根因留给阶段 2。
期待最小复现步骤：进入 XX 页面 → 输入 YY → 点击 ZZ → 看到问题现象。
模糊信号："不稳定复现"、"有时候能有时候不能" → 追问复现频率和条件差异。确实不稳定就写明已知触发条件和复现率。
"无法复现"也是有效回答——写"目前无法稳定复现，只在 X 情况下观察到一次"，别勉强凑步骤。
期待两句话：
不要合并成一句。合在一句"按钮没正常工作"里分析的人不知道"正常"长什么样。
最低采集：在哪个模块 / 功能区域发现的、相关文件或函数（用户知道的话）。
可选：操作系统、浏览器版本、运行环境（dev / prod）、最近有没有改过相关代码。
用户说"不知道在哪个文件"——写"待定"，阶段 2 分析时查。
用户不确定就帮他推荐一个但让用户拍板。
---
doc_type: issue-report
issue: {issue 目录名}
status: draft
severity: P0 | P1 | P2 | P3
summary: {问题现象一句话}
tags: []
---
# {问题简述} Issue Report
## 1. 问题现象
{用户描述的具体异常表现，纯现象描述，不含根因推测}
## 2. 复现步骤
1. {步骤 1}
2. {步骤 2}
3. 观察到：{问题现象}
复现频率：{稳定 / 概率（约 X%） / 暂无法稳定}
## 3. 期望 vs 实际
**期望行为**：{做了 A 应该发生 B}
**实际行为**：{但实际发生了 C}
## 4. 环境信息
- 涉及模块 / 功能：{模块名或功能描述}
- 相关文件 / 函数：{已知 file:line 或"待定"}
- 运行环境：{dev / staging / prod / 不确定}
- 其他上下文：{OS、浏览器、最近改动等，没有写"无"}
## 5. 严重程度
**{P0 / P1 / P2 / P3}** — {一句话理由}
## 备注
{可选：截图描述、日志片段等}
doc_type=issue-report / issue 一致 / severity 和 summary 非空 / tags ≥ 1）status: confirmed告诉用户："问题报告已就绪。下一步阶段 2 根因分析，触发 k-issue-analyze。"
别自己顺手开始分析根因——阶段间的人工 checkpoint 是工作流硬约束。