AutoGineer
Generated banner for Doca Upgrade
Generated logo for Doca Upgrade

Doca Upgrade

NVIDIAOfficialCreated by NVIDIA

  • Skill
  • Workflow
  • Software development
  • Apache-2.0
  • Medium risk
Download ZIP

From the author

Changing DOCA versions safely: upgrading or downgrading the host DOCA packages, refreshing the BlueField BFB, bumping the NGC DOCA container tag, or rolling back, with the discipline detect -> report -> ASK -> only then a guided upgrade. Trigger on "is there a newer DOCA", "I want the newest DOCA features, can I just apt upgrade in place", "should I move to the next release", "the upgrade stopped midway and dpkg is in a broken state", "my component is being deprecated, what now", or "roll me back", even without the word upgrade. Detect what is installed, find the newer release, report the gap, then STOP and ask for explicit confirmation; never upgrade automatically. Do not use it for a runtime error on an unchanged install (doca-debug). Version detection alone belongs to doca-version, first-time install to doca-setup, any hardware / firmware / reboot step to doca-hardware-safety, and public-docs or sunset routing to doca-public-knowledge-map.
— the description by NVIDIA

AutoGineer summary

Written by AutoGineer from the skill’s own files, not by the author

The doca-upgrade skill provides a structured, safety-first approach to managing DOCA software versions. It enforces a strict detect-report-ask-act workflow to prevent accidental or broken upgrades. The skill covers host package upgrades, BlueField BFB refreshes, and container tag updates. It is designed to handle planned version transitions as well as recovery from failed or partial upgrades, ensuring that all hardware-related safety steps are delegated to appropriate specialized skills.

What it does

  • Detects currently installed DOCA versions across host and DPU components.
  • Reports the version gap between the current install and the target release.
  • Enforces a mandatory confirmation gate before executing any upgrade commands.
  • Provides a recovery ladder for interrupted or failed package installations.
  • Routes hardware, firmware, and reboot requirements to the dedicated safety skill.
  • Identifies if components are on a deprecation or sunset track.

When to use it

  • When you need to upgrade or downgrade your DOCA software environment.
  • When an upgrade was interrupted and left the system in a broken state.
  • When you need to verify if a newer DOCA release is available for your setup.
  • When you need to update NGC DOCA container tags.
  • When you suspect your DOCA packages have drifted due to system-wide updates.

Advantages

  • Prevents accidental system breakage by requiring explicit user confirmation.
  • Standardizes the upgrade process across different DOCA deployment types.
  • Provides clear recovery paths for common upgrade failure scenarios.
  • Maintains system integrity by delegating hardware-sensitive tasks to safety-focused modules.

Usage examples

“Should I move to the next DOCA release?”
The agent will detect your current version, report the available target release, explain the gap, and stop to wait for your explicit confirmation.
“The upgrade aborted half-way and dpkg is in a broken state.”
The agent will diagnose the partial upgrade, identify the interrupted transaction, and guide you through the recovery ladder to stabilize the package database.

Install

  1. Download the skill as a ZIP:

    https://autogineer.com/agent-skills/nvidia/doca-upgrade/download

  2. Unzip it into the cross-client skills folder of your project:

    mkdir -p .agents/skills && unzip doca-upgrade.zip -d .agents/skills

Documentation by NVIDIA

DOCA upgrade

Examples

  • "Should I move to the next DOCA release?" — detect what is installed, report the gap, then STOP and ask. Never auto-upgrade.

  • "apt upgrade drifted my DOCA packages." — this is recovery, not a silent repair. Detect, report, ask, then guide.

Quick answers (answer from this file)

  • Not changing versions (a runtime error on the current, pinned install)? This skill does not apply: name doca-debug and stop.

