[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill-nvidia-doca-gpi":3,"mdc-ovly09-key":34,"related-repo-nvidia-doca-gpi":1628,"related-org-nvidia-doca-gpi":1734},{"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-gpi","program GPU-Packet-Initiator for RDMA queues","Use this skill for hands-on DOCA GPI programming — wiring a GPU-Packet-Initiator context so a CUDA kernel drives RDMA queues directly from GPU memory without host CPU mediation. Covers picking GPI vs doca-gpunetio, the doca_gpi \u002F domain \u002F channel object model, the GPU-side handle handoff (doca_gpu_gpi_channel*), attaching GPU memory to a GPI domain, the domain and channel attribute objects, and debugging DOCA_ERROR_* from doca_gpi_* calls. Trigger even when the user does not explicitly mention \"DOCA GPI\" — implicit phrasings include \"my CUDA kernel needs to post RDMA directly from GPU memory\", \"DOCA_ERROR_* from doca_gpi_gpu_channel_get\", \"how do I hand a GPU handle to my CUDA kernel\", \"how many channels can a GPI domain hold\", or \"GPU kernel driving RDMA without the host CPU on the path\". Refuse and route elsewhere for the doca-gpunetio Send\u002FReceive surface, the doca-rdma queue lifecycle, DPA-side initiation (doca-rdmi), or the CUDA programming model — those belong to other skills.\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},"Hardware","hardware","tag",{"name":9,"slug":8,"type":15},{"name":18,"slug":19,"type":15},"Engineering","engineering",{"name":21,"slug":22,"type":15},"CUDA","cuda",2473,"https:\u002F\u002Fgithub.com\u002FNVIDIA\u002Fskills","2026-07-30T05:28:43.410159","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-gpi","---\nlicense: Apache-2.0\nname: doca-gpi\ndescription: >\n  Use this skill for hands-on DOCA GPI programming\n  — wiring a GPU-Packet-Initiator context so a CUDA kernel drives\n  RDMA queues directly from GPU memory without host CPU mediation.\n  Covers picking GPI vs doca-gpunetio, the doca_gpi \u002F domain \u002F\n  channel object model, the GPU-side handle handoff\n  (doca_gpu_gpi_channel*), attaching GPU memory to a GPI domain,\n  the domain and channel attribute objects, and debugging\n  DOCA_ERROR_* from doca_gpi_* calls. Trigger even when the user\n  does not explicitly mention \"DOCA GPI\" — implicit\n  phrasings include \"my CUDA kernel needs to post RDMA directly\n  from GPU memory\", \"DOCA_ERROR_* from doca_gpi_gpu_channel_get\",\n  \"how do I hand a GPU handle to my CUDA kernel\", \"how many\n  channels can a GPI domain hold\", or \"GPU kernel driving RDMA\n  without the host CPU on the path\". Refuse and route elsewhere\n  for the doca-gpunetio\n  Send\u002FReceive surface, the doca-rdma queue lifecycle, DPA-side\n  initiation (doca-rdmi), or the CUDA programming model — those\n  belong to other skills.\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) with a BlueField DPU or ConnectX NIC\n  attached, plus an NVIDIA GPU with CUDA Toolkit installed\n  (GPUDirect-style PCIe path between GPU and NIC). Reads the local\n  install via `pkg-config doca-gpi` (co-requires doca-gpunetio,\n  doca-dpa, doca-verbs) and inspects \u002Fopt\u002Fmellanox\u002Fdoca\u002F{lib,include,samples,applications}.\n---\n\n# DOCA GPI\n\n**Where to start:** This skill assumes DOCA is already installed\nand the user is doing **hands-on GPI work** on a host that has both\na BlueField \u002F ConnectX device and an NVIDIA GPU reachable over\nPCIe. Open [`TASKS.md`](TASKS.md) if the user wants to *do*\nsomething (install \u002F configure \u002F build \u002F modify \u002F run \u002F test \u002F\ndebug \u002F use); open [`CAPABILITIES.md`](CAPABILITIES.md) when the\nquestion is *what can GPI express on this version* — the domain +\nchannel object model, the GPU-side handle handoff, the relationship\nto doca-gpunetio and doca-verbs, the attribute objects, and the\nsafety overlay. If the user has not installed DOCA yet, route to\n[`doca-setup`](..\u002F..\u002Fdoca-setup\u002FSKILL.md) first.\n\n## Example questions this skill answers well\n\nThe CLASSES of GPI questions this skill is built to answer, each\nwith one worked example. The agent should treat the *class* as the\nload-bearing piece — the worked example is a single instance.\n\n- **\"Should I use `doca-gpi` or `doca-gpunetio` for this case?\"** —\n  worked example: *\"my CUDA kernel needs to post RDMA writes\n  directly to a remote DPU's memory — do I want the higher-level\n  Send\u002FReceive surface or the lower-level channel\u002Fqueue surface?\"*.\n  Answered by the *channel-level vs Send\u002FReceive-level* selection\n  rule in\n  [`CAPABILITIES.md ## Capabilities and modes`](CAPABILITIES.md#capabilities-and-modes)\n  surface-selection table.\n- **\"How do I bring up a GPI channel and connect it to a remote\n  peer?\"** — worked example: *\"create the GPI, set domain + channel\n  attribute sizing, create the channel, exchange endpoint\n  connection info with the remote, connect the endpoint\"*. Answered\n  by the channel-object lifecycle in\n  [`CAPABILITIES.md ## Capabilities and modes`](CAPABILITIES.md#capabilities-and-modes)\n  + the configure walk in\n  [`TASKS.md ## configure`](TASKS.md#configure).\n- **\"What is the GPU-side handle and how do I hand it to my CUDA\n  kernel?\"** — worked example: *\"`doca_gpi_gpu_channel_get`\n  returns a `doca_gpu_gpi_channel*` — how do I get that into my\n  CUDA kernel's argument list?\"*. Answered by the GPU-handoff\n  pattern in\n  [`CAPABILITIES.md ## Capabilities and modes`](CAPABILITIES.md#capabilities-and-modes)\n  + the run-side wiring in [`TASKS.md ## run`](TASKS.md#run),\n  cross-linked into\n  [`doca-gpunetio`](..\u002Fdoca-gpunetio\u002FSKILL.md) for the CUDA-side\n  programming surface itself.\n- **\"What does my CUDA + GPU + DOCA version stack need to look\n  like?\"** — worked example: *\"I have BlueField-3 + A100; which\n  CUDA Toolkit and which DOCA version do I need?\"*. Answered by\n  the version-overlay in\n  [`CAPABILITIES.md ## Version compatibility`](CAPABILITIES.md#version-compatibility)\n  + the install-checks in [`TASKS.md ## install`](TASKS.md#install).\n- **\"How do I size the channels and work queues I want?\"** —\n  worked example: *\"I want 64 channels in a domain, each with a\n  1024-entry send queue; which setters express that?\"*. Answered\n  by the attribute-object sizing rule\n  (`doca_gpi_domain_attr_set_num_channels`,\n  `doca_gpi_channel_attr_set_sq_wqe_num`) in\n  [`CAPABILITIES.md ## Capabilities and modes`](CAPABILITIES.md#capabilities-and-modes)\n  + the sizing step in\n  [`TASKS.md ## configure`](TASKS.md#configure).\n- **\"What does this `DOCA_ERROR_*` from a `doca_gpi_*` call\n  mean?\"** — worked example: *\"`DOCA_ERROR_*` from\n  `doca_gpi_gpu_channel_get`\"*. Answered by the GPI overlay\n  on the cross-library taxonomy in\n  [`CAPABILITIES.md ## Error taxonomy`](CAPABILITIES.md#error-taxonomy)\n  + the layered ladder in [`TASKS.md ## debug`](TASKS.md#debug)\n  that escalates to [`doca-debug`](..\u002F..\u002Fdoca-debug\u002FSKILL.md).\n\n## Audience\n\nThis skill serves **external developers building GPU-resident DOCA\napplications that need to drive RDMA queues directly from CUDA\nkernels** — i.e., users whose accelerator-side code wants to post\nRDMA work from GPU memory without round-tripping through the host\nCPU. The canonical caller is a CUDA kernel that runs on an NVIDIA\nGPU on the same host as a BlueField \u002F ConnectX device, has\nGPUDirect-style access to the DPU's RDMA queues through the\nDOCA GPU-NetIO stack, and uses the GPI channel + queue handle to\ndrive RDMA initiation. This skill is *not* for NVIDIA developers\ncontributing to DOCA GPI itself, and it is not the right surface\nfor the higher-level Send\u002FReceive Ethernet-shaped GPU NetIO API —\nthat belongs to [`doca-gpunetio`](..\u002Fdoca-gpunetio\u002FSKILL.md).\n\n## Language scope\n\nDOCA GPI ships as a C library with the `pkg-config` module name\n`doca-gpi`. The library's **host-side** surface (`doca_gpi_*`)\nis C; the **GPU-side** surface — the `doca_gpu_gpi_channel*`\nhandle and the device-side calls a CUDA kernel uses against that\nhandle — is compiled with `nvcc` against the DOCA GPU NetIO\ndevice-side header set documented in\n[`doca-gpunetio`](..\u002Fdoca-gpunetio\u002FSKILL.md). Other-language\nconsumers (Rust, Go, Python, …) consume the host-side `*.so`\nthrough FFI; the skill's contribution in that case is to keep the\nchannel \u002F queue lifecycle, the GPU-handle handoff, the version\ndiscipline, and the safety overlay language-neutral, and to route\nthe agent to the public C ABI as the authoritative surface that\nany wrapper will eventually call. The GPU-side surface is *not*\nwrappable in another language — it is compiled and linked into\nthe CUDA binary itself.\n\n## When to load this skill\n\nLoad this skill when the user is doing **hands-on DOCA GPI work**\non a host with both a BlueField \u002F ConnectX device and an NVIDIA\nGPU. Concretely:\n\n- Deciding between `doca-gpi` (the lower-level channel\u002Fqueue\n  surface) and `doca-gpunetio` (the higher-level Send\u002FReceive\n  surface) for a new GPU-initiated RDMA workload.\n- Creating a `doca_gpi` on a `doca_dev`, configuring it via the\n  `doca_gpi_set_*` family (domain count, GID index, port) and\n  sizing domains and channels through the\n  `doca_gpi_domain_attr_*` \u002F `doca_gpi_channel_attr_*` setters\n  before `doca_gpi_start()`.\n- Creating a channel with `doca_gpi_channel_create` and\n  retrieving its GPU-side handle with `doca_gpi_gpu_channel_get`,\n  then handing the GPU-side handle to a CUDA kernel.\n- Exchanging endpoint connection info with a remote peer using\n  `doca_gpi_channel_ep_conn_info_create` \u002F\n  `doca_gpi_channel_ep_connect` to establish the GPU-driven\n  channel end-to-end.\n- Attaching memory regions to a GPI domain with\n  `doca_gpi_domain_attach_local_mmap` \u002F\n  `doca_gpi_domain_attach_remote_mmap` (each backed by a\n  `doca_mmap` the application created).\n- Debugging a `DOCA_ERROR_*` returned by a `doca_gpi_*` call\n  and deciding whether the cause is a lifecycle ordering bug, a\n  GPU datapath mis-assignment, a CUDA-version mismatch, or a\n  layer below DOCA.\n\nDo **not** load this skill for general DOCA orientation, install\nof DOCA itself, host-CPU-initiated RDMA, or the higher-level GPU\nNetIO Send\u002FReceive Ethernet-shaped API. For those, use\n[`doca-public-knowledge-map`](..\u002F..\u002Fdoca-public-knowledge-map\u002FSKILL.md),\n[`doca-setup`](..\u002F..\u002Fdoca-setup\u002FSKILL.md),\n[`doca-rdma`](..\u002Fdoca-rdma\u002FSKILL.md), and\n[`doca-gpunetio`](..\u002Fdoca-gpunetio\u002FSKILL.md) respectively.\nWhen one question spans the GPI channel lifecycle and CUDA-side\nGPU NetIO behavior, load both skills: this skill owns GPI object\ncreation, connection, and teardown, while `doca-gpunetio` owns\nkernel launch and device-side execution. If that boundary remains\nambiguous after reading both scopes, stop and ask which side is\nfailing instead of choosing one implicitly.\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 GPI-specific\nmaterial lives in two companion files:\n\n- `CAPABILITIES.md` — what GPI can express on this version: the\n  `doca_gpi` \u002F `doca_gpi_domain` \u002F `doca_gpi_channel` object\n  model, the GPU-side handle handoff, the relationship to\n  [`doca-gpunetio`](..\u002Fdoca-gpunetio\u002FSKILL.md) (which owns the\n  GPU-side `doca_gpu_gpi_channel*` device surface) and to\n  [`doca-verbs`](..\u002Fdoca-verbs\u002FSKILL.md) and\n  [`doca-dpa`](..\u002Fdoca-dpa\u002FSKILL.md) (the transport and DPA layers\n  GPI builds on), the domain and channel attribute objects, the\n  maturity statement (every `doca_gpi_*` symbol is\n  `DOCA_EXPERIMENTAL`), the GPI overlay on the cross-library\n  `DOCA_ERROR_*` taxonomy, the observability surface (CUDA-side\n  channel polling, mmap-attach exchange), and the safety policy\n  that gates GPU-side RDMA initiation.\n- `TASKS.md` — step-by-step workflows for the eight in-scope\n  verbs: `install`, `configure`, `build`, `modify`, `run`,\n  `test`, `debug`, `use`. Plus a `Deferred task verbs` block that\n  points out-of-scope questions at the right next skill.\n\nThe skill assumes a host where DOCA is already installed at the\nstandard location, a CUDA Toolkit compatible with the installed\nDOCA is present, and the user has the privileges their public\ninstall profile expects. It does not cover installing DOCA — that\npath goes through [`doca-setup`](..\u002F..\u002Fdoca-setup\u002FSKILL.md).\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 GPI application source code, in any\n  language.** The agent's job is to route the user to verified\n  reference code (the shipped DOCA GPU-NetIO samples on the\n  installed package set are the canonical worked examples for the\n  GPU-side handoff) and to prescribe a minimum-diff modification\n  via the universal modify-a-sample workflow in\n  [`doca-programming-guide`](..\u002F..\u002Fdoca-programming-guide\u002FSKILL.md).\n  Because every GPI symbol is tagged `DOCA_EXPERIMENTAL`\n  in the public header, the skill refuses to author GPI\n  source from documentation prose.\n- **Standalone build manifests** (`meson.build`, `CMakeLists.txt`,\n  `Cargo.toml`, …) parked inside the skill. The agent constructs\n  the build manifest *in the user's project directory* against\n  the user's installed DOCA, where `pkg-config --modversion\n  doca-gpi` is the source of truth.\n- **CUDA kernel templates.** The CUDA-side surface is owned by\n  [`doca-gpunetio`](..\u002Fdoca-gpunetio\u002FSKILL.md); GPI's GPU-side\n  handle is *consumed by* the CUDA programming model documented\n  there. This skill names the GPI-specific handoff (the\n  `doca_gpu_gpi_channel*` type, the channel-connect call) but\n  does not author CUDA kernels.\n- **A `samples\u002F`, `bindings\u002F`, or `reference\u002F` subtree** of any\n  kind. A mock or incomplete artifact in this skill's tree, even\n  one labeled \"reference\", is misleading: users will read it as\n  buildable.\n\n## Loading order\n\n1. Read this `SKILL.md` first to confirm the user's question is\n   in scope.\n2. **For the GPI object model, the GPU-side handoff pattern, the\n   domain and channel attribute objects, the version compatibility\n   rule, the error taxonomy, observability, and safety policy, see\n   [CAPABILITIES.md](CAPABILITIES.md).**\n3. **For step-by-step workflows — install, configure, build,\n   modify, run, test, debug, use — see [TASKS.md](TASKS.md).**\n\nBoth companion files cross-link to each other and to\n[`doca-public-knowledge-map`](..\u002F..\u002Fdoca-public-knowledge-map\u002FSKILL.md)\nwhenever the right answer is \"look it up in the public docs or\nthe installed package layout\" rather than \"GPI-specific\nguidance\".\n\n## Related skills\n\n- [`doca-gpunetio`](..\u002Fdoca-gpunetio\u002FSKILL.md) — the GPU NetIO\n  library that exposes Send\u002FReceive-shaped Ethernet I\u002FO for CUDA\n  kernels and **owns the GPU-side device surface GPI hands off\n  to**: the `doca_gpu_gpi_channel*` type and its device-side\n  `.cuh` API live in doca-gpunetio, and `doca_gpi.h` includes\n  `doca_gpunetio.h`. Both can coexist in the same application.\n  The selection table in\n  [`CAPABILITIES.md ## Capabilities and modes`](CAPABILITIES.md#capabilities-and-modes)\n  is the load-bearing decision aid.\n- [`doca-verbs`](..\u002Fdoca-verbs\u002FSKILL.md) and\n  [`doca-dpa`](..\u002Fdoca-dpa\u002FSKILL.md) — the transport and DPA\n  layers GPI builds on. `dependencies\u002Fmeson.build` lists\n  `doca-dpa`, `doca-gpunetio`, and `doca-verbs` (plus the\n  `libmlx5` \u002F `libibverbs` externals); `doca_gpi_get_dpa` returns\n  the GPI-owned `doca_dpa*` for tuning DPA attributes. The RDMA\n  transport type, GID \u002F port selection, and permission semantics\n  live at the verbs layer; GPI consumes it rather than binding a\n  `doca-rdma` queue.\n- [`doca-rdmi`](..\u002Fdoca-rdmi\u002FSKILL.md) — the sister DPA-side\n  initiator surface. Both GPI and RDMI exist for \"drive RDMA\n  initiation from an accelerator without the host CPU on the\n  data path\"; GPI is the GPU case, RDMI is the DPA case.\n- [`doca-public-knowledge-map`](..\u002F..\u002Fdoca-public-knowledge-map\u002FSKILL.md) — the\n  routing table for every public DOCA documentation source and\n  the on-disk layout of an installed DOCA package.\n- [`doca-setup`](..\u002F..\u002Fdoca-setup\u002FSKILL.md) — env preparation,\n  install verification, and the *I have no install yet* path\n  with the public NGC DOCA container.\n- [`doca-programming-guide`](..\u002F..\u002Fdoca-programming-guide\u002FSKILL.md) —\n  general DOCA programming patterns shared by every library: the\n  canonical `pkg-config` + meson build pattern, the universal\n  modify-a-shipped-sample first-app workflow, the universal\n  Core-context lifecycle, the cross-library `DOCA_ERROR_*`\n  taxonomy. This skill layers GPI 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). GPI-specific debug overlays on top of it.\n- [`doca-hardware-safety`](..\u002F..\u002Fdoca-hardware-safety\u002FSKILL.md) —\n  the bundle-wide hardware-safety meta-policy. The `## Safety\n  policy` overlay in `CAPABILITIES.md` cross-links it.\n- [`doca-version`](..\u002F..\u002Fdoca-version\u002FSKILL.md) — the version\n  detection \u002F four-way match rule every per-artifact `##\n  Version compatibility` anchor builds on. This skill quotes\n  the GPI-specific overlay only (DOCA-side `.pc` PLUS the CUDA\n  Toolkit axis).\n- [`doca-structured-tools-contract`](..\u002F..\u002Fdoca-structured-tools-contract\u002FSKILL.md) —\n  the JSON-schema contracts for the agent-preferred structured\n  helpers; the `## Command appendix` in `TASKS.md` defers to\n  them before falling back to the manual chain.\n\n",{"data":35,"body":39},{"license":26,"name":4,"description":6,"metadata":36,"compatibility":38},{"kind":37},"library","Requires DOCA SDK installed at \u002Fopt\u002Fmellanox\u002Fdoca on Linux (Ubuntu 22.04\u002F24.04 or RHEL\u002FSLES) with a BlueField DPU or ConnectX NIC attached, plus an NVIDIA GPU with CUDA Toolkit installed (GPUDirect-style PCIe path between GPU and NIC). Reads the local install via `pkg-config doca-gpi` (co-requires doca-gpunetio, doca-dpa, doca-verbs) and inspects \u002Fopt\u002Fmellanox\u002Fdoca\u002F{lib,include,samples,applications}.\n",{"type":40,"children":41},"root",[42,50,120,127,139,498,504,532,538,618,624,636,798,858,864,876,1049,1063,1069,1081,1227,1233,1276,1291,1297],{"type":43,"tag":44,"props":45,"children":46},"element","h1",{"id":4},[47],{"type":48,"value":49},"text","DOCA GPI",{"type":43,"tag":51,"props":52,"children":53},"p",{},[54,60,62,67,69,80,82,88,90,99,101,106,108,118],{"type":43,"tag":55,"props":56,"children":57},"strong",{},[58],{"type":48,"value":59},"Where to start:",{"type":48,"value":61}," This skill assumes DOCA is already installed\nand the user is doing ",{"type":43,"tag":55,"props":63,"children":64},{},[65],{"type":48,"value":66},"hands-on GPI work",{"type":48,"value":68}," on a host that has both\na BlueField \u002F ConnectX device and an NVIDIA GPU reachable over\nPCIe. Open ",{"type":43,"tag":70,"props":71,"children":73},"a",{"href":72},"TASKS.md",[74],{"type":43,"tag":75,"props":76,"children":78},"code",{"className":77},[],[79],{"type":48,"value":72},{"type":48,"value":81}," if the user wants to ",{"type":43,"tag":83,"props":84,"children":85},"em",{},[86],{"type":48,"value":87},"do",{"type":48,"value":89},"\nsomething (install \u002F configure \u002F build \u002F modify \u002F run \u002F test \u002F\ndebug \u002F use); open ",{"type":43,"tag":70,"props":91,"children":93},{"href":92},"CAPABILITIES.md",[94],{"type":43,"tag":75,"props":95,"children":97},{"className":96},[],[98],{"type":48,"value":92},{"type":48,"value":100}," when the\nquestion is ",{"type":43,"tag":83,"props":102,"children":103},{},[104],{"type":48,"value":105},"what can GPI express on this version",{"type":48,"value":107}," — the domain +\nchannel object model, the GPU-side handle handoff, the relationship\nto doca-gpunetio and doca-verbs, the attribute objects, and the\nsafety overlay. If the user has not installed DOCA yet, route to\n",{"type":43,"tag":70,"props":109,"children":111},{"href":110},"..\u002F..\u002Fdoca-setup\u002FSKILL.md",[112],{"type":43,"tag":75,"props":113,"children":115},{"className":114},[],[116],{"type":48,"value":117},"doca-setup",{"type":48,"value":119}," first.",{"type":43,"tag":121,"props":122,"children":124},"h2",{"id":123},"example-questions-this-skill-answers-well",[125],{"type":48,"value":126},"Example questions this skill answers well",{"type":43,"tag":51,"props":128,"children":129},{},[130,132,137],{"type":48,"value":131},"The CLASSES of GPI questions this skill is built to answer, each\nwith one worked example. The agent should treat the ",{"type":43,"tag":83,"props":133,"children":134},{},[135],{"type":48,"value":136},"class",{"type":48,"value":138}," as the\nload-bearing piece — the worked example is a single instance.",{"type":43,"tag":140,"props":141,"children":142},"ul",{},[143,195,240,311,356,413],{"type":43,"tag":144,"props":145,"children":146},"li",{},[147,167,169,174,176,181,183,193],{"type":43,"tag":55,"props":148,"children":149},{},[150,152,157,159,165],{"type":48,"value":151},"\"Should I use ",{"type":43,"tag":75,"props":153,"children":155},{"className":154},[],[156],{"type":48,"value":4},{"type":48,"value":158}," or ",{"type":43,"tag":75,"props":160,"children":162},{"className":161},[],[163],{"type":48,"value":164},"doca-gpunetio",{"type":48,"value":166}," for this case?\"",{"type":48,"value":168}," —\nworked example: ",{"type":43,"tag":83,"props":170,"children":171},{},[172],{"type":48,"value":173},"\"my CUDA kernel needs to post RDMA writes\ndirectly to a remote DPU's memory — do I want the higher-level\nSend\u002FReceive surface or the lower-level channel\u002Fqueue surface?\"",{"type":48,"value":175},".\nAnswered by the ",{"type":43,"tag":83,"props":177,"children":178},{},[179],{"type":48,"value":180},"channel-level vs Send\u002FReceive-level",{"type":48,"value":182}," selection\nrule in\n",{"type":43,"tag":70,"props":184,"children":186},{"href":185},"CAPABILITIES.md#capabilities-and-modes",[187],{"type":43,"tag":75,"props":188,"children":190},{"className":189},[],[191],{"type":48,"value":192},"CAPABILITIES.md ## Capabilities and modes",{"type":48,"value":194},"\nsurface-selection table.",{"type":43,"tag":144,"props":196,"children":197},{},[198,203,205,210,212,220],{"type":43,"tag":55,"props":199,"children":200},{},[201],{"type":48,"value":202},"\"How do I bring up a GPI channel and connect it to a remote\npeer?\"",{"type":48,"value":204}," — worked example: ",{"type":43,"tag":83,"props":206,"children":207},{},[208],{"type":48,"value":209},"\"create the GPI, set domain + channel\nattribute sizing, create the channel, exchange endpoint\nconnection info with the remote, connect the endpoint\"",{"type":48,"value":211},". Answered\nby the channel-object lifecycle in\n",{"type":43,"tag":70,"props":213,"children":214},{"href":185},[215],{"type":43,"tag":75,"props":216,"children":218},{"className":217},[],[219],{"type":48,"value":192},{"type":43,"tag":140,"props":221,"children":222},{},[223],{"type":43,"tag":144,"props":224,"children":225},{},[226,228,238],{"type":48,"value":227},"the configure walk in\n",{"type":43,"tag":70,"props":229,"children":231},{"href":230},"TASKS.md#configure",[232],{"type":43,"tag":75,"props":233,"children":235},{"className":234},[],[236],{"type":48,"value":237},"TASKS.md ## configure",{"type":48,"value":239},".",{"type":43,"tag":144,"props":241,"children":242},{},[243,248,249,270,272,280],{"type":43,"tag":55,"props":244,"children":245},{},[246],{"type":48,"value":247},"\"What is the GPU-side handle and how do I hand it to my CUDA\nkernel?\"",{"type":48,"value":204},{"type":43,"tag":83,"props":250,"children":251},{},[252,254,260,262,268],{"type":48,"value":253},"\"",{"type":43,"tag":75,"props":255,"children":257},{"className":256},[],[258],{"type":48,"value":259},"doca_gpi_gpu_channel_get",{"type":48,"value":261},"\nreturns a ",{"type":43,"tag":75,"props":263,"children":265},{"className":264},[],[266],{"type":48,"value":267},"doca_gpu_gpi_channel*",{"type":48,"value":269}," — how do I get that into my\nCUDA kernel's argument list?\"",{"type":48,"value":271},". Answered by the GPU-handoff\npattern in\n",{"type":43,"tag":70,"props":273,"children":274},{"href":185},[275],{"type":43,"tag":75,"props":276,"children":278},{"className":277},[],[279],{"type":48,"value":192},{"type":43,"tag":140,"props":281,"children":282},{},[283],{"type":43,"tag":144,"props":284,"children":285},{},[286,288,298,300,309],{"type":48,"value":287},"the run-side wiring in ",{"type":43,"tag":70,"props":289,"children":291},{"href":290},"TASKS.md#run",[292],{"type":43,"tag":75,"props":293,"children":295},{"className":294},[],[296],{"type":48,"value":297},"TASKS.md ## run",{"type":48,"value":299},",\ncross-linked into\n",{"type":43,"tag":70,"props":301,"children":303},{"href":302},"..\u002Fdoca-gpunetio\u002FSKILL.md",[304],{"type":43,"tag":75,"props":305,"children":307},{"className":306},[],[308],{"type":48,"value":164},{"type":48,"value":310}," for the CUDA-side\nprogramming surface itself.",{"type":43,"tag":144,"props":312,"children":313},{},[314,319,320,325,327,337],{"type":43,"tag":55,"props":315,"children":316},{},[317],{"type":48,"value":318},"\"What does my CUDA + GPU + DOCA version stack need to look\nlike?\"",{"type":48,"value":204},{"type":43,"tag":83,"props":321,"children":322},{},[323],{"type":48,"value":324},"\"I have BlueField-3 + A100; which\nCUDA Toolkit and which DOCA version do I need?\"",{"type":48,"value":326},". Answered by\nthe version-overlay in\n",{"type":43,"tag":70,"props":328,"children":330},{"href":329},"CAPABILITIES.md#version-compatibility",[331],{"type":43,"tag":75,"props":332,"children":334},{"className":333},[],[335],{"type":48,"value":336},"CAPABILITIES.md ## Version compatibility",{"type":43,"tag":140,"props":338,"children":339},{},[340],{"type":43,"tag":144,"props":341,"children":342},{},[343,345,355],{"type":48,"value":344},"the install-checks in ",{"type":43,"tag":70,"props":346,"children":348},{"href":347},"TASKS.md#install",[349],{"type":43,"tag":75,"props":350,"children":352},{"className":351},[],[353],{"type":48,"value":354},"TASKS.md ## install",{"type":48,"value":239},{"type":43,"tag":144,"props":357,"children":358},{},[359,364,365,370,372,378,380,386,388,396],{"type":43,"tag":55,"props":360,"children":361},{},[362],{"type":48,"value":363},"\"How do I size the channels and work queues I want?\"",{"type":48,"value":168},{"type":43,"tag":83,"props":366,"children":367},{},[368],{"type":48,"value":369},"\"I want 64 channels in a domain, each with a\n1024-entry send queue; which setters express that?\"",{"type":48,"value":371},". Answered\nby the attribute-object sizing rule\n(",{"type":43,"tag":75,"props":373,"children":375},{"className":374},[],[376],{"type":48,"value":377},"doca_gpi_domain_attr_set_num_channels",{"type":48,"value":379},",\n",{"type":43,"tag":75,"props":381,"children":383},{"className":382},[],[384],{"type":48,"value":385},"doca_gpi_channel_attr_set_sq_wqe_num",{"type":48,"value":387},") in\n",{"type":43,"tag":70,"props":389,"children":390},{"href":185},[391],{"type":43,"tag":75,"props":392,"children":394},{"className":393},[],[395],{"type":48,"value":192},{"type":43,"tag":140,"props":397,"children":398},{},[399],{"type":43,"tag":144,"props":400,"children":401},{},[402,404,412],{"type":48,"value":403},"the sizing step in\n",{"type":43,"tag":70,"props":405,"children":406},{"href":230},[407],{"type":43,"tag":75,"props":408,"children":410},{"className":409},[],[411],{"type":48,"value":237},{"type":48,"value":239},{"type":43,"tag":144,"props":414,"children":415},{},[416,437,438,455,457,467],{"type":43,"tag":55,"props":417,"children":418},{},[419,421,427,429,435],{"type":48,"value":420},"\"What does this ",{"type":43,"tag":75,"props":422,"children":424},{"className":423},[],[425],{"type":48,"value":426},"DOCA_ERROR_*",{"type":48,"value":428}," from a ",{"type":43,"tag":75,"props":430,"children":432},{"className":431},[],[433],{"type":48,"value":434},"doca_gpi_*",{"type":48,"value":436}," call\nmean?\"",{"type":48,"value":204},{"type":43,"tag":83,"props":439,"children":440},{},[441,442,447,449,454],{"type":48,"value":253},{"type":43,"tag":75,"props":443,"children":445},{"className":444},[],[446],{"type":48,"value":426},{"type":48,"value":448}," from\n",{"type":43,"tag":75,"props":450,"children":452},{"className":451},[],[453],{"type":48,"value":259},{"type":48,"value":253},{"type":48,"value":456},". Answered by the GPI overlay\non the cross-library taxonomy in\n",{"type":43,"tag":70,"props":458,"children":460},{"href":459},"CAPABILITIES.md#error-taxonomy",[461],{"type":43,"tag":75,"props":462,"children":464},{"className":463},[],[465],{"type":48,"value":466},"CAPABILITIES.md ## Error taxonomy",{"type":43,"tag":140,"props":468,"children":469},{},[470],{"type":43,"tag":144,"props":471,"children":472},{},[473,475,485,487,497],{"type":48,"value":474},"the layered ladder in ",{"type":43,"tag":70,"props":476,"children":478},{"href":477},"TASKS.md#debug",[479],{"type":43,"tag":75,"props":480,"children":482},{"className":481},[],[483],{"type":48,"value":484},"TASKS.md ## debug",{"type":48,"value":486},"\nthat escalates to ",{"type":43,"tag":70,"props":488,"children":490},{"href":489},"..\u002F..\u002Fdoca-debug\u002FSKILL.md",[491],{"type":43,"tag":75,"props":492,"children":494},{"className":493},[],[495],{"type":48,"value":496},"doca-debug",{"type":48,"value":239},{"type":43,"tag":121,"props":499,"children":501},{"id":500},"audience",[502],{"type":48,"value":503},"Audience",{"type":43,"tag":51,"props":505,"children":506},{},[507,509,514,516,521,523,531],{"type":48,"value":508},"This skill serves ",{"type":43,"tag":55,"props":510,"children":511},{},[512],{"type":48,"value":513},"external developers building GPU-resident DOCA\napplications that need to drive RDMA queues directly from CUDA\nkernels",{"type":48,"value":515}," — i.e., users whose accelerator-side code wants to post\nRDMA work from GPU memory without round-tripping through the host\nCPU. The canonical caller is a CUDA kernel that runs on an NVIDIA\nGPU on the same host as a BlueField \u002F ConnectX device, has\nGPUDirect-style access to the DPU's RDMA queues through the\nDOCA GPU-NetIO stack, and uses the GPI channel + queue handle to\ndrive RDMA initiation. This skill is ",{"type":43,"tag":83,"props":517,"children":518},{},[519],{"type":48,"value":520},"not",{"type":48,"value":522}," for NVIDIA developers\ncontributing to DOCA GPI itself, and it is not the right surface\nfor the higher-level Send\u002FReceive Ethernet-shaped GPU NetIO API —\nthat belongs to ",{"type":43,"tag":70,"props":524,"children":525},{"href":302},[526],{"type":43,"tag":75,"props":527,"children":529},{"className":528},[],[530],{"type":48,"value":164},{"type":48,"value":239},{"type":43,"tag":121,"props":533,"children":535},{"id":534},"language-scope",[536],{"type":48,"value":537},"Language scope",{"type":43,"tag":51,"props":539,"children":540},{},[541,543,549,551,556,558,563,565,570,572,577,579,584,586,592,594,602,604,610,612,616],{"type":48,"value":542},"DOCA GPI ships as a C library with the ",{"type":43,"tag":75,"props":544,"children":546},{"className":545},[],[547],{"type":48,"value":548},"pkg-config",{"type":48,"value":550}," module name\n",{"type":43,"tag":75,"props":552,"children":554},{"className":553},[],[555],{"type":48,"value":4},{"type":48,"value":557},". The library's ",{"type":43,"tag":55,"props":559,"children":560},{},[561],{"type":48,"value":562},"host-side",{"type":48,"value":564}," surface (",{"type":43,"tag":75,"props":566,"children":568},{"className":567},[],[569],{"type":48,"value":434},{"type":48,"value":571},")\nis C; the ",{"type":43,"tag":55,"props":573,"children":574},{},[575],{"type":48,"value":576},"GPU-side",{"type":48,"value":578}," surface — the ",{"type":43,"tag":75,"props":580,"children":582},{"className":581},[],[583],{"type":48,"value":267},{"type":48,"value":585},"\nhandle and the device-side calls a CUDA kernel uses against that\nhandle — is compiled with ",{"type":43,"tag":75,"props":587,"children":589},{"className":588},[],[590],{"type":48,"value":591},"nvcc",{"type":48,"value":593}," against the DOCA GPU NetIO\ndevice-side header set documented in\n",{"type":43,"tag":70,"props":595,"children":596},{"href":302},[597],{"type":43,"tag":75,"props":598,"children":600},{"className":599},[],[601],{"type":48,"value":164},{"type":48,"value":603},". Other-language\nconsumers (Rust, Go, Python, …) consume the host-side ",{"type":43,"tag":75,"props":605,"children":607},{"className":606},[],[608],{"type":48,"value":609},"*.so",{"type":48,"value":611},"\nthrough FFI; the skill's contribution in that case is to keep the\nchannel \u002F queue lifecycle, the GPU-handle handoff, the version\ndiscipline, and the safety overlay language-neutral, and to route\nthe agent to the public C ABI as the authoritative surface that\nany wrapper will eventually call. The GPU-side surface is ",{"type":43,"tag":83,"props":613,"children":614},{},[615],{"type":48,"value":520},{"type":48,"value":617},"\nwrappable in another language — it is compiled and linked into\nthe CUDA binary itself.",{"type":43,"tag":121,"props":619,"children":621},{"id":620},"when-to-load-this-skill",[622],{"type":48,"value":623},"When to load this skill",{"type":43,"tag":51,"props":625,"children":626},{},[627,629,634],{"type":48,"value":628},"Load this skill when the user is doing ",{"type":43,"tag":55,"props":630,"children":631},{},[632],{"type":48,"value":633},"hands-on DOCA GPI work",{"type":48,"value":635},"\non a host with both a BlueField \u002F ConnectX device and an NVIDIA\nGPU. Concretely:",{"type":43,"tag":140,"props":637,"children":638},{},[639,658,710,730,751,779],{"type":43,"tag":144,"props":640,"children":641},{},[642,644,649,651,656],{"type":48,"value":643},"Deciding between ",{"type":43,"tag":75,"props":645,"children":647},{"className":646},[],[648],{"type":48,"value":4},{"type":48,"value":650}," (the lower-level channel\u002Fqueue\nsurface) and ",{"type":43,"tag":75,"props":652,"children":654},{"className":653},[],[655],{"type":48,"value":164},{"type":48,"value":657}," (the higher-level Send\u002FReceive\nsurface) for a new GPU-initiated RDMA workload.",{"type":43,"tag":144,"props":659,"children":660},{},[661,663,669,671,677,679,685,687,693,695,701,703,709],{"type":48,"value":662},"Creating a ",{"type":43,"tag":75,"props":664,"children":666},{"className":665},[],[667],{"type":48,"value":668},"doca_gpi",{"type":48,"value":670}," on a ",{"type":43,"tag":75,"props":672,"children":674},{"className":673},[],[675],{"type":48,"value":676},"doca_dev",{"type":48,"value":678},", configuring it via the\n",{"type":43,"tag":75,"props":680,"children":682},{"className":681},[],[683],{"type":48,"value":684},"doca_gpi_set_*",{"type":48,"value":686}," family (domain count, GID index, port) and\nsizing domains and channels through the\n",{"type":43,"tag":75,"props":688,"children":690},{"className":689},[],[691],{"type":48,"value":692},"doca_gpi_domain_attr_*",{"type":48,"value":694}," \u002F ",{"type":43,"tag":75,"props":696,"children":698},{"className":697},[],[699],{"type":48,"value":700},"doca_gpi_channel_attr_*",{"type":48,"value":702}," setters\nbefore ",{"type":43,"tag":75,"props":704,"children":706},{"className":705},[],[707],{"type":48,"value":708},"doca_gpi_start()",{"type":48,"value":239},{"type":43,"tag":144,"props":711,"children":712},{},[713,715,721,723,728],{"type":48,"value":714},"Creating a channel with ",{"type":43,"tag":75,"props":716,"children":718},{"className":717},[],[719],{"type":48,"value":720},"doca_gpi_channel_create",{"type":48,"value":722}," and\nretrieving its GPU-side handle with ",{"type":43,"tag":75,"props":724,"children":726},{"className":725},[],[727],{"type":48,"value":259},{"type":48,"value":729},",\nthen handing the GPU-side handle to a CUDA kernel.",{"type":43,"tag":144,"props":731,"children":732},{},[733,735,741,743,749],{"type":48,"value":734},"Exchanging endpoint connection info with a remote peer using\n",{"type":43,"tag":75,"props":736,"children":738},{"className":737},[],[739],{"type":48,"value":740},"doca_gpi_channel_ep_conn_info_create",{"type":48,"value":742}," \u002F\n",{"type":43,"tag":75,"props":744,"children":746},{"className":745},[],[747],{"type":48,"value":748},"doca_gpi_channel_ep_connect",{"type":48,"value":750}," to establish the GPU-driven\nchannel end-to-end.",{"type":43,"tag":144,"props":752,"children":753},{},[754,756,762,763,769,771,777],{"type":48,"value":755},"Attaching memory regions to a GPI domain with\n",{"type":43,"tag":75,"props":757,"children":759},{"className":758},[],[760],{"type":48,"value":761},"doca_gpi_domain_attach_local_mmap",{"type":48,"value":742},{"type":43,"tag":75,"props":764,"children":766},{"className":765},[],[767],{"type":48,"value":768},"doca_gpi_domain_attach_remote_mmap",{"type":48,"value":770}," (each backed by a\n",{"type":43,"tag":75,"props":772,"children":774},{"className":773},[],[775],{"type":48,"value":776},"doca_mmap",{"type":48,"value":778}," the application created).",{"type":43,"tag":144,"props":780,"children":781},{},[782,784,789,791,796],{"type":48,"value":783},"Debugging a ",{"type":43,"tag":75,"props":785,"children":787},{"className":786},[],[788],{"type":48,"value":426},{"type":48,"value":790}," returned by a ",{"type":43,"tag":75,"props":792,"children":794},{"className":793},[],[795],{"type":48,"value":434},{"type":48,"value":797}," call\nand deciding whether the cause is a lifecycle ordering bug, a\nGPU datapath mis-assignment, a CUDA-version mismatch, or a\nlayer below DOCA.",{"type":43,"tag":51,"props":799,"children":800},{},[801,803,807,809,819,820,828,829,839,841,849,851,856],{"type":48,"value":802},"Do ",{"type":43,"tag":55,"props":804,"children":805},{},[806],{"type":48,"value":520},{"type":48,"value":808}," load this skill for general DOCA orientation, install\nof DOCA itself, host-CPU-initiated RDMA, or the higher-level GPU\nNetIO Send\u002FReceive Ethernet-shaped API. For those, use\n",{"type":43,"tag":70,"props":810,"children":812},{"href":811},"..\u002F..\u002Fdoca-public-knowledge-map\u002FSKILL.md",[813],{"type":43,"tag":75,"props":814,"children":816},{"className":815},[],[817],{"type":48,"value":818},"doca-public-knowledge-map",{"type":48,"value":379},{"type":43,"tag":70,"props":821,"children":822},{"href":110},[823],{"type":43,"tag":75,"props":824,"children":826},{"className":825},[],[827],{"type":48,"value":117},{"type":48,"value":379},{"type":43,"tag":70,"props":830,"children":832},{"href":831},"..\u002Fdoca-rdma\u002FSKILL.md",[833],{"type":43,"tag":75,"props":834,"children":836},{"className":835},[],[837],{"type":48,"value":838},"doca-rdma",{"type":48,"value":840},", and\n",{"type":43,"tag":70,"props":842,"children":843},{"href":302},[844],{"type":43,"tag":75,"props":845,"children":847},{"className":846},[],[848],{"type":48,"value":164},{"type":48,"value":850}," respectively.\nWhen one question spans the GPI channel lifecycle and CUDA-side\nGPU NetIO behavior, load both skills: this skill owns GPI object\ncreation, connection, and teardown, while ",{"type":43,"tag":75,"props":852,"children":854},{"className":853},[],[855],{"type":48,"value":164},{"type":48,"value":857}," owns\nkernel launch and device-side execution. If that boundary remains\nambiguous after reading both scopes, stop and ask which side is\nfailing instead of choosing one implicitly.",{"type":43,"tag":121,"props":859,"children":861},{"id":860},"what-this-skill-provides",[862],{"type":48,"value":863},"What this skill provides",{"type":43,"tag":51,"props":865,"children":866},{},[867,869,874],{"type":48,"value":868},"This is a ",{"type":43,"tag":55,"props":870,"children":871},{},[872],{"type":48,"value":873},"thin loader",{"type":48,"value":875},". The body keeps only the orientation\nneeded to pick the right next file. The substantive GPI-specific\nmaterial lives in two companion files:",{"type":43,"tag":140,"props":877,"children":878},{},[879,973],{"type":43,"tag":144,"props":880,"children":881},{},[882,887,889,894,895,901,902,908,910,918,920,925,927,937,939,949,951,956,958,964,966,971],{"type":43,"tag":75,"props":883,"children":885},{"className":884},[],[886],{"type":48,"value":92},{"type":48,"value":888}," — what GPI can express on this version: the\n",{"type":43,"tag":75,"props":890,"children":892},{"className":891},[],[893],{"type":48,"value":668},{"type":48,"value":694},{"type":43,"tag":75,"props":896,"children":898},{"className":897},[],[899],{"type":48,"value":900},"doca_gpi_domain",{"type":48,"value":694},{"type":43,"tag":75,"props":903,"children":905},{"className":904},[],[906],{"type":48,"value":907},"doca_gpi_channel",{"type":48,"value":909}," object\nmodel, the GPU-side handle handoff, the relationship to\n",{"type":43,"tag":70,"props":911,"children":912},{"href":302},[913],{"type":43,"tag":75,"props":914,"children":916},{"className":915},[],[917],{"type":48,"value":164},{"type":48,"value":919}," (which owns the\nGPU-side ",{"type":43,"tag":75,"props":921,"children":923},{"className":922},[],[924],{"type":48,"value":267},{"type":48,"value":926}," device surface) and to\n",{"type":43,"tag":70,"props":928,"children":930},{"href":929},"..\u002Fdoca-verbs\u002FSKILL.md",[931],{"type":43,"tag":75,"props":932,"children":934},{"className":933},[],[935],{"type":48,"value":936},"doca-verbs",{"type":48,"value":938}," and\n",{"type":43,"tag":70,"props":940,"children":942},{"href":941},"..\u002Fdoca-dpa\u002FSKILL.md",[943],{"type":43,"tag":75,"props":944,"children":946},{"className":945},[],[947],{"type":48,"value":948},"doca-dpa",{"type":48,"value":950}," (the transport and DPA layers\nGPI builds on), the domain and channel attribute objects, the\nmaturity statement (every ",{"type":43,"tag":75,"props":952,"children":954},{"className":953},[],[955],{"type":48,"value":434},{"type":48,"value":957}," symbol is\n",{"type":43,"tag":75,"props":959,"children":961},{"className":960},[],[962],{"type":48,"value":963},"DOCA_EXPERIMENTAL",{"type":48,"value":965},"), the GPI overlay on the cross-library\n",{"type":43,"tag":75,"props":967,"children":969},{"className":968},[],[970],{"type":48,"value":426},{"type":48,"value":972}," taxonomy, the observability surface (CUDA-side\nchannel polling, mmap-attach exchange), and the safety policy\nthat gates GPU-side RDMA initiation.",{"type":43,"tag":144,"props":974,"children":975},{},[976,981,983,989,991,997,998,1004,1005,1011,1012,1018,1019,1025,1026,1032,1033,1039,1041,1047],{"type":43,"tag":75,"props":977,"children":979},{"className":978},[],[980],{"type":48,"value":72},{"type":48,"value":982}," — step-by-step workflows for the eight in-scope\nverbs: ",{"type":43,"tag":75,"props":984,"children":986},{"className":985},[],[987],{"type":48,"value":988},"install",{"type":48,"value":990},", ",{"type":43,"tag":75,"props":992,"children":994},{"className":993},[],[995],{"type":48,"value":996},"configure",{"type":48,"value":990},{"type":43,"tag":75,"props":999,"children":1001},{"className":1000},[],[1002],{"type":48,"value":1003},"build",{"type":48,"value":990},{"type":43,"tag":75,"props":1006,"children":1008},{"className":1007},[],[1009],{"type":48,"value":1010},"modify",{"type":48,"value":990},{"type":43,"tag":75,"props":1013,"children":1015},{"className":1014},[],[1016],{"type":48,"value":1017},"run",{"type":48,"value":379},{"type":43,"tag":75,"props":1020,"children":1022},{"className":1021},[],[1023],{"type":48,"value":1024},"test",{"type":48,"value":990},{"type":43,"tag":75,"props":1027,"children":1029},{"className":1028},[],[1030],{"type":48,"value":1031},"debug",{"type":48,"value":990},{"type":43,"tag":75,"props":1034,"children":1036},{"className":1035},[],[1037],{"type":48,"value":1038},"use",{"type":48,"value":1040},". Plus a ",{"type":43,"tag":75,"props":1042,"children":1044},{"className":1043},[],[1045],{"type":48,"value":1046},"Deferred task verbs",{"type":48,"value":1048}," block that\npoints out-of-scope questions at the right next skill.",{"type":43,"tag":51,"props":1050,"children":1051},{},[1052,1054,1062],{"type":48,"value":1053},"The skill assumes a host where DOCA is already installed at the\nstandard location, a CUDA Toolkit compatible with the installed\nDOCA is present, and the user has the privileges their public\ninstall profile expects. It does not cover installing DOCA — that\npath goes through ",{"type":43,"tag":70,"props":1055,"children":1056},{"href":110},[1057],{"type":43,"tag":75,"props":1058,"children":1060},{"className":1059},[],[1061],{"type":48,"value":117},{"type":48,"value":239},{"type":43,"tag":121,"props":1064,"children":1066},{"id":1065},"what-this-skill-deliberately-does-not-ship",[1067],{"type":48,"value":1068},"What this skill deliberately does not ship",{"type":43,"tag":51,"props":1070,"children":1071},{},[1072,1074,1079],{"type":48,"value":1073},"This skill is ",{"type":43,"tag":55,"props":1075,"children":1076},{},[1077],{"type":48,"value":1078},"agent guidance",{"type":48,"value":1080},", not a samples or templates\nbundle. To keep the boundary clean, it deliberately does not\ncontain — and pull requests should not add:",{"type":43,"tag":140,"props":1082,"children":1083},{},[1084,1113,1160,1194],{"type":43,"tag":144,"props":1085,"children":1086},{},[1087,1092,1094,1104,1106,1111],{"type":43,"tag":55,"props":1088,"children":1089},{},[1090],{"type":48,"value":1091},"Pre-written DOCA GPI application source code, in any\nlanguage.",{"type":48,"value":1093}," The agent's job is to route the user to verified\nreference code (the shipped DOCA GPU-NetIO samples on the\ninstalled package set are the canonical worked examples for the\nGPU-side handoff) and to prescribe a minimum-diff modification\nvia the universal modify-a-sample workflow in\n",{"type":43,"tag":70,"props":1095,"children":1097},{"href":1096},"..\u002F..\u002Fdoca-programming-guide\u002FSKILL.md",[1098],{"type":43,"tag":75,"props":1099,"children":1101},{"className":1100},[],[1102],{"type":48,"value":1103},"doca-programming-guide",{"type":48,"value":1105},".\nBecause every GPI symbol is tagged ",{"type":43,"tag":75,"props":1107,"children":1109},{"className":1108},[],[1110],{"type":48,"value":963},{"type":48,"value":1112},"\nin the public header, the skill refuses to author GPI\nsource from documentation prose.",{"type":43,"tag":144,"props":1114,"children":1115},{},[1116,1121,1123,1129,1130,1136,1137,1143,1145,1150,1152,1158],{"type":43,"tag":55,"props":1117,"children":1118},{},[1119],{"type":48,"value":1120},"Standalone build manifests",{"type":48,"value":1122}," (",{"type":43,"tag":75,"props":1124,"children":1126},{"className":1125},[],[1127],{"type":48,"value":1128},"meson.build",{"type":48,"value":990},{"type":43,"tag":75,"props":1131,"children":1133},{"className":1132},[],[1134],{"type":48,"value":1135},"CMakeLists.txt",{"type":48,"value":379},{"type":43,"tag":75,"props":1138,"children":1140},{"className":1139},[],[1141],{"type":48,"value":1142},"Cargo.toml",{"type":48,"value":1144},", …) parked inside the skill. The agent constructs\nthe build manifest ",{"type":43,"tag":83,"props":1146,"children":1147},{},[1148],{"type":48,"value":1149},"in the user's project directory",{"type":48,"value":1151}," against\nthe user's installed DOCA, where ",{"type":43,"tag":75,"props":1153,"children":1155},{"className":1154},[],[1156],{"type":48,"value":1157},"pkg-config --modversion doca-gpi",{"type":48,"value":1159}," is the source of truth.",{"type":43,"tag":144,"props":1161,"children":1162},{},[1163,1168,1170,1178,1180,1185,1187,1192],{"type":43,"tag":55,"props":1164,"children":1165},{},[1166],{"type":48,"value":1167},"CUDA kernel templates.",{"type":48,"value":1169}," The CUDA-side surface is owned by\n",{"type":43,"tag":70,"props":1171,"children":1172},{"href":302},[1173],{"type":43,"tag":75,"props":1174,"children":1176},{"className":1175},[],[1177],{"type":48,"value":164},{"type":48,"value":1179},"; GPI's GPU-side\nhandle is ",{"type":43,"tag":83,"props":1181,"children":1182},{},[1183],{"type":48,"value":1184},"consumed by",{"type":48,"value":1186}," the CUDA programming model documented\nthere. This skill names the GPI-specific handoff (the\n",{"type":43,"tag":75,"props":1188,"children":1190},{"className":1189},[],[1191],{"type":48,"value":267},{"type":48,"value":1193}," type, the channel-connect call) but\ndoes not author CUDA kernels.",{"type":43,"tag":144,"props":1195,"children":1196},{},[1197,1225],{"type":43,"tag":55,"props":1198,"children":1199},{},[1200,1202,1208,1209,1215,1217,1223],{"type":48,"value":1201},"A ",{"type":43,"tag":75,"props":1203,"children":1205},{"className":1204},[],[1206],{"type":48,"value":1207},"samples\u002F",{"type":48,"value":990},{"type":43,"tag":75,"props":1210,"children":1212},{"className":1211},[],[1213],{"type":48,"value":1214},"bindings\u002F",{"type":48,"value":1216},", or ",{"type":43,"tag":75,"props":1218,"children":1220},{"className":1219},[],[1221],{"type":48,"value":1222},"reference\u002F",{"type":48,"value":1224}," subtree",{"type":48,"value":1226}," of any\nkind. A mock or incomplete artifact in this skill's tree, even\none labeled \"reference\", is misleading: users will read it as\nbuildable.",{"type":43,"tag":121,"props":1228,"children":1230},{"id":1229},"loading-order",[1231],{"type":48,"value":1232},"Loading order",{"type":43,"tag":1234,"props":1235,"children":1236},"ol",{},[1237,1250,1263],{"type":43,"tag":144,"props":1238,"children":1239},{},[1240,1242,1248],{"type":48,"value":1241},"Read this ",{"type":43,"tag":75,"props":1243,"children":1245},{"className":1244},[],[1246],{"type":48,"value":1247},"SKILL.md",{"type":48,"value":1249}," first to confirm the user's question is\nin scope.",{"type":43,"tag":144,"props":1251,"children":1252},{},[1253],{"type":43,"tag":55,"props":1254,"children":1255},{},[1256,1258,1262],{"type":48,"value":1257},"For the GPI object model, the GPU-side handoff pattern, the\ndomain and channel attribute objects, the version compatibility\nrule, the error taxonomy, observability, and safety policy, see\n",{"type":43,"tag":70,"props":1259,"children":1260},{"href":92},[1261],{"type":48,"value":92},{"type":48,"value":239},{"type":43,"tag":144,"props":1264,"children":1265},{},[1266],{"type":43,"tag":55,"props":1267,"children":1268},{},[1269,1271,1275],{"type":48,"value":1270},"For step-by-step workflows — install, configure, build,\nmodify, run, test, debug, use — see ",{"type":43,"tag":70,"props":1272,"children":1273},{"href":72},[1274],{"type":48,"value":72},{"type":48,"value":239},{"type":43,"tag":51,"props":1277,"children":1278},{},[1279,1281,1289],{"type":48,"value":1280},"Both companion files cross-link to each other and to\n",{"type":43,"tag":70,"props":1282,"children":1283},{"href":811},[1284],{"type":43,"tag":75,"props":1285,"children":1287},{"className":1286},[],[1288],{"type":48,"value":818},{"type":48,"value":1290},"\nwhenever the right answer is \"look it up in the public docs or\nthe installed package layout\" rather than \"GPI-specific\nguidance\".",{"type":43,"tag":121,"props":1292,"children":1294},{"id":1293},"related-skills",[1295],{"type":48,"value":1296},"Related skills",{"type":43,"tag":140,"props":1298,"children":1299},{},[1300,1361,1449,1464,1477,1497,1524,1537,1567,1598],{"type":43,"tag":144,"props":1301,"children":1302},{},[1303,1311,1313,1318,1320,1325,1327,1333,1335,1341,1343,1349,1351,1359],{"type":43,"tag":70,"props":1304,"children":1305},{"href":302},[1306],{"type":43,"tag":75,"props":1307,"children":1309},{"className":1308},[],[1310],{"type":48,"value":164},{"type":48,"value":1312}," — the GPU NetIO\nlibrary that exposes Send\u002FReceive-shaped Ethernet I\u002FO for CUDA\nkernels and ",{"type":43,"tag":55,"props":1314,"children":1315},{},[1316],{"type":48,"value":1317},"owns the GPU-side device surface GPI hands off\nto",{"type":48,"value":1319},": the ",{"type":43,"tag":75,"props":1321,"children":1323},{"className":1322},[],[1324],{"type":48,"value":267},{"type":48,"value":1326}," type and its device-side\n",{"type":43,"tag":75,"props":1328,"children":1330},{"className":1329},[],[1331],{"type":48,"value":1332},".cuh",{"type":48,"value":1334}," API live in doca-gpunetio, and ",{"type":43,"tag":75,"props":1336,"children":1338},{"className":1337},[],[1339],{"type":48,"value":1340},"doca_gpi.h",{"type":48,"value":1342}," includes\n",{"type":43,"tag":75,"props":1344,"children":1346},{"className":1345},[],[1347],{"type":48,"value":1348},"doca_gpunetio.h",{"type":48,"value":1350},". Both can coexist in the same application.\nThe selection table in\n",{"type":43,"tag":70,"props":1352,"children":1353},{"href":185},[1354],{"type":43,"tag":75,"props":1355,"children":1357},{"className":1356},[],[1358],{"type":48,"value":192},{"type":48,"value":1360},"\nis the load-bearing decision aid.",{"type":43,"tag":144,"props":1362,"children":1363},{},[1364,1372,1373,1381,1383,1389,1391,1396,1397,1402,1404,1409,1411,1417,1418,1424,1426,1432,1434,1440,1442,1447],{"type":43,"tag":70,"props":1365,"children":1366},{"href":929},[1367],{"type":43,"tag":75,"props":1368,"children":1370},{"className":1369},[],[1371],{"type":48,"value":936},{"type":48,"value":938},{"type":43,"tag":70,"props":1374,"children":1375},{"href":941},[1376],{"type":43,"tag":75,"props":1377,"children":1379},{"className":1378},[],[1380],{"type":48,"value":948},{"type":48,"value":1382}," — the transport and DPA\nlayers GPI builds on. ",{"type":43,"tag":75,"props":1384,"children":1386},{"className":1385},[],[1387],{"type":48,"value":1388},"dependencies\u002Fmeson.build",{"type":48,"value":1390}," lists\n",{"type":43,"tag":75,"props":1392,"children":1394},{"className":1393},[],[1395],{"type":48,"value":948},{"type":48,"value":990},{"type":43,"tag":75,"props":1398,"children":1400},{"className":1399},[],[1401],{"type":48,"value":164},{"type":48,"value":1403},", and ",{"type":43,"tag":75,"props":1405,"children":1407},{"className":1406},[],[1408],{"type":48,"value":936},{"type":48,"value":1410}," (plus the\n",{"type":43,"tag":75,"props":1412,"children":1414},{"className":1413},[],[1415],{"type":48,"value":1416},"libmlx5",{"type":48,"value":694},{"type":43,"tag":75,"props":1419,"children":1421},{"className":1420},[],[1422],{"type":48,"value":1423},"libibverbs",{"type":48,"value":1425}," externals); ",{"type":43,"tag":75,"props":1427,"children":1429},{"className":1428},[],[1430],{"type":48,"value":1431},"doca_gpi_get_dpa",{"type":48,"value":1433}," returns\nthe GPI-owned ",{"type":43,"tag":75,"props":1435,"children":1437},{"className":1436},[],[1438],{"type":48,"value":1439},"doca_dpa*",{"type":48,"value":1441}," for tuning DPA attributes. The RDMA\ntransport type, GID \u002F port selection, and permission semantics\nlive at the verbs layer; GPI consumes it rather than binding a\n",{"type":43,"tag":75,"props":1443,"children":1445},{"className":1444},[],[1446],{"type":48,"value":838},{"type":48,"value":1448}," queue.",{"type":43,"tag":144,"props":1450,"children":1451},{},[1452,1462],{"type":43,"tag":70,"props":1453,"children":1455},{"href":1454},"..\u002Fdoca-rdmi\u002FSKILL.md",[1456],{"type":43,"tag":75,"props":1457,"children":1459},{"className":1458},[],[1460],{"type":48,"value":1461},"doca-rdmi",{"type":48,"value":1463}," — the sister DPA-side\ninitiator surface. Both GPI and RDMI exist for \"drive RDMA\ninitiation from an accelerator without the host CPU on the\ndata path\"; GPI is the GPU case, RDMI is the DPA case.",{"type":43,"tag":144,"props":1465,"children":1466},{},[1467,1475],{"type":43,"tag":70,"props":1468,"children":1469},{"href":811},[1470],{"type":43,"tag":75,"props":1471,"children":1473},{"className":1472},[],[1474],{"type":48,"value":818},{"type":48,"value":1476}," — the\nrouting table for every public DOCA documentation source and\nthe on-disk layout of an installed DOCA package.",{"type":43,"tag":144,"props":1478,"children":1479},{},[1480,1488,1490,1495],{"type":43,"tag":70,"props":1481,"children":1482},{"href":110},[1483],{"type":43,"tag":75,"props":1484,"children":1486},{"className":1485},[],[1487],{"type":48,"value":117},{"type":48,"value":1489}," — env preparation,\ninstall verification, and the ",{"type":43,"tag":83,"props":1491,"children":1492},{},[1493],{"type":48,"value":1494},"I have no install yet",{"type":48,"value":1496}," path\nwith the public NGC DOCA container.",{"type":43,"tag":144,"props":1498,"children":1499},{},[1500,1508,1510,1515,1517,1522],{"type":43,"tag":70,"props":1501,"children":1502},{"href":1096},[1503],{"type":43,"tag":75,"props":1504,"children":1506},{"className":1505},[],[1507],{"type":48,"value":1103},{"type":48,"value":1509}," —\ngeneral DOCA programming patterns shared by every library: the\ncanonical ",{"type":43,"tag":75,"props":1511,"children":1513},{"className":1512},[],[1514],{"type":48,"value":548},{"type":48,"value":1516}," + meson build pattern, the universal\nmodify-a-shipped-sample first-app workflow, the universal\nCore-context lifecycle, the cross-library ",{"type":43,"tag":75,"props":1518,"children":1520},{"className":1519},[],[1521],{"type":48,"value":426},{"type":48,"value":1523},"\ntaxonomy. This skill layers GPI specifics on top.",{"type":43,"tag":144,"props":1525,"children":1526},{},[1527,1535],{"type":43,"tag":70,"props":1528,"children":1529},{"href":489},[1530],{"type":43,"tag":75,"props":1531,"children":1533},{"className":1532},[],[1534],{"type":48,"value":496},{"type":48,"value":1536}," — the cross-cutting\ndebug ladder (install \u002F version \u002F build \u002F link \u002F runtime \u002F\nprogram \u002F driver). GPI-specific debug overlays on top of it.",{"type":43,"tag":144,"props":1538,"children":1539},{},[1540,1550,1552,1558,1560,1565],{"type":43,"tag":70,"props":1541,"children":1543},{"href":1542},"..\u002F..\u002Fdoca-hardware-safety\u002FSKILL.md",[1544],{"type":43,"tag":75,"props":1545,"children":1547},{"className":1546},[],[1548],{"type":48,"value":1549},"doca-hardware-safety",{"type":48,"value":1551}," —\nthe bundle-wide hardware-safety meta-policy. The ",{"type":43,"tag":75,"props":1553,"children":1555},{"className":1554},[],[1556],{"type":48,"value":1557},"## Safety policy",{"type":48,"value":1559}," overlay in ",{"type":43,"tag":75,"props":1561,"children":1563},{"className":1562},[],[1564],{"type":48,"value":92},{"type":48,"value":1566}," cross-links it.",{"type":43,"tag":144,"props":1568,"children":1569},{},[1570,1580,1582,1588,1590,1596],{"type":43,"tag":70,"props":1571,"children":1573},{"href":1572},"..\u002F..\u002Fdoca-version\u002FSKILL.md",[1574],{"type":43,"tag":75,"props":1575,"children":1577},{"className":1576},[],[1578],{"type":48,"value":1579},"doca-version",{"type":48,"value":1581}," — the version\ndetection \u002F four-way match rule every per-artifact ",{"type":43,"tag":75,"props":1583,"children":1585},{"className":1584},[],[1586],{"type":48,"value":1587},"## Version compatibility",{"type":48,"value":1589}," anchor builds on. This skill quotes\nthe GPI-specific overlay only (DOCA-side ",{"type":43,"tag":75,"props":1591,"children":1593},{"className":1592},[],[1594],{"type":48,"value":1595},".pc",{"type":48,"value":1597}," PLUS the CUDA\nToolkit axis).",{"type":43,"tag":144,"props":1599,"children":1600},{},[1601,1611,1613,1619,1621,1626],{"type":43,"tag":70,"props":1602,"children":1604},{"href":1603},"..\u002F..\u002Fdoca-structured-tools-contract\u002FSKILL.md",[1605],{"type":43,"tag":75,"props":1606,"children":1608},{"className":1607},[],[1609],{"type":48,"value":1610},"doca-structured-tools-contract",{"type":48,"value":1612}," —\nthe JSON-schema contracts for the agent-preferred structured\nhelpers; the ",{"type":43,"tag":75,"props":1614,"children":1616},{"className":1615},[],[1617],{"type":48,"value":1618},"## Command appendix",{"type":48,"value":1620}," in ",{"type":43,"tag":75,"props":1622,"children":1624},{"className":1623},[],[1625],{"type":48,"value":72},{"type":48,"value":1627}," defers to\nthem before falling back to the manual chain.",{"items":1629,"total":1733},[1630,1647,1661,1675,1687,1704,1719],{"slug":1631,"name":1631,"fn":1632,"description":1633,"org":1634,"tags":1635,"stars":23,"repoUrl":24,"updatedAt":1646},"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},[1636,1639,1642,1643],{"name":1637,"slug":1638,"type":15},"Data Analysis","data-analysis",{"name":1640,"slug":1641,"type":15},"Data Engineering","data-engineering",{"name":9,"slug":8,"type":15},{"name":1644,"slug":1645,"type":15},"Performance","performance","2026-07-14T05:28:43.176466",{"slug":1648,"name":1648,"fn":1649,"description":1650,"org":1651,"tags":1652,"stars":23,"repoUrl":24,"updatedAt":1660},"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},[1653,1656,1659],{"name":1654,"slug":1655,"type":15},"Deployment","deployment",{"name":1657,"slug":1658,"type":15},"Infrastructure","infrastructure",{"name":9,"slug":8,"type":15},"2026-07-14T05:29:06.667109",{"slug":1662,"name":1662,"fn":1663,"description":1664,"org":1665,"tags":1666,"stars":23,"repoUrl":24,"updatedAt":1674},"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},[1667,1670,1671],{"name":1668,"slug":1669,"type":15},"Agents","agents",{"name":9,"slug":8,"type":15},{"name":1672,"slug":1673,"type":15},"Research","research","2026-07-14T05:28:06.816956",{"slug":1676,"name":1676,"fn":1677,"description":1678,"org":1679,"tags":1680,"stars":23,"repoUrl":24,"updatedAt":1686},"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},[1681,1682,1683],{"name":1637,"slug":1638,"type":15},{"name":9,"slug":8,"type":15},{"name":1684,"slug":1685,"type":15},"Testing","testing","2026-07-17T05:29:03.913266",{"slug":1688,"name":1688,"fn":1689,"description":1690,"org":1691,"tags":1692,"stars":23,"repoUrl":24,"updatedAt":1703},"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},[1693,1696,1699,1700],{"name":1694,"slug":1695,"type":15},"Automation","automation",{"name":1697,"slug":1698,"type":15},"Imaging","imaging",{"name":9,"slug":8,"type":15},{"name":1701,"slug":1702,"type":15},"Video","video","2026-07-17T05:28:53.905004",{"slug":1705,"name":1705,"fn":1706,"description":1707,"org":1708,"tags":1709,"stars":23,"repoUrl":24,"updatedAt":1718},"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},[1710,1711,1714,1715],{"name":1654,"slug":1655,"type":15},{"name":1712,"slug":1713,"type":15},"Docker","docker",{"name":9,"slug":8,"type":15},{"name":1716,"slug":1717,"type":15},"Operations","operations","2026-07-17T05:28:56.913999",{"slug":1720,"name":1720,"fn":1721,"description":1722,"org":1723,"tags":1724,"stars":23,"repoUrl":24,"updatedAt":1732},"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},[1725,1726,1729],{"name":9,"slug":8,"type":15},{"name":1727,"slug":1728,"type":15},"Quantum Computing","quantum-computing",{"name":1730,"slug":1731,"type":15},"Simulation","simulation","2026-07-14T05:26:58.898253",305,{"items":1735,"total":1886},[1736,1754,1770,1781,1793,1807,1820,1834,1845,1854,1868,1877],{"slug":1737,"name":1737,"fn":1738,"description":1739,"org":1740,"tags":1741,"stars":1751,"repoUrl":1752,"updatedAt":1753},"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},[1742,1745,1748],{"name":1743,"slug":1744,"type":15},"Documentation","documentation",{"name":1746,"slug":1747,"type":15},"MCP","mcp",{"name":1749,"slug":1750,"type":15},"Search","search",21777,"https:\u002F\u002Fgithub.com\u002FNVIDIA\u002FNemoClaw","2026-07-20T06:00:01.461044",{"slug":1755,"name":1755,"fn":1756,"description":1757,"org":1758,"tags":1759,"stars":1767,"repoUrl":1768,"updatedAt":1769},"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},[1760,1763,1764],{"name":1761,"slug":1762,"type":15},"Containers","containers",{"name":1654,"slug":1655,"type":15},{"name":1765,"slug":1766,"type":15},"Python","python",17049,"https:\u002F\u002Fgithub.com\u002FNVIDIA\u002FMegatron-LM","2026-07-27T06:06:11.249662",{"slug":1771,"name":1771,"fn":1772,"description":1773,"org":1774,"tags":1775,"stars":1767,"repoUrl":1768,"updatedAt":1780},"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},[1776,1779],{"name":1777,"slug":1778,"type":15},"CI\u002FCD","ci-cd",{"name":1654,"slug":1655,"type":15},"2026-07-14T05:25:59.97109",{"slug":1782,"name":1782,"fn":1783,"description":1784,"org":1785,"tags":1786,"stars":1767,"repoUrl":1768,"updatedAt":1792},"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},[1787,1788,1789],{"name":1777,"slug":1778,"type":15},{"name":1654,"slug":1655,"type":15},{"name":1790,"slug":1791,"type":15},"GitHub","github","2026-07-27T06:06:12.278222",{"slug":1794,"name":1794,"fn":1795,"description":1796,"org":1797,"tags":1798,"stars":1767,"repoUrl":1768,"updatedAt":1806},"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},[1799,1802,1803],{"name":1800,"slug":1801,"type":15},"Debugging","debugging",{"name":1790,"slug":1791,"type":15},{"name":1804,"slug":1805,"type":15},"Triage","triage","2026-07-14T05:25:57.442089",{"slug":1808,"name":1808,"fn":1809,"description":1810,"org":1811,"tags":1812,"stars":1767,"repoUrl":1768,"updatedAt":1819},"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},[1813,1816],{"name":1814,"slug":1815,"type":15},"Best Practices","best-practices",{"name":1817,"slug":1818,"type":15},"Code Analysis","code-analysis","2026-07-14T05:25:56.18433",{"slug":1821,"name":1821,"fn":1822,"description":1823,"org":1824,"tags":1825,"stars":1767,"repoUrl":1768,"updatedAt":1833},"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},[1826,1829,1832],{"name":1827,"slug":1828,"type":15},"Machine Learning","machine-learning",{"name":1830,"slug":1831,"type":15},"Migration","migration",{"name":9,"slug":8,"type":15},"2026-07-17T06:07:11.777011",{"slug":1835,"name":1835,"fn":1836,"description":1837,"org":1838,"tags":1839,"stars":1767,"repoUrl":1768,"updatedAt":1844},"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},[1840,1843],{"name":1841,"slug":1842,"type":15},"QA","qa",{"name":1684,"slug":1685,"type":15},"2026-07-14T05:25:53.673039",{"slug":1846,"name":1846,"fn":1847,"description":1848,"org":1849,"tags":1850,"stars":1767,"repoUrl":1768,"updatedAt":1853},"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},[1851,1852],{"name":1654,"slug":1655,"type":15},{"name":1657,"slug":1658,"type":15},"2026-07-14T05:25:49.362534",{"slug":1855,"name":1855,"fn":1856,"description":1857,"org":1858,"tags":1859,"stars":1767,"repoUrl":1768,"updatedAt":1867},"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},[1860,1863,1864],{"name":1861,"slug":1862,"type":15},"Code Review","code-review",{"name":1790,"slug":1791,"type":15},{"name":1865,"slug":1866,"type":15},"Pull Requests","pull-requests","2026-07-14T05:26:01.226578",{"slug":1869,"name":1869,"fn":1870,"description":1871,"org":1872,"tags":1873,"stars":1767,"repoUrl":1768,"updatedAt":1876},"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},[1874,1875],{"name":1841,"slug":1842,"type":15},{"name":1684,"slug":1685,"type":15},"2026-07-14T05:25:54.928983",{"slug":1878,"name":1878,"fn":1879,"description":1880,"org":1881,"tags":1882,"stars":1767,"repoUrl":1768,"updatedAt":1885},"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},[1883,1884],{"name":1694,"slug":1695,"type":15},{"name":1777,"slug":1778,"type":15},"2026-07-30T05:29:03.275638",496]