Menu
issue 流程阶段 3——按已确认根因和方案定点修复、验证、写 {slug}-fix-note.md 落档。两个入口：标准路径从 analyze 来，快速通道从 report 直接来。触发：用户说"开始修 bug"、"按分析修"、"动手改代码"。只动方案声明的文件，不顺手优化。
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。
把新仓库或有零散文档的仓库接入 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