SkillsAdd

nvidia/skills

doca-bf4-deployment

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/DOCA bundle ISO onto the DPU (Grace, the Arm complex) over UEFI HTTP Boot, PXE, or Redfish Virtual Media; the PLDM firmwa…

First seen Jul 18, 2026

Installation

$ npx skills add nvidia/skills --skill doca-bf4-deployment
View on skills.sh ↗ GitHub repository ↗

Similar popular skills

Related neighbors and high-traction skills in the same topics — useful to compare before installing.

expo-deployment Similar name
expo/skills 41K installs
azure-deployment-preflight Similar name
github/awesome-copilot

Performs comprehensive preflight validation of Bicep deployments to Azure, including template s…

9.6K installs
aws-deployment Similar name
aws/agent-toolkit-for-aws

Configures CI/CD pipelines using AWS CodePipeline, CodeBuild, CodeDeploy, CodeConnections, and …

3.6K installs
access-protected-vercel-deployment Similar name
vercel/vercel-plugin

Access protected Vercel URLs with vercel curl or a short-lived OIDC token

2.3K installs
deployment Similar name
railwayapp/railway-skills

This skill should be used when the user wants to manage Railway deployments, view logs, or debu…

1.1K installs
mcloud-deployments Similar name
medusajs/medusa-agent-skills

Execute mcloud deployments commands to list deployments, retrieve deployment details, and fetch…

10 installs

Also in this package

Other skills from nvidia/skills · top by installs.

npx skills add nvidia/skills
rag-blueprint 2.9K accelerated-computing-cudf 2.8K aiq-research 2.8K cuopt-developer 2.5K aiq-deploy 2.4K cuopt-install 2.4K cudaq-guide 2.4K data-designer 2.2K deepstream-dev 2.2K omniverse-cad-to-simready 2.2K

Browse all from nvidia/skills

More details

Agent compatibility

Declared targets from SKILL.md / docs. Unmarked agents are not listed — the skill may still install via the CLI.

Claude Code Not declared
Cursor Not declared
Codex Not declared
GitHub Copilot Not declared
Windsurf Not declared
Gemini CLI Not declared
Cline Not declared
OpenCode Not declared

Repository health

Stars 3.2K
License LICENSE-APACHE
Default branch main
Open issues 5
Status Active

Skill metadata

Parsed from SKILL.md frontmatter.

LicenseApache-2.0
CompatibilityNo 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/HTTPS server to host the bundle ISO, and the target versions from the public BlueField/DOCA release notes.
More metadata
kind
library

Package contents

Files included with this skill beyond the listing page.

  • skill md SKILL.md 12,247 B
  • docs SUMMARY.md 1,040 B

History

  1. First seen on skills.sh
  2. First recorded snapshot · 134 installs

SKILL.md

DOCA BlueField-4 (BF4) deployment

⚠️ WARNING — irreversible hardware operations. This skill guides
operators through potentially destructive, irreversible BlueField-4
hardware operations: PLDM firmware burns, ISO reflashes, power
cycles, and BMC factory resets. These can brick firmware, corrupt
boot media, or cause production outages. Do not proceed without a
maintenance window and a tested rollback plan. Every mutating step is
governed by
[doca-hardware-safety](../doca-hardware-safety/SKILL.md), which
MUST be loaded alongside this skill before any destructive action.

Before executing any mutating step — PLDM firmware burn, ISO reflash,
power cycle, or BMC factory reset — the agent MUST show the exact
command and its blast radius (which device, what becomes unavailable,
whether it is reversible) and obtain the user's explicit confirmation
for that specific action. Never chain destructive steps or run them
speculatively as a side effect of another task.

Where to start: This skill is the bundle's deliberate in-bundle home for day-1 platform bring-up of a BlueField-4 DPU via the BMC — getting a powered-but-bare BF4 to "Grace OS installed, firmware at the target level, ready to deploy a workload." It is the upstream of the two application-deployment skills ([doca-container-deployment](../doca-container-deployment/SKILL.md) and [doca-bare-metal-deployment](../doca-bare-metal-deployment/SKILL.md)): those skills assume a working BlueField; this skill is how the BlueField-4 GETS to working. If the user has a fresh BF4 and wants to install the OS or update firmware, open [TASKS.md](TASKS.md) and start at [## configure](TASKS.md#configure). If the question is what bring-up methods even exist and what is the contract for each, start at [CAPABILITIES.md](CAPABILITIES.md).

