New: 97,000+ skills indexed from GitHub repos with 100+ stars · every skill safety-checkedBrowse top skillsTop skills
Esc to closeBrowse all skills
Submit a skillBrowse skills
Submit a skillBrowse skills

Official agent skill

ONNX Runtime Shared Header Pitfalls

by microsoft in microsoft/onnxruntime

Pitfalls for editing an ONNX Runtime header shared by in-tree and plugin-bridge code: the Node forward-declaration trap and keeping workspace math free of graph types.

OfficialMITAuto-check passedDevelopment

Install ONNX Runtime Shared Header Pitfalls

skills CLI
$ npx skills add microsoft/onnxruntime --skill workspace-estimation-shared-header -a claude-code

Project install by default; add -g for ~/.claude/skills/.

GitHub CLI
$ gh skill install microsoft/onnxruntime workspace-estimation-shared-header --agent claude-code

Project scope by default; add --scope user for a personal install. Needs GitHub CLI 2.90.0 or later (public preview).

Manual copy
$ git clone --depth 1 https://github.com/microsoft/onnxruntime.git skills-src && mkdir -p .claude/skills && cp -r skills-src/.github/skills/workspace-estimation-shared-header .claude/skills/workspace-estimation-shared-header && rm -rf skills-src

Use ~/.claude/skills/ instead of .claude/skills for a personal install. The folder must contain SKILL.md.

Claude Code skills documentation · loads skills from .claude/skills/

Facts

Skill name
workspace-estimation-shared-header
GitHub stars
22k
Token cost
~1.3k tokens
SKILL.md length
619 words
Files
1
Skills in repo
14
Repo updated
First seen
Licence
MIT

At a glance

Pitfalls for editing an ONNX Runtime header shared by in-tree and plugin-bridge code: the Node forward-declaration trap and keeping workspace math free of graph types.

  • Works in 2 steps: Never forward-declare Node in a header… → Keep the shared/reusable half of a…
  • Editing a header that both in-tree and plugin-bridge code include
  • SKILL.md covers 1. Never forward-declare Node… and 2. Keep the shared/reusable…
  • Instructions only: no scripts, shell commands, URLs or credentials in SKILL.md

What it does

This skill records pitfalls for editing a header that is shared between ONNX Runtime's in-tree code and its shared-provider or plugin-bridge code, using the `WorkspaceRequirement` struct in `include/onnxruntime/core/framework/workspace_requirement.h` as the example. It comes from a pilot of two-level workspace-size estimation for `MatMulNBits`, with an `EstimateWorkspace` level and a `DeclareWorkspaceRequirements` level.

The first lesson is never to forward-declare `Node` in a header included from both sides. In-tree code sees one `Node` class and plugin-bridge code sees a different `Node` struct with the same name, so a forward declaration can clash on the class key or silently pick the wrong type depending on include order. The fix is to omit it and let each translation unit's own includes supply `Node`, then confirm the header builds from an in-tree-only unit and from a plugin-DLL unit regardless of include order.

The second lesson is to keep the reusable half of a workspace-estimation function free of graph types, splitting it into a pure-math core that takes plain shape and architecture integers and a separate graph-parsing wrapper. The text available here ends within that second section.

When your agent uses it

  • Editing a header that both in-tree and plugin-bridge code include
  • Making a workspace-estimation math helper callable from a plugin execution provider
  • Debugging a compile error or wrong type caused by a Node forward declaration

Example prompts

  • “I want to add a field to workspace_requirement.h. What do I need to watch out for with the plugin bridge?”
  • “Split this kernel's workspace-size calculation so the math part can be reused from a plugin EP.”
  • “This header compiles alone but fails with the provider bridge included. Could it be the Node forward declaration?”

Requirements

  • A checkout of the ONNX Runtime repository

Workflow steps

2 steps, taken from the step headings in SKILL.md.

  1. Never forward-declare Node in a header included from both worlds
  2. Keep the shared/reusable half of a workspace-estimation function free of graph types

What it can do on your machine

Read from SKILL.md and the folder at commit 8420709. It shows what the files ask for, not the result of running them.

  • Tool permissions

    Pre-approves nothing: there is no allowed-tools line, so your agent's usual permission prompts apply.

    From allowed-tools in the SKILL.md frontmatter.

  • Runs code

    No scripts in the folder and no shell commands in SKILL.md.

    From the folder's file list and the shell code blocks in SKILL.md.

  • Network

    No URLs in SKILL.md.

    From URLs in SKILL.md, links to its own repository left out.

  • Credentials

    Names no API keys, tokens, secrets or passwords.

    From names ending in _API_KEY, _TOKEN, _SECRET, _KEY or _PASSWORD in SKILL.md.

Context cost

ONNX Runtime Shared Header Pitfalls loads about 1.3k tokens when it runs. Until then it costs about 158 tokens; SKILL.md has 619 words of instructions outside code blocks.

