Structural Refactoring 是一个围绕「保持行为不变的结构性代码重构」展开的技能，来源为 lidessen/rossovia。其核心判断是：如何把当前代码重新组织成更好的结构，同时保留真正重要的行为与约束。
用途 该技能把重构当作语义保持问题，而不是文件搬移任务。它不根据文件长度、目录风格、AST 图或可用智能体数量来推断边界，也不用于决定新的产品行为，或自行接受自己的结果。它适用于跨有意义边界的重构请求，例如拆分大型模块等。
主要能力
- 在编辑前建立重构基础：明确实际目标与观察到的行为、结构压力或请求的变更、保持契约、观察到的影响场、最强的「不重构」替代方案、最小候选边界，以及验证与验收负责人。
- 恢复具体整体：阅读目标、调用方、测试、公共契约、已接受的设计与近期相关历史，并在可行时运行当前验证面，区分观察事实与推断出的职责和偏好。
- 对变更分类：确认任务改变代码结构，同时意图保留指定的可观察行为；相邻问题通过边界路由处理，而不是隐藏在重构内部。
- 构建最小充分影响场：只追踪可能改变边界或验证决策的内容，包括公共入口点与直接消费者、状态/效果/生命周期/错误/持久化/并发边界、依赖方向与强耦合定义、不变量与高风险路径，以及能暴露漂移的测试、类型、构建检查与运行时观察。
- 比较边界：保留最强的「不重构」理由，并比较暴露真实权衡所需的最少替代方案；拒绝只缩短文件却增加跨边界流量、重复状态、不稳定接口或迁移风险的拆分。
- 按比例分配注意力：默认由一个智能体处理整个影响场；仅当不同所有权、效果、调用方或保持风险可能被遗漏且可独立评审时，才使用工作单元、子智能体或并行专家视角。
- 设计可逆检查点：按真实依赖排序，使每个检查点都能通过类型检查或运行聚焦验证；除非为保持契约所必需且被明确命名，否则不把行为变更、API 重设计、格式变动与无关清理混入重构。
- 逐检查点执行与观察：同步更新定义与消费者，检查差异，运行能暴露预测失败的最小检查；当观察与计划矛盾时停止并修订影响场。
- 通过独立验证定案：将最终结构与保持契约、公共表面、影响场和已接受边界进行对比，记录可追溯检查与残余风险；重大重构由指定评审者或人工接受，实施智能体不得把自己的报告变成事实。
使用方式 资料未提供具体安装命令或调用方式。技能文本描述了工作流程：先建立重构基础，再恢复具体整体、分类变更、构建影响场、比较边界、分配注意力、设计检查点、逐点执行，最后独立验证。若宿主声明了 Sequence 与匹配解释，则使用宿主版本；否则使用该技能在 references/sequence.md 中的只读回退，仅读取 P07、P02、P13、P15。
适用场景
- 跨有意义边界的重构，例如拆分大型模块。
- 需要保持指定可观察行为与硬约束的结构调整。
- 需要明确影响场、可逆检查点与独立验收的重构任务。
限制
- 不用于决定新的产品行为，也不自行接受结果。
- 若请求的变更只是影响已可见的局部清理，应走普通纪律化开发。
- 若期望的架构或行为尚未确定，应先路由该决策再重构。
- 工作单元是可选执行者与证据来源，不是该技能的拥有者或必需阶段；AST 与代码图工具是可选观察，不是可移植运行时依赖。
- 通过语法或类型检查只能证明它们所观察到的属性；若行为等价性、调用方影响或所有权仍不确定，应报告不确定性，不得声称完成。
资料未提供收费、价格、平台支持或效果数据。