{"owner":"microsoft","repo":"onnxruntime","hasSkills":true,"hasMcp":false,"mcpConfig":null,"found":["AGENTS.md",".github/copilot-instructions.md"],"files":{"AGENTS.md":"# Agent Instructions for ONNX Runtime\n\n## Build, Test, and Lint\n\nSee the `/ort-build`, `/ort-test`, and `/ort-lint` skills (in `.agents/skills/`) for detailed instructions.\n\n## CI\n\nSee the `/ort-ci` skill (in `.agents/skills/`) for triggering, re-running, and unblocking CI checks on a pull request (GitHub Actions, Azure Pipelines, `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## 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\nFor detailed codebase conventions, architecture, and coding standards, see [AGENTS.md](../AGENTS.md).\n\n## Code Review\n\n### No C API Version Bump Needed for API Additions\n\n`ORT_API_VERSION`, the `ort_api_1_to_N` function pointer table, and the version-boundary `static_assert` checks in\n`onnxruntime/core/session/onnxruntime_c_api.cc` are updated only during release preparation — not each time a new API\nis added. See [`docs/Versioning.md`](../docs/Versioning.md) for the full release versioning process.\n\nDuring development, new API function pointers are appended to the **current** `ort_api_1_to_N` table. This is the\nexpected workflow and does **not** require a version bump, a new table, or new `static_assert` entries. Do not flag\nPRs that append new function pointers to the current table as needing a version bump.\n"}}