Always · name and description, kept in context so the agent knows when to use it
~158
When it runs · the whole SKILL.md, loaded when a task matches
~1.3k

Estimates: characters ÷ 4, the usual rule of thumb; real counts depend on the model's tokenizer. Scripts and assets cost tokens only if the agent reads them.

Safety

Auto-check passed

The automated check found no risky patterns in SKILL.md.

Automated static check — not a guarantee. Review scripts before installing. It scans the text of SKILL.md for risky patterns (piping downloads into a shell, reading credential files, hidden Unicode, destructive commands); files beside SKILL.md are not scanned.

SKILL.md

The full file from microsoft/onnxruntime at commit 8420709, republished under its MIT licence (© microsoft). 619 words, ~1,276 tokens.

Download SKILL.mdSave it as .claude/skills/workspace-estimation-shared-header/SKILL.md (or your agent's skills folder).
name
workspace-estimation-shared-header
description
Use when editing a boundary-safe shared header meant to be included by both in-tree and shared-provider/plugin-bridge code (e.g. include/onnxruntime/core/framework/workspace_requirement.h, or any future header supporting OrtKernelWorkspaceEstimateFunc / 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).

Workspace-Estimation Shared Header: DLL-Boundary Pitfalls

Lessons from implementing the two-level (EstimateWorkspace / DeclareWorkspaceRequirements) workspace-size estimation pilot for MatMulNBits (issue #29775 Phase-A, PR #29811). The WorkspaceRequirement struct in include/onnxruntime/core/framework/workspace_requirement.h is designed to be included by both in-tree kernel code and future plugin-EP adapter code — this is exactly the kind of dual-included, DLL-boundary-crossing header where these gotchas apply.

1. Never forward-declare Node in a header included from both worlds

Symptom: a compile failure or, worse, a silent type mismatch that depends on include order — because onnxruntime::Node is not one type across the whole codebase. In-tree code sees class Node from core/graph/graph.h. Shared-provider/plugin-bridge code (anything reachable from a plugin DLL) sees a different Node type from a provider-bridge header (e.g. struct Node final). These are two distinct types that happen to share a name — different "ODR worlds."

The trap: writing class Node; (or any forward-declaration of Node) in a header that might be #included from both worlds. Whichever world's real definition gets included later in the same translation unit can clash with your forward-declaration's class-key (class vs struct), or — worse — the header can compile fine in isolation and only fail (or silently pick the wrong type) once combined with a specific set of other includes.

The fix: omit the forward-declaration entirely. Don't try to avoid the #include of the real Node header for compile-time savings in a shared, dual-included header — let each translation unit's own real includes provide whatever Node type it needs. If you only need a pointer/reference and think a forward-declare is a safe optimization, it is not safe here specifically because the two worlds disagree on the underlying type.

How to confirm you're clear: the header must build cleanly when included from an in-tree-only translation unit AND (once such a target exists) from a plugin-DLL translation unit, without relying on which one happens to be included first.

Show full SKILL.md (313 more words)Show less

2. Keep the shared/reusable half of a workspace-estimation function free of graph types

When a kernel's workspace-size computation needs to be callable from both in-tree and (eventually) plugin code, split it into two pieces:

  • Pure-math core — takes only plain shape/arch integers (e.g. ComputeFpAIntBGemmWorkspaceSize(int m, int n, int k, int sm, int multiProcessorCount)). No Node&, no NodeArg, no TensorShape parsing, no ORT graph types at all. This is the part a future plugin implementation can call verbatim — plugin kernels don't have Node& access, only the C-ABI shape representation (OrtNode, Node_GetInputShape).
  • Graph-parsing wrapper — extracts the plain integers from const Node&/NodeArg/TensorShape (or from the plugin's C-ABI shape accessors). This half is inherently different per build configuration and is NOT reusable across the DLL boundary; it must be reimplemented against whichever shape representation the caller has.

Why this matters concretely: if you accidentally let the pure-math core accept or touch an in-tree graph type (even just to read one field), you've made it impossible to reuse from the plugin path without either (a) linking in-tree graph headers into the plugin DLL (defeats the purpose of a plugin boundary) or (b) duplicating the whole function. Keep the split clean from the start.

How to confirm you're clear: grep the pure-math function's signature and body for any ORT graph type (Node, NodeArg, TensorShape, GraphViewer, etc.) — it should only ever see plain scalars (int/int64_t/size_t) and, at most, opaque device-property values already extracted by the caller. If you find a graph type anywhere in that function, the split has leaked and needs to be pulled apart before a plugin implementation can reuse it.

Related, not yet built: docs/annotated_partitioning/future_directions_constrained_env.md (Phase A / plugin-ABI sections) describes the intended plugin-side C ABI surface for DeclareWorkspaceRequirements, but as of PR #29811 no plugin-side implementation exists yet — see that doc's "Cost of a Real Plugin-Side Override (Deferred)" note for what's still missing beyond just following this split.

© microsoft, MIT. Rendered from Markdown: HTML in the file is shown as text, images as links, and headings moved down two levels. Raw file

Files

Just SKILL.md in .github/skills/workspace-estimation-shared-header of microsoft/onnxruntime.

Open the folder on GitHubat commit 8420709

Compare with similar skills

ONNX Runtime Shared Header Pitfalls next to the 5 skills that share the most tags, products or categories with it. Stars are the repository's; “used in” counts other GitHub owners with a copy.

ONNX Runtime Shared Header Pitfalls compared with similar skills
SkillStarsUsed inTokensAuto-checkLicenceRepo updated
ONNX Runtime Shared Header Pitfalls this skillmicrosoft/onnxruntime22k—~1.3kAutomated safety check: PassMIT
Code Review Skillawesome-skills/code-review-skill2.1k—~2.8kAutomated safety check: NotesMIT
Code Review SkillRain-kl/OpenFlare288—~2.3kAutomated safety check: NotesMIT
Marmite Developmentrochacbruno/marmite880—~6.9kAutomated safety check: PassAGPL-3.0
Code Review Excellenceandrew-yangy/gru-ai155—~1.7kAutomated safety check: NotesMIT
A Philosophy of Software Designciembor/agent-rules-books2.9k—~181Automated safety check: PassMIT

Similar skills

  • Code Review Skill

    awesome-skills/code-review-skill

    Provides comprehensive code review guidance for React 19, Vue 3, Angular 17+, Svelte 5, Rust, TypeScript, Java, Java 8, PHP, Ruby, Rails, Python, Django, FastAPI, Go, C/.NET, Kotlin, Swift, Dart…

    2.1k GitHub stars~2.8k tokensUpdated 29 days ago
    DevelopmentAuto-check: notes

  • Code Review Skill

    Rain-kl/OpenFlare

    Provides comprehensive code review guidance for React 19, Vue 3, Angular 17+, Svelte 5, Rust, TypeScript, Java, PHP, Python, Django, Go, C/.NET, Kotlin, Swift, NestJS, C/C++, and more.

    288 GitHub stars~2.3k tokensUpdated today
    DevelopmentAuto-check: notes

  • Marmite Development

    rochacbruno/marmite

    Guidelines and workflows for contributing to the marmite codebase - covers code quality, testing, architecture patterns, and contribution checklists

    880 GitHub stars~6.9k tokensUpdated 4 days ago
    DevelopmentAuto-check passed

  • Code Review Excellence

    andrew-yangy/gru-ai

    Provides comprehensive code review guidance for React 19, Vue 3, Rust, TypeScript, Java, Python, and C/C++.

    155 GitHub stars~1.7k tokensUpdated 7 mo ago
    DevelopmentAuto-check: notes

  • A Philosophy of Software Design

    ciembor/agent-rules-books

    Apply John Ousterhout-inspired software design rules when reducing complexity, designing module boundaries, or reviewing APIs and abstractions.

    2.9k GitHub stars~181 tokensUpdated 27 days ago
    DevelopmentAuto-check passed

  • Senior Fullstack

    davila7/claude-code-templates

    Comprehensive fullstack development skill for building complete web applications with React, Next.js, Node.js, GraphQL, and PostgreSQL.

    32k GitHub starsUsed in 6 repos~1.1k tokens
    DevelopmentAuto-check: notes

More from microsoft/onnxruntime

All 14 skills in this repo

  • ONNX Runtime Shape Inference Safety Audit

    microsoft/onnxruntime

    Official

    Finds and fixes out-of-range output writes in ONNX Runtime operator shape-inference functions where a getNumOutputs guard admits too few outputs.

    22k GitHub stars~3.3k tokensUpdated today
    Auto-check passed

  • CUTLASS FMHA Incremental Rebuild

    microsoft/onnxruntime

    Official

    Explains why editing CUTLASS fused-MHA headers in ONNX Runtime can leave stale CUDA kernels after an incremental build, and how to force and verify a real rebuild.

    22k GitHub stars~1.3k tokensUpdated today
    Auto-check passed

  • ONNX Runtime Source Build

    microsoft/onnxruntime

    Official

    Builds ONNX Runtime from source with its build scripts, explaining the update, build and test phases, key flags and where the build output lands.

    22k GitHub stars~1.4k tokensUpdated today
    Auto-check passed

  • ONNX Runtime CI Management

    microsoft/onnxruntime

    Official

    Triggers, re-runs and unblocks the CI checks on an ONNX Runtime pull request, after diagnosing whether a failure is transient or needs a code change.

    22k GitHub stars~4.1k tokensUpdated today
    Auto-check passed

  • ONNX Runtime Release Notes

    microsoft/onnxruntime

    Official

    Drafts ONNX Runtime release notes from commit history and contributor metadata using named presets for the full runtime or a scoped component.

    22k GitHub stars~1.6k tokensUpdated today
    Auto-check passed

  • ONNX Runtime Test Runner

    microsoft/onnxruntime

    Official

    Runs and debugs ONNX Runtime tests: Google Test executables for C++ and unittest or pytest for Python, with filters and build-directory guidance.

    22k GitHub stars~1.8k tokensUpdated today
    Auto-check passed

Works with

Categories

Questions about ONNX Runtime Shared Header Pitfalls

What does ONNX Runtime Shared Header Pitfalls do?

Pitfalls for editing an ONNX Runtime header shared by in-tree and plugin-bridge code: the Node forward-declaration trap and keeping workspace math free of graph types. h` as the example. It comes from a pilot of two-level workspace-size estimation for `MatMulNBits`, with an `EstimateWorkspace` level and a `DeclareWorkspaceRequirements` level.

When should I use ONNX Runtime Shared Header Pitfalls?

ONNX Runtime Shared Header Pitfalls fits situations like: editing a header that both in-tree and plugin-bridge code include; making a workspace-estimation math helper callable from a plugin execution provider; debugging a compile error or wrong type caused by a Node forward declaration.

How do I install ONNX Runtime Shared Header Pitfalls in Claude Code?

Run `npx skills add microsoft/onnxruntime --skill workspace-estimation-shared-header -a claude-code`. Or copy the skill folder (.github/skills/workspace-estimation-shared-header in microsoft/onnxruntime) into .claude/skills/workspace-estimation-shared-header in your project. Claude Code loads it when a task matches its description.

How do I install ONNX Runtime Shared Header Pitfalls in Codex?

Run `npx skills add microsoft/onnxruntime --skill workspace-estimation-shared-header -a codex`. Or copy the skill folder (.github/skills/workspace-estimation-shared-header in microsoft/onnxruntime) into .agents/skills/workspace-estimation-shared-header in your project. Codex loads it when a task matches its description.

Can I use ONNX Runtime Shared Header Pitfalls in Cursor, Gemini CLI or GitHub Copilot?

Cursor, Gemini CLI, GitHub Copilot and OpenCode also load SKILL.md folders. With the skills CLI, run `npx skills add microsoft/onnxruntime --skill workspace-estimation-shared-header -a cursor` (or -a gemini-cli, github-copilot or opencode for the others). To copy it by hand, put the folder in .cursor/skills/workspace-estimation-shared-header, .gemini/skills/workspace-estimation-shared-header, .github/skills/workspace-estimation-shared-header and .opencode/skills/workspace-estimation-shared-header in your project.

What does ONNX Runtime Shared Header Pitfalls need to run?

SKILL.md names no scripts, command-line tools or credentials: ONNX Runtime Shared Header Pitfalls is instructions for the agent only. Our summary lists: A checkout of the ONNX Runtime repository.

Does ONNX Runtime Shared Header Pitfalls access the network?

SKILL.md contains no URLs. Any network use would come from the scripts or tools the agent runs. This is read from the text; nothing was executed.

Is ONNX Runtime Shared Header Pitfalls safe to install?

Our automated static check of SKILL.md found no risky patterns, such as piping downloads into a shell, reading credential files or hidden Unicode. It is not a guarantee. Review the folder before installing.

What licence does ONNX Runtime Shared Header Pitfalls use?

ONNX Runtime Shared Header Pitfalls is published under the MIT licence (the repository's licence). It allows redistribution, so the full SKILL.md is shown on this page.

How many tokens does ONNX Runtime Shared Header Pitfalls use?

About 1.3k tokens (SKILL.md is roughly 5.1k characters). Agents keep only the skill's name and description in context until a task matches; then they load SKILL.md in full.

What are the alternatives to ONNX Runtime Shared Header Pitfalls?

Skills that share tags, products or a category with ONNX Runtime Shared Header Pitfalls: Code Review Skill (awesome-skills/code-review-skill, 2.1k stars), Code Review Skill (Rain-kl/OpenFlare, 288 stars), Marmite Development (rochacbruno/marmite, 880 stars) and Code Review Excellence (andrew-yangy/gru-ai, 155 stars). The comparison table on this page puts their stars, adoption, token cost, safety result and licence side by side.

Who maintains ONNX Runtime Shared Header Pitfalls?

microsoft (a GitHub organization, an official publisher) maintains it in microsoft/onnxruntime, which has 22,029 GitHub stars. The repository holds 14 skills in this directory. The repository was last updated on October 7, 2026.

Source: microsoft/onnxruntime on GitHub. Facts on this page come from the repository at the commit we read; the author's words are quoted as theirs.