[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill-nvidia-doca-devemu":3,"mdc-yjm0bn-key":31,"related-repo-nvidia-doca-devemu":766,"related-org-nvidia-doca-devemu":872},{"slug":4,"name":4,"fn":5,"description":6,"org":7,"tags":11,"stars":20,"repoUrl":21,"updatedAt":22,"license":23,"forks":24,"topics":25,"repo":26,"sourceUrl":29,"mdContent":30},"doca-devemu","emulate PCIe devices on BlueField DPUs","Use this skill when the user is doing hands-on DOCA Device Emulation on a BlueField DPU — exposing a custom emulated PCIe device the host sees as a real peripheral while DPU-side code runs the backend, picking the sub-library (PCI Generic, virtio-net, virtio-fs), wiring the per-sub-library Core context plus doorbell \u002F DMA primitives, querying `doca_devemu_*_cap_*`, or debugging DOCA_ERROR_* from a `doca_devemu_*` call. Trigger even when the user does not say \"devemu\" — typical implicit phrasings include \"expose a custom PCIe device from BlueField to the host\", \"host should see a virtio NIC backed by my DPU code\", \"lspci does not show my emulated device\", \"device enumerated but no driver binds\", \"DPU sees nothing when host kicks the queue\", or \"virtio feature negotiation failed at bind\". Refuse and route elsewhere for the packaged DOCA SNAP \u002F Virtio-net Services, host-side virtio kernel drivers, backend body design, or standard BlueField NIC behavior — 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],{"name":13,"slug":14,"type":15},"Hardware","hardware","tag",{"name":9,"slug":8,"type":15},{"name":18,"slug":19,"type":15},"Engineering","engineering",2473,"https:\u002F\u002Fgithub.com\u002FNVIDIA\u002Fskills","2026-07-30T05:28:34.413492","Apache-2.0",281,[],{"repoUrl":21,"stars":20,"forks":24,"topics":27,"description":28},[],"AI agent skills published by NVIDIA","https:\u002F\u002Fgithub.com\u002FNVIDIA\u002Fskills\u002Ftree\u002FHEAD\u002Fskills\u002Fdoca-devemu","---\nlicense: Apache-2.0\nname: doca-devemu\ndescription: >\n  Use this skill when the user is doing hands-on DOCA Device\n  Emulation on a BlueField DPU — exposing a custom emulated PCIe\n  device the host sees as a real peripheral while DPU-side code\n  runs the backend, picking the sub-library (PCI Generic,\n  virtio-net, virtio-fs), wiring the per-sub-library Core context\n  plus doorbell \u002F DMA primitives, querying `doca_devemu_*_cap_*`,\n  or debugging DOCA_ERROR_* from a `doca_devemu_*` call. Trigger\n  even when the user does not say \"devemu\" — typical implicit\n  phrasings include \"expose a custom PCIe device from BlueField to\n  the host\", \"host should see a virtio NIC backed by my DPU code\",\n  \"lspci does not show my emulated device\", \"device enumerated but\n  no driver binds\", \"DPU sees nothing when host kicks the queue\",\n  or \"virtio feature negotiation failed at bind\". Refuse and route\n  elsewhere for the packaged DOCA SNAP \u002F Virtio-net Services,\n  host-side virtio kernel drivers, backend body design, or standard\n  BlueField NIC behavior — those belong to other skills.\nmetadata:\n  kind: library\ncompatibility: >\n  Requires DOCA SDK installed at \u002Fopt\u002Fmellanox\u002Fdoca on BOTH the\n  host AND the BlueField DPU (Ubuntu 22.04\u002F24.04 or RHEL\u002FSLES),\n  with the per-sub-library firmware-level emulation type (PCI\n  Generic \u002F virtio-net \u002F virtio-fs) enabled in BlueField firmware\n  and the host kernel shipping the matching standard driver\n  (virtio_net \u002F virtio_fs \u002F generic PCIe). Reads the local install\n  via the per-sub-library pkg-config module and inspects\n  \u002Fopt\u002Fmellanox\u002Fdoca\u002F{lib,include,samples\u002Fdoca_devemu}.\n---\n\n# DOCA Device Emulation\n\n**Where to start:** This skill assumes DOCA is already installed\non the host AND on the BlueField, the user is doing **hands-on\nemulated-PCIe-device work** from the DPU side (writing the\nbackend that the host's kernel driver will talk to over the\nemulated PCIe surface), and the user knows which CLASS of\nemulated device they want to build. Open\n[`TASKS.md`](TASKS.md) if the user wants to *do* something\n(configure \u002F build \u002F modify \u002F run \u002F test \u002F debug); open\n[`CAPABILITIES.md`](CAPABILITIES.md) when the question is\n*what can Device Emulation express* on this DOCA version + this\nBlueField generation + this firmware. If the user has not\ninstalled DOCA yet, route to\n[`doca-setup`](..\u002F..\u002Fdoca-setup\u002FSKILL.md) first. **Before\nanything else, the agent must route the user to the right\nsub-library** — DOCA Device Emulation is an *umbrella* that\ncovers PCI Generic (raw PCIe device emulation), virtio-net\n(emulated virtio network device), and virtio-fs (emulated\nvirtio filesystem device); each sub-library has its own\ncontext, its own `pkg-config` module, and its own capability\nsurface. The sub-library selection rule lives in\n[`CAPABILITIES.md ## Capabilities and modes`](CAPABILITIES.md#capabilities-and-modes).\nIf the user wants a packaged solution rather than a library\n(e.g. *\"I want NVMe SNAP on my host without writing the\nbackend myself\"*, or *\"I want a managed virtio-net daemon\"*),\nroute via\n[`doca-public-knowledge-map`](..\u002F..\u002Fdoca-public-knowledge-map\u002FSKILL.md)\nto the DOCA SNAP Service \u002F DOCA Virtio-net Service guides\n— those services are *built on top of* this library and are a\ndifferent artifact than what this skill covers.\n\n## Audience\n\nThis skill serves **external developers building applications\nthat consume the DOCA Device Emulation library** — i.e., users\nwhose DPU-side code calls `doca_devemu_pci_*`,\n`doca_devemu_virtio_*`, or `doca_devemu_vfs_*` (directly\nin C \u002F C++, or through FFI \u002F bindings from another language)\nto expose an emulated PCIe device to the host that the host's\nexisting kernel drivers can drive as if it were a real PCIe\nperipheral. It is *not* for NVIDIA developers contributing to\nDOCA Device Emulation itself, and it is *not* the right\nartifact for users who want a packaged emulated-device daemon\nthey do not have to write the backend for (the DOCA SNAP\nService and the DOCA Virtio-net Service are the packaged\noptions that build on top of this library).\n\n**Language scope.** DOCA Device Emulation ships as a C library;\nthis skill covers three sub-libraries end-to-end. Select the exact\ninstalled `pkg-config` module for the user's emulation class (see\nthe sub-library selection table in\n[`CAPABILITIES.md ## Capabilities and modes`](CAPABILITIES.md#capabilities-and-modes)).\nThe shipped samples under\n`\u002Fopt\u002Fmellanox\u002Fdoca\u002Fsamples\u002Fdoca_devemu\u002F` are\nwritten in C. C and C++ consumers are the canonical case and\nthe worked examples in `TASKS.md` assume that path.\nOther-language consumers (Rust, Go, Python, …) consume the\nsame `*.so` files through FFI or language-specific bindings;\nthe skill's contribution in that case is to keep the\nsub-library selection, umbrella lifecycle, capability-discovery,\npermission, and error-taxonomy guidance language-neutral, and\nto route the agent to the public C ABI as the authoritative\nsurface that any wrapper will eventually call.\n\n## When to load this skill\n\nLoad this skill when the user is doing hands-on DOCA Device\nEmulation work from the DPU side, in any language. Concretely:\n\n- Deciding which Device Emulation sub-library (PCI Generic,\n  virtio-net, virtio-fs) the user needs — the umbrella\n  selection question is *this skill's load-bearing first move*.\n- Initializing the per-sub-library DOCA Core context on the\n  DPU (one context per emulated device per sub-library) and\n  configuring the doorbell \u002F DMA primitives the host's PCIe\n  driver will interact with.\n- Reading per-sub-library capability surface via the\n  `doca_devemu_pci_cap_*`, `doca_devemu_virtio_cap_*`, or\n  `doca_devemu_vfs_cap_*` query families against the\n  active `doca_devinfo` BEFORE assuming a particular feature\n  bit or device characteristic is available.\n- Choosing between writing the backend with `doca-devemu`\n  yourself and adopting a packaged service (DOCA SNAP Service\n  \u002F DOCA Virtio-net Service) that already wraps this library.\n- Debugging a `DOCA_ERROR_*` returned from a `doca_devemu_*`\n  call — in particular disambiguating *firmware-level\n  emulation type not enabled* from *BlueField generation does\n  not support this sub-library at all* from *DPU-side process\n  lacks privilege* from *host-side kernel driver did not bind*.\n- Designing or extending non-C bindings (Rust, Go, Python, …)\n  that wrap one of the device-emulation sub-libraries — for\n  the sub-library selection, umbrella lifecycle, capability-\n  discovery, permission, and error-taxonomy rules the wrapper\n  must honor.\n\nDo **not** load this skill for general DOCA orientation,\ninstall of DOCA itself, the host-side kernel driver for the\nemulated device class (virtio-net \u002F virtio-blk \u002F virtio-fs\nkernel drivers ship with the host kernel and are not part of\nDOCA), the packaged SNAP \u002F Virtio-net services (they are\nseparate artifacts with their own service guides), or for\nstandard NIC behavior on the BlueField data path (use\n[`doca-flow`](..\u002Fdoca-flow\u002FSKILL.md) +\n[`doca-eth`](..\u002Fdoca-eth\u002FSKILL.md) instead — Device Emulation\nis for *custom* emulated devices, not for shaping the\nBlueField's built-in NIC personality).\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 Device\nEmulation-specific material lives in two companion files:\n\n- `CAPABILITIES.md` — what Device Emulation can express on\n  this version + this BlueField generation + this firmware:\n  the umbrella architecture (host sees an emulated PCIe\n  device; DPU runs the backend), the sub-library selection\n  rule (PCI Generic vs virtio-net vs virtio-fs), the per-\n  sub-library Core context shape, the doorbell \u002F DMA\n  primitives that bridge host ↔ DPU, the per-sub-library\n  capability-query family (`doca_devemu_*_cap_*`), the\n  per-sub-library `pkg-config` module name, the Device\n  Emulation error taxonomy mapped onto the cross-library\n  `DOCA_ERROR_*` set, the observability surface, the\n  library-vs-packaged-service path-selection rule, and the\n  safety policy that gates env preconditions (DPU-side\n  privileges, BlueField firmware-level emulation type\n  enablement, BlueField generation actually supporting the\n  emulation class).\n- `TASKS.md` — step-by-step workflows for the six in-scope\n  Device Emulation verbs: `configure`, `build`, `modify`,\n  `run`, `test`, `debug`. Plus a `Deferred task verbs` block\n  that points out-of-scope questions at the right next skill.\n\nThe skill assumes a host + BlueField pair where DOCA is\nalready installed at the standard location on both sides, the\nBlueField firmware has the emulation type the user wants to\nbuild enabled, the user has the privileges their public\ninstall profile expects (in particular, sudo on the DPU side\nto perform PCIe-level emulation), and the host kernel ships\nthe standard driver for the emulated device class the user is\nbuilding. It does not cover installing DOCA, flipping\nfirmware-level configuration, or installing host-side kernel\ndrivers — those paths go through\n[`doca-setup`](..\u002F..\u002Fdoca-setup\u002FSKILL.md).\n\n## Loading order\n\n1. Read this `SKILL.md` first to confirm the user's question\n   is in scope (custom emulated PCIe device built on the\n   `doca-devemu` library, not the packaged SNAP \u002F\n   Virtio-net services, not the host-side kernel driver, not\n   standard NIC behavior).\n2. **For the umbrella architecture, the sub-library selection\n   rule (PCI Generic vs virtio-net vs virtio-fs), the per-\n   sub-library Core context shape, the doorbell \u002F DMA\n   primitives, the per-sub-library capability-query rule,\n   the per-sub-library `pkg-config` modules, the library-vs-\n   packaged-service path-selection rule, the error taxonomy,\n   the observability surface, and the safety policy, see\n   [CAPABILITIES.md](CAPABILITIES.md).**\n3. **For step-by-step workflows — configure, build, modify,\n   run, test, debug — see [TASKS.md](TASKS.md).**\n\nBoth companion files cross-link to each other,\n[`doca-version`](..\u002F..\u002Fdoca-version\u002FSKILL.md) for the\ncanonical DOCA version-handling rules (with the Device\nEmulation overlay that the chosen sub-library's `pkg-config`\nmodule plus the firmware-level emulation slot plus the\n`doca_devemu_*_cap_*` query are all part of *\"is this\nemulation supported here\"*), and\n[`doca-public-knowledge-map`](..\u002F..\u002Fdoca-public-knowledge-map\u002FSKILL.md)\nwhenever the right answer is \"look it up in the public DOCA\nDevice Emulation umbrella guide, the per-sub-library guide\nlinked from it, the DOCA SNAP \u002F Virtio-net Service guide, or\nin the on-disk install layout\" rather than \"Device Emulation-\nspecific guidance\".\n\n## Example questions this skill answers well\n\nSee [`references\u002Fdetails.md`](references\u002Fdetails.md#example-questions-this-skill-answers-well).\n## What this skill deliberately does not ship\n\nSee [`references\u002Fdetails.md`](references\u002Fdetails.md#what-this-skill-deliberately-does-not-ship).\n## Related skills\n\nSee [`references\u002Fdetails.md`](references\u002Fdetails.md#related-skills).\n",{"data":32,"body":36},{"license":23,"name":4,"description":6,"metadata":33,"compatibility":35},{"kind":34},"library","Requires DOCA SDK installed at \u002Fopt\u002Fmellanox\u002Fdoca on BOTH the host AND the BlueField DPU (Ubuntu 22.04\u002F24.04 or RHEL\u002FSLES), with the per-sub-library firmware-level emulation type (PCI Generic \u002F virtio-net \u002F virtio-fs) enabled in BlueField firmware and the host kernel shipping the matching standard driver (virtio_net \u002F virtio_fs \u002F generic PCIe). Reads the local install via the per-sub-library pkg-config module and inspects \u002Fopt\u002Fmellanox\u002Fdoca\u002F{lib,include,samples\u002Fdoca_devemu}.\n",{"type":37,"children":38},"root",[39,48,185,192,240,290,296,301,423,465,471,483,579,593,599,656,704,710,726,732,746,752],{"type":40,"tag":41,"props":42,"children":44},"element","h1",{"id":43},"doca-device-emulation",[45],{"type":46,"value":47},"text","DOCA Device Emulation",{"type":40,"tag":49,"props":50,"children":51},"p",{},[52,58,60,65,67,78,80,86,88,97,99,104,106,116,118,123,125,130,132,138,140,150,152,157,159,164,166,176,178,183],{"type":40,"tag":53,"props":54,"children":55},"strong",{},[56],{"type":46,"value":57},"Where to start:",{"type":46,"value":59}," This skill assumes DOCA is already installed\non the host AND on the BlueField, the user is doing ",{"type":40,"tag":53,"props":61,"children":62},{},[63],{"type":46,"value":64},"hands-on\nemulated-PCIe-device work",{"type":46,"value":66}," from the DPU side (writing the\nbackend that the host's kernel driver will talk to over the\nemulated PCIe surface), and the user knows which CLASS of\nemulated device they want to build. Open\n",{"type":40,"tag":68,"props":69,"children":71},"a",{"href":70},"TASKS.md",[72],{"type":40,"tag":73,"props":74,"children":76},"code",{"className":75},[],[77],{"type":46,"value":70},{"type":46,"value":79}," if the user wants to ",{"type":40,"tag":81,"props":82,"children":83},"em",{},[84],{"type":46,"value":85},"do",{"type":46,"value":87}," something\n(configure \u002F build \u002F modify \u002F run \u002F test \u002F debug); open\n",{"type":40,"tag":68,"props":89,"children":91},{"href":90},"CAPABILITIES.md",[92],{"type":40,"tag":73,"props":93,"children":95},{"className":94},[],[96],{"type":46,"value":90},{"type":46,"value":98}," when the question is\n",{"type":40,"tag":81,"props":100,"children":101},{},[102],{"type":46,"value":103},"what can Device Emulation express",{"type":46,"value":105}," on this DOCA version + this\nBlueField generation + this firmware. If the user has not\ninstalled DOCA yet, route to\n",{"type":40,"tag":68,"props":107,"children":109},{"href":108},"..\u002F..\u002Fdoca-setup\u002FSKILL.md",[110],{"type":40,"tag":73,"props":111,"children":113},{"className":112},[],[114],{"type":46,"value":115},"doca-setup",{"type":46,"value":117}," first. ",{"type":40,"tag":53,"props":119,"children":120},{},[121],{"type":46,"value":122},"Before\nanything else, the agent must route the user to the right\nsub-library",{"type":46,"value":124}," — DOCA Device Emulation is an ",{"type":40,"tag":81,"props":126,"children":127},{},[128],{"type":46,"value":129},"umbrella",{"type":46,"value":131}," that\ncovers PCI Generic (raw PCIe device emulation), virtio-net\n(emulated virtio network device), and virtio-fs (emulated\nvirtio filesystem device); each sub-library has its own\ncontext, its own ",{"type":40,"tag":73,"props":133,"children":135},{"className":134},[],[136],{"type":46,"value":137},"pkg-config",{"type":46,"value":139}," module, and its own capability\nsurface. The sub-library selection rule lives in\n",{"type":40,"tag":68,"props":141,"children":143},{"href":142},"CAPABILITIES.md#capabilities-and-modes",[144],{"type":40,"tag":73,"props":145,"children":147},{"className":146},[],[148],{"type":46,"value":149},"CAPABILITIES.md ## Capabilities and modes",{"type":46,"value":151},".\nIf the user wants a packaged solution rather than a library\n(e.g. ",{"type":40,"tag":81,"props":153,"children":154},{},[155],{"type":46,"value":156},"\"I want NVMe SNAP on my host without writing the\nbackend myself\"",{"type":46,"value":158},", or ",{"type":40,"tag":81,"props":160,"children":161},{},[162],{"type":46,"value":163},"\"I want a managed virtio-net daemon\"",{"type":46,"value":165},"),\nroute via\n",{"type":40,"tag":68,"props":167,"children":169},{"href":168},"..\u002F..\u002Fdoca-public-knowledge-map\u002FSKILL.md",[170],{"type":40,"tag":73,"props":171,"children":173},{"className":172},[],[174],{"type":46,"value":175},"doca-public-knowledge-map",{"type":46,"value":177},"\nto the DOCA SNAP Service \u002F DOCA Virtio-net Service guides\n— those services are ",{"type":40,"tag":81,"props":179,"children":180},{},[181],{"type":46,"value":182},"built on top of",{"type":46,"value":184}," this library and are a\ndifferent artifact than what this skill covers.",{"type":40,"tag":186,"props":187,"children":189},"h2",{"id":188},"audience",[190],{"type":46,"value":191},"Audience",{"type":40,"tag":49,"props":193,"children":194},{},[195,197,202,204,210,212,218,219,225,227,232,234,238],{"type":46,"value":196},"This skill serves ",{"type":40,"tag":53,"props":198,"children":199},{},[200],{"type":46,"value":201},"external developers building applications\nthat consume the DOCA Device Emulation library",{"type":46,"value":203}," — i.e., users\nwhose DPU-side code calls ",{"type":40,"tag":73,"props":205,"children":207},{"className":206},[],[208],{"type":46,"value":209},"doca_devemu_pci_*",{"type":46,"value":211},",\n",{"type":40,"tag":73,"props":213,"children":215},{"className":214},[],[216],{"type":46,"value":217},"doca_devemu_virtio_*",{"type":46,"value":158},{"type":40,"tag":73,"props":220,"children":222},{"className":221},[],[223],{"type":46,"value":224},"doca_devemu_vfs_*",{"type":46,"value":226}," (directly\nin C \u002F C++, or through FFI \u002F bindings from another language)\nto expose an emulated PCIe device to the host that the host's\nexisting kernel drivers can drive as if it were a real PCIe\nperipheral. It is ",{"type":40,"tag":81,"props":228,"children":229},{},[230],{"type":46,"value":231},"not",{"type":46,"value":233}," for NVIDIA developers contributing to\nDOCA Device Emulation itself, and it is ",{"type":40,"tag":81,"props":235,"children":236},{},[237],{"type":46,"value":231},{"type":46,"value":239}," the right\nartifact for users who want a packaged emulated-device daemon\nthey do not have to write the backend for (the DOCA SNAP\nService and the DOCA Virtio-net Service are the packaged\noptions that build on top of this library).",{"type":40,"tag":49,"props":241,"children":242},{},[243,248,250,255,257,265,267,273,275,280,282,288],{"type":40,"tag":53,"props":244,"children":245},{},[246],{"type":46,"value":247},"Language scope.",{"type":46,"value":249}," DOCA Device Emulation ships as a C library;\nthis skill covers three sub-libraries end-to-end. Select the exact\ninstalled ",{"type":40,"tag":73,"props":251,"children":253},{"className":252},[],[254],{"type":46,"value":137},{"type":46,"value":256}," module for the user's emulation class (see\nthe sub-library selection table in\n",{"type":40,"tag":68,"props":258,"children":259},{"href":142},[260],{"type":40,"tag":73,"props":261,"children":263},{"className":262},[],[264],{"type":46,"value":149},{"type":46,"value":266},").\nThe shipped samples under\n",{"type":40,"tag":73,"props":268,"children":270},{"className":269},[],[271],{"type":46,"value":272},"\u002Fopt\u002Fmellanox\u002Fdoca\u002Fsamples\u002Fdoca_devemu\u002F",{"type":46,"value":274}," are\nwritten in C. C and C++ consumers are the canonical case and\nthe worked examples in ",{"type":40,"tag":73,"props":276,"children":278},{"className":277},[],[279],{"type":46,"value":70},{"type":46,"value":281}," assume that path.\nOther-language consumers (Rust, Go, Python, …) consume the\nsame ",{"type":40,"tag":73,"props":283,"children":285},{"className":284},[],[286],{"type":46,"value":287},"*.so",{"type":46,"value":289}," files through FFI or language-specific bindings;\nthe skill's contribution in that case is to keep the\nsub-library selection, umbrella lifecycle, capability-discovery,\npermission, and error-taxonomy guidance language-neutral, and\nto route the agent to the public C ABI as the authoritative\nsurface that any wrapper will eventually call.",{"type":40,"tag":186,"props":291,"children":293},{"id":292},"when-to-load-this-skill",[294],{"type":46,"value":295},"When to load this skill",{"type":40,"tag":49,"props":297,"children":298},{},[299],{"type":46,"value":300},"Load this skill when the user is doing hands-on DOCA Device\nEmulation work from the DPU side, in any language. Concretely:",{"type":40,"tag":302,"props":303,"children":304},"ul",{},[305,318,323,360,372,418],{"type":40,"tag":306,"props":307,"children":308},"li",{},[309,311,316],{"type":46,"value":310},"Deciding which Device Emulation sub-library (PCI Generic,\nvirtio-net, virtio-fs) the user needs — the umbrella\nselection question is ",{"type":40,"tag":81,"props":312,"children":313},{},[314],{"type":46,"value":315},"this skill's load-bearing first move",{"type":46,"value":317},".",{"type":40,"tag":306,"props":319,"children":320},{},[321],{"type":46,"value":322},"Initializing the per-sub-library DOCA Core context on the\nDPU (one context per emulated device per sub-library) and\nconfiguring the doorbell \u002F DMA primitives the host's PCIe\ndriver will interact with.",{"type":40,"tag":306,"props":324,"children":325},{},[326,328,334,336,342,344,350,352,358],{"type":46,"value":327},"Reading per-sub-library capability surface via the\n",{"type":40,"tag":73,"props":329,"children":331},{"className":330},[],[332],{"type":46,"value":333},"doca_devemu_pci_cap_*",{"type":46,"value":335},", ",{"type":40,"tag":73,"props":337,"children":339},{"className":338},[],[340],{"type":46,"value":341},"doca_devemu_virtio_cap_*",{"type":46,"value":343},", or\n",{"type":40,"tag":73,"props":345,"children":347},{"className":346},[],[348],{"type":46,"value":349},"doca_devemu_vfs_cap_*",{"type":46,"value":351}," query families against the\nactive ",{"type":40,"tag":73,"props":353,"children":355},{"className":354},[],[356],{"type":46,"value":357},"doca_devinfo",{"type":46,"value":359}," BEFORE assuming a particular feature\nbit or device characteristic is available.",{"type":40,"tag":306,"props":361,"children":362},{},[363,365,370],{"type":46,"value":364},"Choosing between writing the backend with ",{"type":40,"tag":73,"props":366,"children":368},{"className":367},[],[369],{"type":46,"value":4},{"type":46,"value":371},"\nyourself and adopting a packaged service (DOCA SNAP Service\n\u002F DOCA Virtio-net Service) that already wraps this library.",{"type":40,"tag":306,"props":373,"children":374},{},[375,377,383,385,391,393,398,400,405,406,411,412,417],{"type":46,"value":376},"Debugging a ",{"type":40,"tag":73,"props":378,"children":380},{"className":379},[],[381],{"type":46,"value":382},"DOCA_ERROR_*",{"type":46,"value":384}," returned from a ",{"type":40,"tag":73,"props":386,"children":388},{"className":387},[],[389],{"type":46,"value":390},"doca_devemu_*",{"type":46,"value":392},"\ncall — in particular disambiguating ",{"type":40,"tag":81,"props":394,"children":395},{},[396],{"type":46,"value":397},"firmware-level\nemulation type not enabled",{"type":46,"value":399}," from ",{"type":40,"tag":81,"props":401,"children":402},{},[403],{"type":46,"value":404},"BlueField generation does\nnot support this sub-library at all",{"type":46,"value":399},{"type":40,"tag":81,"props":407,"children":408},{},[409],{"type":46,"value":410},"DPU-side process\nlacks privilege",{"type":46,"value":399},{"type":40,"tag":81,"props":413,"children":414},{},[415],{"type":46,"value":416},"host-side kernel driver did not bind",{"type":46,"value":317},{"type":40,"tag":306,"props":419,"children":420},{},[421],{"type":46,"value":422},"Designing or extending non-C bindings (Rust, Go, Python, …)\nthat wrap one of the device-emulation sub-libraries — for\nthe sub-library selection, umbrella lifecycle, capability-\ndiscovery, permission, and error-taxonomy rules the wrapper\nmust honor.",{"type":40,"tag":49,"props":424,"children":425},{},[426,428,432,434,444,446,456,458,463],{"type":46,"value":427},"Do ",{"type":40,"tag":53,"props":429,"children":430},{},[431],{"type":46,"value":231},{"type":46,"value":433}," load this skill for general DOCA orientation,\ninstall of DOCA itself, the host-side kernel driver for the\nemulated device class (virtio-net \u002F virtio-blk \u002F virtio-fs\nkernel drivers ship with the host kernel and are not part of\nDOCA), the packaged SNAP \u002F Virtio-net services (they are\nseparate artifacts with their own service guides), or for\nstandard NIC behavior on the BlueField data path (use\n",{"type":40,"tag":68,"props":435,"children":437},{"href":436},"..\u002Fdoca-flow\u002FSKILL.md",[438],{"type":40,"tag":73,"props":439,"children":441},{"className":440},[],[442],{"type":46,"value":443},"doca-flow",{"type":46,"value":445}," +\n",{"type":40,"tag":68,"props":447,"children":449},{"href":448},"..\u002Fdoca-eth\u002FSKILL.md",[450],{"type":40,"tag":73,"props":451,"children":453},{"className":452},[],[454],{"type":46,"value":455},"doca-eth",{"type":46,"value":457}," instead — Device Emulation\nis for ",{"type":40,"tag":81,"props":459,"children":460},{},[461],{"type":46,"value":462},"custom",{"type":46,"value":464}," emulated devices, not for shaping the\nBlueField's built-in NIC personality).",{"type":40,"tag":186,"props":466,"children":468},{"id":467},"what-this-skill-provides",[469],{"type":46,"value":470},"What this skill provides",{"type":40,"tag":49,"props":472,"children":473},{},[474,476,481],{"type":46,"value":475},"This is a ",{"type":40,"tag":53,"props":477,"children":478},{},[479],{"type":46,"value":480},"thin loader",{"type":46,"value":482},". The body keeps only the orientation\nneeded to pick the right next file. The substantive Device\nEmulation-specific material lives in two companion files:",{"type":40,"tag":302,"props":484,"children":485},{},[486,518],{"type":40,"tag":306,"props":487,"children":488},{},[489,494,496,502,504,509,511,516],{"type":40,"tag":73,"props":490,"children":492},{"className":491},[],[493],{"type":46,"value":90},{"type":46,"value":495}," — what Device Emulation can express on\nthis version + this BlueField generation + this firmware:\nthe umbrella architecture (host sees an emulated PCIe\ndevice; DPU runs the backend), the sub-library selection\nrule (PCI Generic vs virtio-net vs virtio-fs), the per-\nsub-library Core context shape, the doorbell \u002F DMA\nprimitives that bridge host ↔ DPU, the per-sub-library\ncapability-query family (",{"type":40,"tag":73,"props":497,"children":499},{"className":498},[],[500],{"type":46,"value":501},"doca_devemu_*_cap_*",{"type":46,"value":503},"), the\nper-sub-library ",{"type":40,"tag":73,"props":505,"children":507},{"className":506},[],[508],{"type":46,"value":137},{"type":46,"value":510}," module name, the Device\nEmulation error taxonomy mapped onto the cross-library\n",{"type":40,"tag":73,"props":512,"children":514},{"className":513},[],[515],{"type":46,"value":382},{"type":46,"value":517}," set, the observability surface, the\nlibrary-vs-packaged-service path-selection rule, and the\nsafety policy that gates env preconditions (DPU-side\nprivileges, BlueField firmware-level emulation type\nenablement, BlueField generation actually supporting the\nemulation class).",{"type":40,"tag":306,"props":519,"children":520},{},[521,526,528,534,535,541,542,548,549,555,556,562,563,569,571,577],{"type":40,"tag":73,"props":522,"children":524},{"className":523},[],[525],{"type":46,"value":70},{"type":46,"value":527}," — step-by-step workflows for the six in-scope\nDevice Emulation verbs: ",{"type":40,"tag":73,"props":529,"children":531},{"className":530},[],[532],{"type":46,"value":533},"configure",{"type":46,"value":335},{"type":40,"tag":73,"props":536,"children":538},{"className":537},[],[539],{"type":46,"value":540},"build",{"type":46,"value":335},{"type":40,"tag":73,"props":543,"children":545},{"className":544},[],[546],{"type":46,"value":547},"modify",{"type":46,"value":211},{"type":40,"tag":73,"props":550,"children":552},{"className":551},[],[553],{"type":46,"value":554},"run",{"type":46,"value":335},{"type":40,"tag":73,"props":557,"children":559},{"className":558},[],[560],{"type":46,"value":561},"test",{"type":46,"value":335},{"type":40,"tag":73,"props":564,"children":566},{"className":565},[],[567],{"type":46,"value":568},"debug",{"type":46,"value":570},". Plus a ",{"type":40,"tag":73,"props":572,"children":574},{"className":573},[],[575],{"type":46,"value":576},"Deferred task verbs",{"type":46,"value":578}," block\nthat points out-of-scope questions at the right next skill.",{"type":40,"tag":49,"props":580,"children":581},{},[582,584,592],{"type":46,"value":583},"The skill assumes a host + BlueField pair where DOCA is\nalready installed at the standard location on both sides, the\nBlueField firmware has the emulation type the user wants to\nbuild enabled, the user has the privileges their public\ninstall profile expects (in particular, sudo on the DPU side\nto perform PCIe-level emulation), and the host kernel ships\nthe standard driver for the emulated device class the user is\nbuilding. It does not cover installing DOCA, flipping\nfirmware-level configuration, or installing host-side kernel\ndrivers — those paths go through\n",{"type":40,"tag":68,"props":585,"children":586},{"href":108},[587],{"type":40,"tag":73,"props":588,"children":590},{"className":589},[],[591],{"type":46,"value":115},{"type":46,"value":317},{"type":40,"tag":186,"props":594,"children":596},{"id":595},"loading-order",[597],{"type":46,"value":598},"Loading order",{"type":40,"tag":600,"props":601,"children":602},"ol",{},[603,623,643],{"type":40,"tag":306,"props":604,"children":605},{},[606,608,614,616,621],{"type":46,"value":607},"Read this ",{"type":40,"tag":73,"props":609,"children":611},{"className":610},[],[612],{"type":46,"value":613},"SKILL.md",{"type":46,"value":615}," first to confirm the user's question\nis in scope (custom emulated PCIe device built on the\n",{"type":40,"tag":73,"props":617,"children":619},{"className":618},[],[620],{"type":46,"value":4},{"type":46,"value":622}," library, not the packaged SNAP \u002F\nVirtio-net services, not the host-side kernel driver, not\nstandard NIC behavior).",{"type":40,"tag":306,"props":624,"children":625},{},[626],{"type":40,"tag":53,"props":627,"children":628},{},[629,631,636,638,642],{"type":46,"value":630},"For the umbrella architecture, the sub-library selection\nrule (PCI Generic vs virtio-net vs virtio-fs), the per-\nsub-library Core context shape, the doorbell \u002F DMA\nprimitives, the per-sub-library capability-query rule,\nthe per-sub-library ",{"type":40,"tag":73,"props":632,"children":634},{"className":633},[],[635],{"type":46,"value":137},{"type":46,"value":637}," modules, the library-vs-\npackaged-service path-selection rule, the error taxonomy,\nthe observability surface, and the safety policy, see\n",{"type":40,"tag":68,"props":639,"children":640},{"href":90},[641],{"type":46,"value":90},{"type":46,"value":317},{"type":40,"tag":306,"props":644,"children":645},{},[646],{"type":40,"tag":53,"props":647,"children":648},{},[649,651,655],{"type":46,"value":650},"For step-by-step workflows — configure, build, modify,\nrun, test, debug — see ",{"type":40,"tag":68,"props":652,"children":653},{"href":70},[654],{"type":46,"value":70},{"type":46,"value":317},{"type":40,"tag":49,"props":657,"children":658},{},[659,661,671,673,678,680,685,687,692,694,702],{"type":46,"value":660},"Both companion files cross-link to each other,\n",{"type":40,"tag":68,"props":662,"children":664},{"href":663},"..\u002F..\u002Fdoca-version\u002FSKILL.md",[665],{"type":40,"tag":73,"props":666,"children":668},{"className":667},[],[669],{"type":46,"value":670},"doca-version",{"type":46,"value":672}," for the\ncanonical DOCA version-handling rules (with the Device\nEmulation overlay that the chosen sub-library's ",{"type":40,"tag":73,"props":674,"children":676},{"className":675},[],[677],{"type":46,"value":137},{"type":46,"value":679},"\nmodule plus the firmware-level emulation slot plus the\n",{"type":40,"tag":73,"props":681,"children":683},{"className":682},[],[684],{"type":46,"value":501},{"type":46,"value":686}," query are all part of ",{"type":40,"tag":81,"props":688,"children":689},{},[690],{"type":46,"value":691},"\"is this\nemulation supported here\"",{"type":46,"value":693},"), and\n",{"type":40,"tag":68,"props":695,"children":696},{"href":168},[697],{"type":40,"tag":73,"props":698,"children":700},{"className":699},[],[701],{"type":46,"value":175},{"type":46,"value":703},"\nwhenever the right answer is \"look it up in the public DOCA\nDevice Emulation umbrella guide, the per-sub-library guide\nlinked from it, the DOCA SNAP \u002F Virtio-net Service guide, or\nin the on-disk install layout\" rather than \"Device Emulation-\nspecific guidance\".",{"type":40,"tag":186,"props":705,"children":707},{"id":706},"example-questions-this-skill-answers-well",[708],{"type":46,"value":709},"Example questions this skill answers well",{"type":40,"tag":49,"props":711,"children":712},{},[713,715,725],{"type":46,"value":714},"See ",{"type":40,"tag":68,"props":716,"children":718},{"href":717},"references\u002Fdetails.md#example-questions-this-skill-answers-well",[719],{"type":40,"tag":73,"props":720,"children":722},{"className":721},[],[723],{"type":46,"value":724},"references\u002Fdetails.md",{"type":46,"value":317},{"type":40,"tag":186,"props":727,"children":729},{"id":728},"what-this-skill-deliberately-does-not-ship",[730],{"type":46,"value":731},"What this skill deliberately does not ship",{"type":40,"tag":49,"props":733,"children":734},{},[735,736,745],{"type":46,"value":714},{"type":40,"tag":68,"props":737,"children":739},{"href":738},"references\u002Fdetails.md#what-this-skill-deliberately-does-not-ship",[740],{"type":40,"tag":73,"props":741,"children":743},{"className":742},[],[744],{"type":46,"value":724},{"type":46,"value":317},{"type":40,"tag":186,"props":747,"children":749},{"id":748},"related-skills",[750],{"type":46,"value":751},"Related skills",{"type":40,"tag":49,"props":753,"children":754},{},[755,756,765],{"type":46,"value":714},{"type":40,"tag":68,"props":757,"children":759},{"href":758},"references\u002Fdetails.md#related-skills",[760],{"type":40,"tag":73,"props":761,"children":763},{"className":762},[],[764],{"type":46,"value":724},{"type":46,"value":317},{"items":767,"total":871},[768,785,799,813,825,842,857],{"slug":769,"name":769,"fn":770,"description":771,"org":772,"tags":773,"stars":20,"repoUrl":21,"updatedAt":784},"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},[774,777,780,781],{"name":775,"slug":776,"type":15},"Data Analysis","data-analysis",{"name":778,"slug":779,"type":15},"Data Engineering","data-engineering",{"name":9,"slug":8,"type":15},{"name":782,"slug":783,"type":15},"Performance","performance","2026-07-14T05:28:43.176466",{"slug":786,"name":786,"fn":787,"description":788,"org":789,"tags":790,"stars":20,"repoUrl":21,"updatedAt":798},"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},[791,794,797],{"name":792,"slug":793,"type":15},"Deployment","deployment",{"name":795,"slug":796,"type":15},"Infrastructure","infrastructure",{"name":9,"slug":8,"type":15},"2026-07-14T05:29:06.667109",{"slug":800,"name":800,"fn":801,"description":802,"org":803,"tags":804,"stars":20,"repoUrl":21,"updatedAt":812},"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},[805,808,809],{"name":806,"slug":807,"type":15},"Agents","agents",{"name":9,"slug":8,"type":15},{"name":810,"slug":811,"type":15},"Research","research","2026-07-14T05:28:06.816956",{"slug":814,"name":814,"fn":815,"description":816,"org":817,"tags":818,"stars":20,"repoUrl":21,"updatedAt":824},"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},[819,820,821],{"name":775,"slug":776,"type":15},{"name":9,"slug":8,"type":15},{"name":822,"slug":823,"type":15},"Testing","testing","2026-07-17T05:29:03.913266",{"slug":826,"name":826,"fn":827,"description":828,"org":829,"tags":830,"stars":20,"repoUrl":21,"updatedAt":841},"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},[831,834,837,838],{"name":832,"slug":833,"type":15},"Automation","automation",{"name":835,"slug":836,"type":15},"Imaging","imaging",{"name":9,"slug":8,"type":15},{"name":839,"slug":840,"type":15},"Video","video","2026-07-17T05:28:53.905004",{"slug":843,"name":843,"fn":844,"description":845,"org":846,"tags":847,"stars":20,"repoUrl":21,"updatedAt":856},"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},[848,849,852,853],{"name":792,"slug":793,"type":15},{"name":850,"slug":851,"type":15},"Docker","docker",{"name":9,"slug":8,"type":15},{"name":854,"slug":855,"type":15},"Operations","operations","2026-07-17T05:28:56.913999",{"slug":858,"name":858,"fn":859,"description":860,"org":861,"tags":862,"stars":20,"repoUrl":21,"updatedAt":870},"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},[863,864,867],{"name":9,"slug":8,"type":15},{"name":865,"slug":866,"type":15},"Quantum Computing","quantum-computing",{"name":868,"slug":869,"type":15},"Simulation","simulation","2026-07-14T05:26:58.898253",305,{"items":873,"total":1024},[874,892,908,919,931,945,958,972,983,992,1006,1015],{"slug":875,"name":875,"fn":876,"description":877,"org":878,"tags":879,"stars":889,"repoUrl":890,"updatedAt":891},"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},[880,883,886],{"name":881,"slug":882,"type":15},"Documentation","documentation",{"name":884,"slug":885,"type":15},"MCP","mcp",{"name":887,"slug":888,"type":15},"Search","search",21777,"https:\u002F\u002Fgithub.com\u002FNVIDIA\u002FNemoClaw","2026-07-20T06:00:01.461044",{"slug":893,"name":893,"fn":894,"description":895,"org":896,"tags":897,"stars":905,"repoUrl":906,"updatedAt":907},"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},[898,901,902],{"name":899,"slug":900,"type":15},"Containers","containers",{"name":792,"slug":793,"type":15},{"name":903,"slug":904,"type":15},"Python","python",17049,"https:\u002F\u002Fgithub.com\u002FNVIDIA\u002FMegatron-LM","2026-07-27T06:06:11.249662",{"slug":909,"name":909,"fn":910,"description":911,"org":912,"tags":913,"stars":905,"repoUrl":906,"updatedAt":918},"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},[914,917],{"name":915,"slug":916,"type":15},"CI\u002FCD","ci-cd",{"name":792,"slug":793,"type":15},"2026-07-14T05:25:59.97109",{"slug":920,"name":920,"fn":921,"description":922,"org":923,"tags":924,"stars":905,"repoUrl":906,"updatedAt":930},"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},[925,926,927],{"name":915,"slug":916,"type":15},{"name":792,"slug":793,"type":15},{"name":928,"slug":929,"type":15},"GitHub","github","2026-07-27T06:06:12.278222",{"slug":932,"name":932,"fn":933,"description":934,"org":935,"tags":936,"stars":905,"repoUrl":906,"updatedAt":944},"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},[937,940,941],{"name":938,"slug":939,"type":15},"Debugging","debugging",{"name":928,"slug":929,"type":15},{"name":942,"slug":943,"type":15},"Triage","triage","2026-07-14T05:25:57.442089",{"slug":946,"name":946,"fn":947,"description":948,"org":949,"tags":950,"stars":905,"repoUrl":906,"updatedAt":957},"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},[951,954],{"name":952,"slug":953,"type":15},"Best Practices","best-practices",{"name":955,"slug":956,"type":15},"Code Analysis","code-analysis","2026-07-14T05:25:56.18433",{"slug":959,"name":959,"fn":960,"description":961,"org":962,"tags":963,"stars":905,"repoUrl":906,"updatedAt":971},"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},[964,967,970],{"name":965,"slug":966,"type":15},"Machine Learning","machine-learning",{"name":968,"slug":969,"type":15},"Migration","migration",{"name":9,"slug":8,"type":15},"2026-07-17T06:07:11.777011",{"slug":973,"name":973,"fn":974,"description":975,"org":976,"tags":977,"stars":905,"repoUrl":906,"updatedAt":982},"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},[978,981],{"name":979,"slug":980,"type":15},"QA","qa",{"name":822,"slug":823,"type":15},"2026-07-14T05:25:53.673039",{"slug":984,"name":984,"fn":985,"description":986,"org":987,"tags":988,"stars":905,"repoUrl":906,"updatedAt":991},"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},[989,990],{"name":792,"slug":793,"type":15},{"name":795,"slug":796,"type":15},"2026-07-14T05:25:49.362534",{"slug":993,"name":993,"fn":994,"description":995,"org":996,"tags":997,"stars":905,"repoUrl":906,"updatedAt":1005},"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},[998,1001,1002],{"name":999,"slug":1000,"type":15},"Code Review","code-review",{"name":928,"slug":929,"type":15},{"name":1003,"slug":1004,"type":15},"Pull Requests","pull-requests","2026-07-14T05:26:01.226578",{"slug":1007,"name":1007,"fn":1008,"description":1009,"org":1010,"tags":1011,"stars":905,"repoUrl":906,"updatedAt":1014},"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},[1012,1013],{"name":979,"slug":980,"type":15},{"name":822,"slug":823,"type":15},"2026-07-14T05:25:54.928983",{"slug":1016,"name":1016,"fn":1017,"description":1018,"org":1019,"tags":1020,"stars":905,"repoUrl":906,"updatedAt":1023},"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},[1021,1022],{"name":832,"slug":833,"type":15},{"name":915,"slug":916,"type":15},"2026-07-30T05:29:03.275638",496]