DSH 处在开发者预览期，破坏性变更频繁。每次 harness 升级，插件作者都要人工跟进：哪个 API 改了名、哪个注册点搬了家、哪个行为语义变了。官方团队自己也清楚这个痛——2026-08-30，一位官方团队成员在 Discussion #5120（12 赞同、19 条评论）里亲自发问：「有没有人搞过升级 dsh 插件代码来支持新 dsh 版本的 skill？」
需求信号
- #5120 是官方亲自征集，不是用户抱怨——这在需求信号里是独一档：做出来就有官方层面的关注与潜在采纳。
- 评论区的作者们已经贴出了自己维护 20 个插件时的升级踩坑清单，等于有人帮你把需求文档写了一半。
缺口在哪
只有雏形：oh-my-dsh/dsh-plugin-upgrade-skill（在讨论中被提及）与 PerryLink/dsh-plugin-upgrade-015（0★）。一个被官方点名、尚无赢家的方向。
建议形态
Skill（SKILL.md + 检查脚本），不是插件：让 Agent 拿到「把当前插件从 dsh X 升到 Y」的任务时，能按固定方法执行——读两个版本的 API 差异、扫描插件代码里的受影响调用点、逐个改写、跑 typecheck、给出人工复核清单。
实现要点
- 核心资产是「版本间 API 差异数据」：从官方 release notes 与 persistence-changes 等变更记录里结构化出来，而不是让模型现场猜。
- 参考本站维护的 alldsh skills 的形态：SKILL.md 写方法，脚本做机械检查，各自为政。
- 与 #5120 评论区的踩坑清单逐条对齐——那是真实案例库。
最小可行版本
只覆盖最近一次破坏性版本升级（比如 rc.6 → 0.1.x）的迁移，把踩坑清单里的 10 个高频点做成检查脚本。
风险与边界
官方迟早会把这类能力内化进 CLI（upgrade 命令），这个 skill 的生命周期可能只有几个版本。但窗口期内它是插件作者圈层里性价比最高的影响力入口——而且迁移数据本身就是持续资产。
FAQ
为什么做成 skill 而不是插件？
因为执行者是 Agent：迁移是一个「读代码→改代码→验证」的智能体任务，skill 是给 Agent 的方法论载体，比 GUI 插件更贴合场景。