Scope note — BF4 day-1 is in scope by directive. The bundle's
[AGENTS.md ## Non-goals](../../AGENTS.md#non-goals-questions-the-agent-should-recognize-and-refuse-politely)
item 7 lists the BlueField BSP / BFB / RShim / TMFIFO layer and the
BlueField BMC software as externally-productized. **BlueField-4
day-1 bring-up via the BMC is carved into scope for this skill by
directive** because day-1 has no other home in the bundle. The
carve-out is narrow: this skill teaches the documented BMC-driven
install and firmware-update FLOWS (the CLASS), routing every
mutating step through
[doca-hardware-safety](../doca-hardware-safety/SKILL.md) for the
change-application meta-policy. It does NOT redefine that
meta-policy, and it does NOT cover BF3 (route to
doca-bf3-deployment), application launch, or library APIs.

Audience

This skill serves external operators standing up a new BlueField-4 who already have:

  • a BlueField-4 with its BMC reachable out-of-band (BMC SSH plus the

documented Redfish endpoint), so the DPU can be driven without physical access,

  • the BlueField/DOCA bundle ISO (and, for the Grace-Ubuntu path, a

Grace Ubuntu image) downloaded from the public NVIDIA download surface, hosted at {iso-uri} on the operator's own HTTP/HTTPS server, and

  • the target firmware and OS versions read from the **public

BlueField/DOCA release notes** (this skill never quotes a specific pre-release firmware version).

It is not for:

  • BlueField-3 (BF3) bring-up — route to doca-bf3-deployment,
  • developers who want to RUN a DOCA service container or a DOCA-linked

binary on an already-working BlueField — route to [doca-container-deployment](../doca-container-deployment/SKILL.md) or [doca-bare-metal-deployment](../doca-bare-metal-deployment/SKILL.md),

  • the cross-cutting hardware-change meta-policy itself (preflight, OOB

console discipline, maintenance window, rollback) — that is owned by [doca-hardware-safety](../doca-hardware-safety/SKILL.md) and this skill cross-links it, never duplicates it,

  • fleet-scale / orchestrated DPU provisioning — that is DOCA Platform

Framework territory, routed via [doca-public-knowledge-map](../doca-public-knowledge-map/SKILL.md).

The skill teaches the agent the documented bring-up procedure and the rules for quoting Redfish / PLDM / UEFI standard operations and public BlueField/DOCA documentation via [doca-public-knowledge-map](../doca-public-knowledge-map/SKILL.md); it does not invent BMC credentials, ISO URIs, firmware version strings, EIDs, Redfish task IDs, or device names from memory.

When to load this skill

Load this skill when the user is doing hands-on day-1 bring-up of a BlueField-4 via the BMC, or asking a cross-cutting BF4-bring-up question that is not specific to a later application-deployment step. Concretely:

  • Installing the BlueField/DOCA bundle ISO onto the DPU (Grace) for

the first time, and choosing between the three documented install methods — UEFI HTTP Boot (recommended), PXE Boot, or Redfish Virtual Media.

  • Running the PLDM firmware-update flow across the BMC / NIC firmware

/ SBIOS / ERoT components: pushing the .fwpkg bundle through the Redfish UpdateService multipart endpoint, monitoring the returned Task, verifying pending images with pldmtool, and activating with a power cycle.

  • Installing a Grace Ubuntu image (with optional cloud-init via a

CIDATA-labelled config ISO) through Redfish Virtual Media, with either local hosting on the BMC eMMC or remote hosting on an HTTPS server.

  • Reaching the DPU's OOB serial console (BMC SSH plus

obmc-console-client) to watch the installer or UEFI menus.

  • Diagnosing a bring-up that is misbehaving — the ISO will not boot,

virtual media will not attach, a firmware Task hangs or reports an Exception, a pending image never activates, cloud-init is ignored, or the DPU is stuck in a boot loop because media was never detached.

  • Cross-cutting questions: *"HTTP Boot or Redfish Virtual Media — which

do I use, and when do I actually need PXE?", "how do I know the firmware update actually took effect?", "the ISO landed but the NIC firmware update sub-step seems to have failed — what now?"*.

