Menu
修 bug 的子流程入口，把"发现问题"走到验证修复闭环，留下 report / analysis / fix-note 三份文件。触发：用户说"修 bug"、"有个问题"、"修复 XX"。只做路由，根据已有产物走 report / analyze / fix。简单问题走快速通道。
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
维护 `.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 |
| description | 修 bug 的子流程入口，把"发现问题"走到验证修复闭环，留下 report / analysis / fix-note 三份文件。触发：用户说"修 bug"、"有个问题"、"修复 XX"。只做路由，根据已有产物走 report / analyze / fix。简单问题走快速通道。 |
开始任何判断或动作前，先检查 .kflow/attention.md 是否存在；缺失则视为骨架不完整，提示先补齐或运行 k-onboard。本技能只做路由，默认不读 attention 全文；执行子技能动手前会读。
修 bug 直觉是"找到错的地方改了完事"，但这个直觉路径反复制造同样的麻烦：
issue 工作流在"看到问题"和"动手改代码"之间塞缓冲：
发现问题 → 清晰记录（report）→ 根因分析（analyze）→ 定点修复 + 验证（fix）
本技能不写任何东西，只看当前 issue 走到哪步、决定触发哪个子技能。
.kflow/issues/{YYYY-MM-DD}-{slug}/
├── {slug}-report.md ← 阶段 1 问题报告
├── {slug}-analysis.md ← 阶段 2 根因分析
└── {slug}-fix-note.md ← 阶段 3 修复记录（必出产物）
日期取发现 / 提报问题当天定了不动。slug 能一眼看出是什么问题（auth-token-leak、null-pointer-on-empty-list）。
{slug}-fix-note.md 是阶段 3 必出产物——无论修复简单还是复杂都要写。它不是仪式，是回溯凭证：没有它下次类似问题来你只能从 git log 反推。
所有 issue 文档带 YAML frontmatter（doc_type 分别为 issue-report / issue-analysis / issue-fix）便于 search-yaml.py 按 severity / tags / status 检索。
| 阶段 | 子技能 | 主导 | 产出 |
|---|---|---|---|
| 1 问题报告 | k-issue-report | 用户描述，AI 引导 | {slug}-report.md |
| 2 根因分析 | k-issue-analyze | AI 读代码分析，用户确认 | {slug}-analysis.md |
| 3 修复验证 | k-issue-fix | AI 按分析定点修复，用户验证 | 代码 + {slug}-fix-note.md + scoped-commit |
阶段间有人工 checkpoint——让用户在每阶段结束有一次明确把关，防止 AI 一口气从问题跑到代码跑出来才发现走偏。
下面同时满足才进：
流程压缩成：AI 读代码 → 直接告知根因 + 修复方案 → 用户确认 → AI 修复 → 用户验证通过 → AI 写 {slug}-fix-note.md。只产出一份 fix-note.md，省掉 report 和 analysis。
判定口径：是否进快速通道由 k-issue-report 的启动检查做唯一正式判定。一旦进标准路径默认不再二次改判——避免三个阶段对路径各说各话。
不能走快速通道：根因有多个候选 / 修复范围涉及多模块 / 需要先复现才能定位 / 用户希望留完整分析存档。
进入本技能先 Glob .kflow/issues/，自己读已有文件才有数。
| 当前状态 | 触发哪个子技能 |
|---|---|
| 刚发现问题，没有任何文件 | k-issue-report（那里判断走标准还是快速） |
report.md 已存在，没 analysis.md | k-issue-analyze |
analysis.md 已存在，代码还没改 | k-issue-fix |
| 代码已改，还没修复验证记录 | k-issue-fix（走验证） |
| 不确定 | 自己读已有文件按上表对号 |
用户描述的是新功能需求而不是 bug → 告诉用户走 k-feat。
灰色地带：修 issue 过程中发现需要新增能力才能真正解决——先用 issue 工作流把记录和分析做完，再视情况开 feature。不在 issue 里偷偷做新功能，理由跟 feature 不在 PR 里偷偷修 bug 一样：混着改分不清这次到底改了什么范围。
.kflow/reference/system-overview.md — kflow 体系总览.kflow/reference/shared-conventions.md — 共享口径索引，按需打开具体小文件.kflow/attention.md — kflow 启动注意事项和项目硬约束.kflow/architecture/ARCHITECTURE.md — 根因分析时可能要查