用途：将 pi 扩展适配到最新发布的 pi 版本（默认），或适配显式指定 target=<version> 的版本。整个过程分两层：兼容层（步骤 2–4）在不改变行为的前提下修复不兼容变更，任何影响行为的修复都需用户确认；采纳层（步骤 5）调查自当前安装版本以来新增的 API/特性，逐项给出收益、范围与风险，仅在用户选中时逐个采纳。
主要步骤：1）解析目标版本并定位 SDK、阅读变更日志。目标版本解析顺序为显式 target 参数，否则取 npm dist-tags.latest（@earendil-works/pi-coding-agent，并与 GitHub releases 交叉核对）；禁止用既往报告、旧同步、GLOSSARY.md、ADR、git 历史或已安装 devDependencies 推断目标。定位已安装包可查 mise store layouts 或用 pi CLI 解析；目标版本非已安装版本时解包到临时目录（npm pack @earendil-works/pi-coding-agent@<target> 或在临时项目隔离安装）。需阅读已安装→目标范围的 CHANGELOG.md（不只最新条目），记录 Breaking Changes 与涉及扩展表面的 Added/Changed/Removed，并核对目标版本官方文档/API 参考。2）按目标 SDK 类型做类型检查：只有真实类型能发现 SDK 漂移，mock 行为测试不行；用目标版本包而非已安装版本，运行仓库自带 typecheck 或用临时 tsconfig 映射四个包后执行 tsc --noEmit，记录完整错误列表，并验证运行时导出面（所有 from "@earendil-works/..." 说明符，含子路径与深层导入）在目标版本仍可解析。3）分诊每类错误：映射为纯类型修复、契约变更或影响行为；影响行为的类别需用户确认。对镜像 pi 内部实现的扩展要做 mirror-drift 检查，比对目标 dist 源码并核对注释/ADR 中的行号引用。4）以零行为变化做最小修复，直到 tsc --noEmit 退出 0。5）调研新能力并按需采纳，逐项单独实现、类型检查、测试与写 ADR，不批量合并。6）运行测试：环境性失败要作为测试基建工作单独报告，契约变化处更新测试。7）按仓库约定写文档（ADR、GLOSSARY.md、README 兼容性说明）。8）报告解析出的目标版本、各变更类别及纯类型/运行时性质，未验证项标记 [NEEDS MANUAL VERIFICATION]，并说明是否值得发版（不执行发版）。
限制：资料中所有版本号、路径、行号、API 名称均为某次整理时的快照，目标变更日志与目标类型才是权威；资料未提供该技能的具体安装命令、收费与价格信息。