megatron-migration-generator
Megatron Migration Generator
Generate implementation-oriented migration artifacts for MindSpeed only after upstream change analysis and impact mapping have narrowed the work to a high-confidence set of items. The goal is to port the upstream feature into MindSpeed with the upstream commit as the primary reference, not to emit a tiny patch hint.
Default Output Mode
Default to report + patch, and generate the final markdown deliverable in Chinese unless the user explicitly requests another locale.
Do not default to direct code edits or automatic commits. Default to an implementation-first package, not a minimal patch sketch.
Supported Modes
reportProduce a migration report only.patchProduce a migration report plus a full implementation reference package. Default to per-feature folders containingfull.patch, splitpatches/, upstream reference metadata, implementation checklists, and explicit uncovered scope.applyEdit the local workspace without creating a commit. Use only when alignment and impact confidence are high.commitReserve for explicit user requests after patch review. Do not use as the first-pass default.
Entry Conditions
Proceed only when all of the following are true:
- MindSpeed branch is known.
- Megatron base branch is known.
- Megatron target branch or change-set is known.
- Relevant impact items already exist.
- Each migration-worthy item includes upstream commit references and enough implementation scope to tell config/runtime/wrapper/test work apart.
If any of these are missing, stop and ask for or derive the missing prerequisite instead of guessing.
Workflow
- Read the impact report.
- Separate high-confidence items from speculative items.
- For each high-confidence item, describe: the upstream event, the upstream commit and changed files, the upstream implementation units, the local adaptation target, the intended code change, the uncertainty.
- Generate:
one integrated
migration_report.mdimpact_report.jsonif needed for carry-forwardcandidate_patch.mdas a compact summary index afeatures/directory with one subfolder per migration item, each containing:full.patchfor the full local implementation draftpatches/for split patch series organized by implementation unitcandidate.patchas the compatibility entry patchREADME.md,checklist.md,package_manifest.json, andupstream_reference.json - If in
applymode, edit only the approved files and leave a clear explanation of what changed.
Safety Rules
- Never generate migration code directly from raw commit history without an impact report.
- Avoid direct edits in exploration mode.
- When the target is
megatron main, frame code output as a candidate adaptation draft, not a compatibility-guaranteed migration. - Prefer patch artifacts over commits because they are easier to review and safer when branch alignment is still evolving.
- Do not treat one local file edit as a complete feature migration when the upstream commit spans config, runtime logic, wrappers, and tests.
- When a full migration package cannot be completed from the available inputs, explicitly record uncovered implementation units, omitted scope, and manual follow-ups instead of pretending the feature is complete.
Static Validation
Keep validation lightweight and local:
- patch applies cleanly
- paths exist
- names and arguments match local code structure
- basic syntax or lint-level checks when available
- the package explains which upstream implementation units are already ported and which remain to be ported
Do not imply that training correctness, performance, or numerical accuracy has been verified.
References
- Read migration-modes.md before choosing the output form.
- Read implementation-first-package.md before generating a migration package that claims to represent a feature implementation.
- Read report-template.md for the expected integrated markdown deliverable structure. Default to Chinese report language.
- Run synthesize_full_patch_series.py after impact mapping when you want known feature commits to expand into fuller multi-file patch series instead of staying as single-file placeholders.
- Run render_migration_artifacts.py to turn an
impact_report.jsoninto reviewable report and patch-plan artifacts before any manual refinement.
More from ascend/agent-skills
ascendc-operator-dev
AscendC算子端到端开发编排器。当用户需要开发新算子、实现自定义算子、或完成从需求到测试的完整流程时使用。关键词:算子开发、operator development、端到端、完整流程、工作流编排、新建算子。
56ascendc-operator-doc-gen
为AscendC算子生成PyTorch风格的接口文档(README.md)。触发场景:编译调试通过后需要生成接口文档,或用户提到"生成算子文档"、"创建README"、"文档化算子"、"帮我写文档"(算子上下文)、"算子文档"时使用。
55ascendc-operator-design
完成AscendC算子设计 - 帮助用户完成算子的架构设计、接口定义和性能规划。当用户提到算子设计、算子开发、tiling策略、内存规划、AscendC kernel设计、两级tiling、核间切分、核内切分时,使用此skill。
55ascendc-operator-precision-eval
AscendC算子精度评估。对已编译安装的算子生成全面的精度测试用例集(≥30例),运行并生成精度验证报告。关键词:精度测试、precision evaluation、精度报告、accuracy、误差分析。执行完成后 MUST 在当前对话中展示总览、失败摘要与关键发现,不得仅附报告路径。
54ascendc-operator-testcase-gen
完成AscendC算子验证用例生成 - 帮助用户完成testcase设计。当用户提到用例设计、泛化用例生成、算子标杆、UT用例、精度用例、性能用例时,使用此skill。
54ascendc-operator-project-init
初始化 AscendC 算子工程并创建可编译的算子骨架。触发场景:(1) 用户要求创建新算子;(2) 关键词:ascendc算子、新建算子、算子目录、算子初始化;(3) 需要基于 ascend-kernel 模板快速落地。本 skill 不只建目录,还输出“可继续开发”的标准文件与检查清单。
54