DOCA Hardware Safety
A rollback-oriented operating discipline for live DPU and NIC hardware changes.
SKILL.md, CAPABILITIES.md, and TASKS.md define scoped hardware classes, pre-flight inventory, out-of-band access, maintenance windows, operator-confirmed prerequisites, cold-power-cycle rules, replica rehearsal, rollback, and refusal without rollback. skill-card.md also states that credentials are not required and secrets must not be included. Points are deducted because the skill governs real high-impact operations while authorization, approvals, data-flow details, and recovery endpoints remain operator-supplied, and companion-skill dependencies are not independently verified here.
The workflow order, failure taxonomy, refusal behavior, and rollback ladder are substantially consistent, and the companion files are present in the supplied evidence. Static review cannot establish runnable key paths; there is no reproducible command-level test or real CI coverage, several concrete actions are delegated to other skills, and the benchmark's claimed dataset is unavailable.
SKILL.md clearly defines hardware change classes, implicit trigger phrases, and out-of-scope scenarios across BlueField, ConnectX, firmware, kernel, PCIe, and reboot operations. Points are deducted because this is primarily a cross-skill safety overlay rather than a standalone operational guide, and Chinese-language support, localized operations, and mainland-China network reachability are not documented.
The loader, CAPABILITIES.md, TASKS.md, evaluation files, and skill card provide useful progressive structure, dependencies, version anchors, limitations, ownership, and update guidance. Points are deducted because frontmatter declares Apache-2.0 while skill-card.md declares Apache 2.0 AND CC-BY-4.0; author information, changelog, explicit version-maintenance responsibility, and concrete troubleshooting entry points are incomplete. The benchmark also reports missing Instructions/Examples sections.
The skill provides a coherent safety discipline for high-risk hardware changes: inventory, OOB access, maintenance window, application, verification, replica rehearsal, and rollback, with explicit refusal conditions. Points are deducted because it is a thin loader: exact commands, parameters, device versions, and artifact health checks require other skills or operator runbooks. Static evidence does not show directly usable execution output, and the benchmark effectiveness claims are not independently reproducible.
The supplied files contain structured workflow rules, class tables, failure modes, and rollback requirements that support auditability. However, there is no committed test suite, CI coverage, or independently reproducible experiment; BENCHMARK.md provides only aggregate figures and states that the source evaluation dataset was unavailable. Verifiability is therefore limited.
- This is a static review; no commands were executed and hardware actions, rollback paths, or benchmark results were not independently verified.
- Before execution, supply the exact device context, authorization, maintenance window, OOB endpoint, baseline snapshot, version anchors, and a rehearsed rollback procedure.
- Resolve the Apache-2.0 versus Apache 2.0 AND CC-BY-4.0 metadata inconsistency, and add author, version, changelog, and reproducible test evidence.
- Chinese output and mainland-China environment support are undocumented; do not treat the benchmark summary figures as independent proof.
What does this skill do, and when should you use it?
This skill covers live-system changes to DPU and NIC hardware state, including mlxconfig writes, firmware burns, BFB reflashes, mode changes, SR-IOV, PCIe state, and BlueField reboots. It requires pre-flight inventory, out-of-band reachability, a time-boxed maintenance window, representative replica rehearsal, and rollback preparation. Production work is routed through configure, test, modify, run verification, and debug/rollback stages. It is a cross-cutting safety layer and does not contain artifact-specific firmware-slot, kernel-parameter, or container-tag instructions.
Determines whether a request activates the hardware-safety overlay; directs the agent to SKILL.md, CAPABILITIES.md, and TASKS.md; structures inventory capture, out-of-band confirmation, maintenance-window planning, replica testing, rollback rehearsal, production application, and post-change verification; and applies the stated cold-power-cycle discipline to mlxconfig-class changes.
- An operator is about to switch a BlueField between NIC and DPU mode over SSH and needs to protect the management path.
- A network engineer plans to enable SR-IOV, device-emulation slots, or PCIe changes and needs a controlled change plan.
- A firmware engineer is preparing a NIC firmware burn or BlueField BFB reflash during a production maintenance window.
- A platform engineer is changing IOMMU, VFIO, or hugepage boot state before a host reboot.
- A production request lacks rollback, out-of-band access, a maintenance window, or representative replica validation and must be refused or escalated.
What are this skill's strengths and limitations?
- Covers mlxconfig, firmware/BFB operations, kernel state, PCIe, SR-IOV, and BlueField reboot risks.
- Makes maintenance windows, out-of-band access, representative replicas, verification, and documented rollback explicit gates.
- Provides a reusable cross-cutting policy that overlays artifact-specific DOCA safety guidance.
- The repository README describes signed publication, evaluation artifacts, and daily synchronization.
- The substantive workflow is delegated to CAPABILITIES.md and TASKS.md, which are not included in the supplied material.
- Validation requires a live DOCA installation, BlueField or ConnectX hardware, and out-of-band console reachability.
- It does not specify artifact-level firmware slots, exact kernel parameters, or container tags.
- The supplied material provides no evidence of support for particular hardware models, firmware combinations, or comprehensive test coverage.
How do you install this skill?
Install the individual skill with the CLI command documented by the repository README:
npx skills add nvidia/skills --skill doca-hardware-safety --yes
The README does not specify a fixed destination; the CLI prompts for the installation location.
How do you use this skill?
After installation in an Agent Skills-compatible client, invoke it for requests involving live DPU/NIC hardware state, for example: “Plan a safe BlueField mode switch over SSH with SR-IOV enabled.” The skill should state the activation explicitly and route the answer through configure → test → modify → run → debug.