[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill-nvidia-doca-urom-svc":3,"mdc-fijzws-key":34,"related-repo-nvidia-doca-urom-svc":1444,"related-org-nvidia-doca-urom-svc":1550},{"slug":4,"name":4,"fn":5,"description":6,"org":7,"tags":11,"stars":23,"repoUrl":24,"updatedAt":25,"license":26,"forks":27,"topics":28,"repo":29,"sourceUrl":32,"mdContent":33},"doca-urom-svc","configure DOCA UROM service access control","Operate the DOCA UROM Service container on BlueField Arm for remote memory operations (puts, gets, atomics, collectives) enqueued by a paired host using `doca-urom`: pull the NGC image, choose the UCX component, size queues, configure Comch pairing, and align host and service versions. SECURITY: the service has no standalone access control; Comch pairing and RDMA permissions are the boundary. Pair only intended hosts, expose least-privilege memory regions, and verify both views before start. Trigger for slow UCX collectives, unexpected NOT_PERMITTED, or missing completions. Do not use for host application code, MPI\u002FUCX integration design, or DOCA install.\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,20],{"name":13,"slug":14,"type":15},"Security","security","tag",{"name":9,"slug":8,"type":15},{"name":18,"slug":19,"type":15},"Engineering","engineering",{"name":21,"slug":22,"type":15},"Access Control","access-control",2473,"https:\u002F\u002Fgithub.com\u002FNVIDIA\u002Fskills","2026-07-30T05:28:28.408177","Apache-2.0",281,[],{"repoUrl":24,"stars":23,"forks":27,"topics":30,"description":31},[],"AI agent skills published by NVIDIA","https:\u002F\u002Fgithub.com\u002FNVIDIA\u002Fskills\u002Ftree\u002FHEAD\u002Fskills\u002Fdoca-urom-svc","---\nlicense: Apache-2.0\nname: doca-urom-svc\ndescription: >\n  Operate the DOCA UROM Service container on BlueField Arm for remote\n  memory operations (puts, gets, atomics, collectives) enqueued by a\n  paired host using `doca-urom`: pull the NGC image, choose the UCX\n  component, size queues, configure Comch pairing, and align host and\n  service versions. SECURITY: the service has no standalone access\n  control; Comch pairing and RDMA permissions are the boundary. Pair\n  only intended hosts, expose least-privilege memory regions, and\n  verify both views before start. Trigger for slow UCX collectives,\n  unexpected NOT_PERMITTED, or missing completions. Do not use for\n  host application code, MPI\u002FUCX integration design, or DOCA install.\nmetadata:\n  kind: service\ncompatibility: >\n  BlueField-Arm-only DOCA service container; pulled from NVIDIA\n  NGC and started under the BlueField OS container runtime.\n  Host-side install is irrelevant — the host's relationship to\n  this service is via the paired `doca-urom` library over a\n  `doca-rdma` substrate.\n---\n\n# DOCA UROM Service\n\n**Where to start:** This skill is for *operating the DOCA UROM\nService container* on the BlueField Arm side. It is *not* for\n*linking against* a library, and it is *not* the host-side\nenqueue surface. If the user wants to *deploy* or *run* the\nservice container, open [`TASKS.md`](TASKS.md) and start at\n[`## configure`](TASKS.md#configure). If the question is *what\nshape of service is DOCA UROM Service, what does it execute, and\nhow does it pair with the host-side library*, start at\n[`CAPABILITIES.md`](CAPABILITIES.md). If DOCA is not installed\non the BlueField yet, route to\n[`doca-setup`](..\u002F..\u002Fdoca-setup\u002FSKILL.md) first. If the user's\nreal question is about *writing host-side code that enqueues\nremote memory operations through the paired API*, the right\nskill is [`doca-urom`](..\u002F..\u002Flibs\u002Fdoca-urom\u002FSKILL.md) — the\nhost-side library; this service is the DPU-side executor that\nlibrary offloads to.\n\n## Example questions this skill answers well\n\nThe CLASSES of DOCA UROM Service questions this skill is built\nto answer, each with one worked example. The class is the\nload-bearing piece; the worked example is one instance.\n\n- **\"Is DOCA UROM Service the right thing to deploy on my\n  BlueField, or do I just need the host library?\"** — worked\n  example: *\"my MPI cluster's host nodes link against\n  `doca-urom`; what runs on the BlueField side and why must it\n  also be there?\"*. Answered by the publisher \u002F executor\n  paired-contract model in\n  [`CAPABILITIES.md ## Capabilities and modes`](CAPABILITIES.md#capabilities-and-modes)\n  + the deploy-this-when path-selection rule in\n  [`CAPABILITIES.md ## Safety policy`](CAPABILITIES.md#safety-policy)\n  + the env-prep checklist in\n  [`TASKS.md ## configure`](TASKS.md#configure).\n- **\"Which library \u002F service version pair am I supposed to\n  run together?\"** — worked example: *\"the host fleet upgraded\n  to a newer `doca-urom`; do I have to upgrade the service\n  containers on every BlueField, or is the pairing flexible?\"*.\n  Answered by the version-contract overlay in\n  [`CAPABILITIES.md ## Version compatibility`](CAPABILITIES.md#version-compatibility)\n  + the paired-version step in\n  [`TASKS.md ## configure`](TASKS.md#configure) +\n  [`doca-version`](..\u002F..\u002Fdoca-version\u002FSKILL.md) as the canonical\n  body.\n- **\"What does the service configure — UCX components,\n  collectives, queue depths, how the host pairs over Comch?\"** — worked\n  example: *\"my upstream stack wants to offload all-reduce\n  collectives; how do I tell the service to expose that\n  collective family and how does the host pair to it over DOCA\n  Comch?\"*. Answered by the configuration-axes table in\n  [`CAPABILITIES.md ## Capabilities and modes`](CAPABILITIES.md#capabilities-and-modes)\n  + the config-authoring step in\n  [`TASKS.md ## configure`](TASKS.md#configure).\n- **\"Host's `doca-urom` calls fail with `NOT_PERMITTED` even\n  though `doca_dev` access is fine — is this the service?\"** —\n  worked example: *\"first enqueue from host returns\n  `DOCA_ERROR_NOT_PERMITTED` after a clean `doca_ctx_start()`\"*.\n  Answered by the Comch-pairing \u002F RDMA-permissions layer in\n  [`CAPABILITIES.md ## Error taxonomy`](CAPABILITIES.md#error-taxonomy)\n  + the layered ladder in\n  [`TASKS.md ## debug`](TASKS.md#debug), which surfaces *\"is\n  the DOCA Comch endpoint pair correctly established and is the\n  underlying RDMA permission stack happy\"* BEFORE blaming a\n  service-side authz layer (no such layer exists in the shipped\n  binary — `NOT_PERMITTED` here is a Comch \u002F RDMA signal, not a\n  UROM-service authz signal).\n- **\"Operations enqueue but never complete — service or\n  substrate?\"** — worked example: *\"host enqueue succeeds, the\n  progress engine never sees the completion, what layer is\n  hung\"*. Answered by the service-vs-substrate split in\n  [`CAPABILITIES.md ## Error taxonomy`](CAPABILITIES.md#error-taxonomy)\n  + the layered ladder in\n  [`TASKS.md ## debug`](TASKS.md#debug), which separates\n  *service queue full \u002F handler stuck* from *underlying RDMA\n  transport down* before recommending a fix on either side.\n- **\"Performance with offload is worse than the host-CPU\n  baseline — is the service the bottleneck?\"** — worked\n  example: *\"we deployed the service, the workload runs, but\n  collectives are slower than when the host CPU posted them\n  itself\"*. Answered by the offload-isn't-free rule in\n  [`CAPABILITIES.md ## Safety policy`](CAPABILITIES.md#safety-policy)\n  + the smoke-before-scale step in\n  [`TASKS.md ## test`](TASKS.md#test), which surfaces *the\n  workload's pattern may not actually benefit from DPU offload*\n  as a legitimate diagnosis, not a service bug.\n\n## Audience\n\nThis skill serves **external operators and platform teams who\ndeploy and operate the DOCA UROM Service container** on\nBlueField to receive and execute the remote memory operations\nHPC \u002F UCX \u002F MPI workloads on the host enqueue through\n`doca-urom`. Concretely: people running the service container\non BlueField Arm, choosing which UCX components and collectives\nit exposes, sizing the enqueue queue depth, wiring the DOCA\nComch endpoint pairing between host `doca-urom` and the\nservice container (the shipped binary has NO standalone\nservice-side \"host-endpoint authorization list\" — access is\ngoverned by Comch pairing + the underlying RDMA permissions),\nand validating the host-library + DPU-service paired contract\nend-to-end before scaling a real HPC workload on top.\n\nIt is **not** for NVIDIA developers contributing to the DOCA\nUROM Service itself, and it is **not** a programming guide for\n*building applications on top of* DOCA libraries (that is\n[`doca-programming-guide`](..\u002F..\u002Fdoca-programming-guide\u002FSKILL.md)\nplus the matching `libs\u002F\u003Clibrary>` skill). DOCA UROM Service is\na **service**, not a library: the operator deploys a container\non the BlueField and configures it via the documented config\nsurface; they do not link `lib\u003Curomservice>.so` to write their\nown program. The paired host-side library\n[`doca-urom`](..\u002F..\u002Flibs\u002Fdoca-urom\u002FSKILL.md) is a separate\nskill with its own scope and its own audience (HPC application\ndevelopers, not service operators); the agent must refuse to\ncollapse the library and the service into one another.\n\n**Path selection up front.** Deploy this service when the HPC\ncluster's host nodes use the `doca-urom` library and want host\nCPU freed for compute by offloading collective communication\nto the BlueField, when the team is building a custom HPC stack\non top of `doca-urom`, or when an upstream MPI \u002F UCX stack has\nbeen wired to use UROM as a transport. Do **not** deploy this\nservice when the hosts are not using `doca-urom`, when the HPC\nstack is neither MPI nor UCX (this service won't help — it\nexecutes UROM-shaped offloads, not arbitrary networking), or\nwhen the BlueField hardware is too constrained for the\nintended offload (a cap-query at deploy time surfaces this\nupfront, not after the service is running). Deploying the\nservice speculatively into an environment whose host workloads\nwill not actually offload through `doca-urom` adds operational\ncomplexity without any agent-visible benefit.\n\n## When to load this skill\n\nLoad this skill when the user is doing **hands-on DOCA UROM\nService deployment work** on a BlueField where DOCA is already\ninstalled. Concretely:\n\n- Deciding *whether* DOCA UROM Service is the right answer for\n  the user's HPC environment (vs. keeping the host CPU on the\n  communication path with raw `doca-rdma` or with no DPU\n  offload at all).\n- Deploying the service container on BlueField Arm — pulling\n  the image per the public DOCA UROM Service Guide, setting the\n  daemon's CLI flags \u002F env (`SERVICE_ARGS`, `UROM_PLUGIN_PATH`)\n  and mounting the `plugins\u002F` directory, starting \u002F stopping\n  the container under the BlueField container runtime per the\n  public Container Deployment Guide.\n- Choosing the service's configuration axes — which UCX\n  components \u002F collectives the service exposes (cap-bound to\n  what the BlueField generation supports), enqueue queue\n  depths for the offload path, and how the host's `doca-urom`\n  library pairs to the service over DOCA Comch (access is\n  governed by that Comch pairing + the underlying RDMA\n  permissions — there is no service-side authorization list).\n  Pair only explicitly intended hosts and keep RDMA exports\n  and permissions to the minimum the workload requires;\n  pre-start verification through the documented Comch and\n  RDMA read-only surfaces is mandatory.\n- Confirming the host-library + DPU-service version pair is\n  one the DOCA Compatibility Policy supports — a mismatch is\n  the canonical subtle-failure mode for the paired contract.\n- Reading the service container's logs, the service's\n  observability surface, and the underlying RDMA substrate\n  counters to confirm the service is actually executing the\n  operations the host enqueued.\n- Debugging a deployment where the container is healthy but\n  the host's `doca-urom` enqueues fail or never complete, or\n  where the offload's performance is worse than the host-CPU\n  baseline.\n\nDo **not** load this skill for general DOCA orientation,\ninstall of DOCA itself, host-side `doca-urom` library API\nquestions, or non-UROM HPC stack topics. For those, route via\n[`doca-public-knowledge-map`](..\u002F..\u002Fdoca-public-knowledge-map\u002FSKILL.md),\n[`doca-setup`](..\u002F..\u002Fdoca-setup\u002FSKILL.md), or the matching\nhost-side library skill\n[`doca-urom`](..\u002F..\u002Flibs\u002Fdoca-urom\u002FSKILL.md).\n\n## What this skill provides\n\nThis is a **thin loader**. Substantive material lives in two\ncompanion files:\n\n- `CAPABILITIES.md` — the service's architecture (long-running\n  container on BlueField Arm that executes UROM offloads from\n  paired hosts), the publisher \u002F executor paired-contract\n  model and its load-bearing version-coupling rule, the\n  configuration axes (UCX-component \u002F collective surface,\n  enqueue queue sizing, DOCA Comch endpoint pairing), the deployment\n  shape (container on BlueField Arm per the public Container\n  Deployment Guide), the pairing surface (host `doca-urom`\n  library + underlying `doca-rdma` transport substrate), the\n  observability surface (container state + service logs + RDMA\n  counters), the error taxonomy (container-runtime vs\n  service-side-resource vs\n  transport-substrate vs paired-version-mismatch), and the\n  safety policy (path-selection rule, version-contract rule,\n  smoke-before-scale).\n- `TASKS.md` — step-by-step workflows for the in-scope service\n  verbs: `configure`, `build`, `modify`, `run`, `test`,\n  `debug`, plus a `Deferred task verbs` block routing\n  out-of-scope questions and a `Command appendix` of recurring\n  commands.\n\nThe skill assumes a BlueField where DOCA is already installed\nand the operator has the privileges the public DOCA UROM\nService Guide expects to pull, run, and configure containers\non BlueField Arm. It does not cover installing DOCA — that path\ngoes through [`doca-setup`](..\u002F..\u002Fdoca-setup\u002FSKILL.md). It does\nnot cover the host-side `doca-urom` library API — that is\n[`doca-urom`](..\u002F..\u002Flibs\u002Fdoca-urom\u002FSKILL.md).\n\n## What this skill deliberately does not ship\n\nThis skill is **agent guidance**, not a templates or\nsample-config bundle. To keep the boundary clean, it\ndeliberately does not contain — and pull requests should not\nadd:\n\n- **Pre-baked DOCA UROM Service flag \u002F env bundles**\n  (full UCX-component \u002F collective exposure manifests,\n  ready-to-run queue-depth `SERVICE_ARGS` strings) intended\n  to be copy-pasted into\n  production. Service configuration is deployment-specific\n  (per the BlueField\n  generation's capability cap, per the workload's collective\n  pattern); the safe answer for an external operator is to\n  derive the daemon's flags \u002F env from the public DOCA UROM\n  Service Guide against their own deployment. The agent's job is to\n  prescribe the *procedure* and the *configuration-axes\n  decision*, not to ship a config the user might run\n  unmodified.\n- **Container image names, tags, or registry paths.** The\n  authoritative image source is the public DOCA UROM Service\n  Guide reachable through\n  [`doca-public-knowledge-map ## DOCA services`](..\u002F..\u002Fdoca-public-knowledge-map\u002FSKILL.md#doca-services);\n  the service's image tag is version-bound and changes\n  between DOCA releases AND must match the host-side library\n  version per the paired-contract rule. Inventing or\n  memorizing a tag is the canonical hallucination failure\n  mode for a service skill, and for this service in\n  particular it can silently produce a host-library \u002F service\n  version mismatch.\n- **Host-side `doca-urom` application source code, build\n  manifests, or MPI \u002F UCX integration glue.** Those live on\n  the host and belong to\n  [`doca-urom`](..\u002F..\u002Flibs\u002Fdoca-urom\u002FSKILL.md) (host library\n  API) or to upstream MPI \u002F UCX documentation (stack-side\n  integration). This skill names *that* the host side must\n  be wired through `doca-urom` and *that* the version must\n  pair with the service; the host-side bodies are out of\n  scope.\n- **A `samples\u002F`, `templates\u002F`, or `reference\u002F` subtree** of\n  any kind. A mock or incomplete artifact in this skill's\n  tree, even one labeled *\"reference\"*, is misleading:\n  operators will read it as production-ready, and for a\n  paired-contract service that risk is amplified because\n  *\"production-ready\"* implicitly claims a host-library\n  version pairing that the skill cannot guarantee for the\n  reader.\n\n## Loading order\n\n1. Read this `SKILL.md` first to confirm the user's question\n   is in scope **and** that the DOCA UROM Service is the\n   right answer at all (vs. routing entirely to the host-side\n   library skill, or away from UROM if the workload doesn't\n   actually benefit from offload).\n2. **For the service's deployment shape, the publisher \u002F\n   executor paired-contract model, the configuration axes,\n   the host-library + RDMA-substrate pairing surface, the\n   error taxonomy, the observability surface, the\n   version-coupling rule, and the path-selection 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\n## Related skills\n\n- [`doca-urom`](..\u002F..\u002Flibs\u002Fdoca-urom\u002FSKILL.md) — the paired\n  host-side library. Hosts link `doca-urom` to ENQUEUE remote\n  memory operations; this service EXECUTES them. The two\n  skills load together for any HPC offload deployment and they\n  do NOT collapse into one another: the library never executes\n  on its own; this service is never enqueued through by\n  itself. Mismatches between the library and the service are\n  the dominant subtle-failure mode for the paired contract.\n- [`doca-rdma`](..\u002F..\u002Flibs\u002Fdoca-rdma\u002FSKILL.md) — the underlying\n  RDMA transport substrate this service uses to actually move\n  bytes once a host enqueue lands on the DPU. The service does\n  NOT replace RDMA; it sits on top of it. A failing RDMA fabric\n  surfaces at the service as *operations enqueued but never\n  complete* and at the host as `DOCA_ERROR_IO_FAILED`; the fix\n  is on the substrate side, not in this service's config.\n- [`doca-public-knowledge-map`](..\u002F..\u002Fdoca-public-knowledge-map\u002FSKILL.md)\n  — the routing table to the public DOCA UROM Service Guide\n  and the rest of the public DOCA documentation set. The\n  service URL is listed under\n  [`## DOCA services`](..\u002F..\u002Fdoca-public-knowledge-map\u002FSKILL.md#doca-services).\n- [`doca-setup`](..\u002F..\u002Fdoca-setup\u002FSKILL.md) — env preparation\n  and install verification on the BlueField where the service\n  container will run, including the *I have no install yet*\n  path via the public NGC DOCA container. This skill assumes\n  its preconditions are satisfied on BlueField Arm.\n- [`doca-version`](..\u002F..\u002Fdoca-version\u002FSKILL.md) — canonical\n  DOCA version-handling rules. This service's container tag is\n  version-bound AND its host-library pairing is version-bound;\n  this skill's `## Version compatibility` cross-links the\n  four-way match rule and adds the host-library + DPU-service\n  paired-version overlay that is load-bearing for UROM.\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 patterns. The DOCA UROM Service is\n  service-shaped not library-shaped, so the build \u002F modify \u002F\n  first-app pattern there does not apply directly, but the\n  cross-library debug discipline (env-before-program,\n  layer-before-config) remains useful when the service\n  reports an error that originated in the container runtime\n  or in a DOCA library it called.\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). Service-specific debug (container not\n  running, host-library \u002F service version mismatch,\n  transport substrate down, offload\n  not actually helping) overlays on top of that ladder.\n- [`doca-dms`](..\u002Fdoca-dms\u002FSKILL.md) and\n  [`doca-firefly`](..\u002Fdoca-firefly\u002FSKILL.md) — sibling service\n  skills. The agent reading these skills should see the same\n  service-skill shape (container on BlueField Arm, public\n  Container Deployment Guide as the canonical recipe, env\n  preconditions checked first, configured via the documented\n  per-service surface — for UROM that is the daemon's CLI flags\n  \u002F env, not a mounted config file — smoke-before-scale)\n  layered on top of a different\n  per-service problem domain (DMS = device management via\n  gNMI \u002F gNOI; Firefly = time synchronization via PTP;\n  UROM Service = HPC remote memory operation execution via\n  the paired `doca-urom` library).\n",{"data":35,"body":39},{"license":26,"name":4,"description":6,"metadata":36,"compatibility":38},{"kind":37},"service","BlueField-Arm-only DOCA service container; pulled from NVIDIA NGC and started under the BlueField OS container runtime. Host-side install is irrelevant — the host's relationship to this service is via the paired `doca-urom` library over a `doca-rdma` substrate.\n",{"type":40,"children":41},"root",[42,51,179,186,191,574,580,606,674,718,724,736,822,871,877,889,984,1015,1021,1033,1183,1189,1239,1245],{"type":43,"tag":44,"props":45,"children":47},"element","h1",{"id":46},"doca-urom-service",[48],{"type":49,"value":50},"text","DOCA UROM Service",{"type":43,"tag":52,"props":53,"children":54},"p",{},[55,61,63,69,71,76,78,83,85,89,91,96,98,103,105,116,118,128,130,135,137,146,148,158,160,165,167,177],{"type":43,"tag":56,"props":57,"children":58},"strong",{},[59],{"type":49,"value":60},"Where to start:",{"type":49,"value":62}," This skill is for ",{"type":43,"tag":64,"props":65,"children":66},"em",{},[67],{"type":49,"value":68},"operating the DOCA UROM\nService container",{"type":49,"value":70}," on the BlueField Arm side. It is ",{"type":43,"tag":64,"props":72,"children":73},{},[74],{"type":49,"value":75},"not",{"type":49,"value":77}," for\n",{"type":43,"tag":64,"props":79,"children":80},{},[81],{"type":49,"value":82},"linking against",{"type":49,"value":84}," a library, and it is ",{"type":43,"tag":64,"props":86,"children":87},{},[88],{"type":49,"value":75},{"type":49,"value":90}," the host-side\nenqueue surface. If the user wants to ",{"type":43,"tag":64,"props":92,"children":93},{},[94],{"type":49,"value":95},"deploy",{"type":49,"value":97}," or ",{"type":43,"tag":64,"props":99,"children":100},{},[101],{"type":49,"value":102},"run",{"type":49,"value":104}," the\nservice container, open ",{"type":43,"tag":106,"props":107,"children":109},"a",{"href":108},"TASKS.md",[110],{"type":43,"tag":111,"props":112,"children":114},"code",{"className":113},[],[115],{"type":49,"value":108},{"type":49,"value":117}," and start at\n",{"type":43,"tag":106,"props":119,"children":121},{"href":120},"TASKS.md#configure",[122],{"type":43,"tag":111,"props":123,"children":125},{"className":124},[],[126],{"type":49,"value":127},"## configure",{"type":49,"value":129},". If the question is ",{"type":43,"tag":64,"props":131,"children":132},{},[133],{"type":49,"value":134},"what\nshape of service is DOCA UROM Service, what does it execute, and\nhow does it pair with the host-side library",{"type":49,"value":136},", start at\n",{"type":43,"tag":106,"props":138,"children":140},{"href":139},"CAPABILITIES.md",[141],{"type":43,"tag":111,"props":142,"children":144},{"className":143},[],[145],{"type":49,"value":139},{"type":49,"value":147},". If DOCA is not installed\non the BlueField yet, route to\n",{"type":43,"tag":106,"props":149,"children":151},{"href":150},"..\u002F..\u002Fdoca-setup\u002FSKILL.md",[152],{"type":43,"tag":111,"props":153,"children":155},{"className":154},[],[156],{"type":49,"value":157},"doca-setup",{"type":49,"value":159}," first. If the user's\nreal question is about ",{"type":43,"tag":64,"props":161,"children":162},{},[163],{"type":49,"value":164},"writing host-side code that enqueues\nremote memory operations through the paired API",{"type":49,"value":166},", the right\nskill is ",{"type":43,"tag":106,"props":168,"children":170},{"href":169},"..\u002F..\u002Flibs\u002Fdoca-urom\u002FSKILL.md",[171],{"type":43,"tag":111,"props":172,"children":174},{"className":173},[],[175],{"type":49,"value":176},"doca-urom",{"type":49,"value":178}," — the\nhost-side library; this service is the DPU-side executor that\nlibrary offloads to.",{"type":43,"tag":180,"props":181,"children":183},"h2",{"id":182},"example-questions-this-skill-answers-well",[184],{"type":49,"value":185},"Example questions this skill answers well",{"type":43,"tag":52,"props":187,"children":188},{},[189],{"type":49,"value":190},"The CLASSES of DOCA UROM Service questions this skill is built\nto answer, each with one worked example. The class is the\nload-bearing piece; the worked example is one instance.",{"type":43,"tag":192,"props":193,"children":194},"ul",{},[195,264,328,369,469,524],{"type":43,"tag":196,"props":197,"children":198},"li",{},[199,204,206,218,220,230],{"type":43,"tag":56,"props":200,"children":201},{},[202],{"type":49,"value":203},"\"Is DOCA UROM Service the right thing to deploy on my\nBlueField, or do I just need the host library?\"",{"type":49,"value":205}," — worked\nexample: ",{"type":43,"tag":64,"props":207,"children":208},{},[209,211,216],{"type":49,"value":210},"\"my MPI cluster's host nodes link against\n",{"type":43,"tag":111,"props":212,"children":214},{"className":213},[],[215],{"type":49,"value":176},{"type":49,"value":217},"; what runs on the BlueField side and why must it\nalso be there?\"",{"type":49,"value":219},". Answered by the publisher \u002F executor\npaired-contract model in\n",{"type":43,"tag":106,"props":221,"children":223},{"href":222},"CAPABILITIES.md#capabilities-and-modes",[224],{"type":43,"tag":111,"props":225,"children":227},{"className":226},[],[228],{"type":49,"value":229},"CAPABILITIES.md ## Capabilities and modes",{"type":43,"tag":192,"props":231,"children":232},{},[233,248],{"type":43,"tag":196,"props":234,"children":235},{},[236,238],{"type":49,"value":237},"the deploy-this-when path-selection rule in\n",{"type":43,"tag":106,"props":239,"children":241},{"href":240},"CAPABILITIES.md#safety-policy",[242],{"type":43,"tag":111,"props":243,"children":245},{"className":244},[],[246],{"type":49,"value":247},"CAPABILITIES.md ## Safety policy",{"type":43,"tag":196,"props":249,"children":250},{},[251,253,262],{"type":49,"value":252},"the env-prep checklist in\n",{"type":43,"tag":106,"props":254,"children":255},{"href":120},[256],{"type":43,"tag":111,"props":257,"children":259},{"className":258},[],[260],{"type":49,"value":261},"TASKS.md ## configure",{"type":49,"value":263},".",{"type":43,"tag":196,"props":265,"children":266},{},[267,272,274,286,288,298],{"type":43,"tag":56,"props":268,"children":269},{},[270],{"type":49,"value":271},"\"Which library \u002F service version pair am I supposed to\nrun together?\"",{"type":49,"value":273}," — worked example: ",{"type":43,"tag":64,"props":275,"children":276},{},[277,279,284],{"type":49,"value":278},"\"the host fleet upgraded\nto a newer ",{"type":43,"tag":111,"props":280,"children":282},{"className":281},[],[283],{"type":49,"value":176},{"type":49,"value":285},"; do I have to upgrade the service\ncontainers on every BlueField, or is the pairing flexible?\"",{"type":49,"value":287},".\nAnswered by the version-contract overlay in\n",{"type":43,"tag":106,"props":289,"children":291},{"href":290},"CAPABILITIES.md#version-compatibility",[292],{"type":43,"tag":111,"props":293,"children":295},{"className":294},[],[296],{"type":49,"value":297},"CAPABILITIES.md ## Version compatibility",{"type":43,"tag":192,"props":299,"children":300},{},[301],{"type":43,"tag":196,"props":302,"children":303},{},[304,306,314,316,326],{"type":49,"value":305},"the paired-version step in\n",{"type":43,"tag":106,"props":307,"children":308},{"href":120},[309],{"type":43,"tag":111,"props":310,"children":312},{"className":311},[],[313],{"type":49,"value":261},{"type":49,"value":315}," +\n",{"type":43,"tag":106,"props":317,"children":319},{"href":318},"..\u002F..\u002Fdoca-version\u002FSKILL.md",[320],{"type":43,"tag":111,"props":321,"children":323},{"className":322},[],[324],{"type":49,"value":325},"doca-version",{"type":49,"value":327}," as the canonical\nbody.",{"type":43,"tag":196,"props":329,"children":330},{},[331,336,337,342,344,352],{"type":43,"tag":56,"props":332,"children":333},{},[334],{"type":49,"value":335},"\"What does the service configure — UCX components,\ncollectives, queue depths, how the host pairs over Comch?\"",{"type":49,"value":205},{"type":43,"tag":64,"props":338,"children":339},{},[340],{"type":49,"value":341},"\"my upstream stack wants to offload all-reduce\ncollectives; how do I tell the service to expose that\ncollective family and how does the host pair to it over DOCA\nComch?\"",{"type":49,"value":343},". Answered by the configuration-axes table in\n",{"type":43,"tag":106,"props":345,"children":346},{"href":222},[347],{"type":43,"tag":111,"props":348,"children":350},{"className":349},[],[351],{"type":49,"value":229},{"type":43,"tag":192,"props":353,"children":354},{},[355],{"type":43,"tag":196,"props":356,"children":357},{},[358,360,368],{"type":49,"value":359},"the config-authoring step in\n",{"type":43,"tag":106,"props":361,"children":362},{"href":120},[363],{"type":43,"tag":111,"props":364,"children":366},{"className":365},[],[367],{"type":49,"value":261},{"type":49,"value":263},{"type":43,"tag":196,"props":370,"children":371},{},[372,400,402,423,425,435],{"type":43,"tag":56,"props":373,"children":374},{},[375,377,382,384,390,392,398],{"type":49,"value":376},"\"Host's ",{"type":43,"tag":111,"props":378,"children":380},{"className":379},[],[381],{"type":49,"value":176},{"type":49,"value":383}," calls fail with ",{"type":43,"tag":111,"props":385,"children":387},{"className":386},[],[388],{"type":49,"value":389},"NOT_PERMITTED",{"type":49,"value":391}," even\nthough ",{"type":43,"tag":111,"props":393,"children":395},{"className":394},[],[396],{"type":49,"value":397},"doca_dev",{"type":49,"value":399}," access is fine — is this the service?\"",{"type":49,"value":401}," —\nworked example: ",{"type":43,"tag":64,"props":403,"children":404},{},[405,407,413,415,421],{"type":49,"value":406},"\"first enqueue from host returns\n",{"type":43,"tag":111,"props":408,"children":410},{"className":409},[],[411],{"type":49,"value":412},"DOCA_ERROR_NOT_PERMITTED",{"type":49,"value":414}," after a clean ",{"type":43,"tag":111,"props":416,"children":418},{"className":417},[],[419],{"type":49,"value":420},"doca_ctx_start()",{"type":49,"value":422},"\"",{"type":49,"value":424},".\nAnswered by the Comch-pairing \u002F RDMA-permissions layer in\n",{"type":43,"tag":106,"props":426,"children":428},{"href":427},"CAPABILITIES.md#error-taxonomy",[429],{"type":43,"tag":111,"props":430,"children":432},{"className":431},[],[433],{"type":49,"value":434},"CAPABILITIES.md ## Error taxonomy",{"type":43,"tag":192,"props":436,"children":437},{},[438],{"type":43,"tag":196,"props":439,"children":440},{},[441,443,453,455,460,462,467],{"type":49,"value":442},"the layered ladder in\n",{"type":43,"tag":106,"props":444,"children":446},{"href":445},"TASKS.md#debug",[447],{"type":43,"tag":111,"props":448,"children":450},{"className":449},[],[451],{"type":49,"value":452},"TASKS.md ## debug",{"type":49,"value":454},", which surfaces ",{"type":43,"tag":64,"props":456,"children":457},{},[458],{"type":49,"value":459},"\"is\nthe DOCA Comch endpoint pair correctly established and is the\nunderlying RDMA permission stack happy\"",{"type":49,"value":461}," BEFORE blaming a\nservice-side authz layer (no such layer exists in the shipped\nbinary — ",{"type":43,"tag":111,"props":463,"children":465},{"className":464},[],[466],{"type":49,"value":389},{"type":49,"value":468}," here is a Comch \u002F RDMA signal, not a\nUROM-service authz signal).",{"type":43,"tag":196,"props":470,"children":471},{},[472,477,478,483,485,493],{"type":43,"tag":56,"props":473,"children":474},{},[475],{"type":49,"value":476},"\"Operations enqueue but never complete — service or\nsubstrate?\"",{"type":49,"value":273},{"type":43,"tag":64,"props":479,"children":480},{},[481],{"type":49,"value":482},"\"host enqueue succeeds, the\nprogress engine never sees the completion, what layer is\nhung\"",{"type":49,"value":484},". Answered by the service-vs-substrate split in\n",{"type":43,"tag":106,"props":486,"children":487},{"href":427},[488],{"type":43,"tag":111,"props":489,"children":491},{"className":490},[],[492],{"type":49,"value":434},{"type":43,"tag":192,"props":494,"children":495},{},[496],{"type":43,"tag":196,"props":497,"children":498},{},[499,500,508,510,515,517,522],{"type":49,"value":442},{"type":43,"tag":106,"props":501,"children":502},{"href":445},[503],{"type":43,"tag":111,"props":504,"children":506},{"className":505},[],[507],{"type":49,"value":452},{"type":49,"value":509},", which separates\n",{"type":43,"tag":64,"props":511,"children":512},{},[513],{"type":49,"value":514},"service queue full \u002F handler stuck",{"type":49,"value":516}," from ",{"type":43,"tag":64,"props":518,"children":519},{},[520],{"type":49,"value":521},"underlying RDMA\ntransport down",{"type":49,"value":523}," before recommending a fix on either side.",{"type":43,"tag":196,"props":525,"children":526},{},[527,532,533,538,540,548],{"type":43,"tag":56,"props":528,"children":529},{},[530],{"type":49,"value":531},"\"Performance with offload is worse than the host-CPU\nbaseline — is the service the bottleneck?\"",{"type":49,"value":205},{"type":43,"tag":64,"props":534,"children":535},{},[536],{"type":49,"value":537},"\"we deployed the service, the workload runs, but\ncollectives are slower than when the host CPU posted them\nitself\"",{"type":49,"value":539},". Answered by the offload-isn't-free rule in\n",{"type":43,"tag":106,"props":541,"children":542},{"href":240},[543],{"type":43,"tag":111,"props":544,"children":546},{"className":545},[],[547],{"type":49,"value":247},{"type":43,"tag":192,"props":549,"children":550},{},[551],{"type":43,"tag":196,"props":552,"children":553},{},[554,556,566,567,572],{"type":49,"value":555},"the smoke-before-scale step in\n",{"type":43,"tag":106,"props":557,"children":559},{"href":558},"TASKS.md#test",[560],{"type":43,"tag":111,"props":561,"children":563},{"className":562},[],[564],{"type":49,"value":565},"TASKS.md ## test",{"type":49,"value":454},{"type":43,"tag":64,"props":568,"children":569},{},[570],{"type":49,"value":571},"the\nworkload's pattern may not actually benefit from DPU offload",{"type":49,"value":573},"\nas a legitimate diagnosis, not a service bug.",{"type":43,"tag":180,"props":575,"children":577},{"id":576},"audience",[578],{"type":49,"value":579},"Audience",{"type":43,"tag":52,"props":581,"children":582},{},[583,585,590,592,597,599,604],{"type":49,"value":584},"This skill serves ",{"type":43,"tag":56,"props":586,"children":587},{},[588],{"type":49,"value":589},"external operators and platform teams who\ndeploy and operate the DOCA UROM Service container",{"type":49,"value":591}," on\nBlueField to receive and execute the remote memory operations\nHPC \u002F UCX \u002F MPI workloads on the host enqueue through\n",{"type":43,"tag":111,"props":593,"children":595},{"className":594},[],[596],{"type":49,"value":176},{"type":49,"value":598},". Concretely: people running the service container\non BlueField Arm, choosing which UCX components and collectives\nit exposes, sizing the enqueue queue depth, wiring the DOCA\nComch endpoint pairing between host ",{"type":43,"tag":111,"props":600,"children":602},{"className":601},[],[603],{"type":49,"value":176},{"type":49,"value":605}," and the\nservice container (the shipped binary has NO standalone\nservice-side \"host-endpoint authorization list\" — access is\ngoverned by Comch pairing + the underlying RDMA permissions),\nand validating the host-library + DPU-service paired contract\nend-to-end before scaling a real HPC workload on top.",{"type":43,"tag":52,"props":607,"children":608},{},[609,611,615,617,621,623,628,630,640,642,648,650,654,656,662,664,672],{"type":49,"value":610},"It is ",{"type":43,"tag":56,"props":612,"children":613},{},[614],{"type":49,"value":75},{"type":49,"value":616}," for NVIDIA developers contributing to the DOCA\nUROM Service itself, and it is ",{"type":43,"tag":56,"props":618,"children":619},{},[620],{"type":49,"value":75},{"type":49,"value":622}," a programming guide for\n",{"type":43,"tag":64,"props":624,"children":625},{},[626],{"type":49,"value":627},"building applications on top of",{"type":49,"value":629}," DOCA libraries (that is\n",{"type":43,"tag":106,"props":631,"children":633},{"href":632},"..\u002F..\u002Fdoca-programming-guide\u002FSKILL.md",[634],{"type":43,"tag":111,"props":635,"children":637},{"className":636},[],[638],{"type":49,"value":639},"doca-programming-guide",{"type":49,"value":641},"\nplus the matching ",{"type":43,"tag":111,"props":643,"children":645},{"className":644},[],[646],{"type":49,"value":647},"libs\u002F\u003Clibrary>",{"type":49,"value":649}," skill). DOCA UROM Service is\na ",{"type":43,"tag":56,"props":651,"children":652},{},[653],{"type":49,"value":37},{"type":49,"value":655},", not a library: the operator deploys a container\non the BlueField and configures it via the documented config\nsurface; they do not link ",{"type":43,"tag":111,"props":657,"children":659},{"className":658},[],[660],{"type":49,"value":661},"lib\u003Curomservice>.so",{"type":49,"value":663}," to write their\nown program. The paired host-side library\n",{"type":43,"tag":106,"props":665,"children":666},{"href":169},[667],{"type":43,"tag":111,"props":668,"children":670},{"className":669},[],[671],{"type":49,"value":176},{"type":49,"value":673}," is a separate\nskill with its own scope and its own audience (HPC application\ndevelopers, not service operators); the agent must refuse to\ncollapse the library and the service into one another.",{"type":43,"tag":52,"props":675,"children":676},{},[677,682,684,689,691,696,698,702,704,709,711,716],{"type":43,"tag":56,"props":678,"children":679},{},[680],{"type":49,"value":681},"Path selection up front.",{"type":49,"value":683}," Deploy this service when the HPC\ncluster's host nodes use the ",{"type":43,"tag":111,"props":685,"children":687},{"className":686},[],[688],{"type":49,"value":176},{"type":49,"value":690}," library and want host\nCPU freed for compute by offloading collective communication\nto the BlueField, when the team is building a custom HPC stack\non top of ",{"type":43,"tag":111,"props":692,"children":694},{"className":693},[],[695],{"type":49,"value":176},{"type":49,"value":697},", or when an upstream MPI \u002F UCX stack has\nbeen wired to use UROM as a transport. Do ",{"type":43,"tag":56,"props":699,"children":700},{},[701],{"type":49,"value":75},{"type":49,"value":703}," deploy this\nservice when the hosts are not using ",{"type":43,"tag":111,"props":705,"children":707},{"className":706},[],[708],{"type":49,"value":176},{"type":49,"value":710},", when the HPC\nstack is neither MPI nor UCX (this service won't help — it\nexecutes UROM-shaped offloads, not arbitrary networking), or\nwhen the BlueField hardware is too constrained for the\nintended offload (a cap-query at deploy time surfaces this\nupfront, not after the service is running). Deploying the\nservice speculatively into an environment whose host workloads\nwill not actually offload through ",{"type":43,"tag":111,"props":712,"children":714},{"className":713},[],[715],{"type":49,"value":176},{"type":49,"value":717}," adds operational\ncomplexity without any agent-visible benefit.",{"type":43,"tag":180,"props":719,"children":721},{"id":720},"when-to-load-this-skill",[722],{"type":49,"value":723},"When to load this skill",{"type":43,"tag":52,"props":725,"children":726},{},[727,729,734],{"type":49,"value":728},"Load this skill when the user is doing ",{"type":43,"tag":56,"props":730,"children":731},{},[732],{"type":49,"value":733},"hands-on DOCA UROM\nService deployment work",{"type":49,"value":735}," on a BlueField where DOCA is already\ninstalled. Concretely:",{"type":43,"tag":192,"props":737,"children":738},{},[739,759,788,800,805,810],{"type":43,"tag":196,"props":740,"children":741},{},[742,744,749,751,757],{"type":49,"value":743},"Deciding ",{"type":43,"tag":64,"props":745,"children":746},{},[747],{"type":49,"value":748},"whether",{"type":49,"value":750}," DOCA UROM Service is the right answer for\nthe user's HPC environment (vs. keeping the host CPU on the\ncommunication path with raw ",{"type":43,"tag":111,"props":752,"children":754},{"className":753},[],[755],{"type":49,"value":756},"doca-rdma",{"type":49,"value":758}," or with no DPU\noffload at all).",{"type":43,"tag":196,"props":760,"children":761},{},[762,764,770,772,778,780,786],{"type":49,"value":763},"Deploying the service container on BlueField Arm — pulling\nthe image per the public DOCA UROM Service Guide, setting the\ndaemon's CLI flags \u002F env (",{"type":43,"tag":111,"props":765,"children":767},{"className":766},[],[768],{"type":49,"value":769},"SERVICE_ARGS",{"type":49,"value":771},", ",{"type":43,"tag":111,"props":773,"children":775},{"className":774},[],[776],{"type":49,"value":777},"UROM_PLUGIN_PATH",{"type":49,"value":779},")\nand mounting the ",{"type":43,"tag":111,"props":781,"children":783},{"className":782},[],[784],{"type":49,"value":785},"plugins\u002F",{"type":49,"value":787}," directory, starting \u002F stopping\nthe container under the BlueField container runtime per the\npublic Container Deployment Guide.",{"type":43,"tag":196,"props":789,"children":790},{},[791,793,798],{"type":49,"value":792},"Choosing the service's configuration axes — which UCX\ncomponents \u002F collectives the service exposes (cap-bound to\nwhat the BlueField generation supports), enqueue queue\ndepths for the offload path, and how the host's ",{"type":43,"tag":111,"props":794,"children":796},{"className":795},[],[797],{"type":49,"value":176},{"type":49,"value":799},"\nlibrary pairs to the service over DOCA Comch (access is\ngoverned by that Comch pairing + the underlying RDMA\npermissions — there is no service-side authorization list).\nPair only explicitly intended hosts and keep RDMA exports\nand permissions to the minimum the workload requires;\npre-start verification through the documented Comch and\nRDMA read-only surfaces is mandatory.",{"type":43,"tag":196,"props":801,"children":802},{},[803],{"type":49,"value":804},"Confirming the host-library + DPU-service version pair is\none the DOCA Compatibility Policy supports — a mismatch is\nthe canonical subtle-failure mode for the paired contract.",{"type":43,"tag":196,"props":806,"children":807},{},[808],{"type":49,"value":809},"Reading the service container's logs, the service's\nobservability surface, and the underlying RDMA substrate\ncounters to confirm the service is actually executing the\noperations the host enqueued.",{"type":43,"tag":196,"props":811,"children":812},{},[813,815,820],{"type":49,"value":814},"Debugging a deployment where the container is healthy but\nthe host's ",{"type":43,"tag":111,"props":816,"children":818},{"className":817},[],[819],{"type":49,"value":176},{"type":49,"value":821}," enqueues fail or never complete, or\nwhere the offload's performance is worse than the host-CPU\nbaseline.",{"type":43,"tag":52,"props":823,"children":824},{},[825,827,831,833,838,840,850,852,860,862,870],{"type":49,"value":826},"Do ",{"type":43,"tag":56,"props":828,"children":829},{},[830],{"type":49,"value":75},{"type":49,"value":832}," load this skill for general DOCA orientation,\ninstall of DOCA itself, host-side ",{"type":43,"tag":111,"props":834,"children":836},{"className":835},[],[837],{"type":49,"value":176},{"type":49,"value":839}," library API\nquestions, or non-UROM HPC stack topics. For those, route via\n",{"type":43,"tag":106,"props":841,"children":843},{"href":842},"..\u002F..\u002Fdoca-public-knowledge-map\u002FSKILL.md",[844],{"type":43,"tag":111,"props":845,"children":847},{"className":846},[],[848],{"type":49,"value":849},"doca-public-knowledge-map",{"type":49,"value":851},",\n",{"type":43,"tag":106,"props":853,"children":854},{"href":150},[855],{"type":43,"tag":111,"props":856,"children":858},{"className":857},[],[859],{"type":49,"value":157},{"type":49,"value":861},", or the matching\nhost-side library skill\n",{"type":43,"tag":106,"props":863,"children":864},{"href":169},[865],{"type":43,"tag":111,"props":866,"children":868},{"className":867},[],[869],{"type":49,"value":176},{"type":49,"value":263},{"type":43,"tag":180,"props":872,"children":874},{"id":873},"what-this-skill-provides",[875],{"type":49,"value":876},"What this skill provides",{"type":43,"tag":52,"props":878,"children":879},{},[880,882,887],{"type":49,"value":881},"This is a ",{"type":43,"tag":56,"props":883,"children":884},{},[885],{"type":49,"value":886},"thin loader",{"type":49,"value":888},". Substantive material lives in two\ncompanion files:",{"type":43,"tag":192,"props":890,"children":891},{},[892,916],{"type":43,"tag":196,"props":893,"children":894},{},[895,900,902,907,909,914],{"type":43,"tag":111,"props":896,"children":898},{"className":897},[],[899],{"type":49,"value":139},{"type":49,"value":901}," — the service's architecture (long-running\ncontainer on BlueField Arm that executes UROM offloads from\npaired hosts), the publisher \u002F executor paired-contract\nmodel and its load-bearing version-coupling rule, the\nconfiguration axes (UCX-component \u002F collective surface,\nenqueue queue sizing, DOCA Comch endpoint pairing), the deployment\nshape (container on BlueField Arm per the public Container\nDeployment Guide), the pairing surface (host ",{"type":43,"tag":111,"props":903,"children":905},{"className":904},[],[906],{"type":49,"value":176},{"type":49,"value":908},"\nlibrary + underlying ",{"type":43,"tag":111,"props":910,"children":912},{"className":911},[],[913],{"type":49,"value":756},{"type":49,"value":915}," transport substrate), the\nobservability surface (container state + service logs + RDMA\ncounters), the error taxonomy (container-runtime vs\nservice-side-resource vs\ntransport-substrate vs paired-version-mismatch), and the\nsafety policy (path-selection rule, version-contract rule,\nsmoke-before-scale).",{"type":43,"tag":196,"props":917,"children":918},{},[919,924,926,932,933,939,940,946,947,952,953,959,960,966,968,974,976,982],{"type":43,"tag":111,"props":920,"children":922},{"className":921},[],[923],{"type":49,"value":108},{"type":49,"value":925}," — step-by-step workflows for the in-scope service\nverbs: ",{"type":43,"tag":111,"props":927,"children":929},{"className":928},[],[930],{"type":49,"value":931},"configure",{"type":49,"value":771},{"type":43,"tag":111,"props":934,"children":936},{"className":935},[],[937],{"type":49,"value":938},"build",{"type":49,"value":771},{"type":43,"tag":111,"props":941,"children":943},{"className":942},[],[944],{"type":49,"value":945},"modify",{"type":49,"value":771},{"type":43,"tag":111,"props":948,"children":950},{"className":949},[],[951],{"type":49,"value":102},{"type":49,"value":771},{"type":43,"tag":111,"props":954,"children":956},{"className":955},[],[957],{"type":49,"value":958},"test",{"type":49,"value":851},{"type":43,"tag":111,"props":961,"children":963},{"className":962},[],[964],{"type":49,"value":965},"debug",{"type":49,"value":967},", plus a ",{"type":43,"tag":111,"props":969,"children":971},{"className":970},[],[972],{"type":49,"value":973},"Deferred task verbs",{"type":49,"value":975}," block routing\nout-of-scope questions and a ",{"type":43,"tag":111,"props":977,"children":979},{"className":978},[],[980],{"type":49,"value":981},"Command appendix",{"type":49,"value":983}," of recurring\ncommands.",{"type":43,"tag":52,"props":985,"children":986},{},[987,989,997,999,1004,1006,1014],{"type":49,"value":988},"The skill assumes a BlueField where DOCA is already installed\nand the operator has the privileges the public DOCA UROM\nService Guide expects to pull, run, and configure containers\non BlueField Arm. It does not cover installing DOCA — that path\ngoes through ",{"type":43,"tag":106,"props":990,"children":991},{"href":150},[992],{"type":43,"tag":111,"props":993,"children":995},{"className":994},[],[996],{"type":49,"value":157},{"type":49,"value":998},". It does\nnot cover the host-side ",{"type":43,"tag":111,"props":1000,"children":1002},{"className":1001},[],[1003],{"type":49,"value":176},{"type":49,"value":1005}," library API — that is\n",{"type":43,"tag":106,"props":1007,"children":1008},{"href":169},[1009],{"type":43,"tag":111,"props":1010,"children":1012},{"className":1011},[],[1013],{"type":49,"value":176},{"type":49,"value":263},{"type":43,"tag":180,"props":1016,"children":1018},{"id":1017},"what-this-skill-deliberately-does-not-ship",[1019],{"type":49,"value":1020},"What this skill deliberately does not ship",{"type":43,"tag":52,"props":1022,"children":1023},{},[1024,1026,1031],{"type":49,"value":1025},"This skill is ",{"type":43,"tag":56,"props":1027,"children":1028},{},[1029],{"type":49,"value":1030},"agent guidance",{"type":49,"value":1032},", not a templates or\nsample-config bundle. To keep the boundary clean, it\ndeliberately does not contain — and pull requests should not\nadd:",{"type":43,"tag":192,"props":1034,"children":1035},{},[1036,1067,1089,1136],{"type":43,"tag":196,"props":1037,"children":1038},{},[1039,1044,1046,1051,1053,1058,1060,1065],{"type":43,"tag":56,"props":1040,"children":1041},{},[1042],{"type":49,"value":1043},"Pre-baked DOCA UROM Service flag \u002F env bundles",{"type":49,"value":1045},"\n(full UCX-component \u002F collective exposure manifests,\nready-to-run queue-depth ",{"type":43,"tag":111,"props":1047,"children":1049},{"className":1048},[],[1050],{"type":49,"value":769},{"type":49,"value":1052}," strings) intended\nto be copy-pasted into\nproduction. Service configuration is deployment-specific\n(per the BlueField\ngeneration's capability cap, per the workload's collective\npattern); the safe answer for an external operator is to\nderive the daemon's flags \u002F env from the public DOCA UROM\nService Guide against their own deployment. The agent's job is to\nprescribe the ",{"type":43,"tag":64,"props":1054,"children":1055},{},[1056],{"type":49,"value":1057},"procedure",{"type":49,"value":1059}," and the ",{"type":43,"tag":64,"props":1061,"children":1062},{},[1063],{"type":49,"value":1064},"configuration-axes\ndecision",{"type":49,"value":1066},", not to ship a config the user might run\nunmodified.",{"type":43,"tag":196,"props":1068,"children":1069},{},[1070,1075,1077,1087],{"type":43,"tag":56,"props":1071,"children":1072},{},[1073],{"type":49,"value":1074},"Container image names, tags, or registry paths.",{"type":49,"value":1076}," The\nauthoritative image source is the public DOCA UROM Service\nGuide reachable through\n",{"type":43,"tag":106,"props":1078,"children":1080},{"href":1079},"..\u002F..\u002Fdoca-public-knowledge-map\u002FSKILL.md#doca-services",[1081],{"type":43,"tag":111,"props":1082,"children":1084},{"className":1083},[],[1085],{"type":49,"value":1086},"doca-public-knowledge-map ## DOCA services",{"type":49,"value":1088},";\nthe service's image tag is version-bound and changes\nbetween DOCA releases AND must match the host-side library\nversion per the paired-contract rule. Inventing or\nmemorizing a tag is the canonical hallucination failure\nmode for a service skill, and for this service in\nparticular it can silently produce a host-library \u002F service\nversion mismatch.",{"type":43,"tag":196,"props":1090,"children":1091},{},[1092,1104,1106,1114,1116,1121,1123,1128,1130,1134],{"type":43,"tag":56,"props":1093,"children":1094},{},[1095,1097,1102],{"type":49,"value":1096},"Host-side ",{"type":43,"tag":111,"props":1098,"children":1100},{"className":1099},[],[1101],{"type":49,"value":176},{"type":49,"value":1103}," application source code, build\nmanifests, or MPI \u002F UCX integration glue.",{"type":49,"value":1105}," Those live on\nthe host and belong to\n",{"type":43,"tag":106,"props":1107,"children":1108},{"href":169},[1109],{"type":43,"tag":111,"props":1110,"children":1112},{"className":1111},[],[1113],{"type":49,"value":176},{"type":49,"value":1115}," (host library\nAPI) or to upstream MPI \u002F UCX documentation (stack-side\nintegration). This skill names ",{"type":43,"tag":64,"props":1117,"children":1118},{},[1119],{"type":49,"value":1120},"that",{"type":49,"value":1122}," the host side must\nbe wired through ",{"type":43,"tag":111,"props":1124,"children":1126},{"className":1125},[],[1127],{"type":49,"value":176},{"type":49,"value":1129}," and ",{"type":43,"tag":64,"props":1131,"children":1132},{},[1133],{"type":49,"value":1120},{"type":49,"value":1135}," the version must\npair with the service; the host-side bodies are out of\nscope.",{"type":43,"tag":196,"props":1137,"children":1138},{},[1139,1167,1169,1174,1176,1181],{"type":43,"tag":56,"props":1140,"children":1141},{},[1142,1144,1150,1151,1157,1159,1165],{"type":49,"value":1143},"A ",{"type":43,"tag":111,"props":1145,"children":1147},{"className":1146},[],[1148],{"type":49,"value":1149},"samples\u002F",{"type":49,"value":771},{"type":43,"tag":111,"props":1152,"children":1154},{"className":1153},[],[1155],{"type":49,"value":1156},"templates\u002F",{"type":49,"value":1158},", or ",{"type":43,"tag":111,"props":1160,"children":1162},{"className":1161},[],[1163],{"type":49,"value":1164},"reference\u002F",{"type":49,"value":1166}," subtree",{"type":49,"value":1168}," of\nany kind. A mock or incomplete artifact in this skill's\ntree, even one labeled ",{"type":43,"tag":64,"props":1170,"children":1171},{},[1172],{"type":49,"value":1173},"\"reference\"",{"type":49,"value":1175},", is misleading:\noperators will read it as production-ready, and for a\npaired-contract service that risk is amplified because\n",{"type":43,"tag":64,"props":1177,"children":1178},{},[1179],{"type":49,"value":1180},"\"production-ready\"",{"type":49,"value":1182}," implicitly claims a host-library\nversion pairing that the skill cannot guarantee for the\nreader.",{"type":43,"tag":180,"props":1184,"children":1186},{"id":1185},"loading-order",[1187],{"type":49,"value":1188},"Loading order",{"type":43,"tag":1190,"props":1191,"children":1192},"ol",{},[1193,1213,1226],{"type":43,"tag":196,"props":1194,"children":1195},{},[1196,1198,1204,1206,1211],{"type":49,"value":1197},"Read this ",{"type":43,"tag":111,"props":1199,"children":1201},{"className":1200},[],[1202],{"type":49,"value":1203},"SKILL.md",{"type":49,"value":1205}," first to confirm the user's question\nis in scope ",{"type":43,"tag":56,"props":1207,"children":1208},{},[1209],{"type":49,"value":1210},"and",{"type":49,"value":1212}," that the DOCA UROM Service is the\nright answer at all (vs. routing entirely to the host-side\nlibrary skill, or away from UROM if the workload doesn't\nactually benefit from offload).",{"type":43,"tag":196,"props":1214,"children":1215},{},[1216],{"type":43,"tag":56,"props":1217,"children":1218},{},[1219,1221,1225],{"type":49,"value":1220},"For the service's deployment shape, the publisher \u002F\nexecutor paired-contract model, the configuration axes,\nthe host-library + RDMA-substrate pairing surface, the\nerror taxonomy, the observability surface, the\nversion-coupling rule, and the path-selection safety\npolicy, see ",{"type":43,"tag":106,"props":1222,"children":1223},{"href":139},[1224],{"type":49,"value":139},{"type":49,"value":263},{"type":43,"tag":196,"props":1227,"children":1228},{},[1229],{"type":43,"tag":56,"props":1230,"children":1231},{},[1232,1234,1238],{"type":49,"value":1233},"For step-by-step workflows — configure, build, modify,\nrun, test, debug — see ",{"type":43,"tag":106,"props":1235,"children":1236},{"href":108},[1237],{"type":49,"value":108},{"type":49,"value":263},{"type":43,"tag":180,"props":1240,"children":1242},{"id":1241},"related-skills",[1243],{"type":49,"value":1244},"Related skills",{"type":43,"tag":192,"props":1246,"children":1247},{},[1248,1268,1297,1320,1340,1361,1382,1395,1410],{"type":43,"tag":196,"props":1249,"children":1250},{},[1251,1259,1261,1266],{"type":43,"tag":106,"props":1252,"children":1253},{"href":169},[1254],{"type":43,"tag":111,"props":1255,"children":1257},{"className":1256},[],[1258],{"type":49,"value":176},{"type":49,"value":1260}," — the paired\nhost-side library. Hosts link ",{"type":43,"tag":111,"props":1262,"children":1264},{"className":1263},[],[1265],{"type":49,"value":176},{"type":49,"value":1267}," to ENQUEUE remote\nmemory operations; this service EXECUTES them. The two\nskills load together for any HPC offload deployment and they\ndo NOT collapse into one another: the library never executes\non its own; this service is never enqueued through by\nitself. Mismatches between the library and the service are\nthe dominant subtle-failure mode for the paired contract.",{"type":43,"tag":196,"props":1269,"children":1270},{},[1271,1280,1282,1287,1289,1295],{"type":43,"tag":106,"props":1272,"children":1274},{"href":1273},"..\u002F..\u002Flibs\u002Fdoca-rdma\u002FSKILL.md",[1275],{"type":43,"tag":111,"props":1276,"children":1278},{"className":1277},[],[1279],{"type":49,"value":756},{"type":49,"value":1281}," — the underlying\nRDMA transport substrate this service uses to actually move\nbytes once a host enqueue lands on the DPU. The service does\nNOT replace RDMA; it sits on top of it. A failing RDMA fabric\nsurfaces at the service as ",{"type":43,"tag":64,"props":1283,"children":1284},{},[1285],{"type":49,"value":1286},"operations enqueued but never\ncomplete",{"type":49,"value":1288}," and at the host as ",{"type":43,"tag":111,"props":1290,"children":1292},{"className":1291},[],[1293],{"type":49,"value":1294},"DOCA_ERROR_IO_FAILED",{"type":49,"value":1296},"; the fix\nis on the substrate side, not in this service's config.",{"type":43,"tag":196,"props":1298,"children":1299},{},[1300,1308,1310,1319],{"type":43,"tag":106,"props":1301,"children":1302},{"href":842},[1303],{"type":43,"tag":111,"props":1304,"children":1306},{"className":1305},[],[1307],{"type":49,"value":849},{"type":49,"value":1309},"\n— the routing table to the public DOCA UROM Service Guide\nand the rest of the public DOCA documentation set. The\nservice URL is listed under\n",{"type":43,"tag":106,"props":1311,"children":1312},{"href":1079},[1313],{"type":43,"tag":111,"props":1314,"children":1316},{"className":1315},[],[1317],{"type":49,"value":1318},"## DOCA services",{"type":49,"value":263},{"type":43,"tag":196,"props":1321,"children":1322},{},[1323,1331,1333,1338],{"type":43,"tag":106,"props":1324,"children":1325},{"href":150},[1326],{"type":43,"tag":111,"props":1327,"children":1329},{"className":1328},[],[1330],{"type":49,"value":157},{"type":49,"value":1332}," — env preparation\nand install verification on the BlueField where the service\ncontainer will run, including the ",{"type":43,"tag":64,"props":1334,"children":1335},{},[1336],{"type":49,"value":1337},"I have no install yet",{"type":49,"value":1339},"\npath via the public NGC DOCA container. This skill assumes\nits preconditions are satisfied on BlueField Arm.",{"type":43,"tag":196,"props":1341,"children":1342},{},[1343,1351,1353,1359],{"type":43,"tag":106,"props":1344,"children":1345},{"href":318},[1346],{"type":43,"tag":111,"props":1347,"children":1349},{"className":1348},[],[1350],{"type":49,"value":325},{"type":49,"value":1352}," — canonical\nDOCA version-handling rules. This service's container tag is\nversion-bound AND its host-library pairing is version-bound;\nthis skill's ",{"type":43,"tag":111,"props":1354,"children":1356},{"className":1355},[],[1357],{"type":49,"value":1358},"## Version compatibility",{"type":49,"value":1360}," cross-links the\nfour-way match rule and adds the host-library + DPU-service\npaired-version overlay that is load-bearing for UROM.",{"type":43,"tag":196,"props":1362,"children":1363},{},[1364,1374,1376,1380],{"type":43,"tag":106,"props":1365,"children":1367},{"href":1366},"..\u002F..\u002Fdoca-structured-tools-contract\u002FSKILL.md",[1368],{"type":43,"tag":111,"props":1369,"children":1371},{"className":1370},[],[1372],{"type":49,"value":1373},"doca-structured-tools-contract",{"type":49,"value":1375},"\n— the bundle's structured-tools precedence rule (detect \u002F\nprefer \u002F fall back \u002F report). The Command appendix in\n",{"type":43,"tag":106,"props":1377,"children":1378},{"href":108},[1379],{"type":49,"value":108},{"type":49,"value":1381}," honors this contract.",{"type":43,"tag":196,"props":1383,"children":1384},{},[1385,1393],{"type":43,"tag":106,"props":1386,"children":1387},{"href":632},[1388],{"type":43,"tag":111,"props":1389,"children":1391},{"className":1390},[],[1392],{"type":49,"value":639},{"type":49,"value":1394},"\n— general DOCA patterns. The DOCA UROM Service is\nservice-shaped not library-shaped, so the build \u002F modify \u002F\nfirst-app pattern there does not apply directly, but the\ncross-library debug discipline (env-before-program,\nlayer-before-config) remains useful when the service\nreports an error that originated in the container runtime\nor in a DOCA library it called.",{"type":43,"tag":196,"props":1396,"children":1397},{},[1398,1408],{"type":43,"tag":106,"props":1399,"children":1401},{"href":1400},"..\u002F..\u002Fdoca-debug\u002FSKILL.md",[1402],{"type":43,"tag":111,"props":1403,"children":1405},{"className":1404},[],[1406],{"type":49,"value":1407},"doca-debug",{"type":49,"value":1409}," — the cross-cutting\ndebug ladder (install \u002F version \u002F build \u002F link \u002F runtime \u002F\nprogram \u002F driver). Service-specific debug (container not\nrunning, host-library \u002F service version mismatch,\ntransport substrate down, offload\nnot actually helping) overlays on top of that ladder.",{"type":43,"tag":196,"props":1411,"children":1412},{},[1413,1423,1425,1435,1437,1442],{"type":43,"tag":106,"props":1414,"children":1416},{"href":1415},"..\u002Fdoca-dms\u002FSKILL.md",[1417],{"type":43,"tag":111,"props":1418,"children":1420},{"className":1419},[],[1421],{"type":49,"value":1422},"doca-dms",{"type":49,"value":1424}," and\n",{"type":43,"tag":106,"props":1426,"children":1428},{"href":1427},"..\u002Fdoca-firefly\u002FSKILL.md",[1429],{"type":43,"tag":111,"props":1430,"children":1432},{"className":1431},[],[1433],{"type":49,"value":1434},"doca-firefly",{"type":49,"value":1436}," — sibling service\nskills. The agent reading these skills should see the same\nservice-skill shape (container on BlueField Arm, public\nContainer Deployment Guide as the canonical recipe, env\npreconditions checked first, configured via the documented\nper-service surface — for UROM that is the daemon's CLI flags\n\u002F env, not a mounted config file — smoke-before-scale)\nlayered on top of a different\nper-service problem domain (DMS = device management via\ngNMI \u002F gNOI; Firefly = time synchronization via PTP;\nUROM Service = HPC remote memory operation execution via\nthe paired ",{"type":43,"tag":111,"props":1438,"children":1440},{"className":1439},[],[1441],{"type":49,"value":176},{"type":49,"value":1443}," library).",{"items":1445,"total":1549},[1446,1463,1477,1491,1503,1520,1535],{"slug":1447,"name":1447,"fn":1448,"description":1449,"org":1450,"tags":1451,"stars":23,"repoUrl":24,"updatedAt":1462},"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},[1452,1455,1458,1459],{"name":1453,"slug":1454,"type":15},"Data Analysis","data-analysis",{"name":1456,"slug":1457,"type":15},"Data Engineering","data-engineering",{"name":9,"slug":8,"type":15},{"name":1460,"slug":1461,"type":15},"Performance","performance","2026-07-14T05:28:43.176466",{"slug":1464,"name":1464,"fn":1465,"description":1466,"org":1467,"tags":1468,"stars":23,"repoUrl":24,"updatedAt":1476},"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},[1469,1472,1475],{"name":1470,"slug":1471,"type":15},"Deployment","deployment",{"name":1473,"slug":1474,"type":15},"Infrastructure","infrastructure",{"name":9,"slug":8,"type":15},"2026-07-14T05:29:06.667109",{"slug":1478,"name":1478,"fn":1479,"description":1480,"org":1481,"tags":1482,"stars":23,"repoUrl":24,"updatedAt":1490},"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},[1483,1486,1487],{"name":1484,"slug":1485,"type":15},"Agents","agents",{"name":9,"slug":8,"type":15},{"name":1488,"slug":1489,"type":15},"Research","research","2026-07-14T05:28:06.816956",{"slug":1492,"name":1492,"fn":1493,"description":1494,"org":1495,"tags":1496,"stars":23,"repoUrl":24,"updatedAt":1502},"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},[1497,1498,1499],{"name":1453,"slug":1454,"type":15},{"name":9,"slug":8,"type":15},{"name":1500,"slug":1501,"type":15},"Testing","testing","2026-07-17T05:29:03.913266",{"slug":1504,"name":1504,"fn":1505,"description":1506,"org":1507,"tags":1508,"stars":23,"repoUrl":24,"updatedAt":1519},"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},[1509,1512,1515,1516],{"name":1510,"slug":1511,"type":15},"Automation","automation",{"name":1513,"slug":1514,"type":15},"Imaging","imaging",{"name":9,"slug":8,"type":15},{"name":1517,"slug":1518,"type":15},"Video","video","2026-07-17T05:28:53.905004",{"slug":1521,"name":1521,"fn":1522,"description":1523,"org":1524,"tags":1525,"stars":23,"repoUrl":24,"updatedAt":1534},"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},[1526,1527,1530,1531],{"name":1470,"slug":1471,"type":15},{"name":1528,"slug":1529,"type":15},"Docker","docker",{"name":9,"slug":8,"type":15},{"name":1532,"slug":1533,"type":15},"Operations","operations","2026-07-17T05:28:56.913999",{"slug":1536,"name":1536,"fn":1537,"description":1538,"org":1539,"tags":1540,"stars":23,"repoUrl":24,"updatedAt":1548},"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},[1541,1542,1545],{"name":9,"slug":8,"type":15},{"name":1543,"slug":1544,"type":15},"Quantum Computing","quantum-computing",{"name":1546,"slug":1547,"type":15},"Simulation","simulation","2026-07-14T05:26:58.898253",305,{"items":1551,"total":1702},[1552,1570,1586,1597,1609,1623,1636,1650,1661,1670,1684,1693],{"slug":1553,"name":1553,"fn":1554,"description":1555,"org":1556,"tags":1557,"stars":1567,"repoUrl":1568,"updatedAt":1569},"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},[1558,1561,1564],{"name":1559,"slug":1560,"type":15},"Documentation","documentation",{"name":1562,"slug":1563,"type":15},"MCP","mcp",{"name":1565,"slug":1566,"type":15},"Search","search",21777,"https:\u002F\u002Fgithub.com\u002FNVIDIA\u002FNemoClaw","2026-07-20T06:00:01.461044",{"slug":1571,"name":1571,"fn":1572,"description":1573,"org":1574,"tags":1575,"stars":1583,"repoUrl":1584,"updatedAt":1585},"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},[1576,1579,1580],{"name":1577,"slug":1578,"type":15},"Containers","containers",{"name":1470,"slug":1471,"type":15},{"name":1581,"slug":1582,"type":15},"Python","python",17049,"https:\u002F\u002Fgithub.com\u002FNVIDIA\u002FMegatron-LM","2026-07-27T06:06:11.249662",{"slug":1587,"name":1587,"fn":1588,"description":1589,"org":1590,"tags":1591,"stars":1583,"repoUrl":1584,"updatedAt":1596},"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},[1592,1595],{"name":1593,"slug":1594,"type":15},"CI\u002FCD","ci-cd",{"name":1470,"slug":1471,"type":15},"2026-07-14T05:25:59.97109",{"slug":1598,"name":1598,"fn":1599,"description":1600,"org":1601,"tags":1602,"stars":1583,"repoUrl":1584,"updatedAt":1608},"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},[1603,1604,1605],{"name":1593,"slug":1594,"type":15},{"name":1470,"slug":1471,"type":15},{"name":1606,"slug":1607,"type":15},"GitHub","github","2026-07-27T06:06:12.278222",{"slug":1610,"name":1610,"fn":1611,"description":1612,"org":1613,"tags":1614,"stars":1583,"repoUrl":1584,"updatedAt":1622},"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},[1615,1618,1619],{"name":1616,"slug":1617,"type":15},"Debugging","debugging",{"name":1606,"slug":1607,"type":15},{"name":1620,"slug":1621,"type":15},"Triage","triage","2026-07-14T05:25:57.442089",{"slug":1624,"name":1624,"fn":1625,"description":1626,"org":1627,"tags":1628,"stars":1583,"repoUrl":1584,"updatedAt":1635},"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},[1629,1632],{"name":1630,"slug":1631,"type":15},"Best Practices","best-practices",{"name":1633,"slug":1634,"type":15},"Code Analysis","code-analysis","2026-07-14T05:25:56.18433",{"slug":1637,"name":1637,"fn":1638,"description":1639,"org":1640,"tags":1641,"stars":1583,"repoUrl":1584,"updatedAt":1649},"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},[1642,1645,1648],{"name":1643,"slug":1644,"type":15},"Machine Learning","machine-learning",{"name":1646,"slug":1647,"type":15},"Migration","migration",{"name":9,"slug":8,"type":15},"2026-07-17T06:07:11.777011",{"slug":1651,"name":1651,"fn":1652,"description":1653,"org":1654,"tags":1655,"stars":1583,"repoUrl":1584,"updatedAt":1660},"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},[1656,1659],{"name":1657,"slug":1658,"type":15},"QA","qa",{"name":1500,"slug":1501,"type":15},"2026-07-14T05:25:53.673039",{"slug":1662,"name":1662,"fn":1663,"description":1664,"org":1665,"tags":1666,"stars":1583,"repoUrl":1584,"updatedAt":1669},"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},[1667,1668],{"name":1470,"slug":1471,"type":15},{"name":1473,"slug":1474,"type":15},"2026-07-14T05:25:49.362534",{"slug":1671,"name":1671,"fn":1672,"description":1673,"org":1674,"tags":1675,"stars":1583,"repoUrl":1584,"updatedAt":1683},"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},[1676,1679,1680],{"name":1677,"slug":1678,"type":15},"Code Review","code-review",{"name":1606,"slug":1607,"type":15},{"name":1681,"slug":1682,"type":15},"Pull Requests","pull-requests","2026-07-14T05:26:01.226578",{"slug":1685,"name":1685,"fn":1686,"description":1687,"org":1688,"tags":1689,"stars":1583,"repoUrl":1584,"updatedAt":1692},"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},[1690,1691],{"name":1657,"slug":1658,"type":15},{"name":1500,"slug":1501,"type":15},"2026-07-14T05:25:54.928983",{"slug":1694,"name":1694,"fn":1695,"description":1696,"org":1697,"tags":1698,"stars":1583,"repoUrl":1584,"updatedAt":1701},"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},[1699,1700],{"name":1510,"slug":1511,"type":15},{"name":1593,"slug":1594,"type":15},"2026-07-30T05:29:03.275638",496]