These two answers are complete here; open TASKS.md only for a guided upgrade after the user confirms. Run only the read-only detection commands yourself. Package commands (sudo dpkg, apt, apt-get) need root and change the system: give them to the user to run and stop; in an agent shell sudo waits for a password and the session stalls.

  • "Can I just apt upgrade to the next DOCA?" Never upgrade automatically. Detect the installed release with the doca-version four-source chain (pkg-config --modversion doca-common, cat /opt/mellanox/doca/applications/VERSION, doca_caps --version, and the BFB version on BlueField), report the gap to the target release, then STOP and ask for explicit confirmation. BFB, firmware or reboot steps follow doca-hardware-safety.

  • "The upgrade aborted half-way and dpkg reports an interrupted transaction." Recover the package database first: after the user explicitly confirms (both commands change system package state), the user runs sudo dpkg --configure -a, then sudo apt-get -f install (Debian/Ubuntu). Do not re-run the upgrade as the first action; re-detect the release with doca-version before deciding the next step.

Instructions

Follow Loading order below. Open the tasks companion for detect → report → ASK → guided upgrade. Open the capabilities companion for the upgrade-mode taxonomy and refuse-auto-upgrade rule. Do not open every companion file.

Where to start: This skill is the bundle's single source of truth for the discipline that wraps a DOCA upgrade or downgrade. Open the tasks companion when the user wants to do something with an upgrade (detect the gap, ask for confirmation, walk the guided upgrade, verify it, or diagnose a failed one); open the capabilities companion when the question is what does an upgrade even cover (the host apt-upgrade vs BFB reflash vs container-tag bump vs downgrade/rollback modes, the never-auto rule, the confirmation gate, the sunset-awareness concern, the error taxonomy, and the upgrade-specific safety overlay).

How to use this skill. Read this file, then search the companion file for the ## <name> heading the question needs and read that whole section. Answer completely from it, quoting only its symbols and commands. Do not browse docs; use the entry points in doca-public-knowledge-map. Give environment checks as commands for the user's DOCA host. For out-of-scope requests, name the skill that owns them and stop.

For a planned move, the single most important rule this skill exists to enforce is detect → report → ASK → only-then guided upgrade. Never upgrade automatically. The skill detects the installed DOCA env and what newer release is available, reports the gap clearly, then STOPS and asks the user for explicit confirmation. Only on an explicit "yes" does it walk a guided upgrade. A failed or partial move instead enters the recovery ladder without presenting a new target move. In both paths every hardware / firmware / reboot step is delegated to doca-hardware-safety/SKILL.md, never redefined here. Version detection itself is owned by doca-version/SKILL.md; this skill routes there and does not restate the detection chain.

Example questions this skill answers well

The CLASSES of upgrade questions this skill is built to answer, each with one worked example. The agent should treat the class as the load-bearing piece — the worked example is a single instance.

  • "Is there a newer DOCA than what I have, and how far behind am I?" — worked example: "pkg-config --modversion doca-common says <installed X.Y.Z>; what's current and what does moving cost me?". Answered by the detect-and-report-the-gap workflow in

    configure, which routes the

    detection to doca-version/SKILL.md and the what is current lookup to doca-public-knowledge-map/SKILL.md.

  • "Should I just run apt upgrade to move to the next DOCA release?" — worked example: "I want the newest Flow features; can I upgrade in place right now?". Answered by the never-auto rule and the confirmation gate in

    Safety policy

    plus the ask-before-acting step in

    run — the agent reports the gap and

    STOPS for explicit confirmation before any upgrade command runs.

  • "My upgrade left the host on a different release than the BlueField — what happened?" — worked example: "after the upgrade pkg-config reports the new release but bfver still reports the old one". Answered by the host/BFB-skew row in

    Error taxonomy

    and the failed-upgrade diagnosis in

    debug, which re-routes the

    detection to doca-version ## test.

  • "The upgrade aborted half-way and now dpkg is wedged — how do I recover?" — worked example: "apt upgrade was interrupted; dpkg reports an interrupted transaction". Answered by the partial-upgrade and aborted-transaction rows in

    Error taxonomy

    plus the recovery ladder in ## debug.

  • "The upgrade needs me to reflash the BFB / flip BlueField mode / reboot — is that safe?" — worked example: "the target release requires a new BFB; can I reflash now?". Answered by routing every hardware / firmware / reboot step to doca-hardware-safety/SKILL.md via

    run; this skill never redefines the

    reflash, mode-flip, or cold-power-cycle discipline.

  • "My installed component is being sunset — should I keep building on it or move?" — worked example: "I rely on DOCA App Shield / the DOCA Flow Inspector service; are they on a deprecation track?". Answered by the sunset / deprecation awareness concern in

    Capabilities and modes,

    which routes the user to the public release notes via doca-public-knowledge-map/SKILL.md to confirm lifecycle status rather than recommending continued investment in a component that may be sunsetting.

