vue-refactor
vue-refactor
Vue 代码里最常见的三种"该拆":主干太胖、UI 和 IO 纠缠、响应式和业务纠缠。这个 skill 是陪练——先看代码给诊断,再选对应处方,按编译器驱动的方式一步步搬。不写测试防护网,靠编译器 + 单步可回滚保证不改变行为。
方法论出处:Arlo Belshee 的 "Provable Refactorings"、Michael Feathers 的 "Lean on the Compiler"、Michael Thiessen 的 Humble Component + Thin Composable。详细哲学见 reference/compiler-driven-principles.md。
核心纪律(四条,每次都要遵守)
- 行为等价是底线。这次动作不改变任何外部可观察行为——DOM 输出、事件时序、网络请求、store 变化、路由跳转全都要等价。一旦发现顺手会"优化"某个行为,停下,拆出去走 feature 或 issue。
- 每步后编译器必须绿。包括
tsc --noEmit、Volar 类型检查、ESLint、已有的单测。任何一步编译不过就立刻回退这一步,不要"先留着,后面一起修"。 - 一步一个语义单元。一次只搬一个字段、一个方法、一个模板块。不合并、不打包、不"顺手带一个"。
- 创建新 → 替换引用 → 删除旧。永远这个三步循环。不要原地改名(改名会让引用一次性全断),要先建新位置、再一个个搬引用、最后拆旧位置。
违反任意一条都等于回到"AI 胡乱重构"——这个 skill 的存在意义就没了。
More from liuzhengdongfortest/codestable
cs-feat-design
feature 流程阶段 1——为新功能起草 {slug}-design.md 作为后续实现和验收的唯一输入,拍板后抽出 checklist。触发:用户说"开始设计方案"、"写 design doc"、"准备实现 XX",前提是已知道做什么、为谁、怎么算成功。
671cs-brainstorm
想法还模糊时的讨论入口,做分诊后路由到 feature-design / feature-brainstorm / roadmap。AI 是思考伙伴不是记录员。触发:用户说"有个想法还没想清楚"、"先 brainstorm 一下"、"聊一聊这块"、"方向还在摇摆"。不处理 bug 和重构。
670cs-feat-accept
feature 流程阶段 3——验收闭环:对照 design 核实现 + 回写 architecture / requirement / roadmap,最后产出 {slug}-acceptance.md。触发:用户说"功能写完了验收一下"、"做最后检查"、"准备 merge"、"出验收报告"。前置依赖 cs-feat-impl 完成。
670cs-feat-impl
feature 流程阶段 2——按 {slug}-checklist.yaml 里 design 切好的 paradigm 维度 steps 推进,每步具体改哪个文件由 implement 自决,写完用统一格式汇报。触发:用户说"方案确认了开始实现"、"按方案写代码"、"开工"。前提是 design 已 approved 且有 checklist。遇到方案外情况要回方案谈不要硬冲。
669cs-onboard
把新仓库或有零散文档的仓库接入 CodeStable 体系,两条路径自动判断:空仓库从零搭骨架,已有文档走审计 + 迁移映射。触发:用户说"在这个项目里用 CodeStable"、"搭 CodeStable 结构"、"初始化 CodeStable"、"迁移到 CodeStable"。
668cs-feat
新功能开发的子流程入口,把"加个 X 能力"从想法走到验收闭环。触发:用户说"做新功能"、"加个 X"、"实现 XX"。只做路由,根据已有产物决定走 brainstorm / design / fastforward / implement / acceptance。不处理 bug。
667