What problem does it solve? When generating or migrating AscendC operators for Ascend NPU hardware, agents often produce ad-hoc artifacts like Python-embedded C++ source strings or one-off run.sh scripts that cannot be rebuilt or verified. This Skill defines a standard, repeatable project contract so every dsl=ascendc task delivers a CMake-buildable AscendC project plus a thin Python wrapper that the verification pipeline can load and evaluate. ## Core Features & Use Cases - Standard project layout: Enforces a task directory with kernel.py exposing a single ModelNew class and an ascendc_op/ CMake project containing op_kernel, op_host, and op_extension sources. - Lazy extension loading: Specifies that compiled .so files are loaded via torch.ops.load_library inside ModelNew._load() or forward(), avoiding import-time compilation and device selection. - CMake and registration conventions: Documents NPU_ARCH/ASCEND_HOME_PATH variables, TORCH_LIBRARY_FRAGMENT registration under torch.ops.npu, host-side tiling derivation, and Meta function requirements for correct output shapes. - Use Case: When asked to implement an elementwise or broadcast operator for Atlas A2/A3 hardware, follow the Vector template path: create the tiling header, KernelXxx class with Init/CopyIn/Compute/CopyOut/Process, the PyTorch bridge, and register.cpp so the verifier can build and validate the operator. ## Quick Start Ask the agent to generate an AscendC direct-invoke operator project for your target op following this contract, with kernel.py wrapping torch.ops.npu calls and a CMake-buildable ascendc_op directory.
