{"owner":"microsoft","repo":"onnxruntime","hasSkills":true,"totalSkillsCount":5,"totalTokensCount":2811,"categories":["root-instruction","copilot-instructions","mcp-config","marketplace","plugin-manifest"],"hasMcp":true,"mcpConfig":{"mcpServers":{"onnxruntime":{"command":"npx","args":["-y","@modelcontextprotocol/server-onnxruntime"]}}},"found":["AGENTS.md",".github/copilot-instructions.md",".cursor/mcp.json",".claude-plugin/marketplace.json",".claude-plugin/plugin.json"],"skills":{"AGENTS.md":"# Agent Instructions for ONNX Runtime\n\nThis file contains repository-wide guidance for coding agents. See\n[Extending Agent Coding Guidance](docs/Agent_Coding_Guidance.md) when adding or updating guidance.\n\n## Path-Scoped Instructions\n\nBefore implementing or reviewing changes, inspect `.github/instructions/**/*.instructions.md` and parse each file's\n`applyTo` scope. Apply every instruction whose scope matches any target or changed path. Unless explicitly stated\notherwise, matching instructions apply to both implementation and review.\n\n## Agent Skills\n\nRepository skills are available in [`.github/skills`](.github/skills/). Load each skill whose description matches the\nrequested task, subsystem, or behavior.\n\nFor code reviews, follow the `/code-review` skill in addition to relevant domain skills and matching path-scoped\ninstructions.\n\n## Build, Test, and Lint\n\nSee the `/ort-build`, `/ort-test`, and `/ort-lint` skills for detailed instructions.\n\n## CI\n\nSee the `/ort-ci` skill for triggering, re-running, and unblocking CI checks on a pull request (GitHub Actions, Azure\nPipelines, `Python format`, and `license/cla`).\n\n## Architecture Overview\n\nONNX Runtime is a cross-platform inference and training engine for ONNX models. The core pipeline is: **Load model → Build graph → Optimize graph → Partition across Execution Providers → Execute**.\n\n### Key layers (`onnxruntime/core/`)\n\n- **`graph/`** — ONNX model/graph IR. `Model` wraps a `Graph` of `Node`s. `GraphViewer` provides read-only traversal.\n- **`optimizer/`** — Graph transformations (fusion, elimination, constant folding, layout transforms). Organized by optimization level (Level1–Level4).\n- **`framework/`** — Execution machinery: `OpKernel`, `Tensor`, `KernelRegistry`, allocators, executors.\n- **`session/`** — `InferenceSession`: `Load()` → `Initialize()` (optimize + assign kernels) → `Run()`.\n- **`providers/`** — Execution Provider (EP) implementations. Each EP implements `IExecutionProvider`. CPU EP is the default fallback. 20+ EPs exist (CUDA, TensorRT, DirectML, CoreML, OpenVINO, WebGPU, QNN, etc.).\n- **`common/`** — Utilities, status/error types, logging, threading.\n- **`platform/`** — OS abstraction (file I/O, threading).\n\n### Contrib ops (`onnxruntime/contrib_ops/`)\n\nCustom operators not in the ONNX standard, organized by EP (`cpu/`, `cuda/`, `js/`, `webgpu/`). Each EP has its own contrib kernel registration file (e.g., `cpu_contrib_kernels.cc`, `cuda_contrib_kernels.cc`, `js_contrib_kernels.cc`, `webgpu_contrib_kernels.cc`).\n\n### Training (`orttraining/`)\n\nTraining-specific code (gradient ops, loss functions, optimizers, `TrainingSession`) layered on top of the inference framework.\n\n### Language bindings\n\n`csharp/`, `java/`, `js/`, `objectivec/`, `rust/` — each wraps the C API (`include/onnxruntime/core/session/onnxruntime_c_api.h`).\n\n## General Code Conventions\n\n### Code Comments\n\nKeep code comments concise. Add a comment only when it explains rationale, an invariant, a constraint, or subtle behavior\nthat is not clear from the immediate context. Do not narrate obvious code or document the sequence of approaches taken\nto reach the current implementation; that history belongs in the pull request or commit message when relevant.\n\n## C++ Conventions\n\n**Style**: Google C++ Style with modifications. Max line length 120 (aim for 80). See `docs/Coding_Conventions_and_Standards.md` for full details.\n\n### Error handling\n\nFunctions that can fail return `onnxruntime::common::Status`. Key macros from `core/common/common.h`:\n\n- `ORT_RETURN_IF_ERROR(expr)` — early-return if `expr` returns non-OK Status\n- `ORT_THROW_IF_ERROR(expr)` — throw if `expr` returns non-OK Status\n- `ORT_RETURN_IF(cond, ...)` / `ORT_RETURN_IF_NOT(cond, ...)` — conditional early-return with message\n- `ORT_ENFORCE(cond, ...)` — assert-like; throws `OnnxRuntimeException` on failure\n- `ORT_MAKE_STATUS(category, code, ...)` — construct a Status object\n\nExceptions may be disabled in a build, in which case, the throwing macros will call `abort()` instead.\n\nAt the C API boundary, use `API_IMPL_BEGIN` / `API_IMPL_END` to catch exceptions — C++ exceptions must never cross the C API boundary.\n\n### Container types\n\nUse these instead of `std::vector` / `std::unordered_map`:\n\n- `InlinedVector<T>` — small-buffer-optimized vector (64 bytes inline)\n- `InlinedHashSet<T>`, `InlinedHashMap<K,V>` — flat hash containers\n- `NodeHashSet<T>`, `NodeHashMap<K,V>` — when pointer stability is needed\n- `TensorShapeVector` — for shape dimensions\n\nUse `reserve()` not `resize()`. Do not use `absl::` directly — use the ORT typedefs.\n\n### Other conventions\n\n- `#pragma once` for header guards\n- `ORT_DISALLOW_COPY_ASSIGNMENT_AND_MOVE` for new classes until copy/move is proven necessary\n- Prefer `gsl::span<const T>` over `const std::vector<T>&` for input parameters\n- Prefer `std::string_view` by value over `const std::string&`\n- `SafeInt<size_t>` (from `core/common/safeint.h`) for memory size arithmetic\n- **Signed vs unsigned on negative-capable differences.** Any expression of the form `a - b`\n  that can be negative (an offset or remaining-budget computed from counts, e.g.\n  `num_keys - num_queries`) must be stored and compared using a **signed** type\n  (`int32_t`/`int64_t`), and any unsigned operand must be `static_cast` to signed *before*\n  the subtraction/comparison. An unsigned result silently wraps to a huge value (`~4.29e9`\n  for `uint32_t`), which can permanently satisfy or skip a relational guard with **no crash\n  and no warning** — a correct-looking-but-wrong result. Concrete ORT instance + the exact\n  fix sites: CUTLASS FMHA `causal_diagonal_offset`, see the `cuda-attention-kernel-patterns`\n  skill §12.\n- Don't use `else` after `return`\n- Avoid `long` (ambiguous width) — use `int64_t` for dimensions, `size_t` for counts\n- `using namespace` allowed in limited scope but never at global scope in headers\n- `std::make_unique()` for heap allocations; prefer `std::optional` over `unique_ptr` for optional/delayed construction\n\n## Python\n\n### Virtual environment\n\nBuild and test processes may install Python packages. Create and activate an isolated virtual environment first:\n\n```bash\npython -m venv .venv                  # one-time setup\nsource .venv/bin/activate             # Linux/macOS\n.\\.venv\\Scripts\\Activate.ps1          # Windows (PowerShell)\n```\n\nIf a virtual environment already exists (e.g., `.venv/`), activate it rather than creating a new one.\n\n### Conventions\n\n- Follow [Google Python Style Guide](https://google.github.io/styleguide/pyguide.html) (extension of PEP 8)\n- Max line length: 120 characters\n- Formatter: ruff (configured in `pyproject.toml`)\n- Static type checking: pyright/pylance\n- Test framework: `unittest` (preferred) with `pytest` as runner\n\n## C API Conventions\n\nThe main public C API header is `include/onnxruntime/core/session/onnxruntime_c_api.h`. Other public headers are in `include/onnxruntime/core/session/` and `orttraining/orttraining/training_api/include/`.\n\n- Functions that may fail return `OrtStatus*` (`nullptr` on success); release/cleanup functions return `void`\n- Object lifecycle: `OrtCreateXxx` / `OrtReleaseXxx`\n- All strings are UTF-8 encoded\n- Use `int64_t` for dimensions, `size_t` for counts and memory sizes\n- APIs requiring allocation take an `OrtAllocator*` parameter\n- Failed calls must not modify out-parameters\n\n## PR Guidelines\n\n- Keep PRs small (aim for ≤10 files; separate cosmetic changes from functional ones)\n- All changes must have unit tests, unless documentation-only or already adequately covered\n- Build and test locally on at least one platform before submitting\n- PR author is responsible for merging after approval\n",".github/copilot-instructions.md":"# Copilot Instructions for ONNX Runtime\n\nRead and follow [AGENTS.md](../AGENTS.md) for repository-wide guidance, including codebase conventions, architecture,\nand coding standards.\n",".cursor/mcp.json":"# Model Context Protocol (MCP) Configuration\n\nPath: `.cursor/mcp.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/microsoft/onnxruntime/HEAD/.cursor/mcp.json)",".claude-plugin/marketplace.json":"# Claude Plugin Marketplace Catalog\n\nPath: `.claude-plugin/marketplace.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/microsoft/onnxruntime/HEAD/.claude-plugin/marketplace.json)",".claude-plugin/plugin.json":"# claude-plugin Plugin Manifest\n\nPath: `.claude-plugin/plugin.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/microsoft/onnxruntime/HEAD/.claude-plugin/plugin.json)"},"files":{"AGENTS.md":"# Agent Instructions for ONNX Runtime\n\nThis file contains repository-wide guidance for coding agents. See\n[Extending Agent Coding Guidance](docs/Agent_Coding_Guidance.md) when adding or updating guidance.\n\n## Path-Scoped Instructions\n\nBefore implementing or reviewing changes, inspect `.github/instructions/**/*.instructions.md` and parse each file's\n`applyTo` scope. Apply every instruction whose scope matches any target or changed path. Unless explicitly stated\notherwise, matching instructions apply to both implementation and review.\n\n## Agent Skills\n\nRepository skills are available in [`.github/skills`](.github/skills/). Load each skill whose description matches the\nrequested task, subsystem, or behavior.\n\nFor code reviews, follow the `/code-review` skill in addition to relevant domain skills and matching path-scoped\ninstructions.\n\n## Build, Test, and Lint\n\nSee the `/ort-build`, `/ort-test`, and `/ort-lint` skills for detailed instructions.\n\n## CI\n\nSee the `/ort-ci` skill for triggering, re-running, and unblocking CI checks on a pull request (GitHub Actions, Azure\nPipelines, `Python format`, and `license/cla`).\n\n## Architecture Overview\n\nONNX Runtime is a cross-platform inference and training engine for ONNX models. The core pipeline is: **Load model → Build graph → Optimize graph → Partition across Execution Providers → Execute**.\n\n### Key layers (`onnxruntime/core/`)\n\n- **`graph/`** — ONNX model/graph IR. `Model` wraps a `Graph` of `Node`s. `GraphViewer` provides read-only traversal.\n- **`optimizer/`** — Graph transformations (fusion, elimination, constant folding, layout transforms). Organized by optimization level (Level1–Level4).\n- **`framework/`** — Execution machinery: `OpKernel`, `Tensor`, `KernelRegistry`, allocators, executors.\n- **`session/`** — `InferenceSession`: `Load()` → `Initialize()` (optimize + assign kernels) → `Run()`.\n- **`providers/`** — Execution Provider (EP) implementations. Each EP implements `IExecutionProvider`. CPU EP is the default fallback. 20+ EPs exist (CUDA, TensorRT, DirectML, CoreML, OpenVINO, WebGPU, QNN, etc.).\n- **`common/`** — Utilities, status/error types, logging, threading.\n- **`platform/`** — OS abstraction (file I/O, threading).\n\n### Contrib ops (`onnxruntime/contrib_ops/`)\n\nCustom operators not in the ONNX standard, organized by EP (`cpu/`, `cuda/`, `js/`, `webgpu/`). Each EP has its own contrib kernel registration file (e.g., `cpu_contrib_kernels.cc`, `cuda_contrib_kernels.cc`, `js_contrib_kernels.cc`, `webgpu_contrib_kernels.cc`).\n\n### Training (`orttraining/`)\n\nTraining-specific code (gradient ops, loss functions, optimizers, `TrainingSession`) layered on top of the inference framework.\n\n### Language bindings\n\n`csharp/`, `java/`, `js/`, `objectivec/`, `rust/` — each wraps the C API (`include/onnxruntime/core/session/onnxruntime_c_api.h`).\n\n## General Code Conventions\n\n### Code Comments\n\nKeep code comments concise. Add a comment only when it explains rationale, an invariant, a constraint, or subtle behavior\nthat is not clear from the immediate context. Do not narrate obvious code or document the sequence of approaches taken\nto reach the current implementation; that history belongs in the pull request or commit message when relevant.\n\n## C++ Conventions\n\n**Style**: Google C++ Style with modifications. Max line length 120 (aim for 80). See `docs/Coding_Conventions_and_Standards.md` for full details.\n\n### Error handling\n\nFunctions that can fail return `onnxruntime::common::Status`. Key macros from `core/common/common.h`:\n\n- `ORT_RETURN_IF_ERROR(expr)` — early-return if `expr` returns non-OK Status\n- `ORT_THROW_IF_ERROR(expr)` — throw if `expr` returns non-OK Status\n- `ORT_RETURN_IF(cond, ...)` / `ORT_RETURN_IF_NOT(cond, ...)` — conditional early-return with message\n- `ORT_ENFORCE(cond, ...)` — assert-like; throws `OnnxRuntimeException` on failure\n- `ORT_MAKE_STATUS(category, code, ...)` — construct a Status object\n\nExceptions may be disabled in a build, in which case, the throwing macros will call `abort()` instead.\n\nAt the C API boundary, use `API_IMPL_BEGIN` / `API_IMPL_END` to catch exceptions — C++ exceptions must never cross the C API boundary.\n\n### Container types\n\nUse these instead of `std::vector` / `std::unordered_map`:\n\n- `InlinedVector<T>` — small-buffer-optimized vector (64 bytes inline)\n- `InlinedHashSet<T>`, `InlinedHashMap<K,V>` — flat hash containers\n- `NodeHashSet<T>`, `NodeHashMap<K,V>` — when pointer stability is needed\n- `TensorShapeVector` — for shape dimensions\n\nUse `reserve()` not `resize()`. Do not use `absl::` directly — use the ORT typedefs.\n\n### Other conventions\n\n- `#pragma once` for header guards\n- `ORT_DISALLOW_COPY_ASSIGNMENT_AND_MOVE` for new classes until copy/move is proven necessary\n- Prefer `gsl::span<const T>` over `const std::vector<T>&` for input parameters\n- Prefer `std::string_view` by value over `const std::string&`\n- `SafeInt<size_t>` (from `core/common/safeint.h`) for memory size arithmetic\n- **Signed vs unsigned on negative-capable differences.** Any expression of the form `a - b`\n  that can be negative (an offset or remaining-budget computed from counts, e.g.\n  `num_keys - num_queries`) must be stored and compared using a **signed** type\n  (`int32_t`/`int64_t`), and any unsigned operand must be `static_cast` to signed *before*\n  the subtraction/comparison. An unsigned result silently wraps to a huge value (`~4.29e9`\n  for `uint32_t`), which can permanently satisfy or skip a relational guard with **no crash\n  and no warning** — a correct-looking-but-wrong result. Concrete ORT instance + the exact\n  fix sites: CUTLASS FMHA `causal_diagonal_offset`, see the `cuda-attention-kernel-patterns`\n  skill §12.\n- Don't use `else` after `return`\n- Avoid `long` (ambiguous width) — use `int64_t` for dimensions, `size_t` for counts\n- `using namespace` allowed in limited scope but never at global scope in headers\n- `std::make_unique()` for heap allocations; prefer `std::optional` over `unique_ptr` for optional/delayed construction\n\n## Python\n\n### Virtual environment\n\nBuild and test processes may install Python packages. Create and activate an isolated virtual environment first:\n\n```bash\npython -m venv .venv                  # one-time setup\nsource .venv/bin/activate             # Linux/macOS\n.\\.venv\\Scripts\\Activate.ps1          # Windows (PowerShell)\n```\n\nIf a virtual environment already exists (e.g., `.venv/`), activate it rather than creating a new one.\n\n### Conventions\n\n- Follow [Google Python Style Guide](https://google.github.io/styleguide/pyguide.html) (extension of PEP 8)\n- Max line length: 120 characters\n- Formatter: ruff (configured in `pyproject.toml`)\n- Static type checking: pyright/pylance\n- Test framework: `unittest` (preferred) with `pytest` as runner\n\n## C API Conventions\n\nThe main public C API header is `include/onnxruntime/core/session/onnxruntime_c_api.h`. Other public headers are in `include/onnxruntime/core/session/` and `orttraining/orttraining/training_api/include/`.\n\n- Functions that may fail return `OrtStatus*` (`nullptr` on success); release/cleanup functions return `void`\n- Object lifecycle: `OrtCreateXxx` / `OrtReleaseXxx`\n- All strings are UTF-8 encoded\n- Use `int64_t` for dimensions, `size_t` for counts and memory sizes\n- APIs requiring allocation take an `OrtAllocator*` parameter\n- Failed calls must not modify out-parameters\n\n## PR Guidelines\n\n- Keep PRs small (aim for ≤10 files; separate cosmetic changes from functional ones)\n- All changes must have unit tests, unless documentation-only or already adequately covered\n- Build and test locally on at least one platform before submitting\n- PR author is responsible for merging after approval\n",".github/copilot-instructions.md":"# Copilot Instructions for ONNX Runtime\n\nRead and follow [AGENTS.md](../AGENTS.md) for repository-wide guidance, including codebase conventions, architecture,\nand coding standards.\n",".cursor/mcp.json":"# Model Context Protocol (MCP) Configuration\n\nPath: `.cursor/mcp.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/microsoft/onnxruntime/HEAD/.cursor/mcp.json)",".claude-plugin/marketplace.json":"# Claude Plugin Marketplace Catalog\n\nPath: `.claude-plugin/marketplace.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/microsoft/onnxruntime/HEAD/.claude-plugin/marketplace.json)",".claude-plugin/plugin.json":"# claude-plugin Plugin Manifest\n\nPath: `.claude-plugin/plugin.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/microsoft/onnxruntime/HEAD/.claude-plugin/plugin.json)"},"items":[{"name":"AGENTS.md","path":"AGENTS.md","rawUrl":"https://raw.githubusercontent.com/microsoft/onnxruntime/HEAD/AGENTS.md","title":"AI Agent Protocol & Instructions","category":"root-instruction","format":"markdown","content":"# Agent Instructions for ONNX Runtime\n\nThis file contains repository-wide guidance for coding agents. See\n[Extending Agent Coding Guidance](docs/Agent_Coding_Guidance.md) when adding or updating guidance.\n\n## Path-Scoped Instructions\n\nBefore implementing or reviewing changes, inspect `.github/instructions/**/*.instructions.md` and parse each file's\n`applyTo` scope. Apply every instruction whose scope matches any target or changed path. Unless explicitly stated\notherwise, matching instructions apply to both implementation and review.\n\n## Agent Skills\n\nRepository skills are available in [`.github/skills`](.github/skills/). Load each skill whose description matches the\nrequested task, subsystem, or behavior.\n\nFor code reviews, follow the `/code-review` skill in addition to relevant domain skills and matching path-scoped\ninstructions.\n\n## Build, Test, and Lint\n\nSee the `/ort-build`, `/ort-test`, and `/ort-lint` skills for detailed instructions.\n\n## CI\n\nSee the `/ort-ci` skill for triggering, re-running, and unblocking CI checks on a pull request (GitHub Actions, Azure\nPipelines, `Python format`, and `license/cla`).\n\n## Architecture Overview\n\nONNX Runtime is a cross-platform inference and training engine for ONNX models. The core pipeline is: **Load model → Build graph → Optimize graph → Partition across Execution Providers → Execute**.\n\n### Key layers (`onnxruntime/core/`)\n\n- **`graph/`** — ONNX model/graph IR. `Model` wraps a `Graph` of `Node`s. `GraphViewer` provides read-only traversal.\n- **`optimizer/`** — Graph transformations (fusion, elimination, constant folding, layout transforms). Organized by optimization level (Level1–Level4).\n- **`framework/`** — Execution machinery: `OpKernel`, `Tensor`, `KernelRegistry`, allocators, executors.\n- **`session/`** — `InferenceSession`: `Load()` → `Initialize()` (optimize + assign kernels) → `Run()`.\n- **`providers/`** — Execution Provider (EP) implementations. Each EP implements `IExecutionProvider`. CPU EP is the default fallback. 20+ EPs exist (CUDA, TensorRT, DirectML, CoreML, OpenVINO, WebGPU, QNN, etc.).\n- **`common/`** — Utilities, status/error types, logging, threading.\n- **`platform/`** — OS abstraction (file I/O, threading).\n\n### Contrib ops (`onnxruntime/contrib_ops/`)\n\nCustom operators not in the ONNX standard, organized by EP (`cpu/`, `cuda/`, `js/`, `webgpu/`). Each EP has its own contrib kernel registration file (e.g., `cpu_contrib_kernels.cc`, `cuda_contrib_kernels.cc`, `js_contrib_kernels.cc`, `webgpu_contrib_kernels.cc`).\n\n### Training (`orttraining/`)\n\nTraining-specific code (gradient ops, loss functions, optimizers, `TrainingSession`) layered on top of the inference framework.\n\n### Language bindings\n\n`csharp/`, `java/`, `js/`, `objectivec/`, `rust/` — each wraps the C API (`include/onnxruntime/core/session/onnxruntime_c_api.h`).\n\n## General Code Conventions\n\n### Code Comments\n\nKeep code comments concise. Add a comment only when it explains rationale, an invariant, a constraint, or subtle behavior\nthat is not clear from the immediate context. Do not narrate obvious code or document the sequence of approaches taken\nto reach the current implementation; that history belongs in the pull request or commit message when relevant.\n\n## C++ Conventions\n\n**Style**: Google C++ Style with modifications. Max line length 120 (aim for 80). See `docs/Coding_Conventions_and_Standards.md` for full details.\n\n### Error handling\n\nFunctions that can fail return `onnxruntime::common::Status`. Key macros from `core/common/common.h`:\n\n- `ORT_RETURN_IF_ERROR(expr)` — early-return if `expr` returns non-OK Status\n- `ORT_THROW_IF_ERROR(expr)` — throw if `expr` returns non-OK Status\n- `ORT_RETURN_IF(cond, ...)` / `ORT_RETURN_IF_NOT(cond, ...)` — conditional early-return with message\n- `ORT_ENFORCE(cond, ...)` — assert-like; throws `OnnxRuntimeException` on failure\n- `ORT_MAKE_STATUS(category, code, ...)` — construct a Status object\n\nExceptions may be disabled in a build, in which case, the throwing macros will call `abort()` instead.\n\nAt the C API boundary, use `API_IMPL_BEGIN` / `API_IMPL_END` to catch exceptions — C++ exceptions must never cross the C API boundary.\n\n### Container types\n\nUse these instead of `std::vector` / `std::unordered_map`:\n\n- `InlinedVector<T>` — small-buffer-optimized vector (64 bytes inline)\n- `InlinedHashSet<T>`, `InlinedHashMap<K,V>` — flat hash containers\n- `NodeHashSet<T>`, `NodeHashMap<K,V>` — when pointer stability is needed\n- `TensorShapeVector` — for shape dimensions\n\nUse `reserve()` not `resize()`. Do not use `absl::` directly — use the ORT typedefs.\n\n### Other conventions\n\n- `#pragma once` for header guards\n- `ORT_DISALLOW_COPY_ASSIGNMENT_AND_MOVE` for new classes until copy/move is proven necessary\n- Prefer `gsl::span<const T>` over `const std::vector<T>&` for input parameters\n- Prefer `std::string_view` by value over `const std::string&`\n- `SafeInt<size_t>` (from `core/common/safeint.h`) for memory size arithmetic\n- **Signed vs unsigned on negative-capable differences.** Any expression of the form `a - b`\n  that can be negative (an offset or remaining-budget computed from counts, e.g.\n  `num_keys - num_queries`) must be stored and compared using a **signed** type\n  (`int32_t`/`int64_t`), and any unsigned operand must be `static_cast` to signed *before*\n  the subtraction/comparison. An unsigned result silently wraps to a huge value (`~4.29e9`\n  for `uint32_t`), which can permanently satisfy or skip a relational guard with **no crash\n  and no warning** — a correct-looking-but-wrong result. Concrete ORT instance + the exact\n  fix sites: CUTLASS FMHA `causal_diagonal_offset`, see the `cuda-attention-kernel-patterns`\n  skill §12.\n- Don't use `else` after `return`\n- Avoid `long` (ambiguous width) — use `int64_t` for dimensions, `size_t` for counts\n- `using namespace` allowed in limited scope but never at global scope in headers\n- `std::make_unique()` for heap allocations; prefer `std::optional` over `unique_ptr` for optional/delayed construction\n\n## Python\n\n### Virtual environment\n\nBuild and test processes may install Python packages. Create and activate an isolated virtual environment first:\n\n```bash\npython -m venv .venv                  # one-time setup\nsource .venv/bin/activate             # Linux/macOS\n.\\.venv\\Scripts\\Activate.ps1          # Windows (PowerShell)\n```\n\nIf a virtual environment already exists (e.g., `.venv/`), activate it rather than creating a new one.\n\n### Conventions\n\n- Follow [Google Python Style Guide](https://google.github.io/styleguide/pyguide.html) (extension of PEP 8)\n- Max line length: 120 characters\n- Formatter: ruff (configured in `pyproject.toml`)\n- Static type checking: pyright/pylance\n- Test framework: `unittest` (preferred) with `pytest` as runner\n\n## C API Conventions\n\nThe main public C API header is `include/onnxruntime/core/session/onnxruntime_c_api.h`. Other public headers are in `include/onnxruntime/core/session/` and `orttraining/orttraining/training_api/include/`.\n\n- Functions that may fail return `OrtStatus*` (`nullptr` on success); release/cleanup functions return `void`\n- Object lifecycle: `OrtCreateXxx` / `OrtReleaseXxx`\n- All strings are UTF-8 encoded\n- Use `int64_t` for dimensions, `size_t` for counts and memory sizes\n- APIs requiring allocation take an `OrtAllocator*` parameter\n- Failed calls must not modify out-parameters\n\n## PR Guidelines\n\n- Keep PRs small (aim for ≤10 files; separate cosmetic changes from functional ones)\n- All changes must have unit tests, unless documentation-only or already adequately covered\n- Build and test locally on at least one platform before submitting\n- PR author is responsible for merging after approval\n","isInternal":false,"tokens":1873,"sizeBytes":7746},{"name":"copilot-instructions.md","path":".github/copilot-instructions.md","rawUrl":"https://raw.githubusercontent.com/microsoft/onnxruntime/HEAD/.github/copilot-instructions.md","title":"GitHub Copilot Instructions","category":"copilot-instructions","format":"markdown","content":"# Copilot Instructions for ONNX Runtime\n\nRead and follow [AGENTS.md](../AGENTS.md) for repository-wide guidance, including codebase conventions, architecture,\nand coding standards.\n","isInternal":false,"tokens":38,"sizeBytes":181},{"name":"marketplace.json","path":".claude-plugin/marketplace.json","rawUrl":"https://raw.githubusercontent.com/microsoft/onnxruntime/HEAD/.claude-plugin/marketplace.json","title":"Claude Plugin Marketplace Catalog","category":"marketplace","format":"json","content":"# Claude Plugin Marketplace Catalog\n\nPath: `.claude-plugin/marketplace.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/microsoft/onnxruntime/HEAD/.claude-plugin/marketplace.json)","tokens":300,"sizeBytes":200},{"name":"plugin.json","path":".claude-plugin/plugin.json","rawUrl":"https://raw.githubusercontent.com/microsoft/onnxruntime/HEAD/.claude-plugin/plugin.json","title":"claude-plugin Plugin Manifest","category":"plugin-manifest","format":"json","content":"# claude-plugin Plugin Manifest\n\nPath: `.claude-plugin/plugin.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/microsoft/onnxruntime/HEAD/.claude-plugin/plugin.json)","tokens":300,"sizeBytes":186},{"name":"mcp.json","path":".cursor/mcp.json","rawUrl":"https://raw.githubusercontent.com/microsoft/onnxruntime/HEAD/.cursor/mcp.json","title":"Model Context Protocol (MCP) Configuration","category":"mcp-config","format":"json","content":"# Model Context Protocol (MCP) Configuration\n\nPath: `.cursor/mcp.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/microsoft/onnxruntime/HEAD/.cursor/mcp.json)","tokens":300,"sizeBytes":179}],"systemPromptSnippet":"<yakaai_skills repo=\"microsoft/onnxruntime\">\n<!-- File: AGENTS.md (Tokens: ~1873 | Category: root-instruction) -->\n# Agent Instructions for ONNX Runtime\n\nThis file contains repository-wide guidance for coding agents. See\n[Extending Agent Coding Guidance](docs/Agent_Coding_Guidance.md) when adding or updating guidance.\n\n## Path-Scoped Instructions\n\nBefore implementing or reviewing changes, inspect `.github/instructions/**/*.instructions.md` and parse each file's\n`applyTo` scope. Apply every instruction whose scope matches any target or changed path. Unless explicitly stated\notherwise, matching instructions apply to both implementation and review.\n\n## Agent Skills\n\nRepository skills are available in [`.github/skills`](.github/skills/). Load each skill whose description matches the\nrequested task, subsystem, or behavior.\n\nFor code reviews, follow the `/code-review` skill in addition to relevant domain skills and matching path-scoped\ninstructions.\n\n## Build, Test, and Lint\n\nSee the `/ort-build`, `/ort-test`, and `/ort-lint` skills for detailed instructions.\n\n## CI\n\nSee the `/ort-ci` skill for triggering, re-running, and unblocking CI checks on a pull request (GitHub Actions, Azure\nPipelines, `Python format`, and `license/cla`).\n\n## Architecture Overview\n\nONNX Runtime is a cross-platform inference and training engine for ONNX models. The core pipeline is: **Load model → Build graph → Optimize graph → Partition across Execution Providers → Execute**.\n\n### Key layers (`onnxruntime/core/`)\n\n- **`graph/`** — ONNX model/graph IR. `Model` wraps a `Graph` of `Node`s. `GraphViewer` provides read-only traversal.\n- **`optimizer/`** — Graph transformations (fusion, elimination, constant folding, layout transforms). Organized by optimization level (Level1–Level4).\n- **`framework/`** — Execution machinery: `OpKernel`, `Tensor`, `KernelRegistry`, allocators, executors.\n- **`session/`** — `InferenceSession`: `Load()` → `Initialize()` (optimize + assign kernels) → `Run()`.\n- **`providers/`** — Execution Provider (EP) implementations. Each EP implements `IExecutionProvider`. CPU EP is the default fallback. 20+ EPs exist (CUDA, TensorRT, DirectML, CoreML, OpenVINO, WebGPU, QNN, etc.).\n- **`common/`** — Utilities, status/error types, logging, threading.\n- **`platform/`** — OS abstraction (file I/O, threading).\n\n### Contrib ops (`onnxruntime/contrib_ops/`)\n\nCustom operators not in the ONNX standard, organized by EP (`cpu/`, `cuda/`, `js/`, `webgpu/`). Each EP has its own contrib kernel registration file (e.g., `cpu_contrib_kernels.cc`, `cuda_contrib_kernels.cc`, `js_contrib_kernels.cc`, `webgpu_contrib_kernels.cc`).\n\n### Training (`orttraining/`)\n\nTraining-specific code (gradient ops, loss functions, optimizers, `TrainingSession`) layered on top of the inference framework.\n\n### Language bindings\n\n`csharp/`, `java/`, `js/`, `objectivec/`, `rust/` — each wraps the C API (`include/onnxruntime/core/session/onnxruntime_c_api.h`).\n\n## General Code Conventions\n\n### Code Comments\n\nKeep code comments concise. Add a comment only when it explains rationale, an invariant, a constraint, or subtle behavior\nthat is not clear from the immediate context. Do not narrate obvious code or document the sequence of approaches taken\nto reach the current implementation; that history belongs in the pull request or commit message when relevant.\n\n## C++ Conventions\n\n**Style**: Google C++ Style with modifications. Max line length 120 (aim for 80). See `docs/Coding_Conventions_and_Standards.md` for full details.\n\n### Error handling\n\nFunctions that can fail return `onnxruntime::common::Status`. Key macros from `core/common/common.h`:\n\n- `ORT_RETURN_IF_ERROR(expr)` — early-return if `expr` returns non-OK Status\n- `ORT_THROW_IF_ERROR(expr)` — throw if `expr` returns non-OK Status\n- `ORT_RETURN_IF(cond, ...)` / `ORT_RETURN_IF_NOT(cond, ...)` — conditional early-return with message\n- `ORT_ENFORCE(cond, ...)` — assert-like; throws `OnnxRuntimeException` on failure\n- `ORT_MAKE_STATUS(category, code, ...)` — construct a Status object\n\nExceptions may be disabled in a build, in which case, the throwing macros will call `abort()` instead.\n\nAt the C API boundary, use `API_IMPL_BEGIN` / `API_IMPL_END` to catch exceptions — C++ exceptions must never cross the C API boundary.\n\n### Container types\n\nUse these instead of `std::vector` / `std::unordered_map`:\n\n- `InlinedVector<T>` — small-buffer-optimized vector (64 bytes inline)\n- `InlinedHashSet<T>`, `InlinedHashMap<K,V>` — flat hash containers\n- `NodeHashSet<T>`, `NodeHashMap<K,V>` — when pointer stability is needed\n- `TensorShapeVector` — for shape dimensions\n\nUse `reserve()` not `resize()`. Do not use `absl::` directly — use the ORT typedefs.\n\n### Other conventions\n\n- `#pragma once` for header guards\n- `ORT_DISALLOW_COPY_ASSIGNMENT_AND_MOVE` for new classes until copy/move is proven necessary\n- Prefer `gsl::span<const T>` over `const std::vector<T>&` for input parameters\n- Prefer `std::string_view` by value over `const std::string&`\n- `SafeInt<size_t>` (from `core/common/safeint.h`) for memory size arithmetic\n- **Signed vs unsigned on negative-capable differences.** Any expression of the form `a - b`\n  that can be negative (an offset or remaining-budget computed from counts, e.g.\n  `num_keys - num_queries`) must be stored and compared using a **signed** type\n  (`int32_t`/`int64_t`), and any unsigned operand must be `static_cast` to signed *before*\n  the subtraction/comparison. An unsigned result silently wraps to a huge value (`~4.29e9`\n  for `uint32_t`), which can permanently satisfy or skip a relational guard with **no crash\n  and no warning** — a correct-looking-but-wrong result. Concrete ORT instance + the exact\n  fix sites: CUTLASS FMHA `causal_diagonal_offset`, see the `cuda-attention-kernel-patterns`\n  skill §12.\n- Don't use `else` after `return`\n- Avoid `long` (ambiguous width) — use `int64_t` for dimensions, `size_t` for counts\n- `using namespace` allowed in limited scope but never at global scope in headers\n- `std::make_unique()` for heap allocations; prefer `std::optional` over `unique_ptr` for optional/delayed construction\n\n## Python\n\n### Virtual environment\n\nBuild and test processes may install Python packages. Create and activate an isolated virtual environment first:\n\n```bash\npython -m venv .venv                  # one-time setup\nsource .venv/bin/activate             # Linux/macOS\n.\\.venv\\Scripts\\Activate.ps1          # Windows (PowerShell)\n```\n\nIf a virtual environment already exists (e.g., `.venv/`), activate it rather than creating a new one.\n\n### Conventions\n\n- Follow [Google Python Style Guide](https://google.github.io/styleguide/pyguide.html) (extension of PEP 8)\n- Max line length: 120 characters\n- Formatter: ruff (configured in `pyproject.toml`)\n- Static type checking: pyright/pylance\n- Test framework: `unittest` (preferred) with `pytest` as runner\n\n## C API Conventions\n\nThe main public C API header is `include/onnxruntime/core/session/onnxruntime_c_api.h`. Other public headers are in `include/onnxruntime/core/session/` and `orttraining/orttraining/training_api/include/`.\n\n- Functions that may fail return `OrtStatus*` (`nullptr` on success); release/cleanup functions return `void`\n- Object lifecycle: `OrtCreateXxx` / `OrtReleaseXxx`\n- All strings are UTF-8 encoded\n- Use `int64_t` for dimensions, `size_t` for counts and memory sizes\n- APIs requiring allocation take an `OrtAllocator*` parameter\n- Failed calls must not modify out-parameters\n\n## PR Guidelines\n\n- Keep PRs small (aim for ≤10 files; separate cosmetic changes from functional ones)\n- All changes must have unit tests, unless documentation-only or already adequately covered\n- Build and test locally on at least one platform before submitting\n- PR author is responsible for merging after approval\n\n<!-- File: .github/copilot-instructions.md (Tokens: ~38 | Category: copilot-instructions) -->\n# Copilot Instructions for ONNX Runtime\n\nRead and follow [AGENTS.md](../AGENTS.md) for repository-wide guidance, including codebase conventions, architecture,\nand coding standards.\n\n<!-- File: .claude-plugin/marketplace.json (Tokens: ~300 | Category: marketplace) -->\n# Claude Plugin Marketplace Catalog\n\nPath: `.claude-plugin/marketplace.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/microsoft/onnxruntime/HEAD/.claude-plugin/marketplace.json)\n\n<!-- File: .claude-plugin/plugin.json (Tokens: ~300 | Category: plugin-manifest) -->\n# claude-plugin Plugin Manifest\n\nPath: `.claude-plugin/plugin.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/microsoft/onnxruntime/HEAD/.claude-plugin/plugin.json)\n\n<!-- File: .cursor/mcp.json (Tokens: ~300 | Category: mcp-config) -->\n# Model Context Protocol (MCP) Configuration\n\nPath: `.cursor/mcp.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/microsoft/onnxruntime/HEAD/.cursor/mcp.json)\n</yakaai_skills>"}