When to load this skill

Load this skill whenever an upgrade or downgrade of DOCA is the load-bearing concern — the user is asking whether a newer release exists, whether to move to it, how to move safely, or how to recover a move that went wrong. The decision must be made before the agent composes its first sentence; the activation checklist below is mirrored here so the activation rule is at hand whenever this skill is consulted. For a planned upgrade or downgrade, it reports the gap and then STOPS for explicit user confirmation. For a failed or partial upgrade, it enters ## debug first to capture and stabilize the current state; it never uses another upgrade command as the first recovery action, retries the move, or issues a new upgrade command without explicit confirmation.

Agent activation checklist — load this skill at the START of the answer when any cell below is true

Trigger classConcrete prompt-side signals (any one fires the overlay)
Upgrade / downgrade intent"is there a newer DOCA", "should I move to the next release", "upgrade me to the latest", "roll me back to the previous DOCA", "downgrade to 3.1 for a bug repro"
Accidental / drifted upgrade"apt upgrade pulled a newer DOCA point release and broke my build", "my host and BlueField are on different releases now", *"the source channel is latest and I didn't mean to move" *
Failed / partial upgrade"the upgrade aborted half-way", "dpkg is wedged after an interrupted transaction", "upgrade finished but the four-way match no longer holds"
Container tag bumpthe user wants to move an NGC DOCA container deployment from one tag to a newer one, or asks whether bumping the tag is an upgrade
Sunset / deprecation awarenessthe user asks whether the component they depend on is deprecated, being sunset, or worth continued investment

First classify the request. A planned move (including a requested rollback) follows detect → report → ASK. A failed, partial, or accidentally drifted move is already a diagnosis/recovery request: load this skill, capture the current four-source state, and enter TASKS.md ## debug; do not ask for permission to perform an upgrade that has already failed, and do not issue another upgrade command as the first recovery action.

For a planned move, the agent MUST:

  1. Route planned-upgrade version detection to doca-version ## configure. For failed or partial upgrades, start with doca-version ## debug and

    debug. Do NOT restate the

    four-source detection chain here; this skill consumes the detected state and four-way match status.

  2. Report the gap and STOP for explicit confirmation. Present the installed release, the available target release, and what moving costs (per

    Version compatibility),

    then ask the user to confirm. Do NOT proceed to any upgrade command until the user explicitly says yes.

  3. Route every hardware / firmware / reboot step to doca-hardware-safety/SKILL.md. This skill names when such a step is part of the upgrade; that skill names how it is applied safely.

For a failed/partial move, the agent MUST instead classify the captured state against CAPABILITIES.md ## Error taxonomy, delegate the single documented corrective action, and re-enter the recovery ladder. Any unsupported installed → target jump fails closed: do not improvise intermediate releases or commands; require an upgrade path explicitly documented by the Compatibility Policy or release notes.

Do not load this skill for first-time install (use doca-setup/SKILL.md), for the version-detection chain in isolation (use doca-version/SKILL.md), or for general orientation (use doca-public-knowledge-map/SKILL.md).

