关于 ln-33-code-modernizer
面向编码 Agent 的技能,用于评估并执行范围明确的代码现代化。它强调以可衡量的净收益为依据,保留现有行为,并通过验证和回退控制迁移风险。
主要功能
- 01范围明确的现代化流程
- 02基于证据的完成清单
- 03比较不同设计方案
- 04保留行为与契约
- 05验证迁移并支持回退
适用场景
- 01评估现代化是否值得实施
- 02安全替换范围明确的实现
- 03衡量工作流或产物成本变化
安装
复制下面的命令,在终端中运行。
npx skills add https:/ / github.com/ levnikolaevich/ claude-code-skills --skill ln-33-code-modernizer安装后在 Claude Code 中输入/ln-33-code-modernizer确认已加载。
详细介绍
代码现代化
目标: 仅当新设计能切实减少人为工作流阻力、维护工作、风险、依赖重复或交付产物成本时,才对有限范围的功能进行现代化。保留原有行为,隔离迁移,并撤销无法创造净价值的改动。
执行约定: 按顺序排列的复选框构成完成定义。在内部将每项标记为 PENDING、有具体证据支持的 PROVEN、有证据证明其条件不存在的 CLEARED,或存在缺口的 UNPROVEN;阅读、委派或工具故障都不构成证明。完成每个部分后核对各项。回复前,解决所有 PENDING 项,并且只统计 PROVEN 和 CLEARED 项;对每个缺口应用此技能的判定和审批规则。
保留用户意图、范围和现有授权。继续已获授权的工作;仅针对尚未解决的重大选择或必需的外部审批进行询问。根据实际风险调整工作深度,不得悄然跳过检查。遵守依赖关系和安全顺序;否则,针对每项义务选择合适的验证方法。
工具路由
| 需求 | 首选工具 | 适用场景 | 备用方案 |
|---|---|---|---|
| 当前机制及其使用方 | 原生文件搜索,加上语言服务器或宿主原生代码智能工具 | 梳理契约、调用方、配置、数据、生命周期和测试 | 针对性搜索导入、符号、路由和配置,并直接读取相关内容 |
| 现有平台功能 | 清单、锁文件、运行时 API 和最新官方文档 | 避免为已有功能引入新依赖或编写自定义代码 | 仓库示例和源码检查;若无法获取最新文档,将该功能标记为 UNVERIFIED |
| 外部替代方案候选 | 官方软件包注册表、源码仓库、文档、版本发布记录、安全公告和许可证数据 | 将受维护的软件与自定义实现进行比较 | 基于一手资料进行网络研究;不要只依赖热门榜单 |
| 基线和价值 | 构建输出、包体分析、代码清单、基准测试、缺陷或维护证据 | 明确现代化必须带来的改进 | 采用范围和局限性均有文档记录的可复现静态计数 |
| 安全迁移 | Git 隔离、针对性编辑、原生包管理器和仓库生成命令 | 替换一项有限范围的功能及其使用方 | 若无法保护用户改动或生成状态,则停止 |
| 验证 | 仓库定义的构建、代码检查、类型检查、测试、冒烟测试、打包和运行时检查 | 迁移前及每个保留步骤后 | 如果现有证据无法证明重大契约,则选择对整体改动最小的措施 |
| 交付产物分析 | 现有包分析器、大小报告、启动性能分析或依赖报告 | 目标涉及包体积、加载路径或运行时成本 | 按可复现的文件和压缩规则比较构建产物 |
不要仅因存在外部软件包就替换可正常工作的自定义代码。不要引入无人维护的依赖、接受不兼容的许可证,或在未充分了解所有使用方及回滚条件前移除旧路径。
证据规则
- 比较系统复杂度的净变化:移除的代码和风险,减去新增的依赖、适配器、运维和迁移成本。
- 对外部候选方案的主张,必须有关于维护、安全、许可证、运行时支持和 API 适配性的最新一手证据。
- 证明包体积或性能价值,必须有可比较的测量数据;仅减少代码行数并不能证明设计更优。
- 除非请求明确授权契约迁移,否则保留公开行为。
检查清单
1. 定义现代化目标
- 明确范围有限的能力、需要保护的结果、当前痛点、受影响的用户、开发者或运维人员、成功指标、约束和明确的非目标;标记缺乏依据的意图推断。
- 阅读仓库说明,并检查 Git 状态、生成文件、包管理器策略和当前用户更改。
- 梳理当前实现、公共契约、使用方、配置、持久化数据、运行时注册、测试和运维流程。
- 找出必须改善的具体工作流、维护、安全、兼容性、重复、构建包体积、启动或交付成本。
- 在更改代码前建立行为基线和相关定量基线;对于人工工作流,使用可复现的观察指标,例如所需步骤或概念、获得首个有效结果所需时间、错误理解程度和恢复工作量。
- 隔离工作,确保每个迁移步骤都可单独回退,且不会触及无关更改或用户自有更改。
- 创建由本次运行维护的资源清单,记录创建的每个绝对路径、工作树、进程 ID、缓存、报告和临时构件;切勿将预先存在的资源登记为清理目标。
- 如果证据表明范围内没有值得进行的现代化改进,则使用
NO_CHANGE;如果因缺少关键证据而无法评估可能的请求收益,则使用BLOCKED。
2. 评估最简单且可信的设计
- 在寻找新软件包之前,检查语言、运行时、框架、平台和已声明依赖项的功能。
- 找出可直接移除的过时兼容路径、并行机制、未使用的扩展点、重复集成和过渡适配器。
- 对外部候选方案评估其功能契合度、API 稳定性、维护活跃度、安全记录、许可证、所有权、发布节奏、大小、运行时支持和生态兼容性。
- 根据与目标版本相符的官方文档、仓库发布记录、安全公告和软件包元数据,核实候选方案的相关说法。
- 检查迁移指南、破坏性更改、配置模型、生命周期、故障行为、传递依赖和退出方案。
- 为替换候选方案建立语义差异清单:输入规范化、Unicode/时间/日期行为、精度、排序、错误、取消、流式处理、并发、安全限制,以及与当前契约相关的其他边缘行为。
- 在各方案都可行时,比较保留现状、就地简化、使用现有平台功能、采用外部软件和移除功能;优先选择最短且安全的路径,在不掩盖事实或削弱控制权的前提下降低繁琐工作。
- 在相关情况下,估算减少的工作流步骤和概念、结果耗时与恢复工作量的变化、删除的代码、增加的适配器、依赖项和构建包体积的变化、迁移工作量、运维变更、回滚难度和剩余锁定风险。
- 选择有最佳证据支撑且价值与风险比最高的方案,而非最新或最热门的方案。
- 将选定方案标记为
SELECTED,将所有评估过但未选的方案标记为REJECTED,并记录决定各方案取舍的证据或权衡。 - 如果许可证、公共契约、持久化数据迁移、供应商承诺或不可逆的运维权衡会改变产品意图,请征求用户指示;在非临时环境中应用迁移始终需要明确授权。
3. 执行有界迁移
- 将当前外部契约、重要故障以及数据或配置兼容性映射到现有证据;在已批准的测试范围内实施
KEEP、ADD、UPDATE、MERGE、DELETE,或有充分理由的NO_TEST;移除已被取代的测试资源,并为临时特征描述或兼容性证据设定移除触发条件。 - 针对共享的代表性输入和对抗性输入,编写差异测试或特征描述用例;旧实现是用于比较的证据,而非已知缺陷或明确变更行为的判定依据。根据预期契约解决差异。
- 在一个清晰的边界引入替代方案,而不是在整个代码库中混用新旧机制。
- 使用原生包管理器和生成命令处理依赖及生成状态;不要手动编辑锁文件或生成的构件。
- 更新有界功能所需的调用方、类型、配置、依赖注入、路由、事件、序列化、测试、构建脚本和文档。
- 仅在实际使用方有需求时保留向后兼容性,并为每个临时适配器定义移除条件。
- 在一次性副本上准备并测试持久化数据或配置迁移,明确执行顺序、可恢复性、混合版本行为、备份/还原证据、回滚和故障恢复;只有在用户指定目标环境并授权执行已演练的操作后,才能在其他环境中应用。
- 移除报告为未使用的依赖或模块前,检查静态导入扫描可能遗漏的动态导入、反射、插件/配置注册、代码生成、构建脚本、CLI 和可选运行时路径。
- 只有在搜索和运行时接线检查确认没有剩余使用方后,才移除旧实现。
- 检查差异,排除无关重构、格式变动、重复依赖、调试代码和意外的公共契约变更。
4. 验证并保留或舍弃
- 每完成一个迁移步骤,立即运行针对性的契约和回归测试。
- 运行代码库要求的构建、lint、类型、测试、冒烟、打包和应用启动检查。
- 在等效条件下,将约定的工作流、维护、依赖、包体积、启动、性能或缺陷指标与基线进行比较。
- 对于包体积相关工作,应比较实际构建组成、解析后和压缩后的大小、分块、加载行为及源映射,而不能只看包元数据。
- 分别评估入口点和路由的关键路径:总字节数可能减少,但初始传输、请求瀑布、解压、解析/编译、执行或缓存失效可能变差。
- 在更改导入或包元数据前,根据实际打包器依赖图、模块格式、导出、副作用元数据及目标浏览器/运行时,验证摇树优化和去重声明。
- 检查保留方案涉及的安全公告、许可证、运行时支持、包来源及新增的传递依赖。
- 如果迁移失败的代价高昂或难以发现,则演练回滚或移除机制。
- 只有在所需行为和验证均通过,且实现了既定的净收益时,才将迁移标记为
KEEP。 - 在最终决策前,解决有界迁移缺陷并重复受影响的检查;如果价值仍未得到证明、回归问题仍存在,或净复杂度超出约定的权衡范围,则标记为
DISCARD并回退有界变更。 - 仅在确认归属后,移除未保留的适配器、检测代码、功能标志、包和生成的构件;只清理运行记录中由本次运行拥有的路径和确切进程 ID,保留有未提交更改或预先存在的工作树以及已报告的证据。
5. 完成并报告
- 确认保留的迁移完成后,不再存在过时的实现、导入、注册、配置、文档或依赖项。
- 确认相关验证覆盖最终保留状态,复用仍然有效的结果,并重新运行因变更或未解决的失败而失效的检查。将最终差异与原始现代化范围进行比较。
- 根据最终代码、依赖项、测量结果和回滚状态,核对选项与迁移台账。
- 指明残留的自定义代码、兼容性适配器、迁移步骤、运维变更和外部依赖风险。
- 当选定的有界设计被完整保留并通过验证时,使用
MODERNIZED;当保留了一个独立安全的子集,且明确说明了剩余工作时,使用PARTIAL;当所有迁移都已放弃且基线已恢复时,使用NO_CHANGE;当授权、安全证据或所需验证不可用时,使用BLOCKED。
自检
- 提交前先核对。 检查各项证据、需求覆盖情况、矛盾、范围、结论和适用的清理工作。修正报告或已获授权的产物。复用有效证据;不要自动重新扫描代码库或重新运行已成功的命令。仅针对相关变更、失败或未解决的证据重复检查。披露剩余缺口。
输出约定
使用用户的语言按以下顺序报告;保留全部五个字段,并且每项事实只陈述一次。结果较小时,每个字段可占一行;省略空表格,不要复制已链接的产物:
- **结果:**技能专属结论和有证据支持的结果。
- **范围:**审查/变更的范围、排除项、基线和重要假设。
- **证据:**以下技能专属字段;区分事实、推断和未经验证的说法。链接产物;适用时使用表格。
- **验证:**检查及其结果、不可用的证据、适用的清理工作/外部状态。
- 完成情况:
Checklist: X/Y complete;Incomplete: None,或逐项列出每个UNPROVEN项的原因、对结果的影响及确切的后续操作;残留风险和所需决策。
**技能专属证据:**能力、受保护的契约、使用方、当前成本以及行为/价值基线。比较考虑过的替代方案及 SELECTED / REJECTED 的理由。逐项说明迁移的变更、验证、可比较的价值指标及 KEEP / DISCARD。包括代码/依赖项和工作流差异、受影响的测试操作、残留的自定义代码/兼容性、未完成的过渡工作,以及本次运行负责的测量/差异/回滚/清理证据。