mcpField
L
ln-33-code-modernizer

ln-33-code-modernizer

github.com/levnikolaevich开发58452 次安装2 天前更新
代码仓库

关于 ln-33-code-modernizer

面向编码 Agent 的技能,用于评估并执行范围明确的代码现代化。它强调以可衡量的净收益为依据,保留现有行为,并通过验证和回退控制迁移风险。

主要功能

  1. 01范围明确的现代化流程
  2. 02基于证据的完成清单
  3. 03比较不同设计方案
  4. 04保留行为与契约
  5. 05验证迁移并支持回退

适用场景

  1. 01评估现代化是否值得实施
  2. 02安全替换范围明确的实现
  3. 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。

自检

  • 提交前先核对。 检查各项证据、需求覆盖情况、矛盾、范围、结论和适用的清理工作。修正报告或已获授权的产物。复用有效证据;不要自动重新扫描代码库或重新运行已成功的命令。仅针对相关变更、失败或未解决的证据重复检查。披露剩余缺口。

输出约定

使用用户的语言按以下顺序报告;保留全部五个字段,并且每项事实只陈述一次。结果较小时,每个字段可占一行;省略空表格,不要复制已链接的产物:

  1. **结果:**技能专属结论和有证据支持的结果。
  2. **范围:**审查/变更的范围、排除项、基线和重要假设。
  3. **证据:**以下技能专属字段;区分事实、推断和未经验证的说法。链接产物;适用时使用表格。
  4. **验证:**检查及其结果、不可用的证据、适用的清理工作/外部状态。
  5. 完成情况:Checklist: X/Y complete;Incomplete: None,或逐项列出每个 UNPROVEN 项的原因、对结果的影响及确切的后续操作;残留风险和所需决策。

**技能专属证据:**能力、受保护的契约、使用方、当前成本以及行为/价值基线。比较考虑过的替代方案及 SELECTED / REJECTED 的理由。逐项说明迁移的变更、验证、可比较的价值指标及 KEEP / DISCARD。包括代码/依赖项和工作流差异、受影响的测试操作、残留的自定义代码/兼容性、未完成的过渡工作,以及本次运行负责的测量/差异/回滚/清理证据。

评论

支持 Markdown