DOCA Upgrade Control
Safely gate DOCA upgrades and rollbacks with explicit confirmation.
The skill explicitly requires detect, report, and user confirmation before acting; forbids automatic upgrades; requires a rollback path and maintenance window; and delegates firmware, reboot, and hardware actions to a safety skill. Deductions apply because credential and sensitive-data handling are only generic card-level reminders, while dependency security, privilege boundaries, command isolation, and executable rollback details are not concretely verified here.
SKILL.md, CAPABILITIES.md, and TASKS.md present a largely consistent detect, confirm, execute, verify, and diagnose flow. Static materials provide no runnable scripts, real CI, or committed tests covering key paths; behavior depends on companion skills, a live installation, and external release information, so reproducibility and diagnosable failure handling remain limited under the static ceiling.
Triggers, use cases, upgrade modes, and out-of-scope routing are relatively clear and cover host packages, BFB, container tags, and rollback. Deductions apply because core operation depends on a live DOCA installation, other skills, and public release notes; Chinese-language interaction and mainland-China reachability are not addressed, and some trigger wording is broad.
The documentation is layered into a loader, capability reference, and task workflows, with examples, environment requirements, related skills, limitations, version-card information, and maintenance context. Deductions apply for missing explicit authorship, changelog, and concrete maintenance/update ownership, plus inconsistent licensing metadata: the prompt reports NOASSERTION, SKILL.md says Apache-2.0, while the card and repository describe Apache-2.0 plus CC-BY-4.0.
The skill offers a directly usable overall discipline for detect, gap reporting, confirmation, guided upgrade, verification, and failure diagnosis, and the benchmark records limited security, correctness, and effectiveness results. Deductions apply because the evaluation dataset is unavailable, key commands are not demonstrated as executable in the target environment, and substantial implementation steps are delegated to other skills.
The materials provide a pinned revision, an evaluation summary, evaluation prompts, and references to official documentation, giving some auditability. Deductions apply because the evaluation dataset is absent, there is no real CI or committed key-path test suite, and many claims depend on unavailable companion skills and live external sources, leaving static corroboration thin.
- Before execution, verify that the companion skills, /opt/mellanox/doca environment, release notes, and hardware-safety workflow are actually available; no commands were executed in this review.
- Do not treat the benchmark PASS or percentages as independently reproducible evidence because the evaluation dataset is not provided.
- Reconcile the license and maintenance metadata, and verify reachability of public DOCA documentation from mainland-China networks.
What does this skill do, and when should you use it?
This skill governs DOCA upgrades and downgrades across host packages, BlueField BFB images, NGC DOCA container tags, and rollback scenarios. Its core discipline is detect, report, ask, and only then perform a guided change; it never upgrades automatically. For a planned move, it reports the installed release, available target, and migration cost before waiting for explicit confirmation. Failed or partial moves enter diagnosis and recovery, while hardware, firmware, reboot, and version-detection responsibilities are delegated to companion skills.
Loads TASKS.md and CAPABILITIES.md for upgrade-specific guidance; coordinates detection of the installed DOCA environment and discovery of a newer release; reports the version gap and upgrade cost; runs a confirmation-gated guided upgrade or downgrade; verifies the post-upgrade four-way state; classifies partial upgrades, apt-source drift, host/BFB skew, and interrupted dpkg transactions; and routes version detection, public release information, and hardware-safety procedures to related skills.
- A DOCA user wants to know whether a newer release exists and how far behind the current installation is.
- An operator wants to move a host to the next DOCA release through apt but requires an approval checkpoint before commands run.
- A host upgrade leaves the installed host release different from the BlueField BFB release.
- An interrupted apt transaction leaves dpkg wedged and requires a documented recovery path.
- A deployment team wants to bump an NGC DOCA container tag or roll back to an earlier release.
What are this skill's strengths and limitations?
- Enforces a clear never-auto-upgrade policy with an explicit confirmation gate.
- Covers host apt upgrades, BFB refreshes, container-tag bumps, and rollback modes.
- Provides recovery routing for partial upgrades, apt-source drift, host/BFB skew, and interrupted dpkg transactions.
- Separates version detection and hardware-safety responsibilities into dedicated companion skills.
- Live DOCA installation at /opt/mellanox/doca is required for detection, gap reporting, and guided upgrade steps.
- Hardware, firmware, or reboot work additionally requires a BlueField DPU or ConnectX NIC and out-of-band console access.
- The SKILL.md is a thin loader and depends on TASKS.md and CAPABILITIES.md for substantive workflows.
- The supplied source does not provide independent test results, a platform support matrix, or concrete upgrade command sequences.
How do you install this skill?
In an Agent Skills-compatible environment, run: npx skills add nvidia/skills --skill doca-upgrade --yes. The repository README states that the CLI installs a selected skill without requiring a repository clone or manual folder copying.
How do you use this skill?
After installation, ask a relevant question such as “is there a newer DOCA than what I have?”, “should I move to the next release?”, or “roll me back to the previous DOCA”. For a planned move, the skill detects and reports the gap, then stops for explicit confirmation. For a failed move, describe the current failure so it can enter the debug workflow. The detailed workflows are in TASKS.md, and the capability and error taxonomy are in CAPABILITIES.md.
How does this skill compare with similar options?
The skill explicitly routes first-time installation to doca-setup, version detection to doca-version, and hardware, firmware, and reboot safety to doca-hardware-safety; it is not a replacement for those skills.