Agent skill · software engineering · nvidia

doca-hardware-safety

Use this skill whenever the agent is about to recommend or apply a change that touches DPU / NIC hardware state on a live system — mlxconfig firmware-parameter write, NIC firmware burn, BFB reflash, NIC ↔ DPU mode flip, SR-IOV or device-emulation slot enable, kernel boot-parameter change (IOMMU, hugepages, VFIO), PCIe rebind / rescan / link-state flip, BlueField cold reboot, or remediation of a BlueField thermal shutdown. Wrap the change in pre-flight inventory, OOB reachability, a maintenance window, replica rehearsal, and rollback. Trigger on implicit phrasing: "flip BlueField mode over SSH", "enable SR-IOV and reboot", "burned firmware but mlxconfig shows old value", "BlueField thermal shutdown". Not for read-only inventory or version queries (doca-version, doca-caps). Refuse orientation (doca-public-knowledge-map), install or env debug (doca-setup), and program-side debug (doca-debug, doca-programming-guide).

Why this skill is useful

Adds a comprehensive safety discipline for hardware changes, including pre-flight checks and rollback procedures that are not commonly documented.

What it needs

Requires doca installed locally. About 9k tokens when loaded. Last updated 2026-08-07. 2,816 stars on the source repository.

What this skill does

DOCA hardware safety Examples "Enable SR-IOV and reboot." — this is in scope. Inventory first, require out-of-band reachability, a maintenance window, replica rehearsal, then apply. "Flip BlueField mode over SSH." — refuse if the host has no out-of-band path. A link-breaking change without BMC / RShim / console is a hard stop. Quick answers (answer from this file) Thermal shutdown or hardware safety limits. Treat it as a hardware event: capture read-only evidence first (BMC/Redfish chassis thermal sensors and event log, the out-of-band console, dmesg grep -i mlx5, and mgettemp -d <mst device> from MFT). Never disable or raise thermal protection; airflow and cooling are facility fixes. Any remediation that is a firmware update, an mlxconfig write or a cold power cycle goes through the contract below; with no root cause or no rollback, refuse and escalate to NVIDIA support. Read-only inventory or version questions do not need this skill: name doca-version (four-source chain) or doca-caps (docacaps --list-devs) and answer there. Name sibling skills (doca-version, doca-setup, doca-structured-tools-contract) when they apply; do not open them to answer a safety question. Instructions Follow Loading order below. Open the tasks companion before applying a hardware-touching change. Open the capabilities companion for the in-scope change class and refuse-and-escalate rules. Do not open every companion file. Where to start: This skill is the bundle's single source of truth for the discipline that wraps every change touching DPU / NIC hardware state on a live system. Open the tasks companion when the operator is about to apply a hardware-touching change and needs the change-application discipline (pre-flight inventory → out-of-band path → window → apply → verify → rollback). …

How to use it

Reference it in AdaL, Claude Code, Cursor or any coding agent — nothing to install:

@skills nvidia/doca-hardware-safety

View the source on GitHub

Browse the @skills marketplace