[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill-nvidia-doca-bf4-deployment":3,"mdc--cqku73-key":34,"related-repo-nvidia-doca-bf4-deployment":908,"related-org-nvidia-doca-bf4-deployment":1012},{"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-bf4-deployment","manage BlueField-4 hardware firmware and lifecycle","WARNING: guides potentially IRREVERSIBLE BlueField-4 hardware operations (PLDM firmware burns, ISO reflashes, power cycles, BMC factory resets) that can brick firmware, corrupt boot media, or cause outages — a maintenance window and rollback plan are required, and every mutating step is governed by doca-hardware-safety, loaded alongside. Use this skill for BlueField-4 (BF4) day-1 platform bring-up from the BMC: installing the BlueField\u002FDOCA bundle ISO onto the DPU (Grace, the Arm complex) over UEFI HTTP Boot, PXE, or Redfish Virtual Media; the PLDM firmware-update flow (BMC, NIC firmware, SBIOS, ERoT) via the Redfish UpdateService and pldmtool; and a Grace Ubuntu image with optional cloud-init. Trigger on BlueField-4\u002FBF4 bring-up phrasings even without \"BF4\": {bring up my new BlueField-4}, {the BlueField ISO will not boot over HTTP from the BMC}, {attach BF4 virtual media via Redfish}, {BF4 firmware Task stuck at Running}. BF3 bring-up, application launch, and library APIs 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,19,20],{"name":13,"slug":14,"type":15},"Hardware","hardware","tag",{"name":17,"slug":18,"type":15},"Deployment","deployment",{"name":9,"slug":8,"type":15},{"name":21,"slug":22,"type":15},"Engineering","engineering",2473,"https:\u002F\u002Fgithub.com\u002FNVIDIA\u002Fskills","2026-07-20T06:24:41.111692","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-bf4-deployment","---\nlicense: Apache-2.0\nname: doca-bf4-deployment\ndescription: >\n  WARNING: guides potentially IRREVERSIBLE BlueField-4 hardware\n  operations (PLDM firmware burns, ISO reflashes, power cycles, BMC\n  factory resets) that can brick firmware, corrupt boot media, or\n  cause outages — a maintenance window and rollback plan are required,\n  and every mutating step is governed by doca-hardware-safety, loaded\n  alongside. Use this skill for BlueField-4 (BF4) day-1 platform\n  bring-up from the BMC: installing the BlueField\u002FDOCA bundle\n  ISO onto the DPU (Grace, the Arm complex) over UEFI HTTP\n  Boot, PXE, or Redfish Virtual Media; the PLDM firmware-update flow\n  (BMC, NIC firmware, SBIOS, ERoT) via the Redfish UpdateService and\n  pldmtool; and a Grace Ubuntu image with optional cloud-init. Trigger\n  on BlueField-4\u002FBF4 bring-up phrasings even without \"BF4\": {bring up\n  my new BlueField-4}, {the BlueField ISO will not boot over HTTP from\n  the BMC}, {attach BF4 virtual media via Redfish}, {BF4 firmware Task\n  stuck at Running}. BF3 bring-up, application launch, and library APIs\n  belong to other skills.\nmetadata:\n  kind: library\ncompatibility: >\n  No DOCA install is required to read this skill; it teaches the\n  documented BlueField-4 BMC-driven bring-up flows (UEFI HTTP Boot,\n  PXE, Redfish Virtual Media, PLDM firmware update). Executing the\n  steps requires a BlueField-4 with an out-of-band-reachable BMC, a\n  host or HTTP\u002FHTTPS server to host the bundle ISO, and the target\n  versions from the public BlueField\u002FDOCA release notes.\n---\n\n# DOCA BlueField-4 (BF4) deployment\n\n> ⚠️ **WARNING — irreversible hardware operations.** This skill guides\n> operators through potentially destructive, irreversible BlueField-4\n> hardware operations: PLDM firmware burns, ISO reflashes, power\n> cycles, and BMC factory resets. These can brick firmware, corrupt\n> boot media, or cause production outages. Do **not** proceed without a\n> maintenance window and a tested rollback plan. Every mutating step is\n> governed by\n> [`doca-hardware-safety`](..\u002Fdoca-hardware-safety\u002FSKILL.md), which\n> MUST be loaded alongside this skill before any destructive action.\n>\n> Before executing any mutating step — PLDM firmware burn, ISO reflash,\n> power cycle, or BMC factory reset — the agent MUST show the exact\n> command and its blast radius (which device, what becomes unavailable,\n> whether it is reversible) and obtain the user's explicit confirmation\n> for that specific action. Never chain destructive steps or run them\n> speculatively as a side effect of another task.\n\n**Where to start:** This skill is the bundle's deliberate in-bundle\nhome for **day-1 platform bring-up of a BlueField-4 DPU via the\nBMC** — getting a powered-but-bare BF4 to \"Grace OS installed,\nfirmware at the target level, ready to deploy a workload.\" It is the\nupstream of the two application-deployment skills\n([`doca-container-deployment`](..\u002Fdoca-container-deployment\u002FSKILL.md)\nand\n[`doca-bare-metal-deployment`](..\u002Fdoca-bare-metal-deployment\u002FSKILL.md)):\nthose skills assume a working BlueField; this skill is how the\nBlueField-4 GETS to working. If the user has a fresh BF4 and wants to\ninstall the OS or update firmware, open [`TASKS.md`](TASKS.md) and\nstart at [`## configure`](TASKS.md#configure). If the question is\n*what bring-up methods even exist and what is the contract for each*,\nstart at [`CAPABILITIES.md`](CAPABILITIES.md).\n\n> **Scope note — BF4 day-1 is in scope by directive.** The bundle's\n> [`AGENTS.md ## Non-goals`](..\u002F..\u002FAGENTS.md#non-goals-questions-the-agent-should-recognize-and-refuse-politely)\n> item 7 lists the BlueField BSP \u002F BFB \u002F RShim \u002F TMFIFO layer and the\n> BlueField BMC software as externally-productized. **BlueField-4\n> day-1 bring-up via the BMC is carved into scope for this skill by\n> directive** because day-1 has no other home in the bundle. The\n> carve-out is narrow: this skill teaches the documented BMC-driven\n> install and firmware-update FLOWS (the CLASS), routing every\n> *mutating* step through\n> [`doca-hardware-safety`](..\u002Fdoca-hardware-safety\u002FSKILL.md) for the\n> change-application meta-policy. It does NOT redefine that\n> meta-policy, and it does NOT cover BF3 (route to\n> `doca-bf3-deployment`), application launch, or library APIs.\n\n## Audience\n\nThis skill serves **external operators standing up a new\nBlueField-4** who already have:\n\n- a BlueField-4 with its BMC reachable out-of-band (BMC SSH plus the\n  documented Redfish endpoint), so the DPU can be driven without\n  physical access,\n- the BlueField\u002FDOCA bundle ISO (and, for the Grace-Ubuntu path, a\n  Grace Ubuntu image) downloaded from the public NVIDIA download\n  surface, hosted at {iso-uri} on the operator's own HTTP\u002FHTTPS\n  server, and\n- the target firmware and OS versions read from the **public\n  BlueField\u002FDOCA release notes** (this skill never quotes a specific\n  pre-release firmware version).\n\nIt is **not** for:\n\n- BlueField-3 (BF3) bring-up — route to `doca-bf3-deployment`,\n- developers who want to RUN a DOCA service container or a DOCA-linked\n  binary on an already-working BlueField — route to\n  [`doca-container-deployment`](..\u002Fdoca-container-deployment\u002FSKILL.md)\n  or\n  [`doca-bare-metal-deployment`](..\u002Fdoca-bare-metal-deployment\u002FSKILL.md),\n- the cross-cutting hardware-change meta-policy itself (preflight, OOB\n  console discipline, maintenance window, rollback) — that is owned by\n  [`doca-hardware-safety`](..\u002Fdoca-hardware-safety\u002FSKILL.md) and this\n  skill cross-links it, never duplicates it,\n- fleet-scale \u002F orchestrated DPU provisioning — that is DOCA Platform\n  Framework territory, routed via\n  [`doca-public-knowledge-map`](..\u002Fdoca-public-knowledge-map\u002FSKILL.md).\n\nThe skill teaches the agent the documented bring-up *procedure* and\nthe rules for quoting Redfish \u002F PLDM \u002F UEFI standard operations and\npublic BlueField\u002FDOCA documentation via\n[`doca-public-knowledge-map`](..\u002Fdoca-public-knowledge-map\u002FSKILL.md);\nit does not invent BMC credentials, ISO URIs, firmware version\nstrings, EIDs, Redfish task IDs, or device names from memory.\n\n## When to load this skill\n\nLoad this skill when the user is doing **hands-on day-1 bring-up of a\nBlueField-4 via the BMC**, or asking a cross-cutting BF4-bring-up\nquestion that is not specific to a later application-deployment step.\nConcretely:\n\n- Installing the BlueField\u002FDOCA bundle ISO onto the DPU (Grace) for\n  the first time, and choosing between the three documented install\n  methods — UEFI HTTP Boot (recommended), PXE Boot, or Redfish\n  Virtual Media.\n- Running the PLDM firmware-update flow across the BMC \u002F NIC firmware\n  \u002F SBIOS \u002F ERoT components: pushing the `.fwpkg` bundle through the\n  Redfish UpdateService multipart endpoint, monitoring the returned\n  Task, verifying pending images with `pldmtool`, and activating with\n  a power cycle.\n- Installing a Grace Ubuntu image (with optional cloud-init via a\n  CIDATA-labelled config ISO) through Redfish Virtual Media, with\n  either local hosting on the BMC eMMC or remote hosting on an\n  HTTPS server.\n- Reaching the DPU's OOB serial console (BMC SSH plus\n  `obmc-console-client`) to watch the installer or UEFI menus.\n- Diagnosing a bring-up that is misbehaving — the ISO will not boot,\n  virtual media will not attach, a firmware Task hangs or reports an\n  Exception, a pending image never activates, cloud-init is ignored,\n  or the DPU is stuck in a boot loop because media was never detached.\n- Cross-cutting questions: *\"HTTP Boot or Redfish Virtual Media — which\n  do I use, and when do I actually need PXE?\"*, *\"how do I know the\n  firmware update actually took effect?\"*, *\"the ISO landed but the\n  NIC firmware update sub-step seems to have failed — what now?\"*.\n\nDo **not** load this skill for BF3 bring-up (route to\n`doca-bf3-deployment`); for running an application on an\nalready-working BlueField (route to\n[`doca-container-deployment`](..\u002Fdoca-container-deployment\u002FSKILL.md)\nor\n[`doca-bare-metal-deployment`](..\u002Fdoca-bare-metal-deployment\u002FSKILL.md));\nfor env preparation on the installed Grace OS such as hugepages \u002F\npkg-config \u002F devlink (use [`doca-setup`](..\u002Fdoca-setup\u002FSKILL.md)); for\nthe cross-cutting hardware-change meta-policy (route to\n[`doca-hardware-safety`](..\u002Fdoca-hardware-safety\u002FSKILL.md)); or for\nfleet-scale orchestrated provisioning (route via\n[`doca-public-knowledge-map`](..\u002Fdoca-public-knowledge-map\u002FSKILL.md)).\n\n## What this skill provides\n\nThis is a **thin loader**. Substantive material lives in two\ncompanion files:\n\n- `CAPABILITIES.md` — the BF4 day-1 bring-up contract: the three OS\n  install methods (UEFI HTTP Boot, PXE Boot, Redfish Virtual Media)\n  and the Grace-Ubuntu-plus-cloud-init Virtual Media path; the PLDM\n  firmware-update surface across BMC \u002F NIC firmware \u002F SBIOS \u002F ERoT;\n  the version-compatibility overlay on\n  [`doca-version`](..\u002Fdoca-version\u002FSKILL.md) (the install and firmware\n  targets come from the public release notes, never from memory); the\n  bring-up error taxonomy (boot-source -> virtual-media-attach ->\n  firmware-Task -> activation -> cloud-init -> boot-loop); the\n  observability surface (the OOB console, the Redfish Task resource,\n  the Redfish FirmwareInventory, `pldmtool` GetFwParams, and the\n  installed-build check `cat \u002Fetc\u002Fmlnx-release`); and the safety\n  policy (an overlay on\n  [`doca-hardware-safety`](..\u002Fdoca-hardware-safety\u002FSKILL.md): every\n  PLDM burn \u002F ISO reflash \u002F power cycle \u002F BMC factory reset is a\n  MUTATING hardware op; never print a real password; always detach\n  virtual media to avoid boot loops; only public hosts for any\n  NVIDIA URL).\n- `TASKS.md` — step-by-step workflows for the in-scope bring-up verbs:\n  `configure`, `build` (routing stub), `modify` (routing stub), `run`\n  (the three install methods plus the PLDM firmware-update flow plus\n  the Grace-Ubuntu cloud-init path, as `###` sub-anchors), `test`\n  (the post-install \u002F post-update verification sweep), `debug` (the\n  layered bring-up diagnosis), and the `Deferred task verbs` block\n  routing BF3 \u002F application-launch \u002F library-API \u002F env-prep \u002F\n  hardware-meta-policy \u002F fleet questions out to their owning skills.\n\nThe skill assumes a BlueField-4 target where:\n\n- the BMC is reachable out-of-band and the operator has BMC\n  credentials ({bmc-user} \u002F {bmc-password}) they supply — never\n  invented here,\n- the bundle ISO (and any Grace Ubuntu image \u002F cloud-init config ISO)\n  is downloaded from the public NVIDIA download surface and hosted at\n  {iso-uri},\n- the operator has read the target firmware and OS versions from the\n  public BlueField\u002FDOCA release notes.\n\nIt does not cover installing DOCA tooling on the host — that path goes\nthrough [`doca-setup`](..\u002Fdoca-setup\u002FSKILL.md) — and it does not cover\nrunning a workload once Grace is up — those paths go through the two\napplication-deployment skills.\n\n## Loading order\n\n1. Read this `SKILL.md` first to confirm the user's question is in\n   scope (BF4 day-1 bring-up via the BMC; NOT BF3, NOT application\n   launch, NOT a library-API question, NOT the hardware-change\n   meta-policy itself).\n2. **For the bring-up contract (the three install methods, the\n   Grace-Ubuntu cloud-init path, the PLDM firmware-update surface, the\n   version overlay, the bring-up error taxonomy, the observability\n   surface, and the BF4 safety overlay), see\n   [CAPABILITIES.md](CAPABILITIES.md).**\n3. **For step-by-step workflows — `configure`, `build` (routing\n   stub), `modify` (routing stub), `run` (with the three install\n   methods, the PLDM flow, and the Grace-Ubuntu cloud-init path as\n   `###` sub-anchors), `test`, `debug`, plus the `Deferred task verbs`\n   block — see [TASKS.md](TASKS.md).**\n4. **Load\n   [`doca-hardware-safety`](..\u002Fdoca-hardware-safety\u002FSKILL.md)\n   ALONGSIDE** whenever the question reaches a mutating step (PLDM\n   firmware burn, ISO reflash, power cycle, BMC factory reset).\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":35,"body":39},{"license":26,"name":4,"description":6,"metadata":36,"compatibility":38},{"kind":37},"library","No DOCA install is required to read this skill; it teaches the documented BlueField-4 BMC-driven bring-up flows (UEFI HTTP Boot, PXE, Redfish Virtual Media, PLDM firmware update). Executing the steps requires a BlueField-4 with an out-of-band-reachable BMC, a host or HTTP\u002FHTTPS server to host the bundle ISO, and the target versions from the public BlueField\u002FDOCA release notes.\n",{"type":40,"children":41},"root",[42,51,95,178,235,242,254,281,292,362,384,390,402,478,547,553,565,687,692,710,725,731,846,852,868,874,888,894],{"type":43,"tag":44,"props":45,"children":47},"element","h1",{"id":46},"doca-bluefield-4-bf4-deployment",[48],{"type":49,"value":50},"text","DOCA BlueField-4 (BF4) deployment",{"type":43,"tag":52,"props":53,"children":54},"blockquote",{},[55,90],{"type":43,"tag":56,"props":57,"children":58},"p",{},[59,61,67,69,74,76,88],{"type":49,"value":60},"⚠️ ",{"type":43,"tag":62,"props":63,"children":64},"strong",{},[65],{"type":49,"value":66},"WARNING — irreversible hardware operations.",{"type":49,"value":68}," This skill guides\noperators through potentially destructive, irreversible BlueField-4\nhardware operations: PLDM firmware burns, ISO reflashes, power\ncycles, and BMC factory resets. These can brick firmware, corrupt\nboot media, or cause production outages. Do ",{"type":43,"tag":62,"props":70,"children":71},{},[72],{"type":49,"value":73},"not",{"type":49,"value":75}," proceed without a\nmaintenance window and a tested rollback plan. Every mutating step is\ngoverned by\n",{"type":43,"tag":77,"props":78,"children":80},"a",{"href":79},"..\u002Fdoca-hardware-safety\u002FSKILL.md",[81],{"type":43,"tag":82,"props":83,"children":85},"code",{"className":84},[],[86],{"type":49,"value":87},"doca-hardware-safety",{"type":49,"value":89},", which\nMUST be loaded alongside this skill before any destructive action.",{"type":43,"tag":56,"props":91,"children":92},{},[93],{"type":49,"value":94},"Before executing any mutating step — PLDM firmware burn, ISO reflash,\npower cycle, or BMC factory reset — the agent MUST show the exact\ncommand and its blast radius (which device, what becomes unavailable,\nwhether it is reversible) and obtain the user's explicit confirmation\nfor that specific action. Never chain destructive steps or run them\nspeculatively as a side effect of another task.",{"type":43,"tag":56,"props":96,"children":97},{},[98,103,105,110,112,122,124,134,136,145,147,157,159,165,167,176],{"type":43,"tag":62,"props":99,"children":100},{},[101],{"type":49,"value":102},"Where to start:",{"type":49,"value":104}," This skill is the bundle's deliberate in-bundle\nhome for ",{"type":43,"tag":62,"props":106,"children":107},{},[108],{"type":49,"value":109},"day-1 platform bring-up of a BlueField-4 DPU via the\nBMC",{"type":49,"value":111}," — getting a powered-but-bare BF4 to \"Grace OS installed,\nfirmware at the target level, ready to deploy a workload.\" It is the\nupstream of the two application-deployment skills\n(",{"type":43,"tag":77,"props":113,"children":115},{"href":114},"..\u002Fdoca-container-deployment\u002FSKILL.md",[116],{"type":43,"tag":82,"props":117,"children":119},{"className":118},[],[120],{"type":49,"value":121},"doca-container-deployment",{"type":49,"value":123},"\nand\n",{"type":43,"tag":77,"props":125,"children":127},{"href":126},"..\u002Fdoca-bare-metal-deployment\u002FSKILL.md",[128],{"type":43,"tag":82,"props":129,"children":131},{"className":130},[],[132],{"type":49,"value":133},"doca-bare-metal-deployment",{"type":49,"value":135},"):\nthose skills assume a working BlueField; this skill is how the\nBlueField-4 GETS to working. If the user has a fresh BF4 and wants to\ninstall the OS or update firmware, open ",{"type":43,"tag":77,"props":137,"children":139},{"href":138},"TASKS.md",[140],{"type":43,"tag":82,"props":141,"children":143},{"className":142},[],[144],{"type":49,"value":138},{"type":49,"value":146}," and\nstart at ",{"type":43,"tag":77,"props":148,"children":150},{"href":149},"TASKS.md#configure",[151],{"type":43,"tag":82,"props":152,"children":154},{"className":153},[],[155],{"type":49,"value":156},"## configure",{"type":49,"value":158},". If the question is\n",{"type":43,"tag":160,"props":161,"children":162},"em",{},[163],{"type":49,"value":164},"what bring-up methods even exist and what is the contract for each",{"type":49,"value":166},",\nstart at ",{"type":43,"tag":77,"props":168,"children":170},{"href":169},"CAPABILITIES.md",[171],{"type":43,"tag":82,"props":172,"children":174},{"className":173},[],[175],{"type":49,"value":169},{"type":49,"value":177},".",{"type":43,"tag":52,"props":179,"children":180},{},[181],{"type":43,"tag":56,"props":182,"children":183},{},[184,189,191,201,203,208,210,215,217,225,227,233],{"type":43,"tag":62,"props":185,"children":186},{},[187],{"type":49,"value":188},"Scope note — BF4 day-1 is in scope by directive.",{"type":49,"value":190}," The bundle's\n",{"type":43,"tag":77,"props":192,"children":194},{"href":193},"..\u002F..\u002FAGENTS.md#non-goals-questions-the-agent-should-recognize-and-refuse-politely",[195],{"type":43,"tag":82,"props":196,"children":198},{"className":197},[],[199],{"type":49,"value":200},"AGENTS.md ## Non-goals",{"type":49,"value":202},"\nitem 7 lists the BlueField BSP \u002F BFB \u002F RShim \u002F TMFIFO layer and the\nBlueField BMC software as externally-productized. ",{"type":43,"tag":62,"props":204,"children":205},{},[206],{"type":49,"value":207},"BlueField-4\nday-1 bring-up via the BMC is carved into scope for this skill by\ndirective",{"type":49,"value":209}," because day-1 has no other home in the bundle. The\ncarve-out is narrow: this skill teaches the documented BMC-driven\ninstall and firmware-update FLOWS (the CLASS), routing every\n",{"type":43,"tag":160,"props":211,"children":212},{},[213],{"type":49,"value":214},"mutating",{"type":49,"value":216}," step through\n",{"type":43,"tag":77,"props":218,"children":219},{"href":79},[220],{"type":43,"tag":82,"props":221,"children":223},{"className":222},[],[224],{"type":49,"value":87},{"type":49,"value":226}," for the\nchange-application meta-policy. It does NOT redefine that\nmeta-policy, and it does NOT cover BF3 (route to\n",{"type":43,"tag":82,"props":228,"children":230},{"className":229},[],[231],{"type":49,"value":232},"doca-bf3-deployment",{"type":49,"value":234},"), application launch, or library APIs.",{"type":43,"tag":236,"props":237,"children":239},"h2",{"id":238},"audience",[240],{"type":49,"value":241},"Audience",{"type":43,"tag":56,"props":243,"children":244},{},[245,247,252],{"type":49,"value":246},"This skill serves ",{"type":43,"tag":62,"props":248,"children":249},{},[250],{"type":49,"value":251},"external operators standing up a new\nBlueField-4",{"type":49,"value":253}," who already have:",{"type":43,"tag":255,"props":256,"children":257},"ul",{},[258,264,269],{"type":43,"tag":259,"props":260,"children":261},"li",{},[262],{"type":49,"value":263},"a BlueField-4 with its BMC reachable out-of-band (BMC SSH plus the\ndocumented Redfish endpoint), so the DPU can be driven without\nphysical access,",{"type":43,"tag":259,"props":265,"children":266},{},[267],{"type":49,"value":268},"the BlueField\u002FDOCA bundle ISO (and, for the Grace-Ubuntu path, a\nGrace Ubuntu image) downloaded from the public NVIDIA download\nsurface, hosted at {iso-uri} on the operator's own HTTP\u002FHTTPS\nserver, and",{"type":43,"tag":259,"props":270,"children":271},{},[272,274,279],{"type":49,"value":273},"the target firmware and OS versions read from the ",{"type":43,"tag":62,"props":275,"children":276},{},[277],{"type":49,"value":278},"public\nBlueField\u002FDOCA release notes",{"type":49,"value":280}," (this skill never quotes a specific\npre-release firmware version).",{"type":43,"tag":56,"props":282,"children":283},{},[284,286,290],{"type":49,"value":285},"It is ",{"type":43,"tag":62,"props":287,"children":288},{},[289],{"type":49,"value":73},{"type":49,"value":291}," for:",{"type":43,"tag":255,"props":293,"children":294},{},[295,307,331,346],{"type":43,"tag":259,"props":296,"children":297},{},[298,300,305],{"type":49,"value":299},"BlueField-3 (BF3) bring-up — route to ",{"type":43,"tag":82,"props":301,"children":303},{"className":302},[],[304],{"type":49,"value":232},{"type":49,"value":306},",",{"type":43,"tag":259,"props":308,"children":309},{},[310,312,320,322,330],{"type":49,"value":311},"developers who want to RUN a DOCA service container or a DOCA-linked\nbinary on an already-working BlueField — route to\n",{"type":43,"tag":77,"props":313,"children":314},{"href":114},[315],{"type":43,"tag":82,"props":316,"children":318},{"className":317},[],[319],{"type":49,"value":121},{"type":49,"value":321},"\nor\n",{"type":43,"tag":77,"props":323,"children":324},{"href":126},[325],{"type":43,"tag":82,"props":326,"children":328},{"className":327},[],[329],{"type":49,"value":133},{"type":49,"value":306},{"type":43,"tag":259,"props":332,"children":333},{},[334,336,344],{"type":49,"value":335},"the cross-cutting hardware-change meta-policy itself (preflight, OOB\nconsole discipline, maintenance window, rollback) — that is owned by\n",{"type":43,"tag":77,"props":337,"children":338},{"href":79},[339],{"type":43,"tag":82,"props":340,"children":342},{"className":341},[],[343],{"type":49,"value":87},{"type":49,"value":345}," and this\nskill cross-links it, never duplicates it,",{"type":43,"tag":259,"props":347,"children":348},{},[349,351,361],{"type":49,"value":350},"fleet-scale \u002F orchestrated DPU provisioning — that is DOCA Platform\nFramework territory, routed via\n",{"type":43,"tag":77,"props":352,"children":354},{"href":353},"..\u002Fdoca-public-knowledge-map\u002FSKILL.md",[355],{"type":43,"tag":82,"props":356,"children":358},{"className":357},[],[359],{"type":49,"value":360},"doca-public-knowledge-map",{"type":49,"value":177},{"type":43,"tag":56,"props":363,"children":364},{},[365,367,372,374,382],{"type":49,"value":366},"The skill teaches the agent the documented bring-up ",{"type":43,"tag":160,"props":368,"children":369},{},[370],{"type":49,"value":371},"procedure",{"type":49,"value":373}," and\nthe rules for quoting Redfish \u002F PLDM \u002F UEFI standard operations and\npublic BlueField\u002FDOCA documentation via\n",{"type":43,"tag":77,"props":375,"children":376},{"href":353},[377],{"type":43,"tag":82,"props":378,"children":380},{"className":379},[],[381],{"type":49,"value":360},{"type":49,"value":383},";\nit does not invent BMC credentials, ISO URIs, firmware version\nstrings, EIDs, Redfish task IDs, or device names from memory.",{"type":43,"tag":236,"props":385,"children":387},{"id":386},"when-to-load-this-skill",[388],{"type":49,"value":389},"When to load this skill",{"type":43,"tag":56,"props":391,"children":392},{},[393,395,400],{"type":49,"value":394},"Load this skill when the user is doing ",{"type":43,"tag":62,"props":396,"children":397},{},[398],{"type":49,"value":399},"hands-on day-1 bring-up of a\nBlueField-4 via the BMC",{"type":49,"value":401},", or asking a cross-cutting BF4-bring-up\nquestion that is not specific to a later application-deployment step.\nConcretely:",{"type":43,"tag":255,"props":403,"children":404},{},[405,410,431,436,449,454],{"type":43,"tag":259,"props":406,"children":407},{},[408],{"type":49,"value":409},"Installing the BlueField\u002FDOCA bundle ISO onto the DPU (Grace) for\nthe first time, and choosing between the three documented install\nmethods — UEFI HTTP Boot (recommended), PXE Boot, or Redfish\nVirtual Media.",{"type":43,"tag":259,"props":411,"children":412},{},[413,415,421,423,429],{"type":49,"value":414},"Running the PLDM firmware-update flow across the BMC \u002F NIC firmware\n\u002F SBIOS \u002F ERoT components: pushing the ",{"type":43,"tag":82,"props":416,"children":418},{"className":417},[],[419],{"type":49,"value":420},".fwpkg",{"type":49,"value":422}," bundle through the\nRedfish UpdateService multipart endpoint, monitoring the returned\nTask, verifying pending images with ",{"type":43,"tag":82,"props":424,"children":426},{"className":425},[],[427],{"type":49,"value":428},"pldmtool",{"type":49,"value":430},", and activating with\na power cycle.",{"type":43,"tag":259,"props":432,"children":433},{},[434],{"type":49,"value":435},"Installing a Grace Ubuntu image (with optional cloud-init via a\nCIDATA-labelled config ISO) through Redfish Virtual Media, with\neither local hosting on the BMC eMMC or remote hosting on an\nHTTPS server.",{"type":43,"tag":259,"props":437,"children":438},{},[439,441,447],{"type":49,"value":440},"Reaching the DPU's OOB serial console (BMC SSH plus\n",{"type":43,"tag":82,"props":442,"children":444},{"className":443},[],[445],{"type":49,"value":446},"obmc-console-client",{"type":49,"value":448},") to watch the installer or UEFI menus.",{"type":43,"tag":259,"props":450,"children":451},{},[452],{"type":49,"value":453},"Diagnosing a bring-up that is misbehaving — the ISO will not boot,\nvirtual media will not attach, a firmware Task hangs or reports an\nException, a pending image never activates, cloud-init is ignored,\nor the DPU is stuck in a boot loop because media was never detached.",{"type":43,"tag":259,"props":455,"children":456},{},[457,459,464,466,471,472,477],{"type":49,"value":458},"Cross-cutting questions: ",{"type":43,"tag":160,"props":460,"children":461},{},[462],{"type":49,"value":463},"\"HTTP Boot or Redfish Virtual Media — which\ndo I use, and when do I actually need PXE?\"",{"type":49,"value":465},", ",{"type":43,"tag":160,"props":467,"children":468},{},[469],{"type":49,"value":470},"\"how do I know the\nfirmware update actually took effect?\"",{"type":49,"value":465},{"type":43,"tag":160,"props":473,"children":474},{},[475],{"type":49,"value":476},"\"the ISO landed but the\nNIC firmware update sub-step seems to have failed — what now?\"",{"type":49,"value":177},{"type":43,"tag":56,"props":479,"children":480},{},[481,483,487,489,494,496,504,505,513,515,525,527,535,537,545],{"type":49,"value":482},"Do ",{"type":43,"tag":62,"props":484,"children":485},{},[486],{"type":49,"value":73},{"type":49,"value":488}," load this skill for BF3 bring-up (route to\n",{"type":43,"tag":82,"props":490,"children":492},{"className":491},[],[493],{"type":49,"value":232},{"type":49,"value":495},"); for running an application on an\nalready-working BlueField (route to\n",{"type":43,"tag":77,"props":497,"children":498},{"href":114},[499],{"type":43,"tag":82,"props":500,"children":502},{"className":501},[],[503],{"type":49,"value":121},{"type":49,"value":321},{"type":43,"tag":77,"props":506,"children":507},{"href":126},[508],{"type":43,"tag":82,"props":509,"children":511},{"className":510},[],[512],{"type":49,"value":133},{"type":49,"value":514},");\nfor env preparation on the installed Grace OS such as hugepages \u002F\npkg-config \u002F devlink (use ",{"type":43,"tag":77,"props":516,"children":518},{"href":517},"..\u002Fdoca-setup\u002FSKILL.md",[519],{"type":43,"tag":82,"props":520,"children":522},{"className":521},[],[523],{"type":49,"value":524},"doca-setup",{"type":49,"value":526},"); for\nthe cross-cutting hardware-change meta-policy (route to\n",{"type":43,"tag":77,"props":528,"children":529},{"href":79},[530],{"type":43,"tag":82,"props":531,"children":533},{"className":532},[],[534],{"type":49,"value":87},{"type":49,"value":536},"); or for\nfleet-scale orchestrated provisioning (route via\n",{"type":43,"tag":77,"props":538,"children":539},{"href":353},[540],{"type":43,"tag":82,"props":541,"children":543},{"className":542},[],[544],{"type":49,"value":360},{"type":49,"value":546},").",{"type":43,"tag":236,"props":548,"children":550},{"id":549},"what-this-skill-provides",[551],{"type":49,"value":552},"What this skill provides",{"type":43,"tag":56,"props":554,"children":555},{},[556,558,563],{"type":49,"value":557},"This is a ",{"type":43,"tag":62,"props":559,"children":560},{},[561],{"type":49,"value":562},"thin loader",{"type":49,"value":564},". Substantive material lives in two\ncompanion files:",{"type":43,"tag":255,"props":566,"children":567},{},[568,615],{"type":43,"tag":259,"props":569,"children":570},{},[571,576,578,588,590,595,597,603,605,613],{"type":43,"tag":82,"props":572,"children":574},{"className":573},[],[575],{"type":49,"value":169},{"type":49,"value":577}," — the BF4 day-1 bring-up contract: the three OS\ninstall methods (UEFI HTTP Boot, PXE Boot, Redfish Virtual Media)\nand the Grace-Ubuntu-plus-cloud-init Virtual Media path; the PLDM\nfirmware-update surface across BMC \u002F NIC firmware \u002F SBIOS \u002F ERoT;\nthe version-compatibility overlay on\n",{"type":43,"tag":77,"props":579,"children":581},{"href":580},"..\u002Fdoca-version\u002FSKILL.md",[582],{"type":43,"tag":82,"props":583,"children":585},{"className":584},[],[586],{"type":49,"value":587},"doca-version",{"type":49,"value":589}," (the install and firmware\ntargets come from the public release notes, never from memory); the\nbring-up error taxonomy (boot-source -> virtual-media-attach ->\nfirmware-Task -> activation -> cloud-init -> boot-loop); the\nobservability surface (the OOB console, the Redfish Task resource,\nthe Redfish FirmwareInventory, ",{"type":43,"tag":82,"props":591,"children":593},{"className":592},[],[594],{"type":49,"value":428},{"type":49,"value":596}," GetFwParams, and the\ninstalled-build check ",{"type":43,"tag":82,"props":598,"children":600},{"className":599},[],[601],{"type":49,"value":602},"cat \u002Fetc\u002Fmlnx-release",{"type":49,"value":604},"); and the safety\npolicy (an overlay on\n",{"type":43,"tag":77,"props":606,"children":607},{"href":79},[608],{"type":43,"tag":82,"props":609,"children":611},{"className":610},[],[612],{"type":49,"value":87},{"type":49,"value":614},": every\nPLDM burn \u002F ISO reflash \u002F power cycle \u002F BMC factory reset is a\nMUTATING hardware op; never print a real password; always detach\nvirtual media to avoid boot loops; only public hosts for any\nNVIDIA URL).",{"type":43,"tag":259,"props":616,"children":617},{},[618,623,625,631,632,638,640,646,647,653,655,661,663,669,671,677,679,685],{"type":43,"tag":82,"props":619,"children":621},{"className":620},[],[622],{"type":49,"value":138},{"type":49,"value":624}," — step-by-step workflows for the in-scope bring-up verbs:\n",{"type":43,"tag":82,"props":626,"children":628},{"className":627},[],[629],{"type":49,"value":630},"configure",{"type":49,"value":465},{"type":43,"tag":82,"props":633,"children":635},{"className":634},[],[636],{"type":49,"value":637},"build",{"type":49,"value":639}," (routing stub), ",{"type":43,"tag":82,"props":641,"children":643},{"className":642},[],[644],{"type":49,"value":645},"modify",{"type":49,"value":639},{"type":43,"tag":82,"props":648,"children":650},{"className":649},[],[651],{"type":49,"value":652},"run",{"type":49,"value":654},"\n(the three install methods plus the PLDM firmware-update flow plus\nthe Grace-Ubuntu cloud-init path, as ",{"type":43,"tag":82,"props":656,"children":658},{"className":657},[],[659],{"type":49,"value":660},"###",{"type":49,"value":662}," sub-anchors), ",{"type":43,"tag":82,"props":664,"children":666},{"className":665},[],[667],{"type":49,"value":668},"test",{"type":49,"value":670},"\n(the post-install \u002F post-update verification sweep), ",{"type":43,"tag":82,"props":672,"children":674},{"className":673},[],[675],{"type":49,"value":676},"debug",{"type":49,"value":678}," (the\nlayered bring-up diagnosis), and the ",{"type":43,"tag":82,"props":680,"children":682},{"className":681},[],[683],{"type":49,"value":684},"Deferred task verbs",{"type":49,"value":686}," block\nrouting BF3 \u002F application-launch \u002F library-API \u002F env-prep \u002F\nhardware-meta-policy \u002F fleet questions out to their owning skills.",{"type":43,"tag":56,"props":688,"children":689},{},[690],{"type":49,"value":691},"The skill assumes a BlueField-4 target where:",{"type":43,"tag":255,"props":693,"children":694},{},[695,700,705],{"type":43,"tag":259,"props":696,"children":697},{},[698],{"type":49,"value":699},"the BMC is reachable out-of-band and the operator has BMC\ncredentials ({bmc-user} \u002F {bmc-password}) they supply — never\ninvented here,",{"type":43,"tag":259,"props":701,"children":702},{},[703],{"type":49,"value":704},"the bundle ISO (and any Grace Ubuntu image \u002F cloud-init config ISO)\nis downloaded from the public NVIDIA download surface and hosted at\n{iso-uri},",{"type":43,"tag":259,"props":706,"children":707},{},[708],{"type":49,"value":709},"the operator has read the target firmware and OS versions from the\npublic BlueField\u002FDOCA release notes.",{"type":43,"tag":56,"props":711,"children":712},{},[713,715,723],{"type":49,"value":714},"It does not cover installing DOCA tooling on the host — that path goes\nthrough ",{"type":43,"tag":77,"props":716,"children":717},{"href":517},[718],{"type":43,"tag":82,"props":719,"children":721},{"className":720},[],[722],{"type":49,"value":524},{"type":49,"value":724}," — and it does not cover\nrunning a workload once Grace is up — those paths go through the two\napplication-deployment skills.",{"type":43,"tag":236,"props":726,"children":728},{"id":727},"loading-order",[729],{"type":49,"value":730},"Loading order",{"type":43,"tag":732,"props":733,"children":734},"ol",{},[735,748,761,826],{"type":43,"tag":259,"props":736,"children":737},{},[738,740,746],{"type":49,"value":739},"Read this ",{"type":43,"tag":82,"props":741,"children":743},{"className":742},[],[744],{"type":49,"value":745},"SKILL.md",{"type":49,"value":747}," first to confirm the user's question is in\nscope (BF4 day-1 bring-up via the BMC; NOT BF3, NOT application\nlaunch, NOT a library-API question, NOT the hardware-change\nmeta-policy itself).",{"type":43,"tag":259,"props":749,"children":750},{},[751],{"type":43,"tag":62,"props":752,"children":753},{},[754,756,760],{"type":49,"value":755},"For the bring-up contract (the three install methods, the\nGrace-Ubuntu cloud-init path, the PLDM firmware-update surface, the\nversion overlay, the bring-up error taxonomy, the observability\nsurface, and the BF4 safety overlay), see\n",{"type":43,"tag":77,"props":757,"children":758},{"href":169},[759],{"type":49,"value":169},{"type":49,"value":177},{"type":43,"tag":259,"props":762,"children":763},{},[764],{"type":43,"tag":62,"props":765,"children":766},{},[767,769,774,775,780,782,787,788,793,795,800,801,806,807,812,814,819,821,825],{"type":49,"value":768},"For step-by-step workflows — ",{"type":43,"tag":82,"props":770,"children":772},{"className":771},[],[773],{"type":49,"value":630},{"type":49,"value":465},{"type":43,"tag":82,"props":776,"children":778},{"className":777},[],[779],{"type":49,"value":637},{"type":49,"value":781}," (routing\nstub), ",{"type":43,"tag":82,"props":783,"children":785},{"className":784},[],[786],{"type":49,"value":645},{"type":49,"value":639},{"type":43,"tag":82,"props":789,"children":791},{"className":790},[],[792],{"type":49,"value":652},{"type":49,"value":794}," (with the three install\nmethods, the PLDM flow, and the Grace-Ubuntu cloud-init path as\n",{"type":43,"tag":82,"props":796,"children":798},{"className":797},[],[799],{"type":49,"value":660},{"type":49,"value":662},{"type":43,"tag":82,"props":802,"children":804},{"className":803},[],[805],{"type":49,"value":668},{"type":49,"value":465},{"type":43,"tag":82,"props":808,"children":810},{"className":809},[],[811],{"type":49,"value":676},{"type":49,"value":813},", plus the ",{"type":43,"tag":82,"props":815,"children":817},{"className":816},[],[818],{"type":49,"value":684},{"type":49,"value":820},"\nblock — see ",{"type":43,"tag":77,"props":822,"children":823},{"href":138},[824],{"type":49,"value":138},{"type":49,"value":177},{"type":43,"tag":259,"props":827,"children":828},{},[829,844],{"type":43,"tag":62,"props":830,"children":831},{},[832,834,842],{"type":49,"value":833},"Load\n",{"type":43,"tag":77,"props":835,"children":836},{"href":79},[837],{"type":43,"tag":82,"props":838,"children":840},{"className":839},[],[841],{"type":49,"value":87},{"type":49,"value":843},"\nALONGSIDE",{"type":49,"value":845}," whenever the question reaches a mutating step (PLDM\nfirmware burn, ISO reflash, power cycle, BMC factory reset).",{"type":43,"tag":236,"props":847,"children":849},{"id":848},"example-questions-this-skill-answers-well",[850],{"type":49,"value":851},"Example questions this skill answers well",{"type":43,"tag":56,"props":853,"children":854},{},[855,857,867],{"type":49,"value":856},"See ",{"type":43,"tag":77,"props":858,"children":860},{"href":859},"references\u002Fdetails.md#example-questions-this-skill-answers-well",[861],{"type":43,"tag":82,"props":862,"children":864},{"className":863},[],[865],{"type":49,"value":866},"references\u002Fdetails.md",{"type":49,"value":177},{"type":43,"tag":236,"props":869,"children":871},{"id":870},"what-this-skill-deliberately-does-not-ship",[872],{"type":49,"value":873},"What this skill deliberately does not ship",{"type":43,"tag":56,"props":875,"children":876},{},[877,878,887],{"type":49,"value":856},{"type":43,"tag":77,"props":879,"children":881},{"href":880},"references\u002Fdetails.md#what-this-skill-deliberately-does-not-ship",[882],{"type":43,"tag":82,"props":883,"children":885},{"className":884},[],[886],{"type":49,"value":866},{"type":49,"value":177},{"type":43,"tag":236,"props":889,"children":891},{"id":890},"related-skills",[892],{"type":49,"value":893},"Related skills",{"type":43,"tag":56,"props":895,"children":896},{},[897,898,907],{"type":49,"value":856},{"type":43,"tag":77,"props":899,"children":901},{"href":900},"references\u002Fdetails.md#related-skills",[902],{"type":43,"tag":82,"props":903,"children":905},{"className":904},[],[906],{"type":49,"value":866},{"type":49,"value":177},{"items":909,"total":1011},[910,927,939,953,965,982,997],{"slug":911,"name":911,"fn":912,"description":913,"org":914,"tags":915,"stars":23,"repoUrl":24,"updatedAt":926},"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},[916,919,922,923],{"name":917,"slug":918,"type":15},"Data Analysis","data-analysis",{"name":920,"slug":921,"type":15},"Data Engineering","data-engineering",{"name":9,"slug":8,"type":15},{"name":924,"slug":925,"type":15},"Performance","performance","2026-07-14T05:28:43.176466",{"slug":928,"name":928,"fn":929,"description":930,"org":931,"tags":932,"stars":23,"repoUrl":24,"updatedAt":938},"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},[933,934,937],{"name":17,"slug":18,"type":15},{"name":935,"slug":936,"type":15},"Infrastructure","infrastructure",{"name":9,"slug":8,"type":15},"2026-07-14T05:29:06.667109",{"slug":940,"name":940,"fn":941,"description":942,"org":943,"tags":944,"stars":23,"repoUrl":24,"updatedAt":952},"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},[945,948,949],{"name":946,"slug":947,"type":15},"Agents","agents",{"name":9,"slug":8,"type":15},{"name":950,"slug":951,"type":15},"Research","research","2026-07-14T05:28:06.816956",{"slug":954,"name":954,"fn":955,"description":956,"org":957,"tags":958,"stars":23,"repoUrl":24,"updatedAt":964},"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},[959,960,961],{"name":917,"slug":918,"type":15},{"name":9,"slug":8,"type":15},{"name":962,"slug":963,"type":15},"Testing","testing","2026-07-17T05:29:03.913266",{"slug":966,"name":966,"fn":967,"description":968,"org":969,"tags":970,"stars":23,"repoUrl":24,"updatedAt":981},"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},[971,974,977,978],{"name":972,"slug":973,"type":15},"Automation","automation",{"name":975,"slug":976,"type":15},"Imaging","imaging",{"name":9,"slug":8,"type":15},{"name":979,"slug":980,"type":15},"Video","video","2026-07-17T05:28:53.905004",{"slug":983,"name":983,"fn":984,"description":985,"org":986,"tags":987,"stars":23,"repoUrl":24,"updatedAt":996},"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},[988,989,992,993],{"name":17,"slug":18,"type":15},{"name":990,"slug":991,"type":15},"Docker","docker",{"name":9,"slug":8,"type":15},{"name":994,"slug":995,"type":15},"Operations","operations","2026-07-17T05:28:56.913999",{"slug":998,"name":998,"fn":999,"description":1000,"org":1001,"tags":1002,"stars":23,"repoUrl":24,"updatedAt":1010},"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},[1003,1004,1007],{"name":9,"slug":8,"type":15},{"name":1005,"slug":1006,"type":15},"Quantum Computing","quantum-computing",{"name":1008,"slug":1009,"type":15},"Simulation","simulation","2026-07-14T05:26:58.898253",305,{"items":1013,"total":1164},[1014,1032,1048,1059,1071,1085,1098,1112,1123,1132,1146,1155],{"slug":1015,"name":1015,"fn":1016,"description":1017,"org":1018,"tags":1019,"stars":1029,"repoUrl":1030,"updatedAt":1031},"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},[1020,1023,1026],{"name":1021,"slug":1022,"type":15},"Documentation","documentation",{"name":1024,"slug":1025,"type":15},"MCP","mcp",{"name":1027,"slug":1028,"type":15},"Search","search",21777,"https:\u002F\u002Fgithub.com\u002FNVIDIA\u002FNemoClaw","2026-07-20T06:00:01.461044",{"slug":1033,"name":1033,"fn":1034,"description":1035,"org":1036,"tags":1037,"stars":1045,"repoUrl":1046,"updatedAt":1047},"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},[1038,1041,1042],{"name":1039,"slug":1040,"type":15},"Containers","containers",{"name":17,"slug":18,"type":15},{"name":1043,"slug":1044,"type":15},"Python","python",17049,"https:\u002F\u002Fgithub.com\u002FNVIDIA\u002FMegatron-LM","2026-07-27T06:06:11.249662",{"slug":1049,"name":1049,"fn":1050,"description":1051,"org":1052,"tags":1053,"stars":1045,"repoUrl":1046,"updatedAt":1058},"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},[1054,1057],{"name":1055,"slug":1056,"type":15},"CI\u002FCD","ci-cd",{"name":17,"slug":18,"type":15},"2026-07-14T05:25:59.97109",{"slug":1060,"name":1060,"fn":1061,"description":1062,"org":1063,"tags":1064,"stars":1045,"repoUrl":1046,"updatedAt":1070},"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},[1065,1066,1067],{"name":1055,"slug":1056,"type":15},{"name":17,"slug":18,"type":15},{"name":1068,"slug":1069,"type":15},"GitHub","github","2026-07-27T06:06:12.278222",{"slug":1072,"name":1072,"fn":1073,"description":1074,"org":1075,"tags":1076,"stars":1045,"repoUrl":1046,"updatedAt":1084},"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},[1077,1080,1081],{"name":1078,"slug":1079,"type":15},"Debugging","debugging",{"name":1068,"slug":1069,"type":15},{"name":1082,"slug":1083,"type":15},"Triage","triage","2026-07-14T05:25:57.442089",{"slug":1086,"name":1086,"fn":1087,"description":1088,"org":1089,"tags":1090,"stars":1045,"repoUrl":1046,"updatedAt":1097},"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},[1091,1094],{"name":1092,"slug":1093,"type":15},"Best Practices","best-practices",{"name":1095,"slug":1096,"type":15},"Code Analysis","code-analysis","2026-07-14T05:25:56.18433",{"slug":1099,"name":1099,"fn":1100,"description":1101,"org":1102,"tags":1103,"stars":1045,"repoUrl":1046,"updatedAt":1111},"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},[1104,1107,1110],{"name":1105,"slug":1106,"type":15},"Machine Learning","machine-learning",{"name":1108,"slug":1109,"type":15},"Migration","migration",{"name":9,"slug":8,"type":15},"2026-07-17T06:07:11.777011",{"slug":1113,"name":1113,"fn":1114,"description":1115,"org":1116,"tags":1117,"stars":1045,"repoUrl":1046,"updatedAt":1122},"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},[1118,1121],{"name":1119,"slug":1120,"type":15},"QA","qa",{"name":962,"slug":963,"type":15},"2026-07-14T05:25:53.673039",{"slug":1124,"name":1124,"fn":1125,"description":1126,"org":1127,"tags":1128,"stars":1045,"repoUrl":1046,"updatedAt":1131},"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},[1129,1130],{"name":17,"slug":18,"type":15},{"name":935,"slug":936,"type":15},"2026-07-14T05:25:49.362534",{"slug":1133,"name":1133,"fn":1134,"description":1135,"org":1136,"tags":1137,"stars":1045,"repoUrl":1046,"updatedAt":1145},"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},[1138,1141,1142],{"name":1139,"slug":1140,"type":15},"Code Review","code-review",{"name":1068,"slug":1069,"type":15},{"name":1143,"slug":1144,"type":15},"Pull Requests","pull-requests","2026-07-14T05:26:01.226578",{"slug":1147,"name":1147,"fn":1148,"description":1149,"org":1150,"tags":1151,"stars":1045,"repoUrl":1046,"updatedAt":1154},"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},[1152,1153],{"name":1119,"slug":1120,"type":15},{"name":962,"slug":963,"type":15},"2026-07-14T05:25:54.928983",{"slug":1156,"name":1156,"fn":1157,"description":1158,"org":1159,"tags":1160,"stars":1045,"repoUrl":1046,"updatedAt":1163},"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},[1161,1162],{"name":972,"slug":973,"type":15},{"name":1055,"slug":1056,"type":15},"2026-07-30T05:29:03.275638",496]