[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill-nvidia-doca-bench-extension":3,"mdc--uiyj5s-key":34,"related-repo-nvidia-doca-bench-extension":1618,"related-org-nvidia-doca-bench-extension":1724},{"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-bench-extension","build and debug custom doca-bench plugins","Use this skill when the operator is authoring, building, loading, or debugging a custom doca-bench plug-in — a versioned shared library with DOCA_EXPERIMENTAL-marked C entry points that doca-bench loads to measure a workload class its built-in modes do not cover, with doca_bench_cuda as the shipped reference exemplar. Trigger even when the user does not say \"doca-bench-extension\" or \"doca_bench_cuda\" — typical implicit phrasings include \"no built-in doca-bench mode fits my workload\", \"how do I benchmark a CUDA GPUNetIO RX\u002FTX kernel\", \"doca-bench cannot find or load my custom .so\", \"extension exported symbols do not match what the parent expects\", \"soversion mismatch after a DOCA upgrade\", or \"my GPU kernel hangs because stop_flag was never set\". Refuse and route elsewhere for questions about which built-in doca-bench mode to pick, DOCA GPUNetIO programming semantics, CUDA toolkit installation, or contributor work on in-tree extensions — 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},"Plugin Development","plugin-development","tag",{"name":9,"slug":8,"type":15},{"name":18,"slug":19,"type":15},"Engineering","engineering",{"name":21,"slug":22,"type":15},"Debugging","debugging",2473,"https:\u002F\u002Fgithub.com\u002FNVIDIA\u002Fskills","2026-07-20T06:24:00.618695","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-bench-extension","---\nlicense: Apache-2.0\nname: doca-bench-extension\ndescription: >\n  Use this skill when the operator is authoring, building, loading,\n  or debugging a custom doca-bench plug-in — a versioned shared\n  library with DOCA_EXPERIMENTAL-marked C entry points that\n  doca-bench loads to measure a workload class its built-in modes\n  do not cover, with doca_bench_cuda as the shipped reference\n  exemplar. Trigger even when the user does not say\n  \"doca-bench-extension\" or \"doca_bench_cuda\" — typical implicit\n  phrasings include \"no built-in doca-bench mode fits my workload\",\n  \"how do I benchmark a CUDA GPUNetIO RX\u002FTX kernel\", \"doca-bench\n  cannot find or load my custom .so\", \"extension exported symbols\n  do not match what the parent expects\", \"soversion mismatch after\n  a DOCA upgrade\", or \"my GPU kernel hangs because stop_flag was\n  never set\". Refuse and route elsewhere for questions about which\n  built-in doca-bench mode to pick, DOCA GPUNetIO programming\n  semantics, CUDA toolkit installation, or contributor work on\n  in-tree extensions — those belong to other skills.\nmetadata:\n  kind: tool\ncompatibility: >\n  Requires DOCA SDK installed at \u002Fopt\u002Fmellanox\u002Fdoca on Linux\n  (Ubuntu 22.04\u002F24.04 or RHEL\u002FSLES) with a BlueField DPU or\n  ConnectX NIC. Source tree: `\u002Fopt\u002Fmellanox\u002Fdoca\u002Ftools\u002Fbench_extension\u002F`\n  (underscored, NOT kebab-case); the built shared library\n  `libdoca_bench_cuda_impl.so` lands in the platform libdir on a\n  binary install. Also needs `pkg-config doca-common` and, for\n  the GPU-side reference exemplar (DOCA GPUNetIO RX\u002FTX kernels),\n  an NVIDIA GPU + matching CUDA toolkit.\n---\n\n# DOCA Bench Extension\n\n**Where to start:** This is a tool skill for the **extension \u002F\nplug-in framework** that augments\n[`doca-bench`](..\u002Fdoca-bench\u002FSKILL.md) — NOT a workload-shape\nskill on its own. Open [`TASKS.md`](TASKS.md) and start at\n[`## configure`](TASKS.md#configure) to commit to the three-axis\ndecision (workload class is genuinely outside doca-bench's\nbuilt-in modes × extension API surface fits × parent-tool\nco-load is acceptable), then [`## build`](TASKS.md#build) for\nhow a custom extension is compiled and laid out, then\n[`## run`](TASKS.md#run) for how `doca-bench` discovers and\ninvokes the extension, then [`## test`](TASKS.md#test) for the\nsmoke-before-bulk loop the agent applies to every new\nextension. Open [`CAPABILITIES.md`](CAPABILITIES.md) when the\nquestion is *what an extension can do that built-in\n`doca-bench` modes cannot*, *what the extension API surface\nlooks like in broad strokes (the `DOCA_EXPERIMENTAL` C entry\npoints the shipped reference exposes)*, *how the\nbuild \u002F registration \u002F discovery flow works*, or *how the\nextension's lifetime is bounded by the parent `doca-bench`\ninvocation*. If `doca-bench` itself is the question, route to\n[`doca-bench`](..\u002Fdoca-bench\u002FSKILL.md). If the question is\n\"which built-in `doca-bench` mode do I pick?\", that is also\n[`doca-bench`](..\u002Fdoca-bench\u002FSKILL.md) — extensions are the\n*exit ramp* for workloads built-in modes do not cover.\n\n## Example questions this skill answers well\n\n- *\"My workload class is `\u003CX>` — does `doca-bench` measure it\n  natively, or do I need an extension?\"* — the\n  extension-vs-built-in decision question. The agent walks\n  the user back to [`doca-bench`](..\u002Fdoca-bench\u002FSKILL.md)'s\n  built-in mode inventory FIRST and only routes to the\n  extension framework when no built-in mode applies.\n- *\"I want to benchmark a CUDA \u002F GPU-side workload that\n  drives DOCA GPUNetIO RX and TX queues. Where do I start?\n  Is there a reference extension I can copy?\"* — the agent\n  surfaces the shipped `doca_bench_cuda` extension under\n  `\u002Fopt\u002Fmellanox\u002Fdoca\u002Ftools\u002Fbench_extension\u002Fdoca_bench_cuda\u002F` as the\n  reference exemplar and walks the operator through its\n  API surface and build shape.\n- *\"How does `doca-bench` actually discover and load my\n  custom extension at runtime? Is it a versioned shared\n  library? What does my entry-point need to look like?\"* —\n  the build \u002F registration \u002F discovery flow question. The\n  agent walks the Meson-built shared library shape, the\n  versioning, and the parent-tool's runtime discovery path\n  (which the agent does NOT invent from memory — the\n  shipped extension's `meson.build` and the public DOCA Bench\n  documentation on `docs.nvidia.com` are the source of\n  truth).\n- *\"The API headers I have are marked `DOCA_EXPERIMENTAL`.\n  What does that mean for my extension's stability across\n  DOCA releases? Am I going to have to rebuild it every\n  release?\"* — the experimental-surface and version\n  compatibility question.\n- *\"Once I build my extension, what is the cheapest possible\n  smoke I can run before pointing my real workload at it?\n  How do I know `doca-bench` actually loaded it, called\n  into it, and that the call returned the data the parent\n  tool expected?\"* — the smoke-before-bulk question.\n- *\"My custom extension builds, but `doca-bench` says it\n  cannot find \u002F load \u002F call it. Where do I look first?\"* —\n  the layered-debug question that distinguishes\n  build-failures, load-failures, registration-mismatches,\n  and runtime-call-failures.\n\n## Audience\n\nExperienced AI agents and platform \u002F performance engineers\nwho already use [`doca-bench`](..\u002Fdoca-bench\u002FSKILL.md) for\nthe built-in workload modes and now have a workload class\nthat the built-in modes do not cover. Readers are expected\nto be comfortable with native build systems (Meson, in this\ncodebase), shared-library packaging on Linux, and the\n`DOCA_EXPERIMENTAL` API stability contract. If the user\nasks about GPU-side benchmarking via the shipped\n`doca_bench_cuda` reference extension, the reader is also\nexpected to be familiar with DOCA GPUNetIO and CUDA toolchain\nbasics — those domains live in their own skills, not here.\n\nThis skill is NOT for:\n\n- operators who can express their workload with one of\n  `doca-bench`'s built-in modes — that is\n  [`doca-bench`](..\u002Fdoca-bench\u002FSKILL.md);\n- operators who want to benchmark a different DOCA primitive\n  (Flow, Comch, RMAX) via that primitive's own\n  measurement tool — route to that tool;\n- contributors authoring or modifying the in-tree extensions\n  themselves (this skill is for external operators consuming\n  the framework, not for internal DOCA contributors).\n\n## Language scope\n\nA `doca-bench` extension surfaces as:\n\n1. A **versioned shared library** on Linux (`.so` with\n   `soversion` matching the DOCA release), built via the\n   `doca-bench-extension` Meson rules in the shipped\n   `\u002Fopt\u002Fmellanox\u002Fdoca\u002Ftools\u002Fbench_extension\u002Fmeson.build` and the\n   per-extension subdirectory (the reference exemplar is\n   `doca_bench_cuda\u002F`).\n2. A small set of **`DOCA_EXPERIMENTAL`-marked C entry\n   points** that the parent `doca-bench` invokes — i.e. the\n   API surface declared in the extension's header file.\n   The shipped `doca_bench_cuda\u002Fdoca_bench_cuda.h` is the\n   reference for what that surface shape looks like in\n   practice (`*_init`, `*_device_query`,\n   `*_device_synchronize`, and per-workload kernel-start\n   entry points such as `*_start_nop_kernel`,\n   `*_start_eth_recv_kernel`, `*_start_eth_send_kernel`,\n   `*_start_eth_bidir_kernel`).\n3. A set of **per-workload settings structs** that the\n   parent passes through (e.g. the reference exemplar's\n   `doca_bench_cuda_kernel_settings`,\n   `doca_bench_cuda_eth_rx_kernel_settings`,\n   `doca_bench_cuda_eth_tx_kernel_settings`,\n   `doca_bench_cuda_eth_bidir_kernel_settings` carry block\n   counts, threads-per-block, RX \u002F TX queues, buffer\n   address \u002F mkey \u002F size, a stop flag, and a stats\n   pointer).\n\nThe skill itself is Markdown. The user's extension source\nis whatever language the workload requires (C \u002F C++ \u002F CUDA\nin the reference case). The agent does NOT prescribe a\nlanguage beyond what the shipped reference demonstrates.\n\n## When to load this skill\n\nLoad `doca-bench-extension` when ANY of the following is\ntrue:\n\n- the user explicitly mentions `doca-bench-extension`, the\n  `doca_bench_cuda` reference extension, the\n  `doca_bench_cuda_impl` shared library, or any of the\n  `DOCA_EXPERIMENTAL` extension entry points;\n- the user has confirmed (via\n  [`doca-bench TASKS.md ## configure`](..\u002Fdoca-bench\u002FTASKS.md#configure))\n  that none of `doca-bench`'s built-in workload modes\n  measures the class they want, and an extension is the\n  exit ramp;\n- the user wants to copy \u002F extend the shipped\n  `doca_bench_cuda` reference into a custom GPU-side\n  workload extension;\n- the user is debugging why `doca-bench` cannot find \u002F load\n  \u002F call a custom extension they built.\n\nCo-load this skill with:\n\n- [`doca-bench`](..\u002Fdoca-bench\u002FSKILL.md) (the parent tool —\n  ALWAYS co-loaded; extensions only have value as\n  plug-ins into `doca-bench`);\n- [`doca-version`](..\u002F..\u002Fdoca-version\u002FSKILL.md) (the\n  `DOCA_EXPERIMENTAL` surface is versioned with DOCA; the\n  extension's `soversion` is the DOCA `soversion`; the\n  four-way version match applies);\n- [`doca-gpunetio`](..\u002F..\u002Flibs\u002Fdoca-gpunetio\u002FSKILL.md) when\n  the extension is GPU-side and uses GPUNetIO RX \u002F TX\n  queues like the reference exemplar (route the GPUNetIO\n  semantics there, not here);\n- [`doca-debug`](..\u002F..\u002Fdoca-debug\u002FSKILL.md) and\n  [`doca-setup`](..\u002F..\u002Fdoca-setup\u002FSKILL.md) for the\n  env-side debug ladder (driver, firmware, CUDA toolkit,\n  dynamic linker).\n\nDo NOT load this skill when the user's workload fits a\n`doca-bench` built-in mode — extensions add cost (build\ntoolchain, version churn, the experimental-surface\ncontract); the built-in modes are always the first answer to\ntry.\n\n## What this skill provides\n\nThree companion files in this directory, each owning a\ndifferent question shape:\n\n- [`SKILL.md`](SKILL.md) — this file. Audience, scope,\n  loading order, related skills. Routes everything else.\n- [`CAPABILITIES.md`](CAPABILITIES.md) — *what an extension\n  can do that the built-in modes cannot*, *what the API\n  surface looks like in broad strokes*, *how the\n  build \u002F registration \u002F discovery flow works*, *what\n  versions it ships in (including the\n  `DOCA_EXPERIMENTAL`-stability overlay on top of\n  `doca-version`)*, *the layered error taxonomy*,\n  observability, and the safety policy overlay.\n- [`TASKS.md`](TASKS.md) — the procedural verbs\n  (`configure`, `build`, `run`, `test`, `debug`, etc.) plus\n  a `doca-bench-extension`-specific command appendix and\n  the agent-side `use` workflow that consumes the captured\n  extension run.\n\nThe combined skill teaches an AI agent to drive the\n*extension-author-and-wire-in class* of `doca-bench`\nquestions: confirm an extension is needed at all; locate\nthe shipped reference exemplar\n(`\u002Fopt\u002Fmellanox\u002Fdoca\u002Ftools\u002Fbench_extension\u002Fdoca_bench_cuda\u002F`); copy\nits build + API surface shape; build a versioned shared\nlibrary that matches the DOCA release; smoke that the\nparent `doca-bench` actually loads it; diagnose layered\nfailures when it does not.\n\n## What this skill deliberately does not ship\n\n- **Inventory of `doca-bench`'s built-in workload modes.**\n  That belongs to [`doca-bench`](..\u002Fdoca-bench\u002FSKILL.md).\n  This skill is the exit ramp for what the built-in modes\n  do not cover; it does not duplicate the parent's mode\n  inventory.\n- **Invented `DOCA_EXPERIMENTAL` entry-point names beyond\n  what the shipped reference declares.** The shipped\n  `doca_bench_cuda\u002Fdoca_bench_cuda.h` on the user's\n  install is the reference for what the surface shape\n  looks like; the agent does not assert other extensions\n  exist with specific signatures.\n- **A canonical \"right\" extension layout.** The shipped\n  `doca_bench_cuda` reference IS the canonical layout;\n  rewriting it here would drift from the source of truth.\n  The agent points the operator at the shipped tree and\n  walks the operator through *adapting* it.\n- **A documented runtime discovery mechanism the agent\n  invents.** The exact mechanism `doca-bench` uses to\n  locate and load extensions (search path, naming\n  convention, registration call) lives in the public DOCA\n  Bench documentation on `docs.nvidia.com` and the\n  installed `doca-bench` binary. The agent points the\n  operator there rather than asserting a mechanism from\n  memory.\n- **DOCA GPUNetIO programming details.** When the\n  extension is GPU-side (as the reference exemplar is),\n  the GPUNetIO RX \u002F TX queue semantics live in\n  [`doca-gpunetio`](..\u002F..\u002Flibs\u002Fdoca-gpunetio\u002FSKILL.md);\n  this skill cross-links rather than duplicates.\n- **CUDA toolchain installation guidance.** Route to the\n  public NVIDIA CUDA Toolkit documentation on\n  `docs.nvidia.com`; this skill does not duplicate it.\n- **Library-internal `doca-bench` invocation details\n  unrelated to extensions.** The parent's CLI flags,\n  pipeline shapes, and built-in workload classes belong\n  to [`doca-bench`](..\u002Fdoca-bench\u002FSKILL.md).\n\n## Loading order\n\nWhen a `doca-bench-extension` question arrives:\n\n1. Confirm DOCA is installed AND `doca-bench` is reachable\n   on the user's install — if not, route to\n   [`doca-setup`](..\u002F..\u002Fdoca-setup\u002FSKILL.md);\n2. **Confirm none of `doca-bench`'s built-in modes covers\n   the workload class** — if any of them does, route back\n   to [`doca-bench TASKS.md ## configure`](..\u002Fdoca-bench\u002FTASKS.md#configure)\n   and stop. Extensions are the exit ramp, not the first\n   answer;\n3. Read [`CAPABILITIES.md`](CAPABILITIES.md) to commit to\n   the three-axis decision and walk the reference\n   exemplar's API surface shape;\n4. Read [`TASKS.md`](TASKS.md) and walk\n   `## configure → ## build → ## run → ## test → ## debug`\n   in that order; do NOT start with `## run` without the\n   build precondition step.\n\n## Related skills\n\nCross-link conventions follow the bundle's relative path\ncontract from `tools\u002F\u003CX>\u002F`:\n\n- [`doca-bench`](..\u002Fdoca-bench\u002FSKILL.md) — the parent tool.\n  **ALWAYS co-loaded.** Extensions are plug-ins into\n  `doca-bench`; they do not replace it, they do not have a\n  standalone CLI, they do not measure anything without the\n  parent invoking them. Every question on this skill\n  presupposes the parent.\n- [`doca-version`](..\u002F..\u002Fdoca-version\u002FSKILL.md) — the\n  `DOCA_EXPERIMENTAL` surface is versioned with DOCA; the\n  extension's `soversion` matches the DOCA release per\n  the shipped `meson.build`. The four-way version match\n  applies; rebuilding the extension across DOCA upgrades\n  is the rule, not the exception.\n- [`doca-gpunetio`](..\u002F..\u002Flibs\u002Fdoca-gpunetio\u002FSKILL.md) —\n  when the extension is GPU-side and uses GPUNetIO RX \u002F\n  TX queues like the reference `doca_bench_cuda`. Route\n  the GPUNetIO semantics there.\n- [`doca-setup`](..\u002F..\u002Fdoca-setup\u002FSKILL.md) — DOCA install\n  posture (does `doca-bench` exist? does the\n  `doca_bench_cuda_impl` reference library exist? is the\n  CUDA toolchain installed when needed?).\n- [`doca-debug`](..\u002F..\u002Fdoca-debug\u002FSKILL.md) — the\n  cross-cutting debug ladder for env-side issues (dynamic\n  linker, library search path, CUDA driver \u002F toolkit,\n  firmware).\n- [`doca-public-knowledge-map`](..\u002F..\u002Fdoca-public-knowledge-map\u002FSKILL.md)\n  — routing to the public DOCA Bench \u002F DOCA GPUNetIO pages\n  on `docs.nvidia.com` and the release notes for the\n  documented extension lifecycle \u002F discovery mechanism.\n- [`doca-structured-tools-contract`](..\u002F..\u002Fdoca-structured-tools-contract\u002FSKILL.md)\n  — the agent's detect → prefer → fall back → report\n  contract for the structured helpers\n  (`doca-env --json`, `doca-capability-snapshot`,\n  `version-matrix.json`) the build \u002F load preconditions\n  rely on.\n- [`doca-hardware-safety`](..\u002F..\u002Fdoca-hardware-safety\u002FSKILL.md)\n  — the canonical hardware-safety meta-policy that\n  [`CAPABILITIES.md ## Safety policy`](CAPABILITIES.md#safety-policy)\n  overlays. Extensions are external code loaded into\n  `doca-bench`; the safety implications of loading\n  experimental code into a benchmark that touches the\n  dataplane \u002F device are real.\n\nThis skill assumes the user has built shared libraries on\nLinux before and knows what a Meson build is. Background\nmaterial on those topics belongs in the toolchain docs, not\nin this skill.\n",{"data":35,"body":39},{"license":26,"name":4,"description":6,"metadata":36,"compatibility":38},{"kind":37},"tool","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. Source tree: `\u002Fopt\u002Fmellanox\u002Fdoca\u002Ftools\u002Fbench_extension\u002F` (underscored, NOT kebab-case); the built shared library `libdoca_bench_cuda_impl.so` lands in the platform libdir on a binary install. Also needs `pkg-config doca-common` and, for the GPU-side reference exemplar (DOCA GPUNetIO RX\u002FTX kernels), an NVIDIA GPU + matching CUDA toolkit.\n",{"type":40,"children":41},"root",[42,50,251,258,408,414,443,448,483,489,501,679,684,690,702,787,792,893,905,911,916,1054,1087,1093,1265,1271,1283,1378,1384,1397,1613],{"type":43,"tag":44,"props":45,"children":46},"element","h1",{"id":4},[47],{"type":48,"value":49},"text","DOCA Bench Extension",{"type":43,"tag":51,"props":52,"children":53},"p",{},[54,60,62,67,69,81,83,92,94,104,106,116,118,128,130,135,137,147,149,158,160,173,175,188,189,194,196,208,210,215,217,225,227,232,234,242,244,249],{"type":43,"tag":55,"props":56,"children":57},"strong",{},[58],{"type":48,"value":59},"Where to start:",{"type":48,"value":61}," This is a tool skill for the ",{"type":43,"tag":55,"props":63,"children":64},{},[65],{"type":48,"value":66},"extension \u002F\nplug-in framework",{"type":48,"value":68}," that augments\n",{"type":43,"tag":70,"props":71,"children":73},"a",{"href":72},"..\u002Fdoca-bench\u002FSKILL.md",[74],{"type":43,"tag":75,"props":76,"children":78},"code",{"className":77},[],[79],{"type":48,"value":80},"doca-bench",{"type":48,"value":82}," — NOT a workload-shape\nskill on its own. Open ",{"type":43,"tag":70,"props":84,"children":86},{"href":85},"TASKS.md",[87],{"type":43,"tag":75,"props":88,"children":90},{"className":89},[],[91],{"type":48,"value":85},{"type":48,"value":93}," and start at\n",{"type":43,"tag":70,"props":95,"children":97},{"href":96},"TASKS.md#configure",[98],{"type":43,"tag":75,"props":99,"children":101},{"className":100},[],[102],{"type":48,"value":103},"## configure",{"type":48,"value":105}," to commit to the three-axis\ndecision (workload class is genuinely outside doca-bench's\nbuilt-in modes × extension API surface fits × parent-tool\nco-load is acceptable), then ",{"type":43,"tag":70,"props":107,"children":109},{"href":108},"TASKS.md#build",[110],{"type":43,"tag":75,"props":111,"children":113},{"className":112},[],[114],{"type":48,"value":115},"## build",{"type":48,"value":117}," for\nhow a custom extension is compiled and laid out, then\n",{"type":43,"tag":70,"props":119,"children":121},{"href":120},"TASKS.md#run",[122],{"type":43,"tag":75,"props":123,"children":125},{"className":124},[],[126],{"type":48,"value":127},"## run",{"type":48,"value":129}," for how ",{"type":43,"tag":75,"props":131,"children":133},{"className":132},[],[134],{"type":48,"value":80},{"type":48,"value":136}," discovers and\ninvokes the extension, then ",{"type":43,"tag":70,"props":138,"children":140},{"href":139},"TASKS.md#test",[141],{"type":43,"tag":75,"props":142,"children":144},{"className":143},[],[145],{"type":48,"value":146},"## test",{"type":48,"value":148}," for the\nsmoke-before-bulk loop the agent applies to every new\nextension. Open ",{"type":43,"tag":70,"props":150,"children":152},{"href":151},"CAPABILITIES.md",[153],{"type":43,"tag":75,"props":154,"children":156},{"className":155},[],[157],{"type":48,"value":151},{"type":48,"value":159}," when the\nquestion is ",{"type":43,"tag":161,"props":162,"children":163},"em",{},[164,166,171],{"type":48,"value":165},"what an extension can do that built-in\n",{"type":43,"tag":75,"props":167,"children":169},{"className":168},[],[170],{"type":48,"value":80},{"type":48,"value":172}," modes cannot",{"type":48,"value":174},", ",{"type":43,"tag":161,"props":176,"children":177},{},[178,180,186],{"type":48,"value":179},"what the extension API surface\nlooks like in broad strokes (the ",{"type":43,"tag":75,"props":181,"children":183},{"className":182},[],[184],{"type":48,"value":185},"DOCA_EXPERIMENTAL",{"type":48,"value":187}," C entry\npoints the shipped reference exposes)",{"type":48,"value":174},{"type":43,"tag":161,"props":190,"children":191},{},[192],{"type":48,"value":193},"how the\nbuild \u002F registration \u002F discovery flow works",{"type":48,"value":195},", or ",{"type":43,"tag":161,"props":197,"children":198},{},[199,201,206],{"type":48,"value":200},"how the\nextension's lifetime is bounded by the parent ",{"type":43,"tag":75,"props":202,"children":204},{"className":203},[],[205],{"type":48,"value":80},{"type":48,"value":207},"\ninvocation",{"type":48,"value":209},". If ",{"type":43,"tag":75,"props":211,"children":213},{"className":212},[],[214],{"type":48,"value":80},{"type":48,"value":216}," itself is the question, route to\n",{"type":43,"tag":70,"props":218,"children":219},{"href":72},[220],{"type":43,"tag":75,"props":221,"children":223},{"className":222},[],[224],{"type":48,"value":80},{"type":48,"value":226},". If the question is\n\"which built-in ",{"type":43,"tag":75,"props":228,"children":230},{"className":229},[],[231],{"type":48,"value":80},{"type":48,"value":233}," mode do I pick?\", that is also\n",{"type":43,"tag":70,"props":235,"children":236},{"href":72},[237],{"type":43,"tag":75,"props":238,"children":240},{"className":239},[],[241],{"type":48,"value":80},{"type":48,"value":243}," — extensions are the\n",{"type":43,"tag":161,"props":245,"children":246},{},[247],{"type":48,"value":248},"exit ramp",{"type":48,"value":250}," for workloads built-in modes do not cover.",{"type":43,"tag":252,"props":253,"children":255},"h2",{"id":254},"example-questions-this-skill-answers-well",[256],{"type":48,"value":257},"Example questions this skill answers well",{"type":43,"tag":259,"props":260,"children":261},"ul",{},[262,298,324,357,374,391],{"type":43,"tag":263,"props":264,"children":265},"li",{},[266,286,288,296],{"type":43,"tag":161,"props":267,"children":268},{},[269,271,277,279,284],{"type":48,"value":270},"\"My workload class is ",{"type":43,"tag":75,"props":272,"children":274},{"className":273},[],[275],{"type":48,"value":276},"\u003CX>",{"type":48,"value":278}," — does ",{"type":43,"tag":75,"props":280,"children":282},{"className":281},[],[283],{"type":48,"value":80},{"type":48,"value":285}," measure it\nnatively, or do I need an extension?\"",{"type":48,"value":287}," — the\nextension-vs-built-in decision question. The agent walks\nthe user back to ",{"type":43,"tag":70,"props":289,"children":290},{"href":72},[291],{"type":43,"tag":75,"props":292,"children":294},{"className":293},[],[295],{"type":48,"value":80},{"type":48,"value":297},"'s\nbuilt-in mode inventory FIRST and only routes to the\nextension framework when no built-in mode applies.",{"type":43,"tag":263,"props":299,"children":300},{},[301,306,308,314,316,322],{"type":43,"tag":161,"props":302,"children":303},{},[304],{"type":48,"value":305},"\"I want to benchmark a CUDA \u002F GPU-side workload that\ndrives DOCA GPUNetIO RX and TX queues. Where do I start?\nIs there a reference extension I can copy?\"",{"type":48,"value":307}," — the agent\nsurfaces the shipped ",{"type":43,"tag":75,"props":309,"children":311},{"className":310},[],[312],{"type":48,"value":313},"doca_bench_cuda",{"type":48,"value":315}," extension under\n",{"type":43,"tag":75,"props":317,"children":319},{"className":318},[],[320],{"type":48,"value":321},"\u002Fopt\u002Fmellanox\u002Fdoca\u002Ftools\u002Fbench_extension\u002Fdoca_bench_cuda\u002F",{"type":48,"value":323}," as the\nreference exemplar and walks the operator through its\nAPI surface and build shape.",{"type":43,"tag":263,"props":325,"children":326},{},[327,339,341,347,349,355],{"type":43,"tag":161,"props":328,"children":329},{},[330,332,337],{"type":48,"value":331},"\"How does ",{"type":43,"tag":75,"props":333,"children":335},{"className":334},[],[336],{"type":48,"value":80},{"type":48,"value":338}," actually discover and load my\ncustom extension at runtime? Is it a versioned shared\nlibrary? What does my entry-point need to look like?\"",{"type":48,"value":340}," —\nthe build \u002F registration \u002F discovery flow question. The\nagent walks the Meson-built shared library shape, the\nversioning, and the parent-tool's runtime discovery path\n(which the agent does NOT invent from memory — the\nshipped extension's ",{"type":43,"tag":75,"props":342,"children":344},{"className":343},[],[345],{"type":48,"value":346},"meson.build",{"type":48,"value":348}," and the public DOCA Bench\ndocumentation on ",{"type":43,"tag":75,"props":350,"children":352},{"className":351},[],[353],{"type":48,"value":354},"docs.nvidia.com",{"type":48,"value":356}," are the source of\ntruth).",{"type":43,"tag":263,"props":358,"children":359},{},[360,372],{"type":43,"tag":161,"props":361,"children":362},{},[363,365,370],{"type":48,"value":364},"\"The API headers I have are marked ",{"type":43,"tag":75,"props":366,"children":368},{"className":367},[],[369],{"type":48,"value":185},{"type":48,"value":371},".\nWhat does that mean for my extension's stability across\nDOCA releases? Am I going to have to rebuild it every\nrelease?\"",{"type":48,"value":373}," — the experimental-surface and version\ncompatibility question.",{"type":43,"tag":263,"props":375,"children":376},{},[377,389],{"type":43,"tag":161,"props":378,"children":379},{},[380,382,387],{"type":48,"value":381},"\"Once I build my extension, what is the cheapest possible\nsmoke I can run before pointing my real workload at it?\nHow do I know ",{"type":43,"tag":75,"props":383,"children":385},{"className":384},[],[386],{"type":48,"value":80},{"type":48,"value":388}," actually loaded it, called\ninto it, and that the call returned the data the parent\ntool expected?\"",{"type":48,"value":390}," — the smoke-before-bulk question.",{"type":43,"tag":263,"props":392,"children":393},{},[394,406],{"type":43,"tag":161,"props":395,"children":396},{},[397,399,404],{"type":48,"value":398},"\"My custom extension builds, but ",{"type":43,"tag":75,"props":400,"children":402},{"className":401},[],[403],{"type":48,"value":80},{"type":48,"value":405}," says it\ncannot find \u002F load \u002F call it. Where do I look first?\"",{"type":48,"value":407}," —\nthe layered-debug question that distinguishes\nbuild-failures, load-failures, registration-mismatches,\nand runtime-call-failures.",{"type":43,"tag":252,"props":409,"children":411},{"id":410},"audience",[412],{"type":48,"value":413},"Audience",{"type":43,"tag":51,"props":415,"children":416},{},[417,419,427,429,434,436,441],{"type":48,"value":418},"Experienced AI agents and platform \u002F performance engineers\nwho already use ",{"type":43,"tag":70,"props":420,"children":421},{"href":72},[422],{"type":43,"tag":75,"props":423,"children":425},{"className":424},[],[426],{"type":48,"value":80},{"type":48,"value":428}," for\nthe built-in workload modes and now have a workload class\nthat the built-in modes do not cover. Readers are expected\nto be comfortable with native build systems (Meson, in this\ncodebase), shared-library packaging on Linux, and the\n",{"type":43,"tag":75,"props":430,"children":432},{"className":431},[],[433],{"type":48,"value":185},{"type":48,"value":435}," API stability contract. If the user\nasks about GPU-side benchmarking via the shipped\n",{"type":43,"tag":75,"props":437,"children":439},{"className":438},[],[440],{"type":48,"value":313},{"type":48,"value":442}," reference extension, the reader is also\nexpected to be familiar with DOCA GPUNetIO and CUDA toolchain\nbasics — those domains live in their own skills, not here.",{"type":43,"tag":51,"props":444,"children":445},{},[446],{"type":48,"value":447},"This skill is NOT for:",{"type":43,"tag":259,"props":449,"children":450},{},[451,473,478],{"type":43,"tag":263,"props":452,"children":453},{},[454,456,461,463,471],{"type":48,"value":455},"operators who can express their workload with one of\n",{"type":43,"tag":75,"props":457,"children":459},{"className":458},[],[460],{"type":48,"value":80},{"type":48,"value":462},"'s built-in modes — that is\n",{"type":43,"tag":70,"props":464,"children":465},{"href":72},[466],{"type":43,"tag":75,"props":467,"children":469},{"className":468},[],[470],{"type":48,"value":80},{"type":48,"value":472},";",{"type":43,"tag":263,"props":474,"children":475},{},[476],{"type":48,"value":477},"operators who want to benchmark a different DOCA primitive\n(Flow, Comch, RMAX) via that primitive's own\nmeasurement tool — route to that tool;",{"type":43,"tag":263,"props":479,"children":480},{},[481],{"type":48,"value":482},"contributors authoring or modifying the in-tree extensions\nthemselves (this skill is for external operators consuming\nthe framework, not for internal DOCA contributors).",{"type":43,"tag":252,"props":484,"children":486},{"id":485},"language-scope",[487],{"type":48,"value":488},"Language scope",{"type":43,"tag":51,"props":490,"children":491},{},[492,494,499],{"type":48,"value":493},"A ",{"type":43,"tag":75,"props":495,"children":497},{"className":496},[],[498],{"type":48,"value":80},{"type":48,"value":500}," extension surfaces as:",{"type":43,"tag":502,"props":503,"children":504},"ol",{},[505,555,638],{"type":43,"tag":263,"props":506,"children":507},{},[508,509,514,516,522,524,530,532,537,539,545,547,553],{"type":48,"value":493},{"type":43,"tag":55,"props":510,"children":511},{},[512],{"type":48,"value":513},"versioned shared library",{"type":48,"value":515}," on Linux (",{"type":43,"tag":75,"props":517,"children":519},{"className":518},[],[520],{"type":48,"value":521},".so",{"type":48,"value":523}," with\n",{"type":43,"tag":75,"props":525,"children":527},{"className":526},[],[528],{"type":48,"value":529},"soversion",{"type":48,"value":531}," matching the DOCA release), built via the\n",{"type":43,"tag":75,"props":533,"children":535},{"className":534},[],[536],{"type":48,"value":4},{"type":48,"value":538}," Meson rules in the shipped\n",{"type":43,"tag":75,"props":540,"children":542},{"className":541},[],[543],{"type":48,"value":544},"\u002Fopt\u002Fmellanox\u002Fdoca\u002Ftools\u002Fbench_extension\u002Fmeson.build",{"type":48,"value":546}," and the\nper-extension subdirectory (the reference exemplar is\n",{"type":43,"tag":75,"props":548,"children":550},{"className":549},[],[551],{"type":48,"value":552},"doca_bench_cuda\u002F",{"type":48,"value":554},").",{"type":43,"tag":263,"props":556,"children":557},{},[558,560,570,572,577,579,585,587,593,594,600,602,608,610,616,617,623,624,630,631,637],{"type":48,"value":559},"A small set of ",{"type":43,"tag":55,"props":561,"children":562},{},[563,568],{"type":43,"tag":75,"props":564,"children":566},{"className":565},[],[567],{"type":48,"value":185},{"type":48,"value":569},"-marked C entry\npoints",{"type":48,"value":571}," that the parent ",{"type":43,"tag":75,"props":573,"children":575},{"className":574},[],[576],{"type":48,"value":80},{"type":48,"value":578}," invokes — i.e. the\nAPI surface declared in the extension's header file.\nThe shipped ",{"type":43,"tag":75,"props":580,"children":582},{"className":581},[],[583],{"type":48,"value":584},"doca_bench_cuda\u002Fdoca_bench_cuda.h",{"type":48,"value":586}," is the\nreference for what that surface shape looks like in\npractice (",{"type":43,"tag":75,"props":588,"children":590},{"className":589},[],[591],{"type":48,"value":592},"*_init",{"type":48,"value":174},{"type":43,"tag":75,"props":595,"children":597},{"className":596},[],[598],{"type":48,"value":599},"*_device_query",{"type":48,"value":601},",\n",{"type":43,"tag":75,"props":603,"children":605},{"className":604},[],[606],{"type":48,"value":607},"*_device_synchronize",{"type":48,"value":609},", and per-workload kernel-start\nentry points such as ",{"type":43,"tag":75,"props":611,"children":613},{"className":612},[],[614],{"type":48,"value":615},"*_start_nop_kernel",{"type":48,"value":601},{"type":43,"tag":75,"props":618,"children":620},{"className":619},[],[621],{"type":48,"value":622},"*_start_eth_recv_kernel",{"type":48,"value":174},{"type":43,"tag":75,"props":625,"children":627},{"className":626},[],[628],{"type":48,"value":629},"*_start_eth_send_kernel",{"type":48,"value":601},{"type":43,"tag":75,"props":632,"children":634},{"className":633},[],[635],{"type":48,"value":636},"*_start_eth_bidir_kernel",{"type":48,"value":554},{"type":43,"tag":263,"props":639,"children":640},{},[641,643,648,650,656,657,663,664,670,671,677],{"type":48,"value":642},"A set of ",{"type":43,"tag":55,"props":644,"children":645},{},[646],{"type":48,"value":647},"per-workload settings structs",{"type":48,"value":649}," that the\nparent passes through (e.g. the reference exemplar's\n",{"type":43,"tag":75,"props":651,"children":653},{"className":652},[],[654],{"type":48,"value":655},"doca_bench_cuda_kernel_settings",{"type":48,"value":601},{"type":43,"tag":75,"props":658,"children":660},{"className":659},[],[661],{"type":48,"value":662},"doca_bench_cuda_eth_rx_kernel_settings",{"type":48,"value":601},{"type":43,"tag":75,"props":665,"children":667},{"className":666},[],[668],{"type":48,"value":669},"doca_bench_cuda_eth_tx_kernel_settings",{"type":48,"value":601},{"type":43,"tag":75,"props":672,"children":674},{"className":673},[],[675],{"type":48,"value":676},"doca_bench_cuda_eth_bidir_kernel_settings",{"type":48,"value":678}," carry block\ncounts, threads-per-block, RX \u002F TX queues, buffer\naddress \u002F mkey \u002F size, a stop flag, and a stats\npointer).",{"type":43,"tag":51,"props":680,"children":681},{},[682],{"type":48,"value":683},"The skill itself is Markdown. The user's extension source\nis whatever language the workload requires (C \u002F C++ \u002F CUDA\nin the reference case). The agent does NOT prescribe a\nlanguage beyond what the shipped reference demonstrates.",{"type":43,"tag":252,"props":685,"children":687},{"id":686},"when-to-load-this-skill",[688],{"type":48,"value":689},"When to load this skill",{"type":43,"tag":51,"props":691,"children":692},{},[693,695,700],{"type":48,"value":694},"Load ",{"type":43,"tag":75,"props":696,"children":698},{"className":697},[],[699],{"type":48,"value":4},{"type":48,"value":701}," when ANY of the following is\ntrue:",{"type":43,"tag":259,"props":703,"children":704},{},[705,739,763,775],{"type":43,"tag":263,"props":706,"children":707},{},[708,710,715,717,722,724,730,732,737],{"type":48,"value":709},"the user explicitly mentions ",{"type":43,"tag":75,"props":711,"children":713},{"className":712},[],[714],{"type":48,"value":4},{"type":48,"value":716},", the\n",{"type":43,"tag":75,"props":718,"children":720},{"className":719},[],[721],{"type":48,"value":313},{"type":48,"value":723}," reference extension, the\n",{"type":43,"tag":75,"props":725,"children":727},{"className":726},[],[728],{"type":48,"value":729},"doca_bench_cuda_impl",{"type":48,"value":731}," shared library, or any of the\n",{"type":43,"tag":75,"props":733,"children":735},{"className":734},[],[736],{"type":48,"value":185},{"type":48,"value":738}," extension entry points;",{"type":43,"tag":263,"props":740,"children":741},{},[742,744,754,756,761],{"type":48,"value":743},"the user has confirmed (via\n",{"type":43,"tag":70,"props":745,"children":747},{"href":746},"..\u002Fdoca-bench\u002FTASKS.md#configure",[748],{"type":43,"tag":75,"props":749,"children":751},{"className":750},[],[752],{"type":48,"value":753},"doca-bench TASKS.md ## configure",{"type":48,"value":755},")\nthat none of ",{"type":43,"tag":75,"props":757,"children":759},{"className":758},[],[760],{"type":48,"value":80},{"type":48,"value":762},"'s built-in workload modes\nmeasures the class they want, and an extension is the\nexit ramp;",{"type":43,"tag":263,"props":764,"children":765},{},[766,768,773],{"type":48,"value":767},"the user wants to copy \u002F extend the shipped\n",{"type":43,"tag":75,"props":769,"children":771},{"className":770},[],[772],{"type":48,"value":313},{"type":48,"value":774}," reference into a custom GPU-side\nworkload extension;",{"type":43,"tag":263,"props":776,"children":777},{},[778,780,785],{"type":48,"value":779},"the user is debugging why ",{"type":43,"tag":75,"props":781,"children":783},{"className":782},[],[784],{"type":48,"value":80},{"type":48,"value":786}," cannot find \u002F load\n\u002F call a custom extension they built.",{"type":43,"tag":51,"props":788,"children":789},{},[790],{"type":48,"value":791},"Co-load this skill with:",{"type":43,"tag":259,"props":793,"children":794},{},[795,815,851,866],{"type":43,"tag":263,"props":796,"children":797},{},[798,806,808,813],{"type":43,"tag":70,"props":799,"children":800},{"href":72},[801],{"type":43,"tag":75,"props":802,"children":804},{"className":803},[],[805],{"type":48,"value":80},{"type":48,"value":807}," (the parent tool —\nALWAYS co-loaded; extensions only have value as\nplug-ins into ",{"type":43,"tag":75,"props":809,"children":811},{"className":810},[],[812],{"type":48,"value":80},{"type":48,"value":814},");",{"type":43,"tag":263,"props":816,"children":817},{},[818,828,830,835,837,842,844,849],{"type":43,"tag":70,"props":819,"children":821},{"href":820},"..\u002F..\u002Fdoca-version\u002FSKILL.md",[822],{"type":43,"tag":75,"props":823,"children":825},{"className":824},[],[826],{"type":48,"value":827},"doca-version",{"type":48,"value":829}," (the\n",{"type":43,"tag":75,"props":831,"children":833},{"className":832},[],[834],{"type":48,"value":185},{"type":48,"value":836}," surface is versioned with DOCA; the\nextension's ",{"type":43,"tag":75,"props":838,"children":840},{"className":839},[],[841],{"type":48,"value":529},{"type":48,"value":843}," is the DOCA ",{"type":43,"tag":75,"props":845,"children":847},{"className":846},[],[848],{"type":48,"value":529},{"type":48,"value":850},"; the\nfour-way version match applies);",{"type":43,"tag":263,"props":852,"children":853},{},[854,864],{"type":43,"tag":70,"props":855,"children":857},{"href":856},"..\u002F..\u002Flibs\u002Fdoca-gpunetio\u002FSKILL.md",[858],{"type":43,"tag":75,"props":859,"children":861},{"className":860},[],[862],{"type":48,"value":863},"doca-gpunetio",{"type":48,"value":865}," when\nthe extension is GPU-side and uses GPUNetIO RX \u002F TX\nqueues like the reference exemplar (route the GPUNetIO\nsemantics there, not here);",{"type":43,"tag":263,"props":867,"children":868},{},[869,879,881,891],{"type":43,"tag":70,"props":870,"children":872},{"href":871},"..\u002F..\u002Fdoca-debug\u002FSKILL.md",[873],{"type":43,"tag":75,"props":874,"children":876},{"className":875},[],[877],{"type":48,"value":878},"doca-debug",{"type":48,"value":880}," and\n",{"type":43,"tag":70,"props":882,"children":884},{"href":883},"..\u002F..\u002Fdoca-setup\u002FSKILL.md",[885],{"type":43,"tag":75,"props":886,"children":888},{"className":887},[],[889],{"type":48,"value":890},"doca-setup",{"type":48,"value":892}," for the\nenv-side debug ladder (driver, firmware, CUDA toolkit,\ndynamic linker).",{"type":43,"tag":51,"props":894,"children":895},{},[896,898,903],{"type":48,"value":897},"Do NOT load this skill when the user's workload fits a\n",{"type":43,"tag":75,"props":899,"children":901},{"className":900},[],[902],{"type":48,"value":80},{"type":48,"value":904}," built-in mode — extensions add cost (build\ntoolchain, version churn, the experimental-surface\ncontract); the built-in modes are always the first answer to\ntry.",{"type":43,"tag":252,"props":906,"children":908},{"id":907},"what-this-skill-provides",[909],{"type":48,"value":910},"What this skill provides",{"type":43,"tag":51,"props":912,"children":913},{},[914],{"type":48,"value":915},"Three companion files in this directory, each owning a\ndifferent question shape:",{"type":43,"tag":259,"props":917,"children":918},{},[919,933,990],{"type":43,"tag":263,"props":920,"children":921},{},[922,931],{"type":43,"tag":70,"props":923,"children":925},{"href":924},"SKILL.md",[926],{"type":43,"tag":75,"props":927,"children":929},{"className":928},[],[930],{"type":48,"value":924},{"type":48,"value":932}," — this file. Audience, scope,\nloading order, related skills. Routes everything else.",{"type":43,"tag":263,"props":934,"children":935},{},[936,944,946,951,952,957,958,962,963,982,983,988],{"type":43,"tag":70,"props":937,"children":938},{"href":151},[939],{"type":43,"tag":75,"props":940,"children":942},{"className":941},[],[943],{"type":48,"value":151},{"type":48,"value":945}," — ",{"type":43,"tag":161,"props":947,"children":948},{},[949],{"type":48,"value":950},"what an extension\ncan do that the built-in modes cannot",{"type":48,"value":174},{"type":43,"tag":161,"props":953,"children":954},{},[955],{"type":48,"value":956},"what the API\nsurface looks like in broad strokes",{"type":48,"value":174},{"type":43,"tag":161,"props":959,"children":960},{},[961],{"type":48,"value":193},{"type":48,"value":174},{"type":43,"tag":161,"props":964,"children":965},{},[966,968,973,975,980],{"type":48,"value":967},"what\nversions it ships in (including the\n",{"type":43,"tag":75,"props":969,"children":971},{"className":970},[],[972],{"type":48,"value":185},{"type":48,"value":974},"-stability overlay on top of\n",{"type":43,"tag":75,"props":976,"children":978},{"className":977},[],[979],{"type":48,"value":827},{"type":48,"value":981},")",{"type":48,"value":174},{"type":43,"tag":161,"props":984,"children":985},{},[986],{"type":48,"value":987},"the layered error taxonomy",{"type":48,"value":989},",\nobservability, and the safety policy overlay.",{"type":43,"tag":263,"props":991,"children":992},{},[993,1001,1003,1009,1010,1016,1017,1023,1024,1030,1031,1037,1039,1044,1046,1052],{"type":43,"tag":70,"props":994,"children":995},{"href":85},[996],{"type":43,"tag":75,"props":997,"children":999},{"className":998},[],[1000],{"type":48,"value":85},{"type":48,"value":1002}," — the procedural verbs\n(",{"type":43,"tag":75,"props":1004,"children":1006},{"className":1005},[],[1007],{"type":48,"value":1008},"configure",{"type":48,"value":174},{"type":43,"tag":75,"props":1011,"children":1013},{"className":1012},[],[1014],{"type":48,"value":1015},"build",{"type":48,"value":174},{"type":43,"tag":75,"props":1018,"children":1020},{"className":1019},[],[1021],{"type":48,"value":1022},"run",{"type":48,"value":174},{"type":43,"tag":75,"props":1025,"children":1027},{"className":1026},[],[1028],{"type":48,"value":1029},"test",{"type":48,"value":174},{"type":43,"tag":75,"props":1032,"children":1034},{"className":1033},[],[1035],{"type":48,"value":1036},"debug",{"type":48,"value":1038},", etc.) plus\na ",{"type":43,"tag":75,"props":1040,"children":1042},{"className":1041},[],[1043],{"type":48,"value":4},{"type":48,"value":1045},"-specific command appendix and\nthe agent-side ",{"type":43,"tag":75,"props":1047,"children":1049},{"className":1048},[],[1050],{"type":48,"value":1051},"use",{"type":48,"value":1053}," workflow that consumes the captured\nextension run.",{"type":43,"tag":51,"props":1055,"children":1056},{},[1057,1059,1064,1066,1071,1073,1078,1080,1085],{"type":48,"value":1058},"The combined skill teaches an AI agent to drive the\n",{"type":43,"tag":161,"props":1060,"children":1061},{},[1062],{"type":48,"value":1063},"extension-author-and-wire-in class",{"type":48,"value":1065}," of ",{"type":43,"tag":75,"props":1067,"children":1069},{"className":1068},[],[1070],{"type":48,"value":80},{"type":48,"value":1072},"\nquestions: confirm an extension is needed at all; locate\nthe shipped reference exemplar\n(",{"type":43,"tag":75,"props":1074,"children":1076},{"className":1075},[],[1077],{"type":48,"value":321},{"type":48,"value":1079},"); copy\nits build + API surface shape; build a versioned shared\nlibrary that matches the DOCA release; smoke that the\nparent ",{"type":43,"tag":75,"props":1081,"children":1083},{"className":1082},[],[1084],{"type":48,"value":80},{"type":48,"value":1086}," actually loads it; diagnose layered\nfailures when it does not.",{"type":43,"tag":252,"props":1088,"children":1090},{"id":1089},"what-this-skill-deliberately-does-not-ship",[1091],{"type":48,"value":1092},"What this skill deliberately does not ship",{"type":43,"tag":259,"props":1094,"children":1095},{},[1096,1123,1147,1170,1201,1221,1238],{"type":43,"tag":263,"props":1097,"children":1098},{},[1099,1111,1113,1121],{"type":43,"tag":55,"props":1100,"children":1101},{},[1102,1104,1109],{"type":48,"value":1103},"Inventory of ",{"type":43,"tag":75,"props":1105,"children":1107},{"className":1106},[],[1108],{"type":48,"value":80},{"type":48,"value":1110},"'s built-in workload modes.",{"type":48,"value":1112},"\nThat belongs to ",{"type":43,"tag":70,"props":1114,"children":1115},{"href":72},[1116],{"type":43,"tag":75,"props":1117,"children":1119},{"className":1118},[],[1120],{"type":48,"value":80},{"type":48,"value":1122},".\nThis skill is the exit ramp for what the built-in modes\ndo not cover; it does not duplicate the parent's mode\ninventory.",{"type":43,"tag":263,"props":1124,"children":1125},{},[1126,1138,1140,1145],{"type":43,"tag":55,"props":1127,"children":1128},{},[1129,1131,1136],{"type":48,"value":1130},"Invented ",{"type":43,"tag":75,"props":1132,"children":1134},{"className":1133},[],[1135],{"type":48,"value":185},{"type":48,"value":1137}," entry-point names beyond\nwhat the shipped reference declares.",{"type":48,"value":1139}," The shipped\n",{"type":43,"tag":75,"props":1141,"children":1143},{"className":1142},[],[1144],{"type":48,"value":584},{"type":48,"value":1146}," on the user's\ninstall is the reference for what the surface shape\nlooks like; the agent does not assert other extensions\nexist with specific signatures.",{"type":43,"tag":263,"props":1148,"children":1149},{},[1150,1155,1156,1161,1163,1168],{"type":43,"tag":55,"props":1151,"children":1152},{},[1153],{"type":48,"value":1154},"A canonical \"right\" extension layout.",{"type":48,"value":1139},{"type":43,"tag":75,"props":1157,"children":1159},{"className":1158},[],[1160],{"type":48,"value":313},{"type":48,"value":1162}," reference IS the canonical layout;\nrewriting it here would drift from the source of truth.\nThe agent points the operator at the shipped tree and\nwalks the operator through ",{"type":43,"tag":161,"props":1164,"children":1165},{},[1166],{"type":48,"value":1167},"adapting",{"type":48,"value":1169}," it.",{"type":43,"tag":263,"props":1171,"children":1172},{},[1173,1178,1180,1185,1187,1192,1194,1199],{"type":43,"tag":55,"props":1174,"children":1175},{},[1176],{"type":48,"value":1177},"A documented runtime discovery mechanism the agent\ninvents.",{"type":48,"value":1179}," The exact mechanism ",{"type":43,"tag":75,"props":1181,"children":1183},{"className":1182},[],[1184],{"type":48,"value":80},{"type":48,"value":1186}," uses to\nlocate and load extensions (search path, naming\nconvention, registration call) lives in the public DOCA\nBench documentation on ",{"type":43,"tag":75,"props":1188,"children":1190},{"className":1189},[],[1191],{"type":48,"value":354},{"type":48,"value":1193}," and the\ninstalled ",{"type":43,"tag":75,"props":1195,"children":1197},{"className":1196},[],[1198],{"type":48,"value":80},{"type":48,"value":1200}," binary. The agent points the\noperator there rather than asserting a mechanism from\nmemory.",{"type":43,"tag":263,"props":1202,"children":1203},{},[1204,1209,1211,1219],{"type":43,"tag":55,"props":1205,"children":1206},{},[1207],{"type":48,"value":1208},"DOCA GPUNetIO programming details.",{"type":48,"value":1210}," When the\nextension is GPU-side (as the reference exemplar is),\nthe GPUNetIO RX \u002F TX queue semantics live in\n",{"type":43,"tag":70,"props":1212,"children":1213},{"href":856},[1214],{"type":43,"tag":75,"props":1215,"children":1217},{"className":1216},[],[1218],{"type":48,"value":863},{"type":48,"value":1220},";\nthis skill cross-links rather than duplicates.",{"type":43,"tag":263,"props":1222,"children":1223},{},[1224,1229,1231,1236],{"type":43,"tag":55,"props":1225,"children":1226},{},[1227],{"type":48,"value":1228},"CUDA toolchain installation guidance.",{"type":48,"value":1230}," Route to the\npublic NVIDIA CUDA Toolkit documentation on\n",{"type":43,"tag":75,"props":1232,"children":1234},{"className":1233},[],[1235],{"type":48,"value":354},{"type":48,"value":1237},"; this skill does not duplicate it.",{"type":43,"tag":263,"props":1239,"children":1240},{},[1241,1253,1255,1263],{"type":43,"tag":55,"props":1242,"children":1243},{},[1244,1246,1251],{"type":48,"value":1245},"Library-internal ",{"type":43,"tag":75,"props":1247,"children":1249},{"className":1248},[],[1250],{"type":48,"value":80},{"type":48,"value":1252}," invocation details\nunrelated to extensions.",{"type":48,"value":1254}," The parent's CLI flags,\npipeline shapes, and built-in workload classes belong\nto ",{"type":43,"tag":70,"props":1256,"children":1257},{"href":72},[1258],{"type":43,"tag":75,"props":1259,"children":1261},{"className":1260},[],[1262],{"type":48,"value":80},{"type":48,"value":1264},".",{"type":43,"tag":252,"props":1266,"children":1268},{"id":1267},"loading-order",[1269],{"type":48,"value":1270},"Loading order",{"type":43,"tag":51,"props":1272,"children":1273},{},[1274,1276,1281],{"type":48,"value":1275},"When a ",{"type":43,"tag":75,"props":1277,"children":1279},{"className":1278},[],[1280],{"type":48,"value":4},{"type":48,"value":1282}," question arrives:",{"type":43,"tag":502,"props":1284,"children":1285},{},[1286,1307,1334,1349],{"type":43,"tag":263,"props":1287,"children":1288},{},[1289,1291,1296,1298,1306],{"type":48,"value":1290},"Confirm DOCA is installed AND ",{"type":43,"tag":75,"props":1292,"children":1294},{"className":1293},[],[1295],{"type":48,"value":80},{"type":48,"value":1297}," is reachable\non the user's install — if not, route to\n",{"type":43,"tag":70,"props":1299,"children":1300},{"href":883},[1301],{"type":43,"tag":75,"props":1302,"children":1304},{"className":1303},[],[1305],{"type":48,"value":890},{"type":48,"value":472},{"type":43,"tag":263,"props":1308,"children":1309},{},[1310,1322,1324,1332],{"type":43,"tag":55,"props":1311,"children":1312},{},[1313,1315,1320],{"type":48,"value":1314},"Confirm none of ",{"type":43,"tag":75,"props":1316,"children":1318},{"className":1317},[],[1319],{"type":48,"value":80},{"type":48,"value":1321},"'s built-in modes covers\nthe workload class",{"type":48,"value":1323}," — if any of them does, route back\nto ",{"type":43,"tag":70,"props":1325,"children":1326},{"href":746},[1327],{"type":43,"tag":75,"props":1328,"children":1330},{"className":1329},[],[1331],{"type":48,"value":753},{"type":48,"value":1333},"\nand stop. Extensions are the exit ramp, not the first\nanswer;",{"type":43,"tag":263,"props":1335,"children":1336},{},[1337,1339,1347],{"type":48,"value":1338},"Read ",{"type":43,"tag":70,"props":1340,"children":1341},{"href":151},[1342],{"type":43,"tag":75,"props":1343,"children":1345},{"className":1344},[],[1346],{"type":48,"value":151},{"type":48,"value":1348}," to commit to\nthe three-axis decision and walk the reference\nexemplar's API surface shape;",{"type":43,"tag":263,"props":1350,"children":1351},{},[1352,1353,1361,1363,1369,1371,1376],{"type":48,"value":1338},{"type":43,"tag":70,"props":1354,"children":1355},{"href":85},[1356],{"type":43,"tag":75,"props":1357,"children":1359},{"className":1358},[],[1360],{"type":48,"value":85},{"type":48,"value":1362}," and walk\n",{"type":43,"tag":75,"props":1364,"children":1366},{"className":1365},[],[1367],{"type":48,"value":1368},"## configure → ## build → ## run → ## test → ## debug",{"type":48,"value":1370},"\nin that order; do NOT start with ",{"type":43,"tag":75,"props":1372,"children":1374},{"className":1373},[],[1375],{"type":48,"value":127},{"type":48,"value":1377}," without the\nbuild precondition step.",{"type":43,"tag":252,"props":1379,"children":1381},{"id":1380},"related-skills",[1382],{"type":48,"value":1383},"Related skills",{"type":43,"tag":51,"props":1385,"children":1386},{},[1387,1389,1395],{"type":48,"value":1388},"Cross-link conventions follow the bundle's relative path\ncontract from ",{"type":43,"tag":75,"props":1390,"children":1392},{"className":1391},[],[1393],{"type":48,"value":1394},"tools\u002F\u003CX>\u002F",{"type":48,"value":1396},":",{"type":43,"tag":259,"props":1398,"children":1399},{},[1400,1427,1460,1480,1507,1520,1542,1579],{"type":43,"tag":263,"props":1401,"children":1402},{},[1403,1411,1413,1418,1420,1425],{"type":43,"tag":70,"props":1404,"children":1405},{"href":72},[1406],{"type":43,"tag":75,"props":1407,"children":1409},{"className":1408},[],[1410],{"type":48,"value":80},{"type":48,"value":1412}," — the parent tool.\n",{"type":43,"tag":55,"props":1414,"children":1415},{},[1416],{"type":48,"value":1417},"ALWAYS co-loaded.",{"type":48,"value":1419}," Extensions are plug-ins into\n",{"type":43,"tag":75,"props":1421,"children":1423},{"className":1422},[],[1424],{"type":48,"value":80},{"type":48,"value":1426},"; they do not replace it, they do not have a\nstandalone CLI, they do not measure anything without the\nparent invoking them. Every question on this skill\npresupposes the parent.",{"type":43,"tag":263,"props":1428,"children":1429},{},[1430,1438,1440,1445,1446,1451,1453,1458],{"type":43,"tag":70,"props":1431,"children":1432},{"href":820},[1433],{"type":43,"tag":75,"props":1434,"children":1436},{"className":1435},[],[1437],{"type":48,"value":827},{"type":48,"value":1439}," — the\n",{"type":43,"tag":75,"props":1441,"children":1443},{"className":1442},[],[1444],{"type":48,"value":185},{"type":48,"value":836},{"type":43,"tag":75,"props":1447,"children":1449},{"className":1448},[],[1450],{"type":48,"value":529},{"type":48,"value":1452}," matches the DOCA release per\nthe shipped ",{"type":43,"tag":75,"props":1454,"children":1456},{"className":1455},[],[1457],{"type":48,"value":346},{"type":48,"value":1459},". The four-way version match\napplies; rebuilding the extension across DOCA upgrades\nis the rule, not the exception.",{"type":43,"tag":263,"props":1461,"children":1462},{},[1463,1471,1473,1478],{"type":43,"tag":70,"props":1464,"children":1465},{"href":856},[1466],{"type":43,"tag":75,"props":1467,"children":1469},{"className":1468},[],[1470],{"type":48,"value":863},{"type":48,"value":1472}," —\nwhen the extension is GPU-side and uses GPUNetIO RX \u002F\nTX queues like the reference ",{"type":43,"tag":75,"props":1474,"children":1476},{"className":1475},[],[1477],{"type":48,"value":313},{"type":48,"value":1479},". Route\nthe GPUNetIO semantics there.",{"type":43,"tag":263,"props":1481,"children":1482},{},[1483,1491,1493,1498,1500,1505],{"type":43,"tag":70,"props":1484,"children":1485},{"href":883},[1486],{"type":43,"tag":75,"props":1487,"children":1489},{"className":1488},[],[1490],{"type":48,"value":890},{"type":48,"value":1492}," — DOCA install\nposture (does ",{"type":43,"tag":75,"props":1494,"children":1496},{"className":1495},[],[1497],{"type":48,"value":80},{"type":48,"value":1499}," exist? does the\n",{"type":43,"tag":75,"props":1501,"children":1503},{"className":1502},[],[1504],{"type":48,"value":729},{"type":48,"value":1506}," reference library exist? is the\nCUDA toolchain installed when needed?).",{"type":43,"tag":263,"props":1508,"children":1509},{},[1510,1518],{"type":43,"tag":70,"props":1511,"children":1512},{"href":871},[1513],{"type":43,"tag":75,"props":1514,"children":1516},{"className":1515},[],[1517],{"type":48,"value":878},{"type":48,"value":1519}," — the\ncross-cutting debug ladder for env-side issues (dynamic\nlinker, library search path, CUDA driver \u002F toolkit,\nfirmware).",{"type":43,"tag":263,"props":1521,"children":1522},{},[1523,1533,1535,1540],{"type":43,"tag":70,"props":1524,"children":1526},{"href":1525},"..\u002F..\u002Fdoca-public-knowledge-map\u002FSKILL.md",[1527],{"type":43,"tag":75,"props":1528,"children":1530},{"className":1529},[],[1531],{"type":48,"value":1532},"doca-public-knowledge-map",{"type":48,"value":1534},"\n— routing to the public DOCA Bench \u002F DOCA GPUNetIO pages\non ",{"type":43,"tag":75,"props":1536,"children":1538},{"className":1537},[],[1539],{"type":48,"value":354},{"type":48,"value":1541}," and the release notes for the\ndocumented extension lifecycle \u002F discovery mechanism.",{"type":43,"tag":263,"props":1543,"children":1544},{},[1545,1555,1557,1563,1564,1570,1571,1577],{"type":43,"tag":70,"props":1546,"children":1548},{"href":1547},"..\u002F..\u002Fdoca-structured-tools-contract\u002FSKILL.md",[1549],{"type":43,"tag":75,"props":1550,"children":1552},{"className":1551},[],[1553],{"type":48,"value":1554},"doca-structured-tools-contract",{"type":48,"value":1556},"\n— the agent's detect → prefer → fall back → report\ncontract for the structured helpers\n(",{"type":43,"tag":75,"props":1558,"children":1560},{"className":1559},[],[1561],{"type":48,"value":1562},"doca-env --json",{"type":48,"value":174},{"type":43,"tag":75,"props":1565,"children":1567},{"className":1566},[],[1568],{"type":48,"value":1569},"doca-capability-snapshot",{"type":48,"value":601},{"type":43,"tag":75,"props":1572,"children":1574},{"className":1573},[],[1575],{"type":48,"value":1576},"version-matrix.json",{"type":48,"value":1578},") the build \u002F load preconditions\nrely on.",{"type":43,"tag":263,"props":1580,"children":1581},{},[1582,1592,1594,1604,1606,1611],{"type":43,"tag":70,"props":1583,"children":1585},{"href":1584},"..\u002F..\u002Fdoca-hardware-safety\u002FSKILL.md",[1586],{"type":43,"tag":75,"props":1587,"children":1589},{"className":1588},[],[1590],{"type":48,"value":1591},"doca-hardware-safety",{"type":48,"value":1593},"\n— the canonical hardware-safety meta-policy that\n",{"type":43,"tag":70,"props":1595,"children":1597},{"href":1596},"CAPABILITIES.md#safety-policy",[1598],{"type":43,"tag":75,"props":1599,"children":1601},{"className":1600},[],[1602],{"type":48,"value":1603},"CAPABILITIES.md ## Safety policy",{"type":48,"value":1605},"\noverlays. Extensions are external code loaded into\n",{"type":43,"tag":75,"props":1607,"children":1609},{"className":1608},[],[1610],{"type":48,"value":80},{"type":48,"value":1612},"; the safety implications of loading\nexperimental code into a benchmark that touches the\ndataplane \u002F device are real.",{"type":43,"tag":51,"props":1614,"children":1615},{},[1616],{"type":48,"value":1617},"This skill assumes the user has built shared libraries on\nLinux before and knows what a Meson build is. Background\nmaterial on those topics belongs in the toolchain docs, not\nin this skill.",{"items":1619,"total":1723},[1620,1637,1651,1665,1677,1694,1709],{"slug":1621,"name":1621,"fn":1622,"description":1623,"org":1624,"tags":1625,"stars":23,"repoUrl":24,"updatedAt":1636},"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},[1626,1629,1632,1633],{"name":1627,"slug":1628,"type":15},"Data Analysis","data-analysis",{"name":1630,"slug":1631,"type":15},"Data Engineering","data-engineering",{"name":9,"slug":8,"type":15},{"name":1634,"slug":1635,"type":15},"Performance","performance","2026-07-14T05:28:43.176466",{"slug":1638,"name":1638,"fn":1639,"description":1640,"org":1641,"tags":1642,"stars":23,"repoUrl":24,"updatedAt":1650},"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},[1643,1646,1649],{"name":1644,"slug":1645,"type":15},"Deployment","deployment",{"name":1647,"slug":1648,"type":15},"Infrastructure","infrastructure",{"name":9,"slug":8,"type":15},"2026-07-14T05:29:06.667109",{"slug":1652,"name":1652,"fn":1653,"description":1654,"org":1655,"tags":1656,"stars":23,"repoUrl":24,"updatedAt":1664},"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},[1657,1660,1661],{"name":1658,"slug":1659,"type":15},"Agents","agents",{"name":9,"slug":8,"type":15},{"name":1662,"slug":1663,"type":15},"Research","research","2026-07-14T05:28:06.816956",{"slug":1666,"name":1666,"fn":1667,"description":1668,"org":1669,"tags":1670,"stars":23,"repoUrl":24,"updatedAt":1676},"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},[1671,1672,1673],{"name":1627,"slug":1628,"type":15},{"name":9,"slug":8,"type":15},{"name":1674,"slug":1675,"type":15},"Testing","testing","2026-07-17T05:29:03.913266",{"slug":1678,"name":1678,"fn":1679,"description":1680,"org":1681,"tags":1682,"stars":23,"repoUrl":24,"updatedAt":1693},"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},[1683,1686,1689,1690],{"name":1684,"slug":1685,"type":15},"Automation","automation",{"name":1687,"slug":1688,"type":15},"Imaging","imaging",{"name":9,"slug":8,"type":15},{"name":1691,"slug":1692,"type":15},"Video","video","2026-07-17T05:28:53.905004",{"slug":1695,"name":1695,"fn":1696,"description":1697,"org":1698,"tags":1699,"stars":23,"repoUrl":24,"updatedAt":1708},"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},[1700,1701,1704,1705],{"name":1644,"slug":1645,"type":15},{"name":1702,"slug":1703,"type":15},"Docker","docker",{"name":9,"slug":8,"type":15},{"name":1706,"slug":1707,"type":15},"Operations","operations","2026-07-17T05:28:56.913999",{"slug":1710,"name":1710,"fn":1711,"description":1712,"org":1713,"tags":1714,"stars":23,"repoUrl":24,"updatedAt":1722},"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},[1715,1716,1719],{"name":9,"slug":8,"type":15},{"name":1717,"slug":1718,"type":15},"Quantum Computing","quantum-computing",{"name":1720,"slug":1721,"type":15},"Simulation","simulation","2026-07-14T05:26:58.898253",305,{"items":1725,"total":1874},[1726,1744,1760,1771,1783,1795,1808,1822,1833,1842,1856,1865],{"slug":1727,"name":1727,"fn":1728,"description":1729,"org":1730,"tags":1731,"stars":1741,"repoUrl":1742,"updatedAt":1743},"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},[1732,1735,1738],{"name":1733,"slug":1734,"type":15},"Documentation","documentation",{"name":1736,"slug":1737,"type":15},"MCP","mcp",{"name":1739,"slug":1740,"type":15},"Search","search",21777,"https:\u002F\u002Fgithub.com\u002FNVIDIA\u002FNemoClaw","2026-07-20T06:00:01.461044",{"slug":1745,"name":1745,"fn":1746,"description":1747,"org":1748,"tags":1749,"stars":1757,"repoUrl":1758,"updatedAt":1759},"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},[1750,1753,1754],{"name":1751,"slug":1752,"type":15},"Containers","containers",{"name":1644,"slug":1645,"type":15},{"name":1755,"slug":1756,"type":15},"Python","python",17049,"https:\u002F\u002Fgithub.com\u002FNVIDIA\u002FMegatron-LM","2026-07-27T06:06:11.249662",{"slug":1761,"name":1761,"fn":1762,"description":1763,"org":1764,"tags":1765,"stars":1757,"repoUrl":1758,"updatedAt":1770},"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},[1766,1769],{"name":1767,"slug":1768,"type":15},"CI\u002FCD","ci-cd",{"name":1644,"slug":1645,"type":15},"2026-07-14T05:25:59.97109",{"slug":1772,"name":1772,"fn":1773,"description":1774,"org":1775,"tags":1776,"stars":1757,"repoUrl":1758,"updatedAt":1782},"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},[1777,1778,1779],{"name":1767,"slug":1768,"type":15},{"name":1644,"slug":1645,"type":15},{"name":1780,"slug":1781,"type":15},"GitHub","github","2026-07-27T06:06:12.278222",{"slug":1784,"name":1784,"fn":1785,"description":1786,"org":1787,"tags":1788,"stars":1757,"repoUrl":1758,"updatedAt":1794},"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},[1789,1790,1791],{"name":21,"slug":22,"type":15},{"name":1780,"slug":1781,"type":15},{"name":1792,"slug":1793,"type":15},"Triage","triage","2026-07-14T05:25:57.442089",{"slug":1796,"name":1796,"fn":1797,"description":1798,"org":1799,"tags":1800,"stars":1757,"repoUrl":1758,"updatedAt":1807},"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},[1801,1804],{"name":1802,"slug":1803,"type":15},"Best Practices","best-practices",{"name":1805,"slug":1806,"type":15},"Code Analysis","code-analysis","2026-07-14T05:25:56.18433",{"slug":1809,"name":1809,"fn":1810,"description":1811,"org":1812,"tags":1813,"stars":1757,"repoUrl":1758,"updatedAt":1821},"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},[1814,1817,1820],{"name":1815,"slug":1816,"type":15},"Machine Learning","machine-learning",{"name":1818,"slug":1819,"type":15},"Migration","migration",{"name":9,"slug":8,"type":15},"2026-07-17T06:07:11.777011",{"slug":1823,"name":1823,"fn":1824,"description":1825,"org":1826,"tags":1827,"stars":1757,"repoUrl":1758,"updatedAt":1832},"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},[1828,1831],{"name":1829,"slug":1830,"type":15},"QA","qa",{"name":1674,"slug":1675,"type":15},"2026-07-14T05:25:53.673039",{"slug":1834,"name":1834,"fn":1835,"description":1836,"org":1837,"tags":1838,"stars":1757,"repoUrl":1758,"updatedAt":1841},"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},[1839,1840],{"name":1644,"slug":1645,"type":15},{"name":1647,"slug":1648,"type":15},"2026-07-14T05:25:49.362534",{"slug":1843,"name":1843,"fn":1844,"description":1845,"org":1846,"tags":1847,"stars":1757,"repoUrl":1758,"updatedAt":1855},"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},[1848,1851,1852],{"name":1849,"slug":1850,"type":15},"Code Review","code-review",{"name":1780,"slug":1781,"type":15},{"name":1853,"slug":1854,"type":15},"Pull Requests","pull-requests","2026-07-14T05:26:01.226578",{"slug":1857,"name":1857,"fn":1858,"description":1859,"org":1860,"tags":1861,"stars":1757,"repoUrl":1758,"updatedAt":1864},"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},[1862,1863],{"name":1829,"slug":1830,"type":15},{"name":1674,"slug":1675,"type":15},"2026-07-14T05:25:54.928983",{"slug":1866,"name":1866,"fn":1867,"description":1868,"org":1869,"tags":1870,"stars":1757,"repoUrl":1758,"updatedAt":1873},"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},[1871,1872],{"name":1684,"slug":1685,"type":15},{"name":1767,"slug":1768,"type":15},"2026-07-30T05:29:03.275638",496]