菜单
当用户要求将 MySQL 或 Percona Server 补丁从一个版本移植到另一个版本，并要求实际完成 patch 分析、版本差异比对、代码适配、编译、安装、启动验证、功能验证、patch 生成或提交时使用。适用于多版本 MySQL 内核补丁适配、兼容性修复、MTR 或 sysbench 验证，以及将补丁移植过程标准化为低人工参与流水线。
默认使用会先检查来源的 Prompt；你也可以切换为直接命令，或下载本地副本。
决定是否安装前，请先阅读 SKILL.md，以及 SkillsMP 当前展示的配套文件。
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
直接命令不会经过审查 Prompt；运行前请先检查来源。
npx skills add https://github.com/kunpengcompute/skills --skill mysql-patch-multi-version-adaptation命令会保持在同一行。复制前请横向滚动并检查完整内容。
想先保存到本地？可下载 SkillsMP 当前能够提供的文件。
OmniOperator 列式算子调试专家。Use when Codex needs to 做 Omni 与 Spark 结果对比、关闭或开启列式算子定位问题、分析物理计划、处理 Coredump、排查数据不一致、或阅读 Omni 调试工作流。
Full-repo scan of Velox / Spark SQL / OmniOperator expression support status, generating an ecosystem benchmark report. Triggers: expression coverage research, competitive analysis, Omni missing expression inventory, type matrix analysis.
Full-repo scan of Spark SQL / Gluten / OmniOperator / Velox physical operator support status, generating an ecosystem benchmark report. Triggers: operator coverage research, Omni missing operator inventory, Spark physical operator pushdown status, Gluten fallback analysis, Substrait Rel to Omni PlanNode mapping matrix, operator type/config support matrix, competitive analysis vs Velox. Use this skill when the user asks "which operators are currently supported", "which operators are missing", "operator status analysis", "operator coverage", "fallback inventory".
基于 SOC 职业分类
正在显示 SKILL.md
| name | mysql-patch-multi-version-adaptation |
| description | 当用户要求将 MySQL 或 Percona Server 补丁从一个版本移植到另一个版本，并要求实际完成 patch 分析、版本差异比对、代码适配、编译、安装、启动验证、功能验证、patch 生成或提交时使用。适用于多版本 MySQL 内核补丁适配、兼容性修复、MTR 或 sysbench 验证，以及将补丁移植过程标准化为低人工参与流水线。 |
用于 MySQL / Percona Server 补丁跨版本移植。目标不是只做静态分析，而是尽量完成：
8.0.x 的优化补丁移植到另一个 8.0.y[阶段] [分析] [修改] [问题] [解决] [验证]至少确认以下信息：
如果用户没有给全，先从本地仓库和历史命令补齐，不要立刻停下提问。
如果用户只说“把某个能力移植到目标版本”，而仓库多个分支都存在相近 patch，必须先做参考 patch 选择。
默认先查看 boostkit/mysql 代码仓各分支中的 boostdb-patches/，优先从本地对应镜像仓库读取分支和 patch；如果本地镜像缺失，再看用户提供的源码树。
选择规则按优先级从高到低：
具体解释：
8.0.36 这种目标版本，通常优先参考 8.0.43 一类近版本，而不是 8.0.25。对于 plan cache 这类功能，8.0.36 目标版本更适合参考 MySQL-Percona-Server-8.0.43-34 的 patch，而不是 MySQL-8.0.25。原因是：
8.0.25 分支里根本没有同能力 patch8.0.43-34 与 8.0.36 生命周期、optimizer、prepared statement 结构更接近8.0.43-34 patch 自带更完整的测试和修复历史做完选择后，必须在进度输出里明确说明：
参考规则见：
references/reference-patch-selection.md辅助脚本见：
scripts/select_reference_patch.sh先回答四个问题：
如果 patch 很大，先用命令抽取修改面：
git apply --statgit apply --summaryrgsed -n模块归类优先按以下维度整理：
对 patch 修改过的文件逐个比对目标版本：
冲突原因必须归类，不要只说“apply 失败”：
详细检查清单见：
references/checklists.md先做非破坏性检查：
git apply --check如果大部分 hunk 可用，再在可接受的工作树上做：
git apply --reject --whitespace=nowarn要求：
.rej 文件辅助脚本见：
scripts/mysql_patch_adapt_snapshot.sh人工修复按以下顺序处理：
常见原则：
必须真实执行用户给定编译命令。不要自己换一套构建系统，除非原命令不可用且已证明阻塞。
遇到编译错误时：
至少验证：
mysqld --versionmysqladmin ping如果 patch 与 prepared statement / optimizer / range / filesort / tmp table 有关，必须优先设计针对性 SQL。
如果用户给过故障复现命令，例如 sysbench，要尽量复现同路径验证。
生成的新 patch 要满足：
优先用：
git format-patch如果用户要求提交到远程仓库：
提交前还必须检查“本次改动边界”：
git add <file> 精确暂存；不要把无关改动一起打包进一次提交提交信息必须专业化，不允许使用临时标题，例如：
fixwipport patchupdate默认提交标题格式：
[optimization] ...[bugfix] ...[compatibility] ...[refactor] ...[test] ...选择规则：
[optimization][compatibility][bugfix][refactor][test]默认提交正文格式：
推荐风格示例：
[optimization] Accelerate UTF-8/UTF-8MB4 charset handling on AArch64 with NEON/SVE[compatibility] Adapt plan cache patch to MySQL 8.0.30 lifecycle and PSI interfaces[bugfix] Fix odd-length destination handling in utf8mb4 strxfrm path推荐正文写法示例：
Add AArch64 SIMD implementations for ...Update strings/CMakeLists.txt to probe ...Wire optimized paths into ... while preserving generic fallbacksExtend gunit and mysql-test coverage for ...如果用户指定“参考某个 commit 的提交信息风格”，必须先读取该 commit，再复用它的结构和措辞粒度，不要只模仿标题前缀。
如果需要 amend 或重写提交信息，必须保持代码内容边界不变；只修改提交元数据，不顺手混入额外源码调整。
每次适配结束后，都要沉淀一条案例记录，最少包含：
建议记录到 skill 目录下的案例数据文件：
references/adaptation-cases.jsonl新增案例时，优先追加，不要覆盖历史。
每完成一批适配后，要从案例中反推规则库更新：
如果同类任务连续出现失败或高人工修复占比，必须更新：
references/reference-patch-selection.mdreferences/checklists.mdreferences/case-*.md闭环说明见：
references/continuous-improvement.md记录脚本见：
scripts/record_adaptation_case.py默认用下面结构持续汇报：
[阶段]
正在做什么
[分析]
发现了什么
[修改]
改了哪些文件
[问题]
遇到了什么错误
[解决]
如何修复
[验证]
验证结果
最终总结至少覆盖：
调用本 skill 时，优先采用三层提示结构：
模板见：
references/prompt-template.mdreferences/reference-patch-selection.md本 skill 内置了一份实际案例：
references/case-plan-cache-8.0.43-to-8.0.36.md当用户做的是 MySQL 8.0.x 之间的 patch 迁移，尤其是 optimizer / prepared statement / plan cache 相关 patch，优先参考这份案例。
只有同时满足以下条件，才能称为“移植完成”：
mysqld 成功启动如果其中任意一项未完成，结论必须写成“部分完成”，并明确剩余阻塞。