菜单
issue 流程阶段 3——按已确认根因和方案定点修复、验证、写 {slug}-fix-note.md 落档。两个入口：标准路径从 analyze 来，快速通道从 report 直接来。触发：用户说"开始修 bug"、"按分析修"、"动手改代码"。只动方案声明的文件，不顺手优化。
用 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。
把新仓库或有零散文档的仓库接入 kflow 体系——两条路径自动判断：空仓库从零搭骨架，已有文档走审计 + 迁移映射——然后释放技能文件和跨平台入口（AGENTS.md，可选 CLAUDE.md）。触发：用户说"在这个项目里用 kflow"、"搭 kflow 结构"、"初始化 kflow"、"迁移到 kflow"。
| name | k-issue-fix |
| description | issue 流程阶段 3——按已确认根因和方案定点修复、验证、写 {slug}-fix-note.md 落档。两个入口：标准路径从 analyze 来，快速通道从 report 直接来。触发：用户说"开始修 bug"、"按分析修"、"动手改代码"。只动方案声明的文件，不顺手优化。 |
开始任何判断或动作前，先读取 .kflow/attention.md；缺失则视为骨架不完整，提示先补齐或运行 k-onboard。
根因和方案已经确定（标准路径在 analysis、快速通道在 report 阶段口头确认过），你的活是按方案改代码、验证效果、写下修复记录。
fix 阶段最容易出问题的不是改代码本身，而是改的过程中冒出的"顺手"冲动——顺手优化、顺手重构、顺手加抽象。每项单独看说得通，但合在一个 PR 里让别人分不清"这次到底为了修 bug 改了什么"。
共享路径与命名约定看
.kflow/reference/shared-paths.md和k-issue的"文件放哪儿"。读取材料遵守.kflow/reference/shared-token-budget.md，先读选定方案和定位证据，必要时再升级到全文。
doc_type=issue-analysis 且 status=confirmed，第 5 节用户选定了哪个方案.kflow/attention.md + 沉淀目录搜索。analysis/report 字段矛盾、修复范围不清、或要写 fix-note 时再读对应全文：
python .kflow/tools/search-yaml.py --dir .kflow/compound --filter doc_type=trick --filter status=active --query "{关键词}"——确认修复方式不违背已有库用法 / 模式--filter doc_type=explore——确认修复点和已有证据不冲突进入这个入口时 AI 在 report 阶段已读过代码并对根因有把握。
{文件}:{行号} 的 {具体代码} 存在 {问题描述}"，让用户确认根因判断准确.kflow/attention.mdcompound/（trick + explore），默认只读最高相关命中，避免误把已知边界条件当新问题完整测试口径看 .kflow/reference/shared-testing.md。issue-fix 的 TDD 节奏：
不允许跳过复现测试直接修代码——"改完手工试一下没问题了"不算验证。
修复范围来自 analysis 第 5 节"推荐方案"的"影响面"。超出范围的文件——哪怕顺眼——不动。
发现范围外值得改的记一条"顺手发现"不改代码：
> 顺手发现：{文件:行号} {问题简述}。不在本次修复范围，可后续另开 issue。
为什么这么严：顺手改的代码不在分析里，验收对不上，git blame 分不清哪些改动是为这个 bug。
修复只针对根因，不引入新抽象、新接口、新模式。如果发现"要把这个改好得先重构 X"——停下来跟用户确认是否在这个 issue 里做重构，还是拆成独立工作。
为什么：bug 修复天然窄场景，引入新抽象意味着只有这一个使用点支撑——典型过早抽象。
修 bug 看似动作小但 AI 写修复代码一样会漂——大文件再塞特殊处理、大类再加方法、为绕开边界加 if 分支。反射检查见 shared-reflection.md。
issue-fix 比 feature-implement 更谨慎：触发反射信号但结论是"该拆"时默认不在本次 PR 做——按"改动最小化"记成顺手发现。唯一例外是"不拆就没法干净修这个 bug"，那停下来跟用户确认"修这个 bug 的前置是 {重构动作}，合进来还是拆出去单独做"。
修复汇报模板见同目录 reference.md，不允许含糊汇报。汇报后停下等用户回复。
修复改完后逐项核对：
走完验证清单仍问题复现或行为与期望不符——别在原有猜测上反复试错，切换到日志调试模式重新收集运行时证据。
为什么切换：反复试错本质是猜测在原假设下还有什么可能性，但如果原假设就错了再猜也是绕圈。日志强制看实际运行时数据，往往一眼看出原假设哪里偏了。
日志调试步骤、用户取日志提示词、循环限制见同目录 reference.md。
验证通过后在 issue 目录建 {slug}-fix-note.md（位置见 k-issue 的"文件放哪儿"），记录完整闭环。标准路径模板和快速通道模板都在同目录 reference.md。
{slug}-fix-note.md 已建并填写完整按 shared-closeout.md"scoped-commit"规则执行。本阶段：
{slug}-fix-note.md + 本次一并更新的 report / analysis{slug}-fix-note.md 已落盘"，紧接着问是否需要 commit告诉用户："issue 修复完成，工作流闭环。report + analysis + fix-note 已存档。"
按 shared-closeout.md"issue-fix"收尾推荐顺序各问一句（用户"不用"立即跳过）：
k-learn）"k-decide）"k-note）"建议：把 issue 目录文件和代码改动放同一次提交方便追溯；"顺手发现"另开 k-issue-report 处理别塞这个 PR。
修复中发现问题实际是功能缺失（不是 bug）→ 建议另开 k-feat，别在 issue 工作流里偷偷做新功能。
{slug}-fix-note.md 没建就宣告完成git commit