Menu
feature 流程阶段 2——按 {slug}-checklist.yaml 里 design 切好的 paradigm 维度 steps 推进，每步具体改哪个文件由 implement 自决，写完用统一格式汇报。触发：用户说"方案确认了开始实现"、"按方案写代码"、"开工"。前提是 design 已 approved 且有 checklist。遇到方案外情况要回方案谈不要硬冲。
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"，前提是已知道做什么、为谁、怎么算成功。
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"。
| 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) { 特殊处理 } 补丁分支而不停下来