[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill-nvidia-doca-urom":3,"mdc-eqg4fb-key":31,"related-repo-nvidia-doca-urom":1477,"related-org-nvidia-doca-urom":1581},{"slug":4,"name":4,"fn":5,"description":6,"org":7,"tags":11,"stars":20,"repoUrl":21,"updatedAt":22,"license":23,"forks":24,"topics":25,"repo":26,"sourceUrl":29,"mdContent":30},"doca-urom","offload remote memory operations with DOCA UROM","Use this skill when the user is doing hands-on DOCA UROM library work from the host side — wiring doca-urom under an HPC \u002F UCX \u002F MPI stack to OFFLOAD remote memory operations (puts, gets, atomics, collectives) onto a BlueField DPU, creating a UROM Service context (doca_urom_service_*) and Worker contexts (doca_urom_worker_*) that run plugins on the DPU, discovering plugins via doca_urom_service_get_plugins_list, progressing completions, or debugging DOCA_ERROR_* from a doca_urom_* call. Trigger even without \"DOCA UROM\": \"MPI all-reduce burning host CPU\", \"push UCX traffic onto the BlueField\", \"first doca_urom call returns NOT_PERMITTED\", or \"host library and DPU service look out of sync\". Route elsewhere for UROM Service deployment on the DPU side, MPI \u002F UCX collective algorithm design, and RDMA \u002F RoCE \u002F IB substrate bring-up.\n",{"slug":8,"name":9,"logoUrl":10,"githubOrg":9},"nvidia","NVIDIA","https:\u002F\u002Fpexgzepcugksgbtrxkhf.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Forg-logos\u002Fnvidia.png",[12,16,17],{"name":13,"slug":14,"type":15},"Performance","performance","tag",{"name":9,"slug":8,"type":15},{"name":18,"slug":19,"type":15},"Engineering","engineering",2473,"https:\u002F\u002Fgithub.com\u002FNVIDIA\u002Fskills","2026-07-30T05:28:27.489965","Apache-2.0",281,[],{"repoUrl":21,"stars":20,"forks":24,"topics":27,"description":28},[],"AI agent skills published by NVIDIA","https:\u002F\u002Fgithub.com\u002FNVIDIA\u002Fskills\u002Ftree\u002FHEAD\u002Fskills\u002Fdoca-urom","---\nlicense: Apache-2.0\nname: doca-urom\ndescription: >\n  Use this skill when the user is doing hands-on DOCA UROM library work\n  from the host side — wiring doca-urom under an HPC \u002F UCX \u002F MPI stack\n  to OFFLOAD remote memory operations (puts, gets, atomics, collectives)\n  onto a BlueField DPU, creating a UROM Service context\n  (doca_urom_service_*) and Worker contexts (doca_urom_worker_*) that\n  run plugins on the DPU, discovering plugins via\n  doca_urom_service_get_plugins_list, progressing completions, or\n  debugging DOCA_ERROR_* from a doca_urom_* call. Trigger even without\n  \"DOCA UROM\": \"MPI all-reduce burning host CPU\", \"push UCX traffic\n  onto the BlueField\", \"first doca_urom call returns NOT_PERMITTED\", or\n  \"host library and DPU service look out of sync\". Route elsewhere for\n  UROM Service deployment on the DPU side, MPI \u002F UCX collective\n  algorithm design, and RDMA \u002F RoCE \u002F IB substrate bring-up.\nmetadata:\n  kind: library\ncompatibility: >\n  Requires DOCA SDK installed at \u002Fopt\u002Fmellanox\u002Fdoca on Linux (Ubuntu\n  22.04\u002F24.04 or RHEL\u002FSLES) on a host paired with a BlueField DPU\n  running the DOCA UROM Service at a compatible version. Reads the\n  user's local install via `pkg-config doca-urom` and inspects\n  \u002Fopt\u002Fmellanox\u002Fdoca\u002F{lib,include,samples,applications}; underlying\n  RDMA fabric between host and BlueField must be healthy.\n---\n\n# DOCA UROM\n\n**Where to start:** This skill assumes DOCA is already installed on\nboth the host and the BlueField, the DOCA UROM Service is\ndeployed and running on the BlueField side, and the user is doing\n**hands-on UROM work from the host side** — i.e. using\n`doca-urom` from an HPC \u002F UCX \u002F MPI stack on the host to enqueue\nremote memory operations (puts, gets, atomics, active messages,\ncollective primitives) that the BlueField DPU will execute on the\nhost's behalf. Open [`TASKS.md`](TASKS.md) if the user wants to\n*do* something (configure \u002F build \u002F modify \u002F run \u002F test \u002F\ndebug); open [`CAPABILITIES.md`](CAPABILITIES.md) when the\nquestion is *what can the host-side UROM API express* on this\nversion + this BlueField + this UROM Service version. If the\nuser has not installed DOCA yet, route to\n[`doca-setup`](..\u002F..\u002Fdoca-setup\u002FSKILL.md) first; if the user is\nasking about the **DPU-side UROM Service** itself (deployment,\ncontainer, operation lifecycle on the DPU side), that is a\nDIFFERENT artifact — route via\n[`doca-public-knowledge-map ## DOCA services`](..\u002F..\u002Fdoca-public-knowledge-map\u002FSKILL.md#doca-services)\nto the public *DOCA UROM Service* guide. This skill is the\n**host-side library**; the UROM Service is the **DPU-side\nexecutor**, and they are a paired contract.\n\n## Example questions this skill answers well\n\nThe CLASSES of UROM questions this skill is built to answer,\neach with one worked example. The agent should treat the *class*\nas the load-bearing piece — the worked example is a single\ninstance.\n\n- **\"How do I offload my MPI \u002F UCX remote memory operations from\n  the host CPU to the BlueField DPU?\"** — worked example: *\"my\n  MPI all-reduce is consuming host CPU cycles I'd rather use for\n  compute — how do I push that work onto the BlueField via\n  UROM?\"*. Answered by the host-library-plus-DPU-service\n  paired-contract model in\n  [`CAPABILITIES.md ## Capabilities and modes`](CAPABILITIES.md#capabilities-and-modes)\n  + the host-side bring-up workflow in\n  [`TASKS.md ## configure`](TASKS.md#configure).\n- **\"Is the DOCA UROM Service even running on my BlueField, and\n  why does that matter before I write any `doca_urom_*` code?\"** —\n  worked example: *\"my first `doca_urom_*` call returns\n  `DOCA_ERROR_NOT_PERMITTED` on a host where DOCA is otherwise\n  healthy\"*. Answered by the env-precondition matrix in\n  [`CAPABILITIES.md ## Safety policy`](CAPABILITIES.md#safety-policy)\n  + the service-deployed-and-running check in\n  [`TASKS.md ## configure`](TASKS.md#configure) step 1, which\n  routes service-side env questions to\n  [`doca-public-knowledge-map ## DOCA services`](..\u002F..\u002Fdoca-public-knowledge-map\u002FSKILL.md#doca-services).\n- **\"Is this UROM operation type \u002F atomic \u002F collective supported\n  on my device + this DOCA install + this UROM Service\n  version?\"** — worked example: *\"does my BlueField support\n  remote atomic Fetch-and-Add for an MPI window?\"*. Answered by\n  the plugin-discovery rule (`doca_urom_service_get_plugins_list`\n  on a started Service — UROM operations are plugin-defined\n  Command tasks, so the supported-plugins list is the\n  capability surface) in\n  [`CAPABILITIES.md ## Capabilities and modes`](CAPABILITIES.md#capabilities-and-modes)\n  + the discovery step in\n  [`TASKS.md ## configure`](TASKS.md#configure).\n- **\"How does `doca-urom` relate to `doca-rdma` — am I replacing\n  it, layering on top, or something else?\"** — worked example:\n  *\"I already have raw `doca-rdma` working; should I rewrite to\n  use UROM, or is that the wrong tool?\"*. Answered by the\n  path-selection rule in\n  [`CAPABILITIES.md ## Capabilities and modes`](CAPABILITIES.md#capabilities-and-modes)\n  (UROM uses the RDMA transport substrate underneath but adds\n  the DPU-offload contract on top, and is the right tool only\n  when host CPU is the bottleneck due to communication\n  overhead — small \u002F simple point-to-point cases stay on\n  `doca-rdma`).\n- **\"Is this UROM API on my installed DOCA version?\"** — worked\n  example: *\"is the collective-ops plugin discoverable via\n  `doca_urom_service_get_plugins_list` on DOCA 3.x\"*. Answered by the version-compatibility overlay in\n  [`CAPABILITIES.md ## Version compatibility`](CAPABILITIES.md#version-compatibility),\n  which cross-links the canonical detection chain in\n  [`doca-version`](..\u002F..\u002Fdoca-version\u002FSKILL.md) and adds the\n  UROM-specific *host library and DPU service versions must\n  match* overlay.\n- **\"What does this `DOCA_ERROR_*` from a `doca_urom_*` call\n  mean and which layer caused it?\"** — worked example:\n  *\"`DOCA_ERROR_NOT_PERMITTED` on the first\n  `doca_urom_*` enqueue after `doca_ctx_start()` succeeded\"*.\n  Answered by the UROM overlay on the cross-library taxonomy in\n  [`CAPABILITIES.md ## Error taxonomy`](CAPABILITIES.md#error-taxonomy)\n  + the layered ladder in\n  [`TASKS.md ## debug`](TASKS.md#debug) that escalates to\n  [`doca-debug`](..\u002F..\u002Fdoca-debug\u002FSKILL.md).\n\n## Audience\n\nThis skill serves **external developers building HPC \u002F UCX \u002F MPI\napplications that consume the DOCA UROM library from the host\nside** — i.e., users whose code calls `doca_urom_*` (directly in\nC \u002F C++, or through FFI \u002F bindings from another language, or\nthrough a UCX-based stack such as OpenMPI \u002F MPICH that has been\nwired to use DOCA UROM as a UCX transport) to push remote memory\noperations onto the BlueField DPU instead of executing them on\nthe host CPU. It is *not* for NVIDIA developers contributing to\nDOCA UROM itself, nor is it the place to learn how to **deploy \u002F\noperate the DOCA UROM Service** on the DPU side — that goes\nthrough the public *DOCA UROM Service* guide via\n[`doca-public-knowledge-map ## DOCA services`](..\u002F..\u002Fdoca-public-knowledge-map\u002FSKILL.md#doca-services).\n\n**Language scope.** DOCA UROM ships as a host-side C library\nwith `pkg-config` module name `doca-urom`. The shipped samples\nunder `\u002Fopt\u002Fmellanox\u002Fdoca\u002Fsamples\u002Fdoca_urom\u002F` are written in C\n(NVIDIA's choice). C and C++ consumers — including UCX-based\nstacks that wrap the library — are the canonical case and the\nworked examples in `TASKS.md` assume that path. Other-language\nconsumers (Rust, Go, Python, …) consume the same `*.so` through\nFFI or language-specific bindings; the skill's contribution in\nthat case is to keep the lifecycle, capability-discovery,\nservice-deployed-and-running, error-taxonomy, and\nRDMA-substrate guidance language-neutral, and to route the agent\nto the public C ABI as the authoritative surface that any\nwrapper will eventually call.\n\n## When to load this skill\n\nLoad this skill when the user is doing hands-on DOCA UROM work\n**from the host side**, in any language. Concretely:\n\n- Initializing a UROM Service context (`doca_urom_service_*`) on\n  a `doca_dev` that maps to the BlueField the user wants to\n  offload to, then creating Worker contexts\n  (`doca_urom_worker_*`) attached to that Service, and confirming\n  the matching DPU-side UROM Service is reachable before the\n  first enqueue.\n- Enqueueing remote memory operations (puts, gets, atomics,\n  active messages, collective primitives) through the host-side\n  `doca_urom_*` API and progressing the DOCA progress engine\n  for completions.\n- Reading or setting library properties via the host-side UROM\n  API and calling `doca_urom_service_get_plugins_list` on a\n  started Service to discover which plugins (and therefore which\n  operation types \u002F atomics \u002F collectives, since these are\n  plugin-defined) this device + this DOCA install + this DPU-side\n  UROM Service version actually supports.\n- Applying the host-side UROM lifecycle, capability-discovery,\n  and error rules to a UCX-based HPC stack (OpenMPI, MPICH,\n  custom UCX consumer) that is already wired to use UROM.\n  Designing the UCX transport integration itself remains\n  upstream-stack work.\n- Debugging a `DOCA_ERROR_*` returned from a `doca_urom_*` call\n  — in particular disambiguating *DPU-side UROM Service not\n  reachable* from *operation type not supported on this device*\n  from *standard `doca_dev` access denied* from *underlying\n  RDMA transport failure*.\n- Designing or extending non-C bindings (Rust, Go, Python, …)\n  that wrap the UROM C ABI — for the lifecycle,\n  service-deployed-and-running, capability-discovery, and\n  error-taxonomy rules the wrapper must honor.\n\nDo **not** load this skill for general DOCA orientation, install\nof DOCA itself, deployment \u002F operation of the DOCA UROM Service\non the DPU side (a separate artifact, with its own public guide\nreachable via\n[`doca-public-knowledge-map ## DOCA services`](..\u002F..\u002Fdoca-public-knowledge-map\u002FSKILL.md#doca-services)),\nor non-UROM library questions. For those, use\n[`doca-public-knowledge-map`](..\u002F..\u002Fdoca-public-knowledge-map\u002FSKILL.md).\n\n## What this skill provides\n\nThis is a **thin loader**. The body keeps only the orientation\nneeded to pick the right next file. The substantive\nUROM-specific material lives in two companion files:\n\n- `CAPABILITIES.md` — what the host-side UROM API can express on\n  this version + this BlueField + this UROM Service version: the\n  paired-contract model (host library enqueues; DPU service\n  executes); the two host-side context types — the\n  `doca_urom_service` (one per BlueField, bound to its\n  `doca_dev`) and the `doca_urom_worker` contexts attached to it;\n  the enqueue-side operation surface (puts, gets, atomics, active\n  messages, collective primitives) delivered as plugin-defined\n  Worker Command tasks and named generically because exact\n  symbol shapes are plugin- and install-bound; the\n  plugin-discovery surface (`doca_urom_service_get_plugins_list`);\n  the UROM error taxonomy mapped onto the cross-library `DOCA_ERROR_*` set;\n  the observability surface (completion events on the DOCA\n  progress engine, capability snapshots, infrastructure-side\n  RDMA counters); and the safety policy that gates env\n  preconditions (DOCA UROM Service deployed and running on the\n  DPU side; host library and DPU service versions agreeing; an\n  RDMA-capable BlueField + DOCA install).\n- `TASKS.md` — step-by-step workflows for the six in-scope UROM\n  verbs: `configure`, `build`, `modify`, `run`, `test`,\n  `debug`. Plus a `Deferred task verbs` block that points\n  out-of-scope questions at the right next skill.\n\nThe skill assumes a host + BlueField pair where DOCA is already\ninstalled at the standard location, the DOCA UROM Service is\nalready deployed and running on the BlueField, the underlying\nRDMA transport between host and BlueField is healthy, and the\nuser already has at least a sketch of the HPC \u002F UCX \u002F MPI stack\nthey want to offload. It does not cover installing DOCA,\ndeploying the UROM Service container on the BlueField, or\nbringing up RDMA \u002F RoCE \u002F IB transport between host and\nBlueField — those paths go through\n[`doca-setup`](..\u002F..\u002Fdoca-setup\u002FSKILL.md), the public *DOCA\nUROM Service* guide, and [`doca-rdma`](..\u002Fdoca-rdma\u002FSKILL.md)\nrespectively.\n\n## What this skill deliberately does not ship\n\nThis skill is **agent guidance**, not a samples or templates\nbundle. To keep the boundary clean, it deliberately does not\ncontain — and pull requests should not add:\n\n- **Pre-written DOCA UROM application source code, in any\n  language.** The verified UROM source code is the shipped C\n  samples at `\u002Fopt\u002Fmellanox\u002Fdoca\u002Fsamples\u002Fdoca_urom\u002F`. The\n  agent's job is to route the user to those files and prescribe\n  a minimum-diff modification on them via the universal\n  modify-a-sample workflow in\n  [`doca-programming-guide`](..\u002F..\u002Fdoca-programming-guide\u002FSKILL.md),\n  layered with the UROM-specific overrides in\n  [`TASKS.md ## modify`](TASKS.md#modify).\n- **An MPI \u002F UCX algorithm or collective implementation.** This\n  library *offloads* remote memory operations; the algorithm\n  selecting which puts \u002F gets \u002F atomics \u002F collectives to issue\n  for a given MPI primitive is the user's HPC stack (OpenMPI,\n  MPICH, custom UCX consumer) or the user's domain expertise.\n  The agent must refuse to invent collective algorithms and\n  must route any *\"what algorithm should my all-reduce use\"*\n  question to the upstream MPI \u002F UCX documentation — that is a\n  research \u002F stack-design question, not a UROM API question.\n- **Standalone build manifests** (`meson.build`,\n  `CMakeLists.txt`, `Cargo.toml`, …) parked inside the skill.\n  The agent constructs the build manifest *in the user's\n  project directory* against the user's installed DOCA, where\n  `pkg-config --modversion doca-urom` is the source of truth.\n- **A `samples\u002F`, `bindings\u002F`, or `reference\u002F` subtree** of any\n  kind. A mock or incomplete artifact in this skill's tree,\n  even one labeled \"reference\", is misleading: users will read\n  it as buildable.\n- **The DOCA UROM Service surface.** That service is a\n  *separate artifact* with its own public guide; routing for\n  its deployment \u002F operation lives in\n  [`doca-public-knowledge-map ## DOCA services`](..\u002F..\u002Fdoca-public-knowledge-map\u002FSKILL.md#doca-services).\n  Conflating the library (this skill, host-side enqueue) with\n  the service (DPU-side executor) is the single most common\n  UROM first-app design error.\n\n## Loading order\n\n1. Read this `SKILL.md` first to confirm the user's question is\n   in scope (host-side library work; not DPU-side service\n   deployment, and not MPI \u002F UCX algorithm design).\n2. **For the UROM capability matrix, the paired-contract model\n   (host library + DPU service), the Service + Worker context\n   model, the enqueue-side operation surface, the\n   plugin-discovery rule, the env-precondition policy, the\n   error taxonomy, the observability surface, and the safety\n   policy, see [CAPABILITIES.md](CAPABILITIES.md).**\n3. **For step-by-step workflows — configure, build, modify,\n   run, test, debug — see [TASKS.md](TASKS.md).**\n\nBoth companion files cross-link to each other,\n[`doca-version`](..\u002F..\u002Fdoca-version\u002FSKILL.md) for the canonical\nDOCA version-handling rules (with the UROM overlay that the\nhost library version and the DPU service version must match),\n[`doca-rdma`](..\u002Fdoca-rdma\u002FSKILL.md) for the underlying RDMA\ntransport substrate UROM offloads ride on top of, and\n[`doca-public-knowledge-map`](..\u002F..\u002Fdoca-public-knowledge-map\u002FSKILL.md)\nwhenever the right answer is \"look it up in the public DOCA\nUROM library guide, the public DOCA UROM Service guide, or in\nthe on-disk install layout\" rather than \"UROM\nhost-side-specific guidance\".\n\n## Related skills\n\n- [`doca-public-knowledge-map`](..\u002F..\u002Fdoca-public-knowledge-map\u002FSKILL.md) —\n  the routing table for every public DOCA documentation source\n  and the on-disk layout of an installed DOCA package. The\n  DOCA UROM library public guide is at\n  \u003Chttps:\u002F\u002Fdocs.nvidia.com\u002Fdoca\u002Fsdk\u002FDOCA-UROM\u002Findex.html>; the\n  DOCA UROM Service is a *different artifact* documented\n  separately under the *DOCA services* section of that map.\n- [`doca-rdma`](..\u002Fdoca-rdma\u002FSKILL.md) — the underlying RDMA\n  transport substrate the BlueField uses to actually move\n  bytes between nodes once UROM has offloaded a remote memory\n  operation. UROM does NOT replace RDMA; it adds the\n  DPU-offload contract on top so the host CPU does not have to\n  post the verbs itself. When the user's intent is simple\n  point-to-point RDMA and the host CPU is not the bottleneck,\n  the right tool is `doca-rdma` directly — UROM adds the\n  service-side contract that isn't worth its overhead for that\n  case.\n- [`doca-setup`](..\u002F..\u002Fdoca-setup\u002FSKILL.md) — env preparation,\n  install verification, BlueField setup, and the *I have no\n  install yet* path with the public NGC DOCA container. This\n  skill assumes its preconditions are satisfied AND that the\n  DPU-side UROM Service is deployed and running on the\n  BlueField.\n- [`doca-version`](..\u002F..\u002Fdoca-version\u002FSKILL.md) — canonical\n  DOCA version-handling rules. This skill's `## Version\n  compatibility` cross-links the four-way match rule and adds\n  the UROM-specific *host library and DPU service must agree on\n  version* overlay.\n- [`doca-structured-tools-contract`](..\u002F..\u002Fdoca-structured-tools-contract\u002FSKILL.md) —\n  the bundle's structured-tools precedence rule (detect \u002F\n  prefer \u002F fall back \u002F report). The Command appendix in\n  [TASKS.md](TASKS.md) honors this contract.\n- [`doca-programming-guide`](..\u002F..\u002Fdoca-programming-guide\u002FSKILL.md) —\n  general DOCA programming patterns shared by every library:\n  the canonical `pkg-config` + meson build pattern, the\n  universal modify-a-shipped-sample first-app workflow, the\n  universal Core-context lifecycle, the cross-library\n  `DOCA_ERROR_*` taxonomy, and the program-side debug order.\n  This skill layers UROM specifics on top.\n- [`doca-debug`](..\u002F..\u002Fdoca-debug\u002FSKILL.md) — the cross-cutting\n  debug ladder (install \u002F version \u002F build \u002F link \u002F runtime \u002F\n  program \u002F driver). UROM-specific debug (DPU-side UROM\n  Service not running \u002F not reachable, host library + DPU\n  service version skew, RDMA transport failure underneath the\n  UROM offload, operation type not in this device + firmware +\n  service version) overlays on top of that ladder.\n\nThe **DOCA UROM Service** that runs on the DPU side is\ndeliberately **not in scope** for this skill — it is a separate\nartifact with its own public guide, reachable through\n[`doca-public-knowledge-map ## DOCA services`](..\u002F..\u002Fdoca-public-knowledge-map\u002FSKILL.md#doca-services).\nConflating the library and the service is the single most\ncommon UROM first-app design error: the agent must surface the\nlibrary \u002F service split explicitly whenever the question\nstraddles the two.\n",{"data":32,"body":36},{"license":23,"name":4,"description":6,"metadata":33,"compatibility":35},{"kind":34},"library","Requires DOCA SDK installed at \u002Fopt\u002Fmellanox\u002Fdoca on Linux (Ubuntu 22.04\u002F24.04 or RHEL\u002FSLES) on a host paired with a BlueField DPU running the DOCA UROM Service at a compatible version. Reads the user's local install via `pkg-config doca-urom` and inspects \u002Fopt\u002Fmellanox\u002Fdoca\u002F{lib,include,samples,applications}; underlying RDMA fabric between host and BlueField must be healthy.\n",{"type":37,"children":38},"root",[39,47,164,171,183,566,572,620,668,674,686,804,836,842,854,967,1000,1006,1018,1192,1198,1241,1276,1282,1449],{"type":40,"tag":41,"props":42,"children":43},"element","h1",{"id":4},[44],{"type":45,"value":46},"text","DOCA UROM",{"type":40,"tag":48,"props":49,"children":50},"p",{},[51,57,59,64,66,72,74,84,86,92,94,103,105,110,112,122,124,129,131,141,143,148,150,155,157,162],{"type":40,"tag":52,"props":53,"children":54},"strong",{},[55],{"type":45,"value":56},"Where to start:",{"type":45,"value":58}," This skill assumes DOCA is already installed on\nboth the host and the BlueField, the DOCA UROM Service is\ndeployed and running on the BlueField side, and the user is doing\n",{"type":40,"tag":52,"props":60,"children":61},{},[62],{"type":45,"value":63},"hands-on UROM work from the host side",{"type":45,"value":65}," — i.e. using\n",{"type":40,"tag":67,"props":68,"children":70},"code",{"className":69},[],[71],{"type":45,"value":4},{"type":45,"value":73}," from an HPC \u002F UCX \u002F MPI stack on the host to enqueue\nremote memory operations (puts, gets, atomics, active messages,\ncollective primitives) that the BlueField DPU will execute on the\nhost's behalf. Open ",{"type":40,"tag":75,"props":76,"children":78},"a",{"href":77},"TASKS.md",[79],{"type":40,"tag":67,"props":80,"children":82},{"className":81},[],[83],{"type":45,"value":77},{"type":45,"value":85}," if the user wants to\n",{"type":40,"tag":87,"props":88,"children":89},"em",{},[90],{"type":45,"value":91},"do",{"type":45,"value":93}," something (configure \u002F build \u002F modify \u002F run \u002F test \u002F\ndebug); open ",{"type":40,"tag":75,"props":95,"children":97},{"href":96},"CAPABILITIES.md",[98],{"type":40,"tag":67,"props":99,"children":101},{"className":100},[],[102],{"type":45,"value":96},{"type":45,"value":104}," when the\nquestion is ",{"type":40,"tag":87,"props":106,"children":107},{},[108],{"type":45,"value":109},"what can the host-side UROM API express",{"type":45,"value":111}," on this\nversion + this BlueField + this UROM Service version. If the\nuser has not installed DOCA yet, route to\n",{"type":40,"tag":75,"props":113,"children":115},{"href":114},"..\u002F..\u002Fdoca-setup\u002FSKILL.md",[116],{"type":40,"tag":67,"props":117,"children":119},{"className":118},[],[120],{"type":45,"value":121},"doca-setup",{"type":45,"value":123}," first; if the user is\nasking about the ",{"type":40,"tag":52,"props":125,"children":126},{},[127],{"type":45,"value":128},"DPU-side UROM Service",{"type":45,"value":130}," itself (deployment,\ncontainer, operation lifecycle on the DPU side), that is a\nDIFFERENT artifact — route via\n",{"type":40,"tag":75,"props":132,"children":134},{"href":133},"..\u002F..\u002Fdoca-public-knowledge-map\u002FSKILL.md#doca-services",[135],{"type":40,"tag":67,"props":136,"children":138},{"className":137},[],[139],{"type":45,"value":140},"doca-public-knowledge-map ## DOCA services",{"type":45,"value":142},"\nto the public ",{"type":40,"tag":87,"props":144,"children":145},{},[146],{"type":45,"value":147},"DOCA UROM Service",{"type":45,"value":149}," guide. This skill is the\n",{"type":40,"tag":52,"props":151,"children":152},{},[153],{"type":45,"value":154},"host-side library",{"type":45,"value":156},"; the UROM Service is the ",{"type":40,"tag":52,"props":158,"children":159},{},[160],{"type":45,"value":161},"DPU-side\nexecutor",{"type":45,"value":163},", and they are a paired contract.",{"type":40,"tag":165,"props":166,"children":168},"h2",{"id":167},"example-questions-this-skill-answers-well",[169],{"type":45,"value":170},"Example questions this skill answers well",{"type":40,"tag":48,"props":172,"children":173},{},[174,176,181],{"type":45,"value":175},"The CLASSES of UROM questions this skill is built to answer,\neach with one worked example. The agent should treat the ",{"type":40,"tag":87,"props":177,"children":178},{},[179],{"type":45,"value":180},"class",{"type":45,"value":182},"\nas the load-bearing piece — the worked example is a single\ninstance.",{"type":40,"tag":184,"props":185,"children":186},"ul",{},[187,235,312,361,417,472],{"type":40,"tag":188,"props":189,"children":190},"li",{},[191,196,198,203,205,215],{"type":40,"tag":52,"props":192,"children":193},{},[194],{"type":45,"value":195},"\"How do I offload my MPI \u002F UCX remote memory operations from\nthe host CPU to the BlueField DPU?\"",{"type":45,"value":197}," — worked example: ",{"type":40,"tag":87,"props":199,"children":200},{},[201],{"type":45,"value":202},"\"my\nMPI all-reduce is consuming host CPU cycles I'd rather use for\ncompute — how do I push that work onto the BlueField via\nUROM?\"",{"type":45,"value":204},". Answered by the host-library-plus-DPU-service\npaired-contract model in\n",{"type":40,"tag":75,"props":206,"children":208},{"href":207},"CAPABILITIES.md#capabilities-and-modes",[209],{"type":40,"tag":67,"props":210,"children":212},{"className":211},[],[213],{"type":45,"value":214},"CAPABILITIES.md ## Capabilities and modes",{"type":40,"tag":184,"props":216,"children":217},{},[218],{"type":40,"tag":188,"props":219,"children":220},{},[221,223,233],{"type":45,"value":222},"the host-side bring-up workflow in\n",{"type":40,"tag":75,"props":224,"children":226},{"href":225},"TASKS.md#configure",[227],{"type":40,"tag":67,"props":228,"children":230},{"className":229},[],[231],{"type":45,"value":232},"TASKS.md ## configure",{"type":45,"value":234},".",{"type":40,"tag":188,"props":236,"children":237},{},[238,251,253,273,275,285],{"type":40,"tag":52,"props":239,"children":240},{},[241,243,249],{"type":45,"value":242},"\"Is the DOCA UROM Service even running on my BlueField, and\nwhy does that matter before I write any ",{"type":40,"tag":67,"props":244,"children":246},{"className":245},[],[247],{"type":45,"value":248},"doca_urom_*",{"type":45,"value":250}," code?\"",{"type":45,"value":252}," —\nworked example: ",{"type":40,"tag":87,"props":254,"children":255},{},[256,258,263,265,271],{"type":45,"value":257},"\"my first ",{"type":40,"tag":67,"props":259,"children":261},{"className":260},[],[262],{"type":45,"value":248},{"type":45,"value":264}," call returns\n",{"type":40,"tag":67,"props":266,"children":268},{"className":267},[],[269],{"type":45,"value":270},"DOCA_ERROR_NOT_PERMITTED",{"type":45,"value":272}," on a host where DOCA is otherwise\nhealthy\"",{"type":45,"value":274},". Answered by the env-precondition matrix in\n",{"type":40,"tag":75,"props":276,"children":278},{"href":277},"CAPABILITIES.md#safety-policy",[279],{"type":40,"tag":67,"props":280,"children":282},{"className":281},[],[283],{"type":45,"value":284},"CAPABILITIES.md ## Safety policy",{"type":40,"tag":184,"props":286,"children":287},{},[288],{"type":40,"tag":188,"props":289,"children":290},{},[291,293,301,303,311],{"type":45,"value":292},"the service-deployed-and-running check in\n",{"type":40,"tag":75,"props":294,"children":295},{"href":225},[296],{"type":40,"tag":67,"props":297,"children":299},{"className":298},[],[300],{"type":45,"value":232},{"type":45,"value":302}," step 1, which\nroutes service-side env questions to\n",{"type":40,"tag":75,"props":304,"children":305},{"href":133},[306],{"type":40,"tag":67,"props":307,"children":309},{"className":308},[],[310],{"type":45,"value":140},{"type":45,"value":234},{"type":40,"tag":188,"props":313,"children":314},{},[315,320,321,326,328,334,336,344],{"type":40,"tag":52,"props":316,"children":317},{},[318],{"type":45,"value":319},"\"Is this UROM operation type \u002F atomic \u002F collective supported\non my device + this DOCA install + this UROM Service\nversion?\"",{"type":45,"value":197},{"type":40,"tag":87,"props":322,"children":323},{},[324],{"type":45,"value":325},"\"does my BlueField support\nremote atomic Fetch-and-Add for an MPI window?\"",{"type":45,"value":327},". Answered by\nthe plugin-discovery rule (",{"type":40,"tag":67,"props":329,"children":331},{"className":330},[],[332],{"type":45,"value":333},"doca_urom_service_get_plugins_list",{"type":45,"value":335},"\non a started Service — UROM operations are plugin-defined\nCommand tasks, so the supported-plugins list is the\ncapability surface) in\n",{"type":40,"tag":75,"props":337,"children":338},{"href":207},[339],{"type":40,"tag":67,"props":340,"children":342},{"className":341},[],[343],{"type":45,"value":214},{"type":40,"tag":184,"props":345,"children":346},{},[347],{"type":40,"tag":188,"props":348,"children":349},{},[350,352,360],{"type":45,"value":351},"the discovery step in\n",{"type":40,"tag":75,"props":353,"children":354},{"href":225},[355],{"type":40,"tag":67,"props":356,"children":358},{"className":357},[],[359],{"type":45,"value":232},{"type":45,"value":234},{"type":40,"tag":188,"props":362,"children":363},{},[364,384,386,398,400,408,410,415],{"type":40,"tag":52,"props":365,"children":366},{},[367,369,374,376,382],{"type":45,"value":368},"\"How does ",{"type":40,"tag":67,"props":370,"children":372},{"className":371},[],[373],{"type":45,"value":4},{"type":45,"value":375}," relate to ",{"type":40,"tag":67,"props":377,"children":379},{"className":378},[],[380],{"type":45,"value":381},"doca-rdma",{"type":45,"value":383}," — am I replacing\nit, layering on top, or something else?\"",{"type":45,"value":385}," — worked example:\n",{"type":40,"tag":87,"props":387,"children":388},{},[389,391,396],{"type":45,"value":390},"\"I already have raw ",{"type":40,"tag":67,"props":392,"children":394},{"className":393},[],[395],{"type":45,"value":381},{"type":45,"value":397}," working; should I rewrite to\nuse UROM, or is that the wrong tool?\"",{"type":45,"value":399},". Answered by the\npath-selection rule in\n",{"type":40,"tag":75,"props":401,"children":402},{"href":207},[403],{"type":40,"tag":67,"props":404,"children":406},{"className":405},[],[407],{"type":45,"value":214},{"type":45,"value":409},"\n(UROM uses the RDMA transport substrate underneath but adds\nthe DPU-offload contract on top, and is the right tool only\nwhen host CPU is the bottleneck due to communication\noverhead — small \u002F simple point-to-point cases stay on\n",{"type":40,"tag":67,"props":411,"children":413},{"className":412},[],[414],{"type":45,"value":381},{"type":45,"value":416},").",{"type":40,"tag":188,"props":418,"children":419},{},[420,425,427,439,441,451,453,463,465,470],{"type":40,"tag":52,"props":421,"children":422},{},[423],{"type":45,"value":424},"\"Is this UROM API on my installed DOCA version?\"",{"type":45,"value":426}," — worked\nexample: ",{"type":40,"tag":87,"props":428,"children":429},{},[430,432,437],{"type":45,"value":431},"\"is the collective-ops plugin discoverable via\n",{"type":40,"tag":67,"props":433,"children":435},{"className":434},[],[436],{"type":45,"value":333},{"type":45,"value":438}," on DOCA 3.x\"",{"type":45,"value":440},". Answered by the version-compatibility overlay in\n",{"type":40,"tag":75,"props":442,"children":444},{"href":443},"CAPABILITIES.md#version-compatibility",[445],{"type":40,"tag":67,"props":446,"children":448},{"className":447},[],[449],{"type":45,"value":450},"CAPABILITIES.md ## Version compatibility",{"type":45,"value":452},",\nwhich cross-links the canonical detection chain in\n",{"type":40,"tag":75,"props":454,"children":456},{"href":455},"..\u002F..\u002Fdoca-version\u002FSKILL.md",[457],{"type":40,"tag":67,"props":458,"children":460},{"className":459},[],[461],{"type":45,"value":462},"doca-version",{"type":45,"value":464}," and adds the\nUROM-specific ",{"type":40,"tag":87,"props":466,"children":467},{},[468],{"type":45,"value":469},"host library and DPU service versions must\nmatch",{"type":45,"value":471}," overlay.",{"type":40,"tag":188,"props":473,"children":474},{},[475,495,496,523,525,535],{"type":40,"tag":52,"props":476,"children":477},{},[478,480,486,488,493],{"type":45,"value":479},"\"What does this ",{"type":40,"tag":67,"props":481,"children":483},{"className":482},[],[484],{"type":45,"value":485},"DOCA_ERROR_*",{"type":45,"value":487}," from a ",{"type":40,"tag":67,"props":489,"children":491},{"className":490},[],[492],{"type":45,"value":248},{"type":45,"value":494}," call\nmean and which layer caused it?\"",{"type":45,"value":385},{"type":40,"tag":87,"props":497,"children":498},{},[499,501,506,508,513,515,521],{"type":45,"value":500},"\"",{"type":40,"tag":67,"props":502,"children":504},{"className":503},[],[505],{"type":45,"value":270},{"type":45,"value":507}," on the first\n",{"type":40,"tag":67,"props":509,"children":511},{"className":510},[],[512],{"type":45,"value":248},{"type":45,"value":514}," enqueue after ",{"type":40,"tag":67,"props":516,"children":518},{"className":517},[],[519],{"type":45,"value":520},"doca_ctx_start()",{"type":45,"value":522}," succeeded\"",{"type":45,"value":524},".\nAnswered by the UROM overlay on the cross-library taxonomy in\n",{"type":40,"tag":75,"props":526,"children":528},{"href":527},"CAPABILITIES.md#error-taxonomy",[529],{"type":40,"tag":67,"props":530,"children":532},{"className":531},[],[533],{"type":45,"value":534},"CAPABILITIES.md ## Error taxonomy",{"type":40,"tag":184,"props":536,"children":537},{},[538],{"type":40,"tag":188,"props":539,"children":540},{},[541,543,553,555,565],{"type":45,"value":542},"the layered ladder in\n",{"type":40,"tag":75,"props":544,"children":546},{"href":545},"TASKS.md#debug",[547],{"type":40,"tag":67,"props":548,"children":550},{"className":549},[],[551],{"type":45,"value":552},"TASKS.md ## debug",{"type":45,"value":554}," that escalates to\n",{"type":40,"tag":75,"props":556,"children":558},{"href":557},"..\u002F..\u002Fdoca-debug\u002FSKILL.md",[559],{"type":40,"tag":67,"props":560,"children":562},{"className":561},[],[563],{"type":45,"value":564},"doca-debug",{"type":45,"value":234},{"type":40,"tag":165,"props":567,"children":569},{"id":568},"audience",[570],{"type":45,"value":571},"Audience",{"type":40,"tag":48,"props":573,"children":574},{},[575,577,582,584,589,591,596,598,603,605,609,611,619],{"type":45,"value":576},"This skill serves ",{"type":40,"tag":52,"props":578,"children":579},{},[580],{"type":45,"value":581},"external developers building HPC \u002F UCX \u002F MPI\napplications that consume the DOCA UROM library from the host\nside",{"type":45,"value":583}," — i.e., users whose code calls ",{"type":40,"tag":67,"props":585,"children":587},{"className":586},[],[588],{"type":45,"value":248},{"type":45,"value":590}," (directly in\nC \u002F C++, or through FFI \u002F bindings from another language, or\nthrough a UCX-based stack such as OpenMPI \u002F MPICH that has been\nwired to use DOCA UROM as a UCX transport) to push remote memory\noperations onto the BlueField DPU instead of executing them on\nthe host CPU. It is ",{"type":40,"tag":87,"props":592,"children":593},{},[594],{"type":45,"value":595},"not",{"type":45,"value":597}," for NVIDIA developers contributing to\nDOCA UROM itself, nor is it the place to learn how to ",{"type":40,"tag":52,"props":599,"children":600},{},[601],{"type":45,"value":602},"deploy \u002F\noperate the DOCA UROM Service",{"type":45,"value":604}," on the DPU side — that goes\nthrough the public ",{"type":40,"tag":87,"props":606,"children":607},{},[608],{"type":45,"value":147},{"type":45,"value":610}," guide via\n",{"type":40,"tag":75,"props":612,"children":613},{"href":133},[614],{"type":40,"tag":67,"props":615,"children":617},{"className":616},[],[618],{"type":45,"value":140},{"type":45,"value":234},{"type":40,"tag":48,"props":621,"children":622},{},[623,628,630,636,638,643,645,651,653,658,660,666],{"type":40,"tag":52,"props":624,"children":625},{},[626],{"type":45,"value":627},"Language scope.",{"type":45,"value":629}," DOCA UROM ships as a host-side C library\nwith ",{"type":40,"tag":67,"props":631,"children":633},{"className":632},[],[634],{"type":45,"value":635},"pkg-config",{"type":45,"value":637}," module name ",{"type":40,"tag":67,"props":639,"children":641},{"className":640},[],[642],{"type":45,"value":4},{"type":45,"value":644},". The shipped samples\nunder ",{"type":40,"tag":67,"props":646,"children":648},{"className":647},[],[649],{"type":45,"value":650},"\u002Fopt\u002Fmellanox\u002Fdoca\u002Fsamples\u002Fdoca_urom\u002F",{"type":45,"value":652}," are written in C\n(NVIDIA's choice). C and C++ consumers — including UCX-based\nstacks that wrap the library — are the canonical case and the\nworked examples in ",{"type":40,"tag":67,"props":654,"children":656},{"className":655},[],[657],{"type":45,"value":77},{"type":45,"value":659}," assume that path. Other-language\nconsumers (Rust, Go, Python, …) consume the same ",{"type":40,"tag":67,"props":661,"children":663},{"className":662},[],[664],{"type":45,"value":665},"*.so",{"type":45,"value":667}," through\nFFI or language-specific bindings; the skill's contribution in\nthat case is to keep the lifecycle, capability-discovery,\nservice-deployed-and-running, error-taxonomy, and\nRDMA-substrate guidance language-neutral, and to route the agent\nto the public C ABI as the authoritative surface that any\nwrapper will eventually call.",{"type":40,"tag":165,"props":669,"children":671},{"id":670},"when-to-load-this-skill",[672],{"type":45,"value":673},"When to load this skill",{"type":40,"tag":48,"props":675,"children":676},{},[677,679,684],{"type":45,"value":678},"Load this skill when the user is doing hands-on DOCA UROM work\n",{"type":40,"tag":52,"props":680,"children":681},{},[682],{"type":45,"value":683},"from the host side",{"type":45,"value":685},", in any language. Concretely:",{"type":40,"tag":184,"props":687,"children":688},{},[689,718,730,742,747,799],{"type":40,"tag":188,"props":690,"children":691},{},[692,694,700,702,708,710,716],{"type":45,"value":693},"Initializing a UROM Service context (",{"type":40,"tag":67,"props":695,"children":697},{"className":696},[],[698],{"type":45,"value":699},"doca_urom_service_*",{"type":45,"value":701},") on\na ",{"type":40,"tag":67,"props":703,"children":705},{"className":704},[],[706],{"type":45,"value":707},"doca_dev",{"type":45,"value":709}," that maps to the BlueField the user wants to\noffload to, then creating Worker contexts\n(",{"type":40,"tag":67,"props":711,"children":713},{"className":712},[],[714],{"type":45,"value":715},"doca_urom_worker_*",{"type":45,"value":717},") attached to that Service, and confirming\nthe matching DPU-side UROM Service is reachable before the\nfirst enqueue.",{"type":40,"tag":188,"props":719,"children":720},{},[721,723,728],{"type":45,"value":722},"Enqueueing remote memory operations (puts, gets, atomics,\nactive messages, collective primitives) through the host-side\n",{"type":40,"tag":67,"props":724,"children":726},{"className":725},[],[727],{"type":45,"value":248},{"type":45,"value":729}," API and progressing the DOCA progress engine\nfor completions.",{"type":40,"tag":188,"props":731,"children":732},{},[733,735,740],{"type":45,"value":734},"Reading or setting library properties via the host-side UROM\nAPI and calling ",{"type":40,"tag":67,"props":736,"children":738},{"className":737},[],[739],{"type":45,"value":333},{"type":45,"value":741}," on a\nstarted Service to discover which plugins (and therefore which\noperation types \u002F atomics \u002F collectives, since these are\nplugin-defined) this device + this DOCA install + this DPU-side\nUROM Service version actually supports.",{"type":40,"tag":188,"props":743,"children":744},{},[745],{"type":45,"value":746},"Applying the host-side UROM lifecycle, capability-discovery,\nand error rules to a UCX-based HPC stack (OpenMPI, MPICH,\ncustom UCX consumer) that is already wired to use UROM.\nDesigning the UCX transport integration itself remains\nupstream-stack work.",{"type":40,"tag":188,"props":748,"children":749},{},[750,752,757,759,764,766,771,773,778,780,792,793,798],{"type":45,"value":751},"Debugging a ",{"type":40,"tag":67,"props":753,"children":755},{"className":754},[],[756],{"type":45,"value":485},{"type":45,"value":758}," returned from a ",{"type":40,"tag":67,"props":760,"children":762},{"className":761},[],[763],{"type":45,"value":248},{"type":45,"value":765}," call\n— in particular disambiguating ",{"type":40,"tag":87,"props":767,"children":768},{},[769],{"type":45,"value":770},"DPU-side UROM Service not\nreachable",{"type":45,"value":772}," from ",{"type":40,"tag":87,"props":774,"children":775},{},[776],{"type":45,"value":777},"operation type not supported on this device",{"type":45,"value":779},"\nfrom ",{"type":40,"tag":87,"props":781,"children":782},{},[783,785,790],{"type":45,"value":784},"standard ",{"type":40,"tag":67,"props":786,"children":788},{"className":787},[],[789],{"type":45,"value":707},{"type":45,"value":791}," access denied",{"type":45,"value":772},{"type":40,"tag":87,"props":794,"children":795},{},[796],{"type":45,"value":797},"underlying\nRDMA transport failure",{"type":45,"value":234},{"type":40,"tag":188,"props":800,"children":801},{},[802],{"type":45,"value":803},"Designing or extending non-C bindings (Rust, Go, Python, …)\nthat wrap the UROM C ABI — for the lifecycle,\nservice-deployed-and-running, capability-discovery, and\nerror-taxonomy rules the wrapper must honor.",{"type":40,"tag":48,"props":805,"children":806},{},[807,809,813,815,823,825,835],{"type":45,"value":808},"Do ",{"type":40,"tag":52,"props":810,"children":811},{},[812],{"type":45,"value":595},{"type":45,"value":814}," load this skill for general DOCA orientation, install\nof DOCA itself, deployment \u002F operation of the DOCA UROM Service\non the DPU side (a separate artifact, with its own public guide\nreachable via\n",{"type":40,"tag":75,"props":816,"children":817},{"href":133},[818],{"type":40,"tag":67,"props":819,"children":821},{"className":820},[],[822],{"type":45,"value":140},{"type":45,"value":824},"),\nor non-UROM library questions. For those, use\n",{"type":40,"tag":75,"props":826,"children":828},{"href":827},"..\u002F..\u002Fdoca-public-knowledge-map\u002FSKILL.md",[829],{"type":40,"tag":67,"props":830,"children":832},{"className":831},[],[833],{"type":45,"value":834},"doca-public-knowledge-map",{"type":45,"value":234},{"type":40,"tag":165,"props":837,"children":839},{"id":838},"what-this-skill-provides",[840],{"type":45,"value":841},"What this skill provides",{"type":40,"tag":48,"props":843,"children":844},{},[845,847,852],{"type":45,"value":846},"This is a ",{"type":40,"tag":52,"props":848,"children":849},{},[850],{"type":45,"value":851},"thin loader",{"type":45,"value":853},". The body keeps only the orientation\nneeded to pick the right next file. The substantive\nUROM-specific material lives in two companion files:",{"type":40,"tag":184,"props":855,"children":856},{},[857,904],{"type":40,"tag":188,"props":858,"children":859},{},[860,865,867,873,875,880,882,888,890,895,897,902],{"type":40,"tag":67,"props":861,"children":863},{"className":862},[],[864],{"type":45,"value":96},{"type":45,"value":866}," — what the host-side UROM API can express on\nthis version + this BlueField + this UROM Service version: the\npaired-contract model (host library enqueues; DPU service\nexecutes); the two host-side context types — the\n",{"type":40,"tag":67,"props":868,"children":870},{"className":869},[],[871],{"type":45,"value":872},"doca_urom_service",{"type":45,"value":874}," (one per BlueField, bound to its\n",{"type":40,"tag":67,"props":876,"children":878},{"className":877},[],[879],{"type":45,"value":707},{"type":45,"value":881},") and the ",{"type":40,"tag":67,"props":883,"children":885},{"className":884},[],[886],{"type":45,"value":887},"doca_urom_worker",{"type":45,"value":889}," contexts attached to it;\nthe enqueue-side operation surface (puts, gets, atomics, active\nmessages, collective primitives) delivered as plugin-defined\nWorker Command tasks and named generically because exact\nsymbol shapes are plugin- and install-bound; the\nplugin-discovery surface (",{"type":40,"tag":67,"props":891,"children":893},{"className":892},[],[894],{"type":45,"value":333},{"type":45,"value":896},");\nthe UROM error taxonomy mapped onto the cross-library ",{"type":40,"tag":67,"props":898,"children":900},{"className":899},[],[901],{"type":45,"value":485},{"type":45,"value":903}," set;\nthe observability surface (completion events on the DOCA\nprogress engine, capability snapshots, infrastructure-side\nRDMA counters); and the safety policy that gates env\npreconditions (DOCA UROM Service deployed and running on the\nDPU side; host library and DPU service versions agreeing; an\nRDMA-capable BlueField + DOCA install).",{"type":40,"tag":188,"props":905,"children":906},{},[907,912,914,920,922,928,929,935,936,942,943,949,951,957,959,965],{"type":40,"tag":67,"props":908,"children":910},{"className":909},[],[911],{"type":45,"value":77},{"type":45,"value":913}," — step-by-step workflows for the six in-scope UROM\nverbs: ",{"type":40,"tag":67,"props":915,"children":917},{"className":916},[],[918],{"type":45,"value":919},"configure",{"type":45,"value":921},", ",{"type":40,"tag":67,"props":923,"children":925},{"className":924},[],[926],{"type":45,"value":927},"build",{"type":45,"value":921},{"type":40,"tag":67,"props":930,"children":932},{"className":931},[],[933],{"type":45,"value":934},"modify",{"type":45,"value":921},{"type":40,"tag":67,"props":937,"children":939},{"className":938},[],[940],{"type":45,"value":941},"run",{"type":45,"value":921},{"type":40,"tag":67,"props":944,"children":946},{"className":945},[],[947],{"type":45,"value":948},"test",{"type":45,"value":950},",\n",{"type":40,"tag":67,"props":952,"children":954},{"className":953},[],[955],{"type":45,"value":956},"debug",{"type":45,"value":958},". Plus a ",{"type":40,"tag":67,"props":960,"children":962},{"className":961},[],[963],{"type":45,"value":964},"Deferred task verbs",{"type":45,"value":966}," block that points\nout-of-scope questions at the right next skill.",{"type":40,"tag":48,"props":968,"children":969},{},[970,972,980,982,987,989,998],{"type":45,"value":971},"The skill assumes a host + BlueField pair where DOCA is already\ninstalled at the standard location, the DOCA UROM Service is\nalready deployed and running on the BlueField, the underlying\nRDMA transport between host and BlueField is healthy, and the\nuser already has at least a sketch of the HPC \u002F UCX \u002F MPI stack\nthey want to offload. It does not cover installing DOCA,\ndeploying the UROM Service container on the BlueField, or\nbringing up RDMA \u002F RoCE \u002F IB transport between host and\nBlueField — those paths go through\n",{"type":40,"tag":75,"props":973,"children":974},{"href":114},[975],{"type":40,"tag":67,"props":976,"children":978},{"className":977},[],[979],{"type":45,"value":121},{"type":45,"value":981},", the public ",{"type":40,"tag":87,"props":983,"children":984},{},[985],{"type":45,"value":986},"DOCA\nUROM Service",{"type":45,"value":988}," guide, and ",{"type":40,"tag":75,"props":990,"children":992},{"href":991},"..\u002Fdoca-rdma\u002FSKILL.md",[993],{"type":40,"tag":67,"props":994,"children":996},{"className":995},[],[997],{"type":45,"value":381},{"type":45,"value":999},"\nrespectively.",{"type":40,"tag":165,"props":1001,"children":1003},{"id":1002},"what-this-skill-deliberately-does-not-ship",[1004],{"type":45,"value":1005},"What this skill deliberately does not ship",{"type":40,"tag":48,"props":1007,"children":1008},{},[1009,1011,1016],{"type":45,"value":1010},"This skill is ",{"type":40,"tag":52,"props":1012,"children":1013},{},[1014],{"type":45,"value":1015},"agent guidance",{"type":45,"value":1017},", not a samples or templates\nbundle. To keep the boundary clean, it deliberately does not\ncontain — and pull requests should not add:",{"type":40,"tag":184,"props":1019,"children":1020},{},[1021,1061,1085,1132,1165],{"type":40,"tag":188,"props":1022,"children":1023},{},[1024,1029,1031,1036,1038,1048,1050,1060],{"type":40,"tag":52,"props":1025,"children":1026},{},[1027],{"type":45,"value":1028},"Pre-written DOCA UROM application source code, in any\nlanguage.",{"type":45,"value":1030}," The verified UROM source code is the shipped C\nsamples at ",{"type":40,"tag":67,"props":1032,"children":1034},{"className":1033},[],[1035],{"type":45,"value":650},{"type":45,"value":1037},". The\nagent's job is to route the user to those files and prescribe\na minimum-diff modification on them via the universal\nmodify-a-sample workflow in\n",{"type":40,"tag":75,"props":1039,"children":1041},{"href":1040},"..\u002F..\u002Fdoca-programming-guide\u002FSKILL.md",[1042],{"type":40,"tag":67,"props":1043,"children":1045},{"className":1044},[],[1046],{"type":45,"value":1047},"doca-programming-guide",{"type":45,"value":1049},",\nlayered with the UROM-specific overrides in\n",{"type":40,"tag":75,"props":1051,"children":1053},{"href":1052},"TASKS.md#modify",[1054],{"type":40,"tag":67,"props":1055,"children":1057},{"className":1056},[],[1058],{"type":45,"value":1059},"TASKS.md ## modify",{"type":45,"value":234},{"type":40,"tag":188,"props":1062,"children":1063},{},[1064,1069,1071,1076,1078,1083],{"type":40,"tag":52,"props":1065,"children":1066},{},[1067],{"type":45,"value":1068},"An MPI \u002F UCX algorithm or collective implementation.",{"type":45,"value":1070}," This\nlibrary ",{"type":40,"tag":87,"props":1072,"children":1073},{},[1074],{"type":45,"value":1075},"offloads",{"type":45,"value":1077}," remote memory operations; the algorithm\nselecting which puts \u002F gets \u002F atomics \u002F collectives to issue\nfor a given MPI primitive is the user's HPC stack (OpenMPI,\nMPICH, custom UCX consumer) or the user's domain expertise.\nThe agent must refuse to invent collective algorithms and\nmust route any ",{"type":40,"tag":87,"props":1079,"children":1080},{},[1081],{"type":45,"value":1082},"\"what algorithm should my all-reduce use\"",{"type":45,"value":1084},"\nquestion to the upstream MPI \u002F UCX documentation — that is a\nresearch \u002F stack-design question, not a UROM API question.",{"type":40,"tag":188,"props":1086,"children":1087},{},[1088,1093,1095,1101,1102,1108,1109,1115,1117,1122,1124,1130],{"type":40,"tag":52,"props":1089,"children":1090},{},[1091],{"type":45,"value":1092},"Standalone build manifests",{"type":45,"value":1094}," (",{"type":40,"tag":67,"props":1096,"children":1098},{"className":1097},[],[1099],{"type":45,"value":1100},"meson.build",{"type":45,"value":950},{"type":40,"tag":67,"props":1103,"children":1105},{"className":1104},[],[1106],{"type":45,"value":1107},"CMakeLists.txt",{"type":45,"value":921},{"type":40,"tag":67,"props":1110,"children":1112},{"className":1111},[],[1113],{"type":45,"value":1114},"Cargo.toml",{"type":45,"value":1116},", …) parked inside the skill.\nThe agent constructs the build manifest ",{"type":40,"tag":87,"props":1118,"children":1119},{},[1120],{"type":45,"value":1121},"in the user's\nproject directory",{"type":45,"value":1123}," against the user's installed DOCA, where\n",{"type":40,"tag":67,"props":1125,"children":1127},{"className":1126},[],[1128],{"type":45,"value":1129},"pkg-config --modversion doca-urom",{"type":45,"value":1131}," is the source of truth.",{"type":40,"tag":188,"props":1133,"children":1134},{},[1135,1163],{"type":40,"tag":52,"props":1136,"children":1137},{},[1138,1140,1146,1147,1153,1155,1161],{"type":45,"value":1139},"A ",{"type":40,"tag":67,"props":1141,"children":1143},{"className":1142},[],[1144],{"type":45,"value":1145},"samples\u002F",{"type":45,"value":921},{"type":40,"tag":67,"props":1148,"children":1150},{"className":1149},[],[1151],{"type":45,"value":1152},"bindings\u002F",{"type":45,"value":1154},", or ",{"type":40,"tag":67,"props":1156,"children":1158},{"className":1157},[],[1159],{"type":45,"value":1160},"reference\u002F",{"type":45,"value":1162}," subtree",{"type":45,"value":1164}," of any\nkind. A mock or incomplete artifact in this skill's tree,\neven one labeled \"reference\", is misleading: users will read\nit as buildable.",{"type":40,"tag":188,"props":1166,"children":1167},{},[1168,1173,1175,1180,1182,1190],{"type":40,"tag":52,"props":1169,"children":1170},{},[1171],{"type":45,"value":1172},"The DOCA UROM Service surface.",{"type":45,"value":1174}," That service is a\n",{"type":40,"tag":87,"props":1176,"children":1177},{},[1178],{"type":45,"value":1179},"separate artifact",{"type":45,"value":1181}," with its own public guide; routing for\nits deployment \u002F operation lives in\n",{"type":40,"tag":75,"props":1183,"children":1184},{"href":133},[1185],{"type":40,"tag":67,"props":1186,"children":1188},{"className":1187},[],[1189],{"type":45,"value":140},{"type":45,"value":1191},".\nConflating the library (this skill, host-side enqueue) with\nthe service (DPU-side executor) is the single most common\nUROM first-app design error.",{"type":40,"tag":165,"props":1193,"children":1195},{"id":1194},"loading-order",[1196],{"type":45,"value":1197},"Loading order",{"type":40,"tag":1199,"props":1200,"children":1201},"ol",{},[1202,1215,1228],{"type":40,"tag":188,"props":1203,"children":1204},{},[1205,1207,1213],{"type":45,"value":1206},"Read this ",{"type":40,"tag":67,"props":1208,"children":1210},{"className":1209},[],[1211],{"type":45,"value":1212},"SKILL.md",{"type":45,"value":1214}," first to confirm the user's question is\nin scope (host-side library work; not DPU-side service\ndeployment, and not MPI \u002F UCX algorithm design).",{"type":40,"tag":188,"props":1216,"children":1217},{},[1218],{"type":40,"tag":52,"props":1219,"children":1220},{},[1221,1223,1227],{"type":45,"value":1222},"For the UROM capability matrix, the paired-contract model\n(host library + DPU service), the Service + Worker context\nmodel, the enqueue-side operation surface, the\nplugin-discovery rule, the env-precondition policy, the\nerror taxonomy, the observability surface, and the safety\npolicy, see ",{"type":40,"tag":75,"props":1224,"children":1225},{"href":96},[1226],{"type":45,"value":96},{"type":45,"value":234},{"type":40,"tag":188,"props":1229,"children":1230},{},[1231],{"type":40,"tag":52,"props":1232,"children":1233},{},[1234,1236,1240],{"type":45,"value":1235},"For step-by-step workflows — configure, build, modify,\nrun, test, debug — see ",{"type":40,"tag":75,"props":1237,"children":1238},{"href":77},[1239],{"type":45,"value":77},{"type":45,"value":234},{"type":40,"tag":48,"props":1242,"children":1243},{},[1244,1246,1254,1256,1264,1266,1274],{"type":45,"value":1245},"Both companion files cross-link to each other,\n",{"type":40,"tag":75,"props":1247,"children":1248},{"href":455},[1249],{"type":40,"tag":67,"props":1250,"children":1252},{"className":1251},[],[1253],{"type":45,"value":462},{"type":45,"value":1255}," for the canonical\nDOCA version-handling rules (with the UROM overlay that the\nhost library version and the DPU service version must match),\n",{"type":40,"tag":75,"props":1257,"children":1258},{"href":991},[1259],{"type":40,"tag":67,"props":1260,"children":1262},{"className":1261},[],[1263],{"type":45,"value":381},{"type":45,"value":1265}," for the underlying RDMA\ntransport substrate UROM offloads ride on top of, and\n",{"type":40,"tag":75,"props":1267,"children":1268},{"href":827},[1269],{"type":40,"tag":67,"props":1270,"children":1272},{"className":1271},[],[1273],{"type":45,"value":834},{"type":45,"value":1275},"\nwhenever the right answer is \"look it up in the public DOCA\nUROM library guide, the public DOCA UROM Service guide, or in\nthe on-disk install layout\" rather than \"UROM\nhost-side-specific guidance\".",{"type":40,"tag":165,"props":1277,"children":1279},{"id":1278},"related-skills",[1280],{"type":45,"value":1281},"Related skills",{"type":40,"tag":184,"props":1283,"children":1284},{},[1285,1321,1341,1361,1388,1409,1436],{"type":40,"tag":188,"props":1286,"children":1287},{},[1288,1296,1298,1305,1307,1312,1314,1319],{"type":40,"tag":75,"props":1289,"children":1290},{"href":827},[1291],{"type":40,"tag":67,"props":1292,"children":1294},{"className":1293},[],[1295],{"type":45,"value":834},{"type":45,"value":1297}," —\nthe routing table for every public DOCA documentation source\nand the on-disk layout of an installed DOCA package. The\nDOCA UROM library public guide is at\n",{"type":40,"tag":75,"props":1299,"children":1303},{"href":1300,"rel":1301},"https:\u002F\u002Fdocs.nvidia.com\u002Fdoca\u002Fsdk\u002FDOCA-UROM\u002Findex.html",[1302],"nofollow",[1304],{"type":45,"value":1300},{"type":45,"value":1306},"; the\nDOCA UROM Service is a ",{"type":40,"tag":87,"props":1308,"children":1309},{},[1310],{"type":45,"value":1311},"different artifact",{"type":45,"value":1313}," documented\nseparately under the ",{"type":40,"tag":87,"props":1315,"children":1316},{},[1317],{"type":45,"value":1318},"DOCA services",{"type":45,"value":1320}," section of that map.",{"type":40,"tag":188,"props":1322,"children":1323},{},[1324,1332,1334,1339],{"type":40,"tag":75,"props":1325,"children":1326},{"href":991},[1327],{"type":40,"tag":67,"props":1328,"children":1330},{"className":1329},[],[1331],{"type":45,"value":381},{"type":45,"value":1333}," — the underlying RDMA\ntransport substrate the BlueField uses to actually move\nbytes between nodes once UROM has offloaded a remote memory\noperation. UROM does NOT replace RDMA; it adds the\nDPU-offload contract on top so the host CPU does not have to\npost the verbs itself. When the user's intent is simple\npoint-to-point RDMA and the host CPU is not the bottleneck,\nthe right tool is ",{"type":40,"tag":67,"props":1335,"children":1337},{"className":1336},[],[1338],{"type":45,"value":381},{"type":45,"value":1340}," directly — UROM adds the\nservice-side contract that isn't worth its overhead for that\ncase.",{"type":40,"tag":188,"props":1342,"children":1343},{},[1344,1352,1354,1359],{"type":40,"tag":75,"props":1345,"children":1346},{"href":114},[1347],{"type":40,"tag":67,"props":1348,"children":1350},{"className":1349},[],[1351],{"type":45,"value":121},{"type":45,"value":1353}," — env preparation,\ninstall verification, BlueField setup, and the ",{"type":40,"tag":87,"props":1355,"children":1356},{},[1357],{"type":45,"value":1358},"I have no\ninstall yet",{"type":45,"value":1360}," path with the public NGC DOCA container. This\nskill assumes its preconditions are satisfied AND that the\nDPU-side UROM Service is deployed and running on the\nBlueField.",{"type":40,"tag":188,"props":1362,"children":1363},{},[1364,1372,1374,1380,1382,1387],{"type":40,"tag":75,"props":1365,"children":1366},{"href":455},[1367],{"type":40,"tag":67,"props":1368,"children":1370},{"className":1369},[],[1371],{"type":45,"value":462},{"type":45,"value":1373}," — canonical\nDOCA version-handling rules. This skill's ",{"type":40,"tag":67,"props":1375,"children":1377},{"className":1376},[],[1378],{"type":45,"value":1379},"## Version compatibility",{"type":45,"value":1381}," cross-links the four-way match rule and adds\nthe UROM-specific ",{"type":40,"tag":87,"props":1383,"children":1384},{},[1385],{"type":45,"value":1386},"host library and DPU service must agree on\nversion",{"type":45,"value":471},{"type":40,"tag":188,"props":1389,"children":1390},{},[1391,1401,1403,1407],{"type":40,"tag":75,"props":1392,"children":1394},{"href":1393},"..\u002F..\u002Fdoca-structured-tools-contract\u002FSKILL.md",[1395],{"type":40,"tag":67,"props":1396,"children":1398},{"className":1397},[],[1399],{"type":45,"value":1400},"doca-structured-tools-contract",{"type":45,"value":1402}," —\nthe bundle's structured-tools precedence rule (detect \u002F\nprefer \u002F fall back \u002F report). The Command appendix in\n",{"type":40,"tag":75,"props":1404,"children":1405},{"href":77},[1406],{"type":45,"value":77},{"type":45,"value":1408}," honors this contract.",{"type":40,"tag":188,"props":1410,"children":1411},{},[1412,1420,1422,1427,1429,1434],{"type":40,"tag":75,"props":1413,"children":1414},{"href":1040},[1415],{"type":40,"tag":67,"props":1416,"children":1418},{"className":1417},[],[1419],{"type":45,"value":1047},{"type":45,"value":1421}," —\ngeneral DOCA programming patterns shared by every library:\nthe canonical ",{"type":40,"tag":67,"props":1423,"children":1425},{"className":1424},[],[1426],{"type":45,"value":635},{"type":45,"value":1428}," + meson build pattern, the\nuniversal modify-a-shipped-sample first-app workflow, the\nuniversal Core-context lifecycle, the cross-library\n",{"type":40,"tag":67,"props":1430,"children":1432},{"className":1431},[],[1433],{"type":45,"value":485},{"type":45,"value":1435}," taxonomy, and the program-side debug order.\nThis skill layers UROM specifics on top.",{"type":40,"tag":188,"props":1437,"children":1438},{},[1439,1447],{"type":40,"tag":75,"props":1440,"children":1441},{"href":557},[1442],{"type":40,"tag":67,"props":1443,"children":1445},{"className":1444},[],[1446],{"type":45,"value":564},{"type":45,"value":1448}," — the cross-cutting\ndebug ladder (install \u002F version \u002F build \u002F link \u002F runtime \u002F\nprogram \u002F driver). UROM-specific debug (DPU-side UROM\nService not running \u002F not reachable, host library + DPU\nservice version skew, RDMA transport failure underneath the\nUROM offload, operation type not in this device + firmware +\nservice version) overlays on top of that ladder.",{"type":40,"tag":48,"props":1450,"children":1451},{},[1452,1454,1458,1460,1465,1467,1475],{"type":45,"value":1453},"The ",{"type":40,"tag":52,"props":1455,"children":1456},{},[1457],{"type":45,"value":147},{"type":45,"value":1459}," that runs on the DPU side is\ndeliberately ",{"type":40,"tag":52,"props":1461,"children":1462},{},[1463],{"type":45,"value":1464},"not in scope",{"type":45,"value":1466}," for this skill — it is a separate\nartifact with its own public guide, reachable through\n",{"type":40,"tag":75,"props":1468,"children":1469},{"href":133},[1470],{"type":40,"tag":67,"props":1471,"children":1473},{"className":1472},[],[1474],{"type":45,"value":140},{"type":45,"value":1476},".\nConflating the library and the service is the single most\ncommon UROM first-app design error: the agent must surface the\nlibrary \u002F service split explicitly whenever the question\nstraddles the two.",{"items":1478,"total":1580},[1479,1494,1508,1522,1534,1551,1566],{"slug":1480,"name":1480,"fn":1481,"description":1482,"org":1483,"tags":1484,"stars":20,"repoUrl":21,"updatedAt":1493},"accelerated-computing-cudf","accelerate data processing with cuDF","Official NVIDIA-authored guidance for NVIDIA cuDF GPU DataFrames, pandas acceleration, dask-cuDF, ETL, joins, groupby, CSV\u002FParquet I\u002FO, nullable semantics, and multi-GPU DataFrame workloads.",{"slug":8,"name":9,"logoUrl":10,"githubOrg":9},[1485,1488,1491,1492],{"name":1486,"slug":1487,"type":15},"Data Analysis","data-analysis",{"name":1489,"slug":1490,"type":15},"Data Engineering","data-engineering",{"name":9,"slug":8,"type":15},{"name":13,"slug":14,"type":15},"2026-07-14T05:28:43.176466",{"slug":1495,"name":1495,"fn":1496,"description":1497,"org":1498,"tags":1499,"stars":20,"repoUrl":21,"updatedAt":1507},"aiq-deploy","deploy and manage NVIDIA AI-Q infrastructure","Use when asked to install, deploy, run, validate, troubleshoot, or stop NVIDIA AI-Q Blueprint infrastructure.\n",{"slug":8,"name":9,"logoUrl":10,"githubOrg":9},[1500,1503,1506],{"name":1501,"slug":1502,"type":15},"Deployment","deployment",{"name":1504,"slug":1505,"type":15},"Infrastructure","infrastructure",{"name":9,"slug":8,"type":15},"2026-07-14T05:29:06.667109",{"slug":1509,"name":1509,"fn":1510,"description":1511,"org":1512,"tags":1513,"stars":20,"repoUrl":21,"updatedAt":1521},"aiq-research","conduct deep research with AI-Q","Use when asked to run deep research or AI-Q research through a reachable NVIDIA AI-Q Blueprint backend.\n",{"slug":8,"name":9,"logoUrl":10,"githubOrg":9},[1514,1517,1518],{"name":1515,"slug":1516,"type":15},"Agents","agents",{"name":9,"slug":8,"type":15},{"name":1519,"slug":1520,"type":15},"Research","research","2026-07-14T05:28:06.816956",{"slug":1523,"name":1523,"fn":1524,"description":1525,"org":1526,"tags":1527,"stars":20,"repoUrl":21,"updatedAt":1533},"amc-run-sample-calibration","run AMC sample dataset calibration","Run end-to-end calibration on the shipped sample dataset (sdg_08_2_sample_data_010926.zip) against a running AMC microservice. Use when user says 'test sample dataset', 'run sample calibration', 'verify AMC install', or 'launch and test'.",{"slug":8,"name":9,"logoUrl":10,"githubOrg":9},[1528,1529,1530],{"name":1486,"slug":1487,"type":15},{"name":9,"slug":8,"type":15},{"name":1531,"slug":1532,"type":15},"Testing","testing","2026-07-17T05:29:03.913266",{"slug":1535,"name":1535,"fn":1536,"description":1537,"org":1538,"tags":1539,"stars":20,"repoUrl":21,"updatedAt":1550},"amc-run-video-calibration","calibrate video datasets with AutoMagicCalib","Calibrate a new dataset from pre-recorded video files via the AutoMagicCalib REST API. Use when user has local MP4s and says 'calibrate my videos', 'run AMC on these videos', or similar. For RTSP\u002Flive streams, use amc-run-rtsp-calibration instead.",{"slug":8,"name":9,"logoUrl":10,"githubOrg":9},[1540,1543,1546,1547],{"name":1541,"slug":1542,"type":15},"Automation","automation",{"name":1544,"slug":1545,"type":15},"Imaging","imaging",{"name":9,"slug":8,"type":15},{"name":1548,"slug":1549,"type":15},"Video","video","2026-07-17T05:28:53.905004",{"slug":1552,"name":1552,"fn":1553,"description":1554,"org":1555,"tags":1556,"stars":20,"repoUrl":21,"updatedAt":1565},"amc-setup-calibration-stack","deploy AutoMagicCalib microservice with Docker","Launch AutoMagicCalib microservice and web UI from NGC release images via Docker Compose. Use when user says 'deploy auto calibration', 'launch auto calibration', 'launch AMC', 'start MS+UI', or 'set up auto-magic-calib'. Requires NGC API key.",{"slug":8,"name":9,"logoUrl":10,"githubOrg":9},[1557,1558,1561,1562],{"name":1501,"slug":1502,"type":15},{"name":1559,"slug":1560,"type":15},"Docker","docker",{"name":9,"slug":8,"type":15},{"name":1563,"slug":1564,"type":15},"Operations","operations","2026-07-17T05:28:56.913999",{"slug":1567,"name":1567,"fn":1568,"description":1569,"org":1570,"tags":1571,"stars":20,"repoUrl":21,"updatedAt":1579},"cudaq-guide","develop quantum applications with CUDA-Q","CUDA-Q onboarding guide for installation, test programs, GPU simulation, QPU hardware, and quantum applications.",{"slug":8,"name":9,"logoUrl":10,"githubOrg":9},[1572,1573,1576],{"name":9,"slug":8,"type":15},{"name":1574,"slug":1575,"type":15},"Quantum Computing","quantum-computing",{"name":1577,"slug":1578,"type":15},"Simulation","simulation","2026-07-14T05:26:58.898253",305,{"items":1582,"total":1733},[1583,1601,1617,1628,1640,1654,1667,1681,1692,1701,1715,1724],{"slug":1584,"name":1584,"fn":1585,"description":1586,"org":1587,"tags":1588,"stars":1598,"repoUrl":1599,"updatedAt":1600},"nemoclaw-user-guide","retrieve NemoClaw documentation and configuration","Guides human users' AI agents to the NemoClaw docs MCP server and canonical Fern documentation in Markdown form. Use when users ask how to install, configure, operate, troubleshoot, secure, or learn NemoClaw with an AI coding assistant. Trigger keywords - nemoclaw docs, use nemoclaw with ai agent, nemoclaw mcp docs, nemoclaw install help, nemoclaw quickstart, nemoclaw markdown docs, llms.txt, agent skills.",{"slug":8,"name":9,"logoUrl":10,"githubOrg":9},[1589,1592,1595],{"name":1590,"slug":1591,"type":15},"Documentation","documentation",{"name":1593,"slug":1594,"type":15},"MCP","mcp",{"name":1596,"slug":1597,"type":15},"Search","search",21777,"https:\u002F\u002Fgithub.com\u002FNVIDIA\u002FNemoClaw","2026-07-20T06:00:01.461044",{"slug":1602,"name":1602,"fn":1603,"description":1604,"org":1605,"tags":1606,"stars":1614,"repoUrl":1615,"updatedAt":1616},"mcore-build-and-dependency","manage Megatron-LM development environments","Container-based dev environment setup and dependency management for Megatron-LM. Covers acquiring and launching the CI container, uv package management, and updating uv.lock.",{"slug":8,"name":9,"logoUrl":10,"githubOrg":9},[1607,1610,1611],{"name":1608,"slug":1609,"type":15},"Containers","containers",{"name":1501,"slug":1502,"type":15},{"name":1612,"slug":1613,"type":15},"Python","python",17049,"https:\u002F\u002Fgithub.com\u002FNVIDIA\u002FMegatron-LM","2026-07-27T06:06:11.249662",{"slug":1618,"name":1618,"fn":1619,"description":1620,"org":1621,"tags":1622,"stars":1614,"repoUrl":1615,"updatedAt":1627},"mcore-bump-base-image","update NVIDIA PyTorch base images","Bump the NVIDIA PyTorch base image (`nvcr.io\u002Fnvidia\u002Fpytorch:YY.MM-py3`) used by Megatron-LM CI. Covers the two pin sites (GitHub CI in `docker\u002F.ngc_version.dev` and GitLab CI in `.gitlab\u002Fstages\u002F01.build.yml`), the post-bump CI loop (re-run functional tests, refresh golden values, mark broken tests), and the gotchas that bit PRs",{"slug":8,"name":9,"logoUrl":10,"githubOrg":9},[1623,1626],{"name":1624,"slug":1625,"type":15},"CI\u002FCD","ci-cd",{"name":1501,"slug":1502,"type":15},"2026-07-14T05:25:59.97109",{"slug":1629,"name":1629,"fn":1630,"description":1631,"org":1632,"tags":1633,"stars":1614,"repoUrl":1615,"updatedAt":1639},"mcore-cicd","manage CI\u002FCD pipelines for Megatron-LM","CI\u002FCD reference for Megatron-LM. Covers CI pipeline structure, PR scope labels, triggering internal GitLab CI (which force-pushes the current branch to a pull-request\u002FBRANCH ref — always dry-run and verify the destination first; never run against shared or protected branches), and CI failure investigation.",{"slug":8,"name":9,"logoUrl":10,"githubOrg":9},[1634,1635,1636],{"name":1624,"slug":1625,"type":15},{"name":1501,"slug":1502,"type":15},{"name":1637,"slug":1638,"type":15},"GitHub","github","2026-07-27T06:06:12.278222",{"slug":1641,"name":1641,"fn":1642,"description":1643,"org":1644,"tags":1645,"stars":1614,"repoUrl":1615,"updatedAt":1653},"mcore-create-issue","investigate CI failures and create issues","Investigate a failing GitHub Actions run or job and create a GitHub issue for the failure.",{"slug":8,"name":9,"logoUrl":10,"githubOrg":9},[1646,1649,1650],{"name":1647,"slug":1648,"type":15},"Debugging","debugging",{"name":1637,"slug":1638,"type":15},{"name":1651,"slug":1652,"type":15},"Triage","triage","2026-07-14T05:25:57.442089",{"slug":1655,"name":1655,"fn":1656,"description":1657,"org":1658,"tags":1659,"stars":1614,"repoUrl":1615,"updatedAt":1666},"mcore-linting-and-formatting","lint and format Megatron-LM code","Linting and formatting for Megatron-LM. Covers running autoformat.sh, tools (ruff, black, isort, pylint, mypy), and code style rules.",{"slug":8,"name":9,"logoUrl":10,"githubOrg":9},[1660,1663],{"name":1661,"slug":1662,"type":15},"Best Practices","best-practices",{"name":1664,"slug":1665,"type":15},"Code Analysis","code-analysis","2026-07-14T05:25:56.18433",{"slug":1668,"name":1668,"fn":1669,"description":1670,"org":1671,"tags":1672,"stars":1614,"repoUrl":1615,"updatedAt":1680},"mcore-migrate-gpt-to-hybrid","migrate Megatron-LM models to HybridModel","Migration guide for moving Megatron Core GPTModel checkpoints, model providers, training commands, and layer mappings to HybridModel.",{"slug":8,"name":9,"logoUrl":10,"githubOrg":9},[1673,1676,1679],{"name":1674,"slug":1675,"type":15},"Machine Learning","machine-learning",{"name":1677,"slug":1678,"type":15},"Migration","migration",{"name":9,"slug":8,"type":15},"2026-07-17T06:07:11.777011",{"slug":1682,"name":1682,"fn":1683,"description":1684,"org":1685,"tags":1686,"stars":1614,"repoUrl":1615,"updatedAt":1691},"mcore-onboard-gb200-1node-tests","onboard functional tests for GB200","Onboard 1-node GitHub MR functional tests for GB200 from existing mr-scoped 2-node tests.",{"slug":8,"name":9,"logoUrl":10,"githubOrg":9},[1687,1690],{"name":1688,"slug":1689,"type":15},"QA","qa",{"name":1531,"slug":1532,"type":15},"2026-07-14T05:25:53.673039",{"slug":1693,"name":1693,"fn":1694,"description":1695,"org":1696,"tags":1697,"stars":1614,"repoUrl":1615,"updatedAt":1700},"mcore-run-on-slurm","launch distributed training jobs on SLURM","How to launch distributed Megatron-LM training jobs on a SLURM cluster. Covers a minimal sbatch skeleton, environment-variable setup for torch.distributed.run, CUDA_DEVICE_MAX_CONNECTIONS rules across hardware and parallelism modes, container conventions, monitoring, and per-rank failure diagnosis.",{"slug":8,"name":9,"logoUrl":10,"githubOrg":9},[1698,1699],{"name":1501,"slug":1502,"type":15},{"name":1504,"slug":1505,"type":15},"2026-07-14T05:25:49.362534",{"slug":1702,"name":1702,"fn":1703,"description":1704,"org":1705,"tags":1706,"stars":1614,"repoUrl":1615,"updatedAt":1714},"mcore-split-pr","split pull requests to reduce review load","Split a PR into multiple PRs to reduce the number of required CODEOWNERS reviewer groups.",{"slug":8,"name":9,"logoUrl":10,"githubOrg":9},[1707,1710,1711],{"name":1708,"slug":1709,"type":15},"Code Review","code-review",{"name":1637,"slug":1638,"type":15},{"name":1712,"slug":1713,"type":15},"Pull Requests","pull-requests","2026-07-14T05:26:01.226578",{"slug":1716,"name":1716,"fn":1717,"description":1718,"org":1719,"tags":1720,"stars":1614,"repoUrl":1615,"updatedAt":1723},"mcore-testing","run and manage Megatron-LM tests","Test system for Megatron-LM. Covers test layout, recipe YAML structure, adding and running unit and functional tests, golden values, marker filters, and CI parity.",{"slug":8,"name":9,"logoUrl":10,"githubOrg":9},[1721,1722],{"name":1688,"slug":1689,"type":15},{"name":1531,"slug":1532,"type":15},"2026-07-14T05:25:54.928983",{"slug":1725,"name":1725,"fn":1726,"description":1727,"org":1728,"tags":1729,"stars":1614,"repoUrl":1615,"updatedAt":1732},"nightly-sync","manage nightly main-to-dev sync workflows","Domain knowledge for the nightly main-to-dev sync workflow. Covers merge strategy, CI architecture, failure investigation, and known issues.",{"slug":8,"name":9,"logoUrl":10,"githubOrg":9},[1730,1731],{"name":1541,"slug":1542,"type":15},{"name":1624,"slug":1625,"type":15},"2026-07-30T05:29:03.275638",496]