Ren refactor
Skill HubertBiyo/ren-flow/plugins/ren-flow/skills/ren-refactor
ren = 人 (human). Human-in-the-loop Vibe Coding workflow for Claude Code — 16 skills orchestrating the software lifecycle: intent → spec → code → verify → knowledge.
npx -y skills add HubertBiyo/ren-flow --skill ren-refactorAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 0 stars0 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
What its author says it does
Copied from the file, not written here
代码优化 / 重构 —— 处理「行为不变、结构变」的工作(结构拆分、性能、可读性),扫描 → 选定 → 逐步改。按规模分快路 / 全程。触发:用户说「优化一下」「重构」「拆一下」「这段太长了」「性能不行」,且不夹带行为改动。
SKILL.md
4.8 KB, as published. Nobody here has run it
ren-refactor
启动必读
先 Read .ren-flow/attention.md。
工作区模式(根 attention.md 标 mode: workspace):制品按业务域分层 —— 本技能产物落到 .ren-flow/domains/{domain}/ 下而非 .ren-flow/。先确认本次业务域(域清单见根 attention),再 Read .ren-flow/domains/{domain}/attention.md 取该域约定。
这个技能干什么
处理「行为不变、结构变」的活 —— 拆胖文件、抽重复、调性能、改可读性。
底线:行为等价。 一旦会改外部可观察行为 —— 不走 ren-refactor:行为该变是需求,走 ren-spec;行为错了是 bug,走 ren-fix。
AI 自己重构有两个稳定翻车点:不清楚模块真实约束改出不等价的东西;一次吞太大改到后面忘了前面。本技能在「想优化」和「动手」之间塞一层扫描清单 + 用户勾选,让 AI 只接能稳定做对的活。产物:一个重构目录 .ren-flow/refactors/{YYYY-MM-DD}-{slug}/,主文件 {slug}-refactor.md;扫描清单、before/after 等伴生文件一并放进去。
先判规模:快路还是全程
快路(同时满足):单函数 / 单文件、1-3 处改动、有测试可自证、不改公开接口。 → 直接指出 1-3 条优化 → 用户一次确认 → 原地改 → 跑测试自证。
全程(任一命中):跨多文件、改动 > 3 处、改公开接口、需人工目视验证、无测试覆盖。 → 走下面三阶段。
三阶段
阶段 1:扫描(scan)
先锁定范围:用户点名的文件 / 「这个页面」(入口组件 + 直接 import,不追公共依赖)/「这个模块」(模块目录内,不出边界)。范围 > 15 文件先请用户缩小。
按四层找优化点(当模板用):
- L1 行为等价迁移:接口要改但多处调用 → Parallel Change;整块旧逻辑被新实现替换 → Strangler Fig
- L2 代码级:超长函数(>50 行 / 圈复杂度高)、重复片段、神秘临时变量、深层嵌套
- L3 结构拆分:文件 / 组件偏胖、一个文件管多件事、容器与展示混杂、相同逻辑多处各写一份
- L4 性能:重复计算、N+1 查询、列表无分页 / 虚拟化、监听无清理
产出清单交用户勾选 ✓/✗(✗ 写理由)。不替用户勾选。真没发现值得做的就老实说,不凑数。
阶段 2:定方案(design)
对勾选项:排顺序(有依赖的排前)、每条写「改什么 → 怎么改 → 怎么验证行为不变 → 谁验(AI 自证 / 人工目视)」。无测试覆盖的条目,前置「先补刻画测试」—— 否则「行为等价」只是口头承诺。整体交用户 review 放行。
阶段 3:逐步改(apply)
- 一步一做不批量 —— 按顺序,当前步没验证通过不开下一步,保留单步可回滚
- 每步验证:AI 自证的跑测试 / 类型检查 / lint;人工目视的停下来请用户确认(前端效果 AI 看不到,不能用「类型检查过了」替代)
- 行为等价自检:每步问一句「这步有没有可能改了外部可观察行为?」有怀疑就退回
- 偏离当场停 —— 发现方案没考虑的情况,停下汇报,不自己发挥
- 全部做完跑全量测试 + 检查,写 refactor 记录 —— 模板与归档规则见
references/record-format.md(范围 / 执行记录 / 偏离三节 + frontmatter)。
与其他技能的边界
- 改行为 →
ren-spec(需求变)或ren-fix(bug) - 重构中发现的 bug → 记成
ren-fix,不在重构里偷偷修 - 重构中冒出「顺便加个 X」→ 停下,拆成
ren-spec - 跨模块的边界重划不是单次 refactor —— 拆成「
ren-arch更新 + 多个模块级 refactor」 - 命名偏好 / 引号风格这类口味项不进清单 —— 要定就走
ren-note的 decision
退出条件
- 扫描清单用户已勾选(✓/✗)
- 每条勾选项有「怎么验证行为不变」
- 无测试覆盖的条目已前置补测试
- 逐步改,每步有验证记录;人工目视项有用户确认
- 全量测试 / 检查通过,无夹带的行为改动
- refactor 记录已落盘
容易踩的坑
- 夹带行为改动 —— 顺手修 bug / 改文案,该拆出去
- 一次提交做多步 —— 失去单步回滚能力
- 没测试覆盖硬上 ——「行为等价」变成空头承诺
- 人工目视项自己跳过 —— 前端效果 AI 看不到
- 扫大模块直接动手 —— 产出没法决策的长清单
- 把口味项列进清单 —— 命名偏好走 decision
Gives 0 of the 12 instructions most refactoring skills give
Counted across 521 of the 525 authors here whose files we hold, read 2026-08-06
- run tests after each changein 59 of 521, across 56 files
- write tests before refactoringin 27 of 521, across 24 files
- preserve external behaviorin 26 of 521, across 22 files
- remove dead codein 25 of 521, across 24 files
- make small incremental changesin 20 of 521, across 17 files
- break the implementation into tiny commitsin 18 of 521, across 5 files
- ask the user about alternative optionsin 17 of 521, across 4 files
- create a GitHub issue with the planin 17 of 521, across 4 files
- explore the repository to verify assertionsin 17 of 521, across 4 files
- interview the user about the refactorin 16 of 521, across 3 files
- check the codebase for test coveragein 16 of 521, across 3 files
- refactor one thing at a timein 16 of 521, across 12 files
Said here and by no other author read
- read the attention file before starting
- classify the refactor size before starting
- lock the refactor scope
- scan for optimization points
- let the user check the scan list
- execute the plan step by step
Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once.