菜单
当用户想把自定义算子工程中的 kernel 模板改造成 `<<<>>>` kernel 直调形式，或从自定义算子工程中抽取某个 kernel 模板并转换成 `<<<>>>` 直调方式时使用。触发：用户提到"自定义算子转直调"、"从算子工程抽 kernel"、"kernel 模板改 `<<<>>>`"等。不适用于从零开发新算子
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Profile PyPTO kernels in-core with the Ascend msprof op-simulator — cycle-accurate per-kernel traces. Use when the user wants to profile a built case, inspect kernel timing or instruction streams, or generate MindStudio Insight traces.
Tune cube/matmul tile sizes (row tile, N fragment, K fragment) for a PyPTO kernel — analytic hints, an on-chip buffer constraint model, and an empirical device sweep. Use when optimizing a matmul/cube's throughput, sizing the row / N / K tiles, resolving Mat (L1) / L0C / UB buffer overflows, or trading one tile dim for another.
Locate which pypto commit introduced a precision regression. Only pypto and its corresponding simpler (submodule) are tracked — ptoas and pto-isa versions are not part of the bisect. If the culprit is a simpler submodule bump, performs a second-level bisect within simpler.
Reproduce a reported problem, collect dependency versions, and create a GitHub issue. Use when the user wants to file a bug, request a feature, or create any GitHub issue.
Ascend C 开发资源索引（本地+在线）。提供：(1) 本地 API 文档索引、示例代码映射，(2) 在线文档搜索功能，(3) 资源查找优先级，(4) Explore Agent 使用指南。优先使用本地资源，仅在本地检索不到时使用在线搜索。
Complete git commit workflow including pre-commit checks, staging, message generation, and verification. Use when creating commits or preparing changes for commit.
| name | ascendc-custom-op-to-kernel-launch |
| description | 当用户想把自定义算子工程中的 kernel 模板改造成 `<<<>>>` kernel 直调形式，或从自定义算子工程中抽取某个 kernel 模板并转换成 `<<<>>>` 直调方式时使用。触发：用户提到"自定义算子转直调"、"从算子工程抽 kernel"、"kernel 模板改 `<<<>>>`"等。不适用于从零开发新算子 |
<<<>>> kernel 直调改造这个 skill 处理的是两类任务：
<<<>>> kernel 直调形态<<<>>> 方式目标不是“把文件复制过来”，而是识别并拆解现有实现里的 kernel、tiling、host glue 与外部依赖，把它整理成一个 本地可维护、依赖闭环清晰、kernel 语义不变、可直接 launch 的版本。
它默认解决的是：
op_kernel/archXX 或类似源树中抽出 header-only / inline kernel 代码#include ".. 开头的跨目录依赖<<<>>> kernel 直调所需的最小必要改写它默认 不处理：
aclnn / OpDef / 注册流程它可以处理两类任务：
<<<>>> 直调入口 / standalone sample host glue 适配如果用户已经明确告诉你：
就不要再拆成两个技能链路，直接按同一条自定义算子转直调工作流推进。
优先把任务识别为以下一种：
arch35/ 目录搬到当前路径，删掉相对 include，并把依赖函数搬到本地../../rms_norm/...、../inc/platform.hDataCopyImpl / ComputeRstd / CeilDiv，不整包复制上游头文件*_apt.cpp 一起放到目标目录，并显式指出还缺哪些外部宏/tiling 结构如果用户明确说：
则不要误判成“只做 kernel 去耦”；要按 kernel + tiling + standalone sample/story host glue 的完整链路处理。
<<<>>> 直调链路先确认这 3 件事：
op_kernel/ 或 op_kernel/archXX/*_apt.cpp / tiling / <<<>>> 入口一并可独立编译调用默认假设：
但如果用户明确要求 standalone story / cann-samples / <<<>>> 直调：
aclnn / OpDef / 注册链路用 Glob / Read / Grep 先确认：
.h / .cpp*_apt.cpp）archXX 特化头特别注意：
common / regbase_common / base 头里.. 相对 include，并建立“符号级依赖图”必须先找出所有：
#include "../..."#include "../../..."然后对每个相对 include 做两件事：
不要因为某个头被 include 了，就整包复制整个头文件。
输出时至少要列出：
默认推荐结构：
xxx_local_deps.h只有在依赖非常少时，才考虑把外部内容直接塞回原头文件。
推荐结构通常是：
foo_regbase.hfoo_regbase_common.hfoo_regbase_split_d.hfoo_local_deps.hfoo_apt.cpp 或 foo_apt.h这样做的好处：
把依赖分成 4 类来搬。
典型例子：
platform::GetUbBlockSizeplatform::GetVRegSize如果只是返回固定常量，优先改成：
constexpr 包装platform namespace 子集典型例子：
BUFFER_NUMDOUBLE_BUFFER_NUMONCE_VECTOR_SIZECeilDivis_samebfloat16_t 兼容定义这类通常来自某个 *_base.h，但真正需要的往往只是一小段，不要整包搬。
典型例子：
V_LENGTHCeilAlignComputeMultiLevelRstdcastTraitB162B32castTraitB322B16这类最容易出现“命名空间错位”。必须核实符号真实归属，而不是照抄 using。
典型例子：
DataCopyImplComputeSumComputeRstdComputeMultiLevelReduce只复制 当前 kernel 真正调用到的函数，并补齐它们的直接闭包。
不要把整个上游 regbase_common.h 原样拖进目标目录。
<<<>>> 直调 / standalone story，再补 tiling / host glue，但保持 kernel 独立当用户明确要 cann-samples / standalone story / <<<>>> 直调时：
op_host 的 tiling 逻辑改成本地 helper，而不是继续绑定原工程注册框架<<<>>> launch 方式工作，而不是继续依赖原工程分发宏这里的重点是：
如果源目录中已经有一个 *_common.h 明显是从上游算法模板改出来的：
典型坑：
using RmsNorm::castTraitB162B32;NormCommon处理原则：
using 归属如果某个 using 或 include 只是在源码里“看起来像要用”，但实际未被引用：
典型例子：
using RmsNorm::DataCopyCustom; 只声明不使用如果用户只要求 kernel 本地化，做到以下即可视为完成：
.. 相对 include但如果入口文件 *_apt.cpp 还依赖：
DTYPE_X1GET_TILING_DATA_WITH_STRUCTTILING_KEY_IS必须在结果里明确说明：
常见做法：
GET_TILING_DATA_WITH_STRUCT 依赖GM_ADDR，host 侧 device 指针也从一开始就保持 GM_ADDR常见做法：
GM_ADDR inputDevice = nullptr;aclrtMalloc(reinterpret_cast<void**>(&inputDevice), size, ...) 申请inputDeviceaclrtFree(inputDevice) 释放不要这样做：
void*std::unique_ptr<void> 里reinterpret_cast<GM_ADDR>(ptr)原因：
void* 到 GM_ADDR 的这种转换GM_ADDR，host 侧也要沿着这条 ABI 一致到底尤其注意：
is32BAligned == 1 的路径is32BAligned == 0 的路径baseColLen，还是 AlignUp(baseColLen, ubMinBlockLen)典型例子：
baseRowLen = maxTileLen / baseColLenbaseRowLen = maxTileLen / AlignUp(baseColLen, ubMinBlockLen)不要为了“代码更整齐”把两条公式都改成后一种。
原因：
完成这类任务时，结果里至少要给出：
.h / .cpp.. includeusing如果任务明确是 <<<>>> 直调 / standalone story / cann-samples，结果中还应补一句：
快速执行时，直接按 references/custom-op-to-kernel-launch-checklist.md 做静态核验。
注意：
<<<>>> 直调，它仍可用于检查 kernel 闭包是否干净，但不能替代你对 host tiling / direct-launch glue 的单独判断至少做以下静态检查：
在目标文件集合中搜索：
#include "../#include "../../期望：无匹配。
重点搜：
using RmsNorm::castTraitB162B32using RmsNorm::castTraitB322B16如果真实定义不在 RmsNorm，必须修正。
确认以下符号要么来自本地 helper，要么来自稳定 SDK 头：
CeilDivCeilAlignDataCopyImplComputeSumComputeRstdComputeMultiLevelReduceComputeMultiLevelRstd确认并删除：
using如果同时适配了 *_apt.cpp 或 *_apt.h，必须明确检查：
DTYPE_X1GET_TILING_DATA_WITH_STRUCTTILING_KEY_IS如果最终 direct-launch 入口参数仍然是 GM_ADDR，必须明确检查：
GM_ADDRaclrtMalloc 是否按 reinterpret_cast<void**>(&devicePtr) 形式写入这个 GM_ADDR 变量devicePtrreinterpret_cast<GM_ADDR>(voidPtr) 这种调用点强转期望：
void* -> GM_ADDR 的临门一脚强转如果把 host tiling 从原工程提取成本地 helper，必须明确检查：
重点关注：
baseRowLenbaseColLentileLengthis32BAligned 相关分支*_base.h / *_common.h 原样复制这会把大量无关实现也拖进来，后续更难维护。默认只搬最小闭包。
很多符号是通过中间头间接暴露的。迁移时必须追到真实定义位置。
这样会让当前目录暂时“看起来干净”，但实际符号解析断掉。
用户如果只要 kernel 代码适配，就不要主动扩展到 host / graph / 注册。
*_apt.cpp 很容易在 include 改完之后，看起来也“在当前目录里了”，但其实仍不能独立编译。必须显式说明。
void* 持有 device 指针，launch 时再强转成 GM_ADDR这在普通 C++ 里看起来像小问题，但在 AscendC direct-launch 场景里经常会 直接编译失败。
正确做法是：
GM_ADDRGM_ADDRaclrtMalloc(reinterpret_cast<void**>(&devicePtr), ...)devicePtr看起来像是在“清理重复代码”，但这类改法最容易偷偷改掉原始切块语义。
典型危险动作：
AlignUp(baseColLen, ubMinBlockLen)结果往往不是立即编译错，而是：
当源目录是：
add_rms_norm/arch35/add_rms_norm_regbase.hadd_rms_norm/arch35/add_rms_norm_regbase_common.hadd_rms_norm/arch35/add_rms_norm_regbase_split_d.h典型处理方式是：
add_rms_norm_local_deps.h../inc/platform.h../../rms_norm/rms_norm_base.h../../rms_norm/arch35/rms_norm_regbase_common.h../../norm_common/reduce_common_regbase.hGetUbBlockSize / GetVRegSizeBUFFER_NUM / DOUBLE_BUFFER_NUM / ONCE_VECTOR_SIZE / CeilDiv / is_sameV_LENGTH / CeilAlign / ComputeMultiLevelRstd / castTraitB162B32 / castTraitB322B16DataCopyImpl / ComputeSum / ComputeRstd / ComputeMultiLevelReducecastTraitB162B32 / castTraitB322B16 应归到 NormCommonadd_rms_norm_apt.cpp，要额外声明：
DTYPE_X1 / GET_TILING_DATA_WITH_STRUCT 仍来自外部编译环境*_apt.cpp 改成 *_apt.hadd_rms_norm(...) 分发GET_TILING_DATA_WITH_STRUCT / TILING_KEY_ISDTYPE_X1 / DTYPE_X2 / DTYPE_GAMMA / DTYPE_Y / DTYPE_RSTD / DTYPE_X 这类模板参数，参数声明仍保持原来的 GM_ADDR，不要擅自改成 __gm__ T* 形式*_apt.h 默认不要写 using namespace；优先在入口实现里使用 ::AscendC::...、::AddRmsNorm::... 这类显式限定，避免把命名空间污染扩散给包含方#if defined(__NPU_DEVICE__) ... #endif 包起来，避免 host 侧包含入口头时直接编译 device 实现add_rms_norm_local_deps.h / add_rms_norm_regbase_common.h / add_rms_norm_regbase.h / add_rms_norm_regbase_split_d.h 这类 kernel 实现头，就把 __NPU_DEVICE__ 宏放在这些实现头里，而不是优先放在入口头 *_apt.h优先使用：
Glob：找文件Grep：找 include 和符号引用Read：读源文件和定义文件Edit：改现有文件Write：只用于新增 helper 头或新增目标副本不要用 shell 的 grep/cat/find 代替这些专用工具，除非确实没有替代方案。
这类任务的核心不是“把文件复制过来”，而是：
把 kernel 代码适配成一个最小依赖闭包明确、语义不变、目标目录内可维护的本地版本。