What this skill provides

This is a thin loader. The body keeps only the orientation needed to pick the right next file. The substantive upgrade material lives in two companion files:

  • the capabilities companion — the upgrade surface: the upgrade-mode taxonomy (host apt upgrade vs BFB reflash vs container-tag bump vs downgrade/rollback), the never-auto rule and the confirmation gate, the sunset / deprecation-awareness concern, the version-compatibility overlay that redirects to doca-version, the error taxonomy (partial upgrade, apt-source drift, host/BFB skew, aborted transaction / dpkg interrupted), the observability surface (which commands prove the upgrade did or did not happen), and the upgrade-specific safety overlay on top of doca-hardware-safety.

  • the tasks companion — step-by-step workflows for the in-scope verbs: configure (detect + discover target + apt-source precheck), build and modify (routing stubs — the version-pin change is owned elsewhere), run (the confirmation-gated guided upgrade), test (post-upgrade four-way verification), debug (diagnose a failed / partial upgrade), plus a Deferred task verbs block.

Loading order

  1. Read this skill first to confirm the user's question is in scope (an upgrade / downgrade is being contemplated or recovered).

  2. For the upgrade-mode taxonomy, the never-auto rule, the sunset-awareness concern, the error taxonomy, observability, and the safety overlay, see the capabilities companion.

  3. For step-by-step workflows — detect-and-report, the confirmation-gated guided upgrade, post-upgrade verification, and failed-upgrade diagnosis — see the tasks companion.

Related skills

  • doca-version/SKILL.md — owns the four-source detection chain and the four-way match rule. This skill's detect step routes there and does not redefine version detection; the gap report consumes the detected version.

  • doca-setup/SKILL.md — owns first-time install, install verification, and the apt-source path. This skill's apt-source consistency precheck cross-links there before any apt-shaped upgrade is contemplated.

  • doca-hardware-safety/SKILL.md — owns every hardware / firmware / reboot step (mlxconfig, BFB reflash, BlueField mode flip, cold power cycle). This skill's ## Safety policy overlays that meta-policy and adds only the upgrade-specific surface (confirmation gate, rollback-first, maintenance window).

  • doca-public-knowledge-map/SKILL.md — the routing table to public DOCA docs, including the release notes and the Compatibility Policy. This skill routes what is the current release and is this component sunsetting there; it does not duplicate the routing.

  • doca-debug/SKILL.md — the cross-cutting debug ladder. A failed upgrade whose residual symptom lives at a software layer hands off there once the upgrade state is known.

  • doca-programming-guide/SKILL.md — the build pattern a consumer rebuilds against after an upgrade. This skill surfaces that a rebuild may be needed; the build mechanics live there.

  • doca-structured-tools-contract/SKILL.md — the JSON schemas the agent prefers when present; the upgrade detect step reuses the same doca-env one-shot the version skill uses, when the host has it.

Files

TASKS.md

DOCA upgrade workflows

Where to start: The verbs run configure → build → modify → run → test → debug. The load-bearing flow is configure (detect + report the gap), then run (the confirmation-gated guided upgrade), then test (prove it landed), with debug for a move that went wrong. build and modify are routing stubs — the version-pin change that selects a target release is owned by other skills.

Read this file when the loader sent you here from SKILL.md. For the upgrade-mode taxonomy, the never-auto rule, the sunset concern, the error taxonomy, observability, and the safety overlay, see CAPABILITIES.md. The version-detection chain is owned by doca-version/SKILL.md; the hardware / firmware / reboot discipline is owned by doca-hardware-safety/SKILL.md.

Each verb below describes the shape of the workflow, not a copy-paste recipe. The agent's job is to walk the user through the steps in order, verifying preconditions before recommending the next call — and, above all, to STOP and ask before any upgrade command runs.

configure

