菜单
feature 流程阶段 2——按 {slug}-checklist.yaml 里 design 切好的 paradigm 维度 steps 推进，每步具体改哪个文件由 implement 自决，写完用统一格式汇报。触发：用户说"方案确认了开始实现"、"按方案写代码"、"开工"。前提是 design 已 approved 且有 checklist。遇到方案外情况要回方案谈不要硬冲。
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
| name | k-feat-impl |
| description | feature 流程阶段 2——按 {slug}-checklist.yaml 里 design 切好的 paradigm 维度 steps 推进，每步具体改哪个文件由 implement 自决，写完用统一格式汇报。触发：用户说"方案确认了开始实现"、"按方案写代码"、"开工"。前提是 design 已 approved 且有 checklist。遇到方案外情况要回方案谈不要硬冲。 |
开始任何判断或动作前，先读取 .kflow/attention.md；缺失则视为骨架不完整，提示先补齐或运行 k-onboard。
到这一步用户已经在方案上签过字了，你的活是把方案变成代码。容易出问题的不是写代码本身，而是实现路上发现方案没覆盖到的情况时怎么办——硬冲下去就把方案当摆设了。下面整套规则就是为了让"停下来"成为默认动作。
共享路径与命名约定看
.kflow/reference/shared-paths.md。读取材料遵守.kflow/reference/shared-token-budget.md，实现阶段只读方案相关节和当前 step 需要的代码。
具体规则是这三条姿态的落点，理解姿态比记规则重要。
只写当前步骤明确要的东西。不顺手加"以后可能要"的可配置项、抽象层、参数开关、防御性兜底。判据：写完一段觉得"是不是还得加点 X"，先问 X 是不是当前用户能感知到的——不是就别加。整体写完一看 200 行其实 50 行能讲清楚 → 重写。多出来的代码不是中性的，是后人维护的负担。
改某个函数时只改那个函数。同文件里别的函数风格丑、命名怪——除非和本次改动直接冲突，否则别碰。新代码风格匹配当前文件已有写法。混进的"顺手改"会把功能 PR 稀释成"一坨综合改动"，review 成本翻几倍。值得改的按下文"顺手发现"格式记成后续 issue。
孤儿处理：你这次改动让某个 import / 函数变成死代码 → 删掉。不是你改动造成的死代码 → 留着记成顺手发现。
写到一半发现 design 没覆盖的角落（边界条件、错误路径、方案外文件）——默认停下来回 design 谈。下面"补丁分支"和"术语守护"是这条姿态的两个典型落点；任何"design 没明说我替它选了一个"的瞬间都触发。
frontmatter：doc_type=feature-design / feature 一致 / status=approved / summary 非空 / tags ≥ 2。
标准 design（节 0/1/2/3/4）：
Fastforward design（节 0/1/2/3）：
任一项不达标 → 退回 k-feat-design 补齐。原因：方案漏的项实现时一定要现场补，等于绕过 checkpoint。
注意：标准 design 第 3 节"验收契约"只说"做完后什么应该成立"，不说"具体怎么做"。改动文件清单 / 函数级落点 / 测试代码归 implement 自决，不要因为 design 里没写就退回去要求补。
feature 字段一致steps 非空（design 已产出，paradigm 维度切片，4-8 步）；checks 非空k-feat-design 生成{slug}-checklist.yaml、需求来源（用户描述 + brainstorm note）、.kflow/attention.md通常第 1 步；接续上次中断从已 done 的下一步继续。
design 给的 steps 是 paradigm 维度切片（编排骨架 → 计算节点 → 持久化 → 测试），具体每步改哪个文件由你执行时决定。如果某一步实际是 3 个独立子动作、或发现微重构是它的前置（参考反射检查），跟用户对齐后追加 / 拆分 steps，不偷偷做。
design 第 2.5 节微重构的衔接：
如果 2.5 结论是"做微重构（拆文件）"或"做微重构（重组目录）"，checklist 第 1 步就是它——独立跑完，按 2.5 节"行为不变怎么验证"那条核对：
不要合并到下一步——一旦混在一起，行为变更和结构变更就分不开，出问题回滚不到干净中间态
如果 2.5 结论是"不做"但写到中途反射检查触发了拆分信号 → 走下面"反射检查"那条路径（停下来 → 和用户对齐 → 能 provable 解决就追加独立 step），不要绕过用户确认偷偷追加
如果 2.5 末尾有"建议沉淀的 convention"段：implement 阶段不主动归档——只在重组目录跑通且行为零改动确认后，在汇报里带一句"design 2.5 建议沉淀的 convention 已就绪，等 acceptance 阶段确认是否走 k-decide"，把决定权交给 acceptance / 用户
按 steps 列表顺序执行，不合并、不跳。每完成一步立即把 status pending → done。
最常见违规是"顺手把下一步也做了"——每步都对应独立可验证的退出信号，两步合做意味着出问题时不知道是哪一步引入的、回滚也回不到干净中间态。
发现值得重构的点（参考 .kflow/reference/shared-reflection.md "写代码时的反射检查"），只要不在本次功能影响面内就记成后续 issue：
> 顺手发现：{文件:行号} {问题简述}。不在本次范围，记录待后续 issue。
顺手改的代码不在方案里，验收对不上；后人 git blame 也分不清是为本次功能还是顺手。
标准 design：新写的类型 / 函数 / 变量名都要去方案 doc 第 0 节对照，不允许出现 doc 里没有的新概念。要引入新概念 → 先停下来改第 0 节、grep 防冲突、用户确认。
Fastforward design：没有正式术语表，但要新起概念名时也要 grep 一下当前代码防冲突。
代价：术语冲突意味着同概念两个名字 / 同名字两个概念——后者会让搜索完全失效。
写代码时冒出 if (特殊情况) { 特殊处理 } 这种结构，停。这种分支基本只有一个原因：方案没覆盖到这种情况。继续写得到的是"为了让代码能跑而加的特殊逻辑"——下次别人改这块时不知道这个分支为什么存在。回方案谈：补进 design / 砍掉 / 明确为遗留问题。
除上面流程约束外，还有一组针对代码质量的反射检查——看 .kflow/reference/shared-reflection.md。
核心：不是"超过 N 行必须拆"，而是"遇到 X 情况就停下来问自己"。每条对应 AI 默认会走进去的坑（往大文件继续追加、往大类加方法、补丁分支、复制粘贴、第 4+ 个参数、往万能 util 堆东西）。
反射检查结论是"要拆 / 新建文件 / 重命名 / 抽共用层"且超出现有 steps 范围 → 跟用户商量决定，不偷偷拆完继续写。判据按和 design 2.5 一致的边界分两路（避免 impl 自己造一套口径）：
k-refactor，当前 step 用最少的改动绕过去；不要因为"反正都看到了"就在 feature 里顺手做掉——这会把功能 PR 稀释成综合改动，也违反 design 2.5 早就划好的边界所有步骤完成后用下面模板汇报，停下来等用户 review。
固定模板的意义：含糊汇报等于把验证责任推回用户。固定模板逼你把改了哪些文件、是否触碰方案外、是否引入新概念一一说清楚。
## 实现完成汇报
### 动了哪些文件
{git status 真实输出}
### 改了哪些函数 / 类型（按步骤分组）
**步骤 N：{步骤名}**
- file:line 函数名 改动类型（新增 / 修改 / 删除）
### 是否触碰到方案外的文件？
{是 / 否。是的话说明原因 + 是否已同步更新方案 doc}
### 是否引入了方案 doc 里没有的新概念 / 抽象？
{是 / 否。是的话说明已回填方案 doc（标准 design 补第 0 节 + 第 2.1 节；fastforward 补第 1 节）并做过 grep 防冲突}
### 代码质量反射检查自检
{对照 shared-reflection，触发哪些信号 + 怎么处理；都没触发写"无触发"}
### 推进顺序退出信号核对
{对照 steps 逐条列 action + exit_signal + status（应全为 done）}
### 验收场景自检
**标准 design**：对照第 3 节关键场景清单，每条靠什么运行时测试满足（单测 / 集成）+ 反向核对项是否守住。类型系统保证"不能这样调"的标注"编译期保证"，行为逻辑必须有运行时测试
**Fastforward design**：对照第 2 节验收标准逐条核对
汇报后停等 review。
按行为约束 TDD，不可选。 完整测试口径看 .kflow/reference/shared-testing.md。
关键路径要有集成 / 端到端证据——用户可见主路径、跨模块编排、持久化、外部接口变化必须覆盖。UI 主路径用真实浏览器；后端用真实项目边界或 test DB / contract test，不要 mock 掉被验证对象。具体怎么测、用什么 framework——design 没规定，自决。
类型系统能保证"不能这样调"（编译期直接报错）→ 可以不写运行时测试。但"调了之后结果对"是行为逻辑 → 必须有运行时测试，哪怕类型签名看起来限制了返回类型。
done告诉用户："所有步骤完成，方案 doc 已同步。下一步阶段 3 验收闭环，触发 k-feat-accept。"
别自己顺手开始写验收报告——验收需要独立的 checklist 节奏，提前进入会让把关失效。
实现过程中如果踩到了项目通用的硬约束 / 命令陷阱 / 环境设置（"啊原来这个项目要先 X 才能 Y"，一两行能讲清、下个 feature 的 AI 还会再撞一次）→ 在告诉用户去 accept 前顺便提一句："这次发现 {具体那条}，是不是要 k-note 一下加到 attention.md，免得下次再踩？"——单条即可，不连写多条；用户说"等 accept 一起处理" 就跳过，accept 第 8 节会兜底盘点。
if (用户是 X) { 特殊处理 } 补丁分支而不停下来维护 `.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"，前提是已知道做什么、为谁、怎么算成功。
issue 流程阶段 2——读 report + 读代码定位根因、评估风险，给用户 2-3 个修复方案让 TA 拍板。这一步不改代码。触发：用户说"分析这个 bug"、"找根因"、"定位问题"，且已有 {slug}-report.md。
issue 流程阶段 3——按已确认根因和方案定点修复、验证、写 {slug}-fix-note.md 落档。两个入口：标准路径从 analyze 来，快速通道从 report 直接来。触发：用户说"开始修 bug"、"按分析修"、"动手改代码"。只动方案声明的文件，不顺手优化。
把新仓库或有零散文档的仓库接入 kflow 体系——两条路径自动判断：空仓库从零搭骨架，已有文档走审计 + 迁移映射——然后释放技能文件和跨平台入口（AGENTS.md，可选 CLAUDE.md）。触发：用户说"在这个项目里用 kflow"、"搭 kflow 结构"、"初始化 kflow"、"迁移到 kflow"。