What problem does it solve? Migrating an existing registry-based AscendC custom operator to a direct-invoke layout often introduces silent correctness bugs when kernel algorithms or tiling formulas are accidentally altered. This Skill defines fidelity rules so only the registration framework glue is replaced while kernel logic and tiling math stay intact. ## Core Features & Use Cases - Fidelity-Preserving Migration: Keeps kernel class layout, CopyIn/Compute/CopyOut order, loop structure, and dtype/tiling-key branches unchanged while replacing registry macros like IMPL_OP_OPTILING and REGISTER_TILING_DATA_CLASS. - Direct-Invoke Glue Generation: Guides creation of the direct launcher entry ABI, shared POD tiling struct, host launch code, PyTorch extension with torch.ops.npu registration and Meta functions, and a lazy-loading kernel.py. - Dependency Closure and Verification: Copies only the minimal symbol closure of external helpers, guards device-only code with NPU_HOST checks, and provides a checklist covering ABI consistency, tiling struct layout, and Meta shape/dtype correctness. - Use Case: You have a registry-invoke AscendC operator for Atlas A2 hardware and need it repackaged as a kernel.py plus ascendc_op/ direct-invoke project without changing its numerical behavior. ## Quick Start Migrate my registry-based AscendC operator in this workspace to a direct-invoke kernel.py and ascendc_op project while preserving the kernel algorithm and tiling formulas.