Goal: detect what DOCA is installed, discover what newer release is available, run the apt-source consistency precheck, and report the gap — all WITHOUT issuing any upgrade.

Steps the agent should walk the user through:

  1. Confirm this is an upgrade, not a first install. The target must have an existing DOCA state that doca-version can detect. If no live install is present, STOP and route to doca-setup/SKILL.md; do not turn a first install into an upgrade workflow.

  2. Detect the installed version. Route to doca-version ## configure (doca-version/TASKS.md#configure) and capture the four-source chain plus the four-way match status. This skill consumes that result; it does NOT restate the detection chain. Record the version and host kind for the session.

  3. Discover the available target release. Look up what release is current via the DOCA Release Notes, reached through doca-public-knowledge-map ## Public documentation entry points (doca-public-knowledge-map/SKILL.md#public-documentation-entry-points). Never quote a "latest" version from memory; the target is the one the user names or the one the release notes confirm is current.

  4. Run the apt-source consistency precheck. For any host that will receive an apt-shaped upgrade, route to doca-version ## apt-source consistency (doca-version/TASKS.md#apt-source-consistency) to confirm the configured source channel matches the intended target before any move is contemplated.

  5. Validate that the jump is supported. Check the requested installed → target path against the public Compatibility Policy and target release notes. If that exact jump is not documented, fail closed: report it as unsupported and do not invent an intermediate-release sequence.

  6. Check for sunset / deprecation status. Per CAPABILITIES.md ## Capabilities and modes, surface whether an installed component appears to be on a deprecation track and route the user to the release notes via doca-public-knowledge-map/SKILL.md to confirm, rather than recommending continued investment.

  7. Report the gap. State the installed release, the target release, the upgrade mode (per the mode table), and what moving costs. Then STOP — the actual move is gated on explicit confirmation in ## run.

If detection fails (a pkg-config not-found or a four-way mismatch), this is failed/partial-state diagnosis, not planned-upgrade loading. Route directly through doca-version ## debug (doca-version/TASKS.md#debug), then enter this file's ## debug ladder; do not produce a target gap or confirmation prompt from an incoherent baseline.

build

Routing stub. An upgrade does not produce a build artifact; there is no compile-time output of moving a host from one DOCA release to the next. The build pattern a DOCA consumer rebuilds against AFTER an upgrade is owned by doca-programming-guide ## build (doca-programming-guide/TASKS.md#build), and the build-time-vs-runtime version match is owned by doca-version ## build (doca-version/TASKS.md#build).

This skill's only build-side concern is to SURFACE that an upgrade that moves the runtime release may require the user to rebuild their application against the new headers — the rebuild itself is routed to the two skills above, and the post-upgrade build/runtime match is verified in ## test. The agent does not invent build flags or a rebuild recipe here.

modify

Routing stub. The concrete "modify" an upgrade entails is changing the version pin that selects the target release — the apt-source channel pin, or a build-manifest minimum, or a container tag. Those edits are owned by other skills and this skill does NOT redefine them:

  • The apt-source channel pin and the local-repo / network-URL shapes are owned by doca-version ## apt-source consistency (doca-version/TASKS.md#apt-source-consistency) and the install path in doca-setup ## configure (doca-setup/TASKS.md#configure).

  • A build-manifest pkg-config minimum or a container-tag pin is owned by doca-version ## modify (doca-version/TASKS.md#modify).

This skill's role is to name which pin a chosen upgrade target requires changing and to route the edit to the owning skill; the agent does not invent a channel URL, a version literal, or a tag string here.

run

Goal: walk the guided upgrade — but ONLY after the gap has been reported in ## configure AND the user has explicitly confirmed. This verb is where the never-auto rule is enforced.