Do not load this skill for BF3 bring-up (route to doca-bf3-deployment); for running an application on an already-working BlueField (route to [doca-container-deployment](../doca-container-deployment/SKILL.md) or [doca-bare-metal-deployment](../doca-bare-metal-deployment/SKILL.md)); for env preparation on the installed Grace OS such as hugepages / pkg-config / devlink (use [doca-setup](../doca-setup/SKILL.md)); for the cross-cutting hardware-change meta-policy (route to [doca-hardware-safety](../doca-hardware-safety/SKILL.md)); or for fleet-scale orchestrated provisioning (route via [doca-public-knowledge-map](../doca-public-knowledge-map/SKILL.md)).

What this skill provides

This is a thin loader. Substantive material lives in two companion files:

  • CAPABILITIES.md — the BF4 day-1 bring-up contract: the three OS

install methods (UEFI HTTP Boot, PXE Boot, Redfish Virtual Media) and the Grace-Ubuntu-plus-cloud-init Virtual Media path; the PLDM firmware-update surface across BMC / NIC firmware / SBIOS / ERoT; the version-compatibility overlay on [doca-version](../doca-version/SKILL.md) (the install and firmware targets come from the public release notes, never from memory); the bring-up error taxonomy (boot-source -> virtual-media-attach -> firmware-Task -> activation -> cloud-init -> boot-loop); the observability surface (the OOB console, the Redfish Task resource, the Redfish FirmwareInventory, pldmtool GetFwParams, and the installed-build check cat /etc/mlnx-release); and the safety policy (an overlay on [doca-hardware-safety](../doca-hardware-safety/SKILL.md): every PLDM burn / ISO reflash / power cycle / BMC factory reset is a MUTATING hardware op; never print a real password; always detach virtual media to avoid boot loops; only public hosts for any NVIDIA URL).

  • TASKS.md — step-by-step workflows for the in-scope bring-up verbs:

configure, build (routing stub), modify (routing stub), run (the three install methods plus the PLDM firmware-update flow plus the Grace-Ubuntu cloud-init path, as ### sub-anchors), test (the post-install / post-update verification sweep), debug (the layered bring-up diagnosis), and the Deferred task verbs block routing BF3 / application-launch / library-API / env-prep / hardware-meta-policy / fleet questions out to their owning skills.

The skill assumes a BlueField-4 target where:

  • the BMC is reachable out-of-band and the operator has BMC

credentials ({bmc-user} / {bmc-password}) they supply — never invented here,

  • the bundle ISO (and any Grace Ubuntu image / cloud-init config ISO)

is downloaded from the public NVIDIA download surface and hosted at {iso-uri},

  • the operator has read the target firmware and OS versions from the

public BlueField/DOCA release notes.

It does not cover installing DOCA tooling on the host — that path goes through [doca-setup](../doca-setup/SKILL.md) — and it does not cover running a workload once Grace is up — those paths go through the two application-deployment skills.

Loading order

  1. Read this SKILL.md first to confirm the user's question is in

scope (BF4 day-1 bring-up via the BMC; NOT BF3, NOT application launch, NOT a library-API question, NOT the hardware-change meta-policy itself).

  1. **For the bring-up contract (the three install methods, the

Grace-Ubuntu cloud-init path, the PLDM firmware-update surface, the version overlay, the bring-up error taxonomy, the observability surface, and the BF4 safety overlay), see [CAPABILITIES.md](CAPABILITIES.md).**

  1. **For step-by-step workflows — configure, build (routing

stub), modify (routing stub), run (with the three install methods, the PLDM flow, and the Grace-Ubuntu cloud-init path as ### sub-anchors), test, debug, plus the Deferred task verbs block — see [TASKS.md](TASKS.md).**

  1. **Load

[doca-hardware-safety](../doca-hardware-safety/SKILL.md) ALONGSIDE** whenever the question reaches a mutating step (PLDM firmware burn, ISO reflash, power cycle, BMC factory reset).

Example questions this skill answers well

See [references/details.md](references/details.md#example-questions-this-skill-answers-well).

What this skill deliberately does not ship

See [references/details.md](references/details.md#what-this-skill-deliberately-does-not-ship).

Related skills

See [references/details.md](references/details.md#related-skills).