[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M69AJ65WPPT5DS4JA8YWN37B":3,"skill-same:01M69AJ65WPPT5DS4JA8YWN37B":73},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":23,"publishedAt":44,"linkOnly":45,"markdownContent":46,"markdownBody":47,"frontMatter":48,"refName":49,"commitSha":50,"skillDirectory":51,"forksCount":52,"repositoryHtmlUrl":53,"repositoryHomepageUrl":54,"ownerHtmlUrl":55,"ownerBlogUrl":56,"ownerDescription":57,"updatedAt":58,"install":59,"resources":72},"01M69AJ65WPPT5DS4JA8YWN37B","workspace-estimation-shared-header",null,"Use when editing a boundary-safe shared header meant to be included by both in-tree and shared-provider\u002Fplugin-bridge code (e.g. include\u002Fonnxruntime\u002Fcore\u002Fframework\u002Fworkspace_requirement.h, or any future header supporting OrtKernelWorkspaceEstimateFunc \u002F DeclareWorkspaceRequirements per issue #29775's Phase-A workspace-estimation roadmap), or when a workspace-estimation math helper needs to be callable from a future plugin EP DLL. Covers a Node forward-declaration ODR trap and the math-helper vs. graph-parsing-wrapper reuse boundary discovered while implementing PR #29811 (MatMulNBits pilot).","microsoft\u002Fonnxruntime","microsoft","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F6154722?v=4","01M698VYDXZ6JW5WH3CRV650R8","Microsoft","01M69AGY0EW9AJXAH7HK223SQZ",22286,"MIT","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fonnxruntime\u002Fblob\u002Fmain\u002F.github\u002Fskills\u002Fworkspace-estimation-shared-header\u002FSKILL.md",[18],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000031","产品经理","PROFESSION","适用职业",[24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43],"workspace estimation shared header","shared","workspace","estimation","when","safe","phase","implementing","tree","issue","Wrapper","roadmap","bridge","math","node","parsing","graph","framework","code","pr","2026-11-10 10:12:30",false,"---\nname: workspace-estimation-shared-header\ndescription: \"Use when editing a boundary-safe shared header meant to be included by both in-tree and shared-provider\u002Fplugin-bridge code (e.g. include\u002Fonnxruntime\u002Fcore\u002Fframework\u002Fworkspace_requirement.h, or any future header supporting OrtKernelWorkspaceEstimateFunc \u002F DeclareWorkspaceRequirements per issue #29775's Phase-A workspace-estimation roadmap), or when a workspace-estimation math helper needs to be callable from a future plugin EP DLL. Covers a Node forward-declaration ODR trap and the math-helper vs. graph-parsing-wrapper reuse boundary discovered while implementing PR #29811 (MatMulNBits pilot).\"\n---\n\n# Workspace-Estimation Shared Header: DLL-Boundary Pitfalls\n\nLessons from implementing the two-level (`EstimateWorkspace` \u002F `DeclareWorkspaceRequirements`)\nworkspace-size estimation pilot for `MatMulNBits` (issue #29775 Phase-A, PR #29811). The\n`WorkspaceRequirement` struct in `include\u002Fonnxruntime\u002Fcore\u002Fframework\u002Fworkspace_requirement.h` is\ndesigned to be included by both in-tree kernel code and future plugin-EP adapter code — this is exactly\nthe kind of dual-included, DLL-boundary-crossing header where these gotchas apply.\n\n## 1. Never forward-declare `Node` in a header included from both worlds\n\n**Symptom:** a compile failure or, worse, a silent type mismatch that depends on include order —\nbecause `onnxruntime::Node` is not one type across the whole codebase. In-tree code sees `class Node`\nfrom `core\u002Fgraph\u002Fgraph.h`. Shared-provider\u002Fplugin-bridge code (anything reachable from a plugin DLL)\nsees a *different* `Node` type from a provider-bridge header (e.g. `struct Node final`). These are two\ndistinct types that happen to share a name — different \"ODR worlds.\"\n\n**The trap:** writing `class Node;` (or any forward-declaration of `Node`) in a header that might be\n`#include`d from both worlds. Whichever world's real definition gets included later in the same\ntranslation unit can clash with your forward-declaration's class-key (`class` vs `struct`), or — worse\n— the header can compile fine in isolation and only fail (or silently pick the wrong type) once combined\nwith a specific set of other includes.\n\n**The fix:** omit the forward-declaration entirely. Don't try to avoid the `#include` of the real `Node`\nheader for compile-time savings in a shared, dual-included header — let each translation unit's own\nreal includes provide whatever `Node` type it needs. If you only need a pointer\u002Freference and think a\nforward-declare is a safe optimization, it is not safe here specifically because the two worlds disagree\non the underlying type.\n\n**How to confirm you're clear:** the header must build cleanly when included from an in-tree-only\ntranslation unit AND (once such a target exists) from a plugin-DLL translation unit, without relying on\nwhich one happens to be included first.\n\n## 2. Keep the shared\u002Freusable half of a workspace-estimation function free of graph types\n\nWhen a kernel's workspace-size computation needs to be callable from both in-tree and (eventually)\nplugin code, split it into two pieces:\n\n- **Pure-math core** — takes only plain shape\u002Farch integers (e.g.\n  `ComputeFpAIntBGemmWorkspaceSize(int m, int n, int k, int sm, int multiProcessorCount)`). No\n  `Node&`, no `NodeArg`, no `TensorShape` parsing, no ORT graph types at all. This is the part a future\n  plugin implementation can call *verbatim* — plugin kernels don't have `Node&` access, only the C-ABI\n  shape representation (`OrtNode`, `Node_GetInputShape`).\n- **Graph-parsing wrapper** — extracts the plain integers from `const Node&`\u002F`NodeArg`\u002F`TensorShape` (or\n  from the plugin's C-ABI shape accessors). This half is inherently different per build configuration and\n  is NOT reusable across the DLL boundary; it must be reimplemented against whichever shape\n  representation the caller has.\n\n**Why this matters concretely:** if you accidentally let the pure-math core accept or touch an in-tree\ngraph type (even just to read one field), you've made it impossible to reuse from the plugin path without\neither (a) linking in-tree graph headers into the plugin DLL (defeats the purpose of a plugin boundary) or\n(b) duplicating the whole function. Keep the split clean from the start.\n\n**How to confirm you're clear:** grep the pure-math function's signature and body for any ORT graph type\n(`Node`, `NodeArg`, `TensorShape`, `GraphViewer`, etc.) — it should only ever see plain scalars\n(`int`\u002F`int64_t`\u002F`size_t`) and, at most, opaque device-property values already extracted by the caller.\nIf you find a graph type anywhere in that function, the split has leaked and needs to be pulled apart\nbefore a plugin implementation can reuse it.\n\nRelated, not yet built: `docs\u002Fannotated_partitioning\u002Ffuture_directions_constrained_env.md` (Phase A \u002F\nplugin-ABI sections) describes the intended plugin-side C ABI surface for `DeclareWorkspaceRequirements`,\nbut as of PR #29811 no plugin-side implementation exists yet — see that doc's \"Cost of a Real\nPlugin-Side Override (Deferred)\" note for what's still missing beyond just following this split.\n","# Workspace-Estimation Shared Header: DLL-Boundary Pitfalls\n\nLessons from implementing the two-level (`EstimateWorkspace` \u002F `DeclareWorkspaceRequirements`)\nworkspace-size estimation pilot for `MatMulNBits` (issue #29775 Phase-A, PR #29811). The\n`WorkspaceRequirement` struct in `include\u002Fonnxruntime\u002Fcore\u002Fframework\u002Fworkspace_requirement.h` is\ndesigned to be included by both in-tree kernel code and future plugin-EP adapter code — this is exactly\nthe kind of dual-included, DLL-boundary-crossing header where these gotchas apply.\n\n## 1. Never forward-declare `Node` in a header included from both worlds\n\n**Symptom:** a compile failure or, worse, a silent type mismatch that depends on include order —\nbecause `onnxruntime::Node` is not one type across the whole codebase. In-tree code sees `class Node`\nfrom `core\u002Fgraph\u002Fgraph.h`. Shared-provider\u002Fplugin-bridge code (anything reachable from a plugin DLL)\nsees a *different* `Node` type from a provider-bridge header (e.g. `struct Node final`). These are two\ndistinct types that happen to share a name — different \"ODR worlds.\"\n\n**The trap:** writing `class Node;` (or any forward-declaration of `Node`) in a header that might be\n`#include`d from both worlds. Whichever world's real definition gets included later in the same\ntranslation unit can clash with your forward-declaration's class-key (`class` vs `struct`), or — worse\n— the header can compile fine in isolation and only fail (or silently pick the wrong type) once combined\nwith a specific set of other includes.\n\n**The fix:** omit the forward-declaration entirely. Don't try to avoid the `#include` of the real `Node`\nheader for compile-time savings in a shared, dual-included header — let each translation unit's own\nreal includes provide whatever `Node` type it needs. If you only need a pointer\u002Freference and think a\nforward-declare is a safe optimization, it is not safe here specifically because the two worlds disagree\non the underlying type.\n\n**How to confirm you're clear:** the header must build cleanly when included from an in-tree-only\ntranslation unit AND (once such a target exists) from a plugin-DLL translation unit, without relying on\nwhich one happens to be included first.\n\n## 2. Keep the shared\u002Freusable half of a workspace-estimation function free of graph types\n\nWhen a kernel's workspace-size computation needs to be callable from both in-tree and (eventually)\nplugin code, split it into two pieces:\n\n- **Pure-math core** — takes only plain shape\u002Farch integers (e.g.\n  `ComputeFpAIntBGemmWorkspaceSize(int m, int n, int k, int sm, int multiProcessorCount)`). No\n  `Node&`, no `NodeArg`, no `TensorShape` parsing, no ORT graph types at all. This is the part a future\n  plugin implementation can call *verbatim* — plugin kernels don't have `Node&` access, only the C-ABI\n  shape representation (`OrtNode`, `Node_GetInputShape`).\n- **Graph-parsing wrapper** — extracts the plain integers from `const Node&`\u002F`NodeArg`\u002F`TensorShape` (or\n  from the plugin's C-ABI shape accessors). This half is inherently different per build configuration and\n  is NOT reusable across the DLL boundary; it must be reimplemented against whichever shape\n  representation the caller has.\n\n**Why this matters concretely:** if you accidentally let the pure-math core accept or touch an in-tree\ngraph type (even just to read one field), you've made it impossible to reuse from the plugin path without\neither (a) linking in-tree graph headers into the plugin DLL (defeats the purpose of a plugin boundary) or\n(b) duplicating the whole function. Keep the split clean from the start.\n\n**How to confirm you're clear:** grep the pure-math function's signature and body for any ORT graph type\n(`Node`, `NodeArg`, `TensorShape`, `GraphViewer`, etc.) — it should only ever see plain scalars\n(`int`\u002F`int64_t`\u002F`size_t`) and, at most, opaque device-property values already extracted by the caller.\nIf you find a graph type anywhere in that function, the split has leaked and needs to be pulled apart\nbefore a plugin implementation can reuse it.\n\nRelated, not yet built: `docs\u002Fannotated_partitioning\u002Ffuture_directions_constrained_env.md` (Phase A \u002F\nplugin-ABI sections) describes the intended plugin-side C ABI surface for `DeclareWorkspaceRequirements`,\nbut as of PR #29811 no plugin-side implementation exists yet — see that doc's \"Cost of a Real\nPlugin-Side Override (Deferred)\" note for what's still missing beyond just following this split.\n",{"name":5,"description":7},"main","4edd78a847b9d7755f32d6c99aa60cab2addd39b",".github\u002Fskills\u002Fworkspace-estimation-shared-header",4439,"https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fonnxruntime","https:\u002F\u002Fonnxruntime.ai","https:\u002F\u002Fgithub.com\u002Fmicrosoft","https:\u002F\u002Fopensource.microsoft.com","Open source projects and samples from Microsoft","2026-11-12 03:12:39",{"source":8,"skillName":5,"commands":60,"prompt":70,"zipAvailable":71},[61,64,67],{"tool":62,"command":63},"npx","npx skills add microsoft\u002Fonnxruntime --skill workspace-estimation-shared-header",{"tool":65,"command":66},"bunx","bunx skills add microsoft\u002Fonnxruntime --skill workspace-estimation-shared-header",{"tool":68,"command":69},"pnpm","pnpm dlx skills add microsoft\u002Fonnxruntime --skill workspace-estimation-shared-header","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fonnxruntime\u002Fblob\u002Fmain\u002F.github\u002Fskills\u002Fworkspace-estimation-shared-header\u002FSKILL.md",true,[],[74,109,133,152,168,192],{"skillNo":75,"name":76,"nameZh":6,"description":77,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":78,"categories":79,"keywords":85,"publishedAt":44},"01M69AJ3F3NXDS7QP76KZ9EX5H","webgpu-local-testing","Build and run ONNX Runtime WebGPU provider tests on Linux WITHOUT a real GPU, using a software Vulkan adapter (Mesa lavapipe). Use when you need to exercise WebGPU EP kernels off-Mac — the Linux webgpu CI leg is build-only, so software Vulkan is how you actually run WebGPU correctness tests locally. SCOPE - lavapipe only validates host-side enforce\u002Fshape bugs and MatMul-free kernels; any graph containing MatMul (including the expanded-Attention node tests) crashes lavapipe and runs ONLY on macOS-arm64 Metal, which is the source of truth for those. Covers install (dnf on Azure Linux), the --use_webgpu build flag, the onnxruntime_provider_test target, VK_ICD_FILENAMES, and the lavapipe MatMul crash gotcha.","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fonnxruntime\u002Fblob\u002Fmain\u002F.github\u002Fskills\u002Fwebgpu-local-testing\u002FSKILL.md",[80],{"categoryNo":81,"categoryName":82,"taxonomyType":83,"taxonomyTypeDesc":84},"01JBSEEDCAT000000000000008","测试与质量","SCENARIO","使用场景",[86,87,88,89,90,91,92,93,94,95,96,97,98,99,100,38,101,102,103,104,105,106,107,108,28],"testing","webgpu","webgpu local testing","local testing","local","macos","metal","vulkan","linux","test","onnx","run","ci","exercise","how","install","only","free","host","scope","you","vk","which",{"skillNo":110,"name":111,"nameZh":6,"description":112,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":113,"categories":114,"keywords":115,"publishedAt":44},"01M69AJ1ASRSCJ90HDWN05TW82","python-kwargs-setattr-security","When reviewing or fixing Python code that uses setattr() with user-controlled kwargs to configure C++ extension objects (SessionOptions, RunOptions, etc.) in ONNX Runtime. Use this to apply the allowlist pattern that prevents arbitrary file writes and other attacks via reflected property access.","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fonnxruntime\u002Fblob\u002Fmain\u002F.github\u002Fskills\u002Fpython-kwargs-setattr-security\u002FSKILL.md",[],[116,117,118,96,42,119,120,121,122,123,124,125,126,127,128,129,130,131,132,28],"python","security","python kwargs setattr security","file","access","configure","use","objects","pattern","c++","runtime","extension","via","with","attacks","python code","apply",{"skillNo":134,"name":135,"nameZh":6,"description":136,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":137,"categories":138,"keywords":139,"publishedAt":44},"01M69AHZ0M0Q90TP0KYMZ10HEP","ort-transformers-gpu-pytest","Run the ONNX Runtime transformers Python tests (onnxruntime\u002Ftest\u002Fpython\u002Ftransformers) against a GPU wheel, and confirm real cuDNN\u002Fflash SDPA dispatch. Use when a transformers pytest fails with ModuleNotFoundError onnxruntime.capi, when torch's bundled CUDA\u002FcuDNN libs shadow the ORT-built ones (wrong-version dispatch or load errors), or when you must PROVE a test exercised the cuDNN SDPA decode tier instead of silently skipping\u002Ffalling back to MATH.","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fonnxruntime\u002Fblob\u002Fmain\u002F.github\u002Fskills\u002Fort-transformers-gpu-pytest\u002FSKILL.md",[],[140,141,142,143,116,95,96,97,144,37,122,145,126,146,147,106,148,149,150,151,28],"ort transformers gpu pytest","gpu","Transformers","pytest","flash","back","tests","SDPA","errors","load","prove","decode",{"skillNo":153,"name":154,"nameZh":6,"description":155,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":156,"categories":157,"keywords":159,"publishedAt":44},"01M69AHW3EFVHBHB2S7103YA21","ort-test","Run ONNX Runtime tests. Use this skill when asked to run tests, debug test failures, or find and execute specific test cases in ONNX Runtime.","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fonnxruntime\u002Fblob\u002Fmain\u002F.github\u002Fskills\u002Fort-test\u002FSKILL.md",[158],{"categoryNo":81,"categoryName":82,"taxonomyType":83,"taxonomyTypeDesc":84},[95,160,161,162,163,96,164,97,165,166,122,126,146,167,28],"ort test","run tests","debug","debug test","debug test failures","find","execute","test cases",{"skillNo":169,"name":170,"nameZh":6,"description":171,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":172,"categories":173,"keywords":174,"publishedAt":44},"01M69AHSKXBSERP5NGAJB5E6XD","ort-release-notes","Draft ONNX Runtime release notes using preset configurations for full ORT or scoped component releases. Use when generating highlights with PR links, compiling human contributor acknowledgments from compile_contributors.py output, and applying preset path filtering.","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fonnxruntime\u002Fblob\u002Fmain\u002F.github\u002Fskills\u002Fort-release-notes\u002FSKILL.md",[],[175,176,177,178,179,180,96,43,181,182,183,184,185,186,126,187,188,189,190,191,28],"notes","ort release notes","release notes","release","component","preset","compile","compiling","contributors","releases","human","full","links","path","for","scoped","contributor",{"skillNo":193,"name":194,"nameZh":6,"description":195,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":196,"categories":197,"keywords":201,"publishedAt":44},"01M69AHQAPER0CRAZ0FTX0G2FT","ort-lint","Lint and format ONNX Runtime code. Use this skill when asked to lint, format, or check code style for C++ or Python files in ONNX Runtime.","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fonnxruntime\u002Fblob\u002Fmain\u002F.github\u002Fskills\u002Fort-lint\u002FSKILL.md",[198],{"categoryNo":199,"categoryName":200,"taxonomyType":83,"taxonomyTypeDesc":84},"01JBSEEDCAT000000000000007","代码审查",[202,203,116,204,96,42,205,206,122,207,125,126,208,189,28],"ort lint","lint","code style","format","check","files","style"]