Steps the agent should walk the user through (in order):

  1. Confirm before acting. Restate the installed → target gap and the upgrade mode, then obtain explicit user confirmation per CAPABILITIES.md ## Safety policy. No upgrade command runs until the user says yes; "should I upgrade?" is answered with the gap and a request to confirm. If the user declines or does not explicitly confirm, state that no upgrade will proceed, summarize the captured current state, and stop awaiting further instructions.

  2. Confirm a rollback path first. Before the move, confirm the prior version anchors are captured and a rollback exists for the chosen mode (reinstall the prior release, reflash the prior BFB, redeploy the prior container tag) per the rollback-first rule. Apply the viability criteria in CAPABILITIES.md ## Safety policy; record the immutable rollback artifact and its verification command, and STOP if it cannot be resolved or restored.

  3. Open a maintenance window when the move is disruptive. For a host carrying real workload, any shared-service disruption, BFB reflash, or reboot-class step, require the explicit time-boxed window from the safety policy. Record the start/end time, affected workloads, notified stakeholders, OOB contact, and rollback owner; if that gate is incomplete, STOP before applying the move. For an idle dedicated non-prod target, record the isolation evidence and proceed without inventing a stakeholder window.

  4. Apply the mode-appropriate move. For a host apt upgrade, route the package-set convergence to doca-setup ## configure (doca-setup/TASKS.md#configure) after the apt source is reconciled. The agent does not invent the package list; it uses the documented install procedure.

  5. Delegate every hardware / firmware / reboot step. A BFB reflash, a BlueField mode flip, an mlxconfig write, or any cold power cycle the target release requires is routed to doca-hardware-safety ## modify (doca-hardware-safety/TASKS.md#modify) and the pre-flight discipline in doca-hardware-safety ## configure (doca-hardware-safety/TASKS.md#configure). This skill names when such a step is part of the upgrade; that skill names how it is applied safely. The agent never redefines the reflash / mode-flip / power-cycle steps here.

  6. Gate the workload behind verification. Do not declare the upgrade done until ## test passes; route the post-change workload gate through doca-hardware-safety ## run (doca-hardware-safety/TASKS.md#run) when the move touched hardware state.

test

Goal: prove the upgrade landed — the install converged on the target release and is internally consistent — before any workload depends on it.

This is a loop, not a one-shot pass. Each iteration re-reads the version state and compares against the target; the loop terminates when the four-way match holds on the target release.

Iteration shape:

  1. Post-upgrade four-way match. Route to doca-version ## test (doca-version/TASKS.md#test) and confirm pkg-config --modversion doca-common, cat /opt/mellanox/doca/applications/VERSION, doca_caps --version, and (on BlueField) the BFB version all agree on the target release. A partial result is a failed upgrade.

  2. Compare against the captured baseline. Per CAPABILITIES.md ## Observability, the pre-upgrade state was captured in ## configure; the post-upgrade state must show the target release, not the old one, on every source.

  3. Confirm host/BFB are in step. On BlueField hosts, confirm the BFB moved with the host packages; a skew is the host/BFB row in CAPABILITIES.md ## Error taxonomy and routes back to ## debug.

  4. Confirm the consumer still builds / runs. If the user has an application, confirm it builds and runs against the new release per doca-version ## test (doca-version/TASKS.md#test); a build/runtime skew after the move is a failed upgrade.

  5. Loop back if any source still reads the old release. Re-run from step 1 after any corrective action until the four-way match holds on the target.

debug

Goal: when an upgrade fails or lands partially, diagnose it before any other layer is considered. The upgrade-level failure modes are enumerated in CAPABILITIES.md ## Error taxonomy; this verb is the recovery ladder.

