Doca Bf4 Deployment by NVIDIA — AI Skill for Any LLM

Overview

Publisher	NVIDIA
Repository	`skills`
Skill name	`doca-bf4-deployment`
Stars	3.3K
Forks	397
Bundled files	7
License	Apache-2.0
Links	Skill source Repository Homepage

Markdown instructions

A SKILL.md file the model loads on demand, so it only costs tokens when a request actually matches.

Works with any LLM

AI skills are plain Markdown, not provider-specific code, so this works with GPT, Claude, Gemini, Grok, or a local model.

7 bundled files

Scripts, templates, and references the model can read while it works. Files are read-only and never executed.

Open source

Published by NVIDIA on GitHub. Read the source before you install it.

Installation

Install the Doca Bf4 Deployment AI skill in TypingMind to use it with any LLM, or drop it into another agent that reads SKILL.md.

Install in TypingMind

TypingMind installs a skill straight from its GitHub folder — it reads SKILL.md, bundles the resource files, and stores the result locally.

Open the app and go to Plugins → Skills.
Choose "Install from GitHub".
Paste the skill folder URL below and confirm.
Enable the skill in any chat where you want it available.

Plugins → Skills → Add skill → From GitHub URL, then paste the folder URL and press Continue.

Install in another agent

Any agent that reads the Agent Skills format can use this skill — copy the folder into that agent's skills directory.

Claude Code — .claude/skills

git clone --depth 1 https://github.com/NVIDIA/skills.git /tmp/skills
mkdir -p .claude/skills
cp -r /tmp/skills/skills/doca-bf4-deployment .claude/skills/doca-bf4-deployment

Restart Claude Code after copying so it picks up the new skill.

Use it in TypingMind

Enable Doca Bf4 Deployment in any TypingMind chat and the model takes it from there. Its name and description sit in the system prompt, and the moment a request matches, the model loads the full instructions itself — you never invoke it by hand, and it costs no tokens until it is actually used.

The model loads Doca Bf4 Deployment on its own as soon as a request matches it.

Works with any AI model

AI skills are plain Markdown instructions rather than provider-specific code, so Doca Bf4 Deployment is not tied to the model it was written for. Install it once in TypingMind and use it with GPT-5, Claude, Gemini, Grok, DeepSeek, Mistral, Llama, or a local model you run yourself — all on your own API keys.

Loaded only when it is needed

The system prompt carries just the name and description. The instructions are fetched on the first matching request, so an idle skill costs nothing.

Switch models mid-chat

Because the skill is instructions rather than code, changing model does not break it — the next model reads the same SKILL.md.

Skill instructions

This is the SKILL.md content the model loads. Read it before installing — a skill is instructions your model will follow.

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, 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 and doca-bare-metal-deployment): 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 and start at ## configure. If the question is what bring-up methods even exist and what is the contract for each, start at CAPABILITIES.md.

Scope note — BF4 day-1 is in scope by directive. The bundle's AGENTS.md ## Non-goals 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 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 or doca-bare-metal-deployment,
the cross-cutting hardware-change meta-policy itself (preflight, OOB console discipline, maintenance window, rollback) — that is owned by doca-hardware-safety 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.

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; 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 or doca-bare-metal-deployment); for env preparation on the installed Grace OS such as hugepages / pkg-config / devlink (use doca-setup); for the cross-cutting hardware-change meta-policy (route to doca-hardware-safety); or for fleet-scale orchestrated provisioning (route via doca-public-knowledge-map).

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 (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: 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 — and it does not cover running a workload once Grace is up — those paths go through the two application-deployment skills.

Loading order

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).
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.
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.
Load doca-hardware-safety ALONGSIDE whenever the question reaches a mutating step (PLDM firmware burn, ISO reflash, power cycle, BMC factory reset).

Frequently asked questions

What does the Doca Bf4 Deployment AI skill do?

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/DOCA 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, S...

Why use Doca Bf4 Deployment on TypingMind?

Because you install it once and use it with any model. Doca Bf4 Deployment is plain Markdown rather than provider-specific code, so the same skill runs on GPT-5, Claude, Gemini, Grok, or a local model — and you can switch model mid-chat without it breaking. TypingMind runs on your own API keys, so you pay providers directly instead of a per-seat subscription, and your skills and chats stay in your own storage.

How do I install Doca Bf4 Deployment in TypingMind?

Open Plugins → Skills → Install from GitHub in TypingMind and paste https://github.com/NVIDIA/skills/tree/main/skills/doca-bf4-deployment. TypingMind reads its SKILL.md and bundles its files and installs it as a skill you can enable per chat.

Which AI models can use Doca Bf4 Deployment?

Any model you connect in TypingMind. AI skills are plain Markdown instructions rather than provider-specific code, so GPT, Claude, Gemini, Grok, and local models can all load this skill when a request matches it.

How many AI models can I use with Doca Bf4 Deployment?

As many as you like. As long as a model supports skills, you can use Doca Bf4 Deployment with it — GPT, Claude, Gemini, Grok, DeepSeek, Mistral, Llama and more — all on TypingMind with your own API keys.

Is the Doca Bf4 Deployment AI skill free?

Yes. It is published on GitHub by NVIDIA under the Apache-2.0 license. You only pay your own AI provider for the tokens you use.

What are AI skills?

An AI skill is a reusable instruction bundle that teaches an AI model how to do one specific task. It follows the open Agent Skills format: a SKILL.md file with a name and description, plus any scripts, templates or reference files the model may need. The model reads the instructions only when your request matches the skill, so an installed skill costs nothing until it is used.

How are AI skills different from plugins or MCP servers?

A plugin or MCP server gives a model new tools to call — code that runs somewhere and returns a result. An AI skill gives the model knowledge and process instead: how to approach a task, which steps to follow, what good output looks like. Skills are plain Markdown, so they need no server, no API key and no runtime, and they work with any model.

Overview

Installation

Install in TypingMind

Install in another agent

Use it in TypingMind

Works with any AI model

Skill instructions

DOCA BlueField-4 (BF4) deployment

Audience

When to load this skill

What this skill provides

Loading order

Example questions this skill answers well

What this skill deliberately does not ship

Related skills

Bundled files

Frequently asked questions

Related AI Skills

Set up your own AI workspace now