The recovery ladder.

  1. Read all four sources. Route to doca-version ## debug (doca-version/TASKS.md#debug) and capture the post-upgrade four-source state. Identify which sources moved to the target and which did not.

  2. Classify the failure. Map the captured state to a row in CAPABILITIES.md ## Error taxonomy:

    • Apt-source drift → reconcile the source first per doca-version ## apt-source consistency (doca-version/TASKS.md#apt-source-consistency), then re-converge.

    • Aborted transaction / dpkg interrupted → recover the package database first: show the user sudo dpkg --configure -a, then sudo apt-get -f install (Debian/Ubuntu), say that both change system package state, and run them only after the user's explicit confirmation; do not re-run the upgrade as the first action, and re-detect via doca-version afterwards.

    • Partial upgrade → converge the package set on one release via the install path in doca-setup ## debug (doca-setup/TASKS.md#debug).

    • Host/BFB skew → route the proposed BFB corrective change to doca-hardware-safety ## modify (doca-hardware-safety/TASKS.md#modify); that skill decides whether the documented rollback/OOB gates permit it. Do not prescribe the reflash here.

  3. Re-verify against the target. After the corrective action, re-run ## test step 1; the four-way match must hold on the target release before any other layer is reconsidered.

  4. Bound identical failures. If the exact same four-source state and error recur after one documented corrective action, stop repeating it. Preserve both identical captures, invoke the rollback/escalation path, and do not recommend an unbounded retry.

  5. Hand off a residual software-layer symptom. Once the version state is known-good and a symptom remains, route to doca-debug ## debug (doca-debug/TASKS.md#debug) with the captured upgrade state as evidence.

When the failure is a hardware-state failure that has no documented recovery (a one-way firmware roll, a bricked BFB), the agent applies the refuse-and-escalate rule owned by doca-hardware-safety ## debug (doca-hardware-safety/TASKS.md#debug) — it does not guess at a recovery.

Deferred task verbs

The following verbs are out of scope for this skill but are commonly asked in the same conversations. Route them as follows so the agent does not invent guidance:

  • install / first-time setup. Owned by doca-setup ## recognize (doca-setup/TASKS.md#recognize) and doca-setup ## no-install (doca-setup/TASKS.md#no-install). This skill assumes something is already installed; an upgrade is moving from one installed release to another.

  • version detection in isolation. Owned by doca-version ## configure (doca-version/TASKS.md#configure). This skill consumes the detected version; it does not own the detection chain.

  • the hardware / firmware / reboot step itself. Owned by doca-hardware-safety ## modify (doca-hardware-safety/TASKS.md#modify). This skill names when a reflash / mode-flip / cold-power-cycle is part of an upgrade; that skill owns how it is applied safely.

Requirements and compatibility

Works with: Claude Code, Claude apps, OpenAI Codex, GitHub Copilot, Cursor, Gemini CLI, Kiro, OpenCode, Goose, Amp, Roo Code, JetBrains Junie, Factory Droid, Devin (ex-Windsurf), Mistral Vibe, OpenHands, Letta

“Works with” means the tool reads the open Agent Skills format; a skill written for one tool may use features others lack.

The author says: No DOCA install required to read this skill (it is a cross-cutting overlay loaded against any DOCA artifact skill); the detection, gap-report, and guided-upgrade steps within DO require a live DOCA install at /opt/mellanox/doca, and the hardware / firmware / reboot steps require a BlueField DPU or ConnectX NIC plus out-of-band console reachability as gated by doca-hardware-safety.

Security

What our scanner noticed· Medium risk

  • Phrasing that asks for actions without confirmation
  • Large base64-encoded blobs

A static scan is not a guarantee. Skills are third-party content: review a skill before you let an agent use it.

Attribution and licence

Created by
NVIDIA
Publisher
NVIDIA (Official)
Source
NVIDIA/skills · skills/doca-upgrade · commit fce3cca
Licence
Apache License 2.0 (redistribution allowed)
  • LICENSE (added by AutoGineer from LICENSE-APACHE)
  • ATTRIBUTION.md (written by AutoGineer)
Synced

AutoGineer is not affiliated with or endorsed by NVIDIA or NVIDIA.

Download ZIP

The ZIP holds the skill’s files, its licence files and an ATTRIBUTION.md. Download doca-upgrade.zip