Doca Caps

NVIDIAOfficialCreated by NVIDIA

Skill
Tool integration
Software development
Apache-2.0
Medium risk

From the author

Use this skill when the user wants to invoke the read-only doca_caps CLI to ask what DOCA sees on this host — listing DOCA devices and PCIe addresses, listing representor devices, asking which DOCA libraries are available on the current OS, checking per-device per-library capabilities, scoping output to a specific PCIe address, or capturing a side-effect-free capability snapshot for debug or install smoke-test. Trigger even when the user does not explicitly mention "doca_caps" or "capabilities print tool" — typical implicit phrasings include "what does DOCA actually see on this box", "is my BlueField PF visible to DOCA", "is Flow available on my RHEL host", "enumerate VF representors for pf0", "doca_caps: command not found", or "empty output for RDMA, is the tool broken". Refuse and route elsewhere for DOCA installation (doca-setup owns it; never walk the steps), library-internal capability matrices (Flow pipe creation, RDMA verbs features), streaming telemetry / DTS, or modifying the shipped binary.

— the description by NVIDIA

AutoGineer summary

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

The doca-caps skill provides instructions for using the doca_caps command-line tool, a read-only utility designed to report the state of DOCA on a host. It enables users to enumerate DOCA devices, identify available libraries, list representor devices, and capture capability snapshots for debugging or installation verification. This skill acts as a thin loader, directing users to specific companion files for detailed capability reporting and task-based workflows. It is strictly limited to read-only operations and does not perform DOCA installations or library-internal configuration.

What it does

Enumerates DOCA devices and their associated PCIe addresses.
Lists DOCA libraries available on the current operating system.
Identifies visible representor devices for specific PFs.
Captures side-effect-free capability snapshots for debug or smoke-test purposes.
Scopes capability output to specific PCIe addresses.
Interprets empty or missing output from the tool.

When to use it

When you need to verify if DOCA hardware is visible on a host.
When you need to confirm which DOCA libraries are supported on your current OS.
When you need to generate a capability snapshot to attach to a debug session.
When you need to perform a quick smoke-test of a DOCA installation.
When you need to identify representor devices for network configuration.

Advantages

Provides a standardized, side-effect-free way to inspect system state.
Helps verify installation health without modifying system configuration.
Facilitates consistent data collection for debugging and support.
Integrates cleanly with other DOCA-related workflows and skills.

Usage examples

“What DOCA devices does this host see?”: The agent invokes doca_caps --list-devs to provide a list of visible DOCA devices and their PCIe addresses.
“Is Flow available on my RHEL host?”: The agent checks the library-availability surface and invokes the tool to confirm if the Flow library is present.
“Enumerate VF representors for pf0.”: The agent uses the tool to list representor devices, specifically filtering for those associated with pf0.
“Save device and library capability output to a file.”: The agent executes the snapshot workflow to capture the current system state into a file for later debugging.

Install

Download the skill as a ZIP:
https://autogineer.com/agent-skills/nvidia/doca-caps/download
Unzip it into the cross-client skills folder of your project:
```
mkdir -p .agents/skills && unzip doca-caps.zip -d .agents/skills
```

Documentation by NVIDIA

DOCA Capabilities Print Tool (`doca_caps`)

Examples

"What DOCA devices does this host see?" — this is in scope. Stay on doca_caps; do not start a library-internal capability matrix here.
"Is Flow available on my RHEL host?" — list libraries then scope per-device if needed.

Instructions

Follow Loading order below. Open the tasks companion for run / test. Open the capabilities companion for what the CLI reports. Do not open every companion file.

Where to start: This is a tool skill for invoking doca_caps, a side-effect-free CLI. Open the tasks companion and start at ## run for the documented invocations, or ## test when using doca_caps as an install smoke-test. Open the capabilities companion when the question is what kinds of capability families doca_caps reports.

Boundary: this skill never installs DOCA. doca_caps verifies an install and never performs one. A request to install DOCA — choosing packages, adding repositories, running a package manager — is out of scope here, and stays out of scope even though this skill's ## test verb uses the tool as an install smoke-test afterwards. Hand the whole request to doca-setup/SKILL.md by name. Naming the owner and then listing the steps anyway is the failure mode to avoid: do not walk the installation, not even as a summary or a caveat.
This narrows installation only. It is not a reason to answer narrowly about tooling: when the user's question reaches past doca_caps — what else can I ask this hardware, how do I measure it, how do I inspect a running pipeline — name the sibling tool that owns it (doca_bench, doca_flow_tune, pcc_counters.sh, doca_comm_channel_admin, …) and tie it to the question. Pointing at the rest of the catalog is this skill's job, not a boundary breach.

Example questions this skill answers well

The CLASSES of doca_caps questions this skill is built to answer, each with one worked example. The class is the load-bearing piece; the worked example is one instance.

"What DOCA devices does this host see?" — worked example: "is my BlueField PF visible to DOCA". Answered by the device enumeration in the capabilities companion
- the --list-devs invocation in the tasks companion.
"Which DOCA libraries are available on this OS?" — worked example: "is Flow available on my RHEL host". Answered by the library-availability surface in the capabilities companion
- the library-listing invocation in the tasks companion.
"Does this device support library X capability Y?" — worked example: "does this device support Flow hairpin?". Answered by the per-device per-library capability matrix in the capabilities companion
- the --pci-addr-scoped invocation in the tasks companion.
"What representors are visible to DOCA?" — worked example: "enumerate VF representors for pf0". Answered by the representor enumeration in the capabilities companion
- the --list-rep-devs invocation in the tasks companion.
"I want a snapshot of state to attach to my debug session." — worked example: "save device + library + capability output to a file". Answered by the snapshot workflow in the tasks companion and consumed by doca-debug/SKILL.md step 3 (read-only triple) and doca-programming-guide/SKILL.md.
"doca_caps returned nothing for capability Y — what does that mean?" — worked example: "empty output for RDMA". Answered by the empty-output interpretation rules in the tasks companion + the capabilities companion.

Audience

This skill serves external operators, developers, and AI agents who need a side-effect-free way to ask "what does DOCA see on this host?" before doing anything that changes state. Concretely:

An external developer who installed DOCA (or is using the public NGC DOCA container per doca-setup/SKILL.md) and wants to confirm the install can see hardware before writing code.
A platform operator deploying a DOCA service who wants a documented, read-only snapshot of which DOCA libraries this host actually supports and which capabilities each DOCA device offers.
An AI agent producing a capability snapshot artifact during the documented setup or programming-guide debug procedures (it's listed as the canonical first step in doca-setup/SKILL.md and doca-programming-guide/SKILL.md).

It is not for users debugging doca_caps itself, and not a substitute for the live public Capabilities Print Tool guide.

doca_caps is shipped as a tool (a single CLI binary), not a library you link against. The skill uses the same kind: tool three-file shape as the rest of the bundle so the agent's task-verb contract (configure / build / modify / run / test / debug) is uniform across libraries, services, and tools — even when individual verbs collapse to a routing stub for a shipped read-only binary.

When to load this skill

Load this skill when the user is — or the agent needs to — invoke doca_caps on a real host with DOCA installed (or inside the public NGC DOCA container). Concretely:

Running doca_caps --list-devs to enumerate DOCA devices.
Running doca_caps --list-rep-devs to enumerate representor devices.
Scoping output to a specific PCIe address with --pci-addr.
Listing the DOCA libraries the install reports as available on the current OS.
Listing the available DOCA logger names.
Capturing a documented, side-effect-free capability snapshot as prerequisite evidence for later ## debug workflows.

Do not load this skill for general DOCA orientation, library API work, or installation. For those, use doca-public-knowledge-map/SKILL.md, the matching libs/<library> skill, or doca-setup/SKILL.md.

What this skill provides

This is a thin loader. Substantive material lives in two companion files:

the capabilities companion — what doca_caps reports (the five documented capability families: devices, representors, libraries, library capabilities, loggers), version availability and execution environment, the tool's narrow error surface, its observability role inside other skills' workflows, and its read-only safety posture.
the tasks companion — step-by-step workflows for the in-scope task verbs: configure (route to install), build (route to install), modify (refuse), run (the documented invocations), test (capability snapshot as install smoke-test), debug (what to do when the tool reports nothing or fails), plus a Deferred task verbs block routing out-of-scope questions.

The skill assumes a host where DOCA is already installed (or the public NGC DOCA container is running) and the operator has whatever permissions the public guide requires for doca_caps to enumerate devices on their platform.

What this skill deliberately does not ship

This skill is agent guidance, not a samples or scripts bundle. To keep the boundary clean, it deliberately does not contain — and pull requests should not add:

Pre-baked example output. Output is install- and hardware-specific. A captured example pinned to one platform and one DOCA version misleads operators on a different platform / version.
Wrappers, parsers, or scripts in any language that consume doca_caps output. The output format is documented; if a user wants to script against it, the right answer is "read the live guide, write the parser against your installed version".
A samples/ or reference/ subtree. This is a thin loader for a documented CLI; substantive material lives on the public page and in --help.

Loading order

Read this skill first to confirm the user's question is in scope (the user actually wants to invoke doca_caps, not learn about DOCA in general).
For what doca_caps reports, version availability, error surface, and safety posture, see the capabilities companion.
For the documented invocations and the capability-snapshot workflow — configure, build, modify, run, test, debug — see the tasks companion.

doca-public-knowledge-map/SKILL.md — routing to the public Capabilities Print Tool guide and the rest of the public DOCA documentation set.
doca-setup/SKILL.md — env preparation, install verification (doca_caps is the canonical first step there), and the I have no install yet path with the public NGC DOCA container.
doca-programming-guide/SKILL.md — cross-library programming patterns, including the ## debug procedure where the saved doca_caps snapshot is consumed.
The matching libs/<library> skill — for fine-grained, library-specific capability questions that go beyond what doca_caps exposes.

Files

ATTRIBUTION.mdAdded by AutoGineer885 B
BENCHMARK.md9.9 KiB
CAPABILITIES.md14.8 KiB
LICENSELicence file added by AutoGineer11.2 KiB
SKILL.md10.3 KiB
SKILLCARD.yaml2.7 KiB
TASKS.md17.1 KiB
evals/evals.json2.3 KiB
skill-card.md5.0 KiB
skill.oms.sig5.1 KiB

TASKS.md

DOCA Capabilities Print Tool — Tasks

Where to start: The verbs that carry real workflow content are ## run, ## test, and ## debug. The other three (configure, build, modify) are documented routing stubs that exist because the bundle's verb contract is uniform. The ## test verb is an iterative loop, not a one-shot pass — see the eval-loop overlay in ## test below.

This file is loaded by SKILL.md after CAPABILITIES.md. It walks the agent through the six task verbs every artifact in this bundle exposes (configure / build / modify / run / test / debug), then explicitly defers task verbs that do not belong here.

For doca_caps, the verbs that carry real workflow content are run, test, and debug. The other three verbs exist as anchors because the agent's task-verb contract is uniform across libraries, services, and tools — and each one carries a meaningful routing stub that names where the user's question really belongs.

configure

doca_caps takes no configuration. It is a flag-driven read-only CLI; there are no config files, no daemons, no environment knobs the public guide documents as required.

If the user is asking "how do I configure doca_caps?", the question they almost certainly mean is one of:

"How do I install DOCA so doca_caps shows up?" → route to doca-setup ## install (doca-setup/TASKS.md#configure). The binary is shipped with every DOCA install since 2.6.0; configuring is install.
"How do I make doca_caps see device X?" → not a configuration question; it is a hardware / driver / permission question. Run doca_caps --list-devs first (see ## run) and let the empty-output diagnosis flow in ## debug guide the next step.
"How do I configure DOCA logging that affects what doca_caps prints?" → doca_caps's own output is fixed by its flags; general DOCA log filtering belongs to doca-programming-guide CAPABILITIES.md ## Observability (doca-programming-guide/CAPABILITIES.md#observability).

Do not invent configuration files or environment variables for this tool. If the public guide does not document a config knob, it does not exist.

build

doca_caps is shipped pre-built as part of every DOCA install (/opt/mellanox/doca/tools/doca_caps). There is no source tree the external user is expected to compile, no build flags, no meson or make workflow.

Routing for nearby "build" questions:

"The binary isn't there — do I need to build it?" → no. Route to doca-setup ## install (doca-setup/TASKS.md#configure). The fix is to install (or re-install) DOCA, or use the public NGC DOCA container per doca-setup ## no-install (doca-setup/TASKS.md#no-install).
"I want to build a tool that uses doca_caps-style capability introspection from inside my application" → not a doca_caps question. Route to the matching libs/<library> skill — DOCA libraries expose programmatic capability checks; doca_caps is a CLI wrapper around (a subset of) those checks for operator use.

The ## What this skill deliberately does not ship block in SKILL.md explicitly forbids adding a build recipe for doca_caps or shipping wrappers around it; revisit that policy before changing this section.

modify

Do not modify the shipped doca_caps binary. It is an NVIDIA- shipped read-only CLI; there is no documented public way to change its behavior, output format, or capability surface, and none should be invented.

Routing for nearby "modify" questions:

"The output format is inconvenient — can I change it?" → no, not inside this skill. The documented surface is the surface. If the user wants structured output, the right answer is "write a parser against the documented format on your installed version" — and even that is out of scope per SKILL.md ## What this skill deliberately does not ship.
"Can I patch doca_caps to add flag X?" → out of scope for external users; this skill is for consumers of the shipped tool, not contributors to it.
"I need different information than doca_caps reports" → route to the matching libs/<library> skill or to doca-programming-guide/SKILL.md — the right answer is to call the underlying library API programmatically, not to modify the CLI wrapper.

run

The two invocations the public guide explicitly walks through are:

/opt/mellanox/doca/tools/doca_caps --list-devs
/opt/mellanox/doca/tools/doca_caps --list-rep-devs

Either can be scoped to a single PCIe address with --pci-addr, which the public guide documents as supported on both --list-devs and --list-rep-devs.

Recommended flow when the user asks the agent to "check what DOCA sees":

Confirm the binary is present at /opt/mellanox/doca/tools/doca_caps. If absent, route to ## configure above.
Run --list-devs first. This is the canonical first invocation in both doca-setup ## test (doca-setup/TASKS.md#test) and doca-programming-guide ## debug (doca-programming-guide/TASKS.md#debug). Capture the full output verbatim.
If the user cares about representors / SR-IOV / SF setups, also run --list-rep-devs. Otherwise this is noise.
If the user has a specific PCIe address in mind, scope with --pci-addr <addr> to keep output focused; otherwise list everything.
For exact, current flag inventory (e.g. logger listing, OS target listing, library-list flag, library-capabilities flag), read --help on the installed version. Do not invent flags from generic CLI knowledge — the public guide and --help are the source of truth, see CAPABILITIES.md ## Capabilities and modes for the documented capability families and doca-public-knowledge-map ## DOCA tools (doca-public-knowledge-map/SKILL.md#doca-tools) for the public guide URL.

When recording the run for downstream consumers (the capability snapshot pattern), write down: the DOCA version, the host platform (host vs BlueField Arm, OS, kernel), the exact command line used, and the full unredacted output. The downstream ## test and ## debug workflows depend on those four fields.

test

doca_caps is the canonical install smoke-test prescribed by doca-setup ## test (doca-setup/TASKS.md#test).

## test is an iterative loop, not a one-shot pass. The agent re-runs doca_caps after every state-changing action that should have affected DOCA's view of the host (driver reload, firmware change, BlueField mode flip, container --device change). Treating the smoke as a one-shot pass is the failure mode this loop replaces.

The eval-loop overlay (rows apply to every DOCA install, not just one):

Step	Why this is a loop, not a step	Where the substance lives
1 → ## debug	Empty / unexpected output is a finding, not a tool failure; the agent must walk the debug ladder, then re-run step 1	`## debug`
1 → driver reload → 1	After `modprobe` / driver reload, re-run step 1 to confirm DOCA's view caught up	`doca-setup ## debug` (`doca-setup/TASKS.md#debug`) layer Driver
1 → firmware / mode change → 1	After `mlxconfig` or BlueField mode change, re-run step 1 to confirm the new capability surface	`doca-setup ## configure` (`doca-setup/TASKS.md#configure`)
1 → container `--device` change → 1	After remounting / `--device`-mapping a container, re-run step 1 inside the container	`doca-setup ## no-install` (`doca-setup/TASKS.md#no-install`)
1 (clean) → save → debug session	Once clean, the snapshot is saved and consumed by `doca-debug ## test` step 3 (read-only triple)	`doca-debug ## test` (`doca-debug/TASKS.md#test`)

The agent's rule: every state-changing action that could affect DOCA's view re-opens the smoke. Saving a stale snapshot from before a mutation is exactly the failure mode this loop is here to prevent.

The pattern the rest of the bundle expects:

Run doca_caps --list-devs.
Exit code 0 + at least one DOCA device listed ⇒ the install can see hardware. The install is probably healthy at the level doca_caps can verify; routing for the next health check is library-specific (e.g. doca-flow CAPABILITIES.md ## Capabilities and modes (doca-flow/CAPABILITIES.md#capabilities-and-modes) for whether DOCA Flow can program the device).
Exit code 0 + zero devices listed ⇒ the install is on a host with no DOCA-supported PCIe device, or the user is inside a container without PCIe passthrough, or the driver stack is not loaded. This is a finding, not a tool failure — see ## debug for the layered diagnosis.
Non-zero exit code ⇒ the tool failed (permission, missing library, broken install). See CAPABILITIES.md ## Error taxonomy for the layered taxonomy.

The output of step 1 is the capability snapshot that subsequent debug steps consume. Save it (file, paste buffer, conversation artifact) — without it, downstream debug starts guessing. This matters more than it looks: the most common reason a Flow-style "why isn't this working" debug session goes off the rails is that the agent skipped this step and inferred capability from device model number instead of from doca_caps ground truth.

This skill does not ship a "test fixture" or pre-recorded expected output. The expected output is install- and hardware-specific; pinning one would mislead operators on a different platform / version. See SKILL.md ## What this skill deliberately does not ship.

debug

When doca_caps returns nothing useful or fails, walk the CAPABILITIES.md ## Error taxonomy layers in order. The shape of the diagnosis:

Tool-not-installed. doca_caps does not exist at /opt/mellanox/doca/tools/doca_caps. Confirm DOCA is installed (e.g. pkg-config --modversion doca-common, cat /opt/mellanox/doca/applications/VERSION) and that the version is ≥ 2.6.0. Route to doca-setup ## install (doca-setup/TASKS.md#configure) if not.
Permission / driver layer. Tool runs but cannot enumerate devices. Check that the underlying driver stack (mlx5_core, IB stack) is loaded, that the user has whatever privileges the public install profile expects, and that the BlueField mode is compatible with the requested capability family. The tool's own message and dmesg are ground truth; do not guess at causes.
Empty / partial output, exit 0. Capability finding, not a tool failure:
- Zero devices listed in --list-devs: no DOCA-supported PCIe device on this host, or the container lacks PCIe passthrough, or the user is inside the public NGC DOCA container without --device mappings. Route to doca-setup ## no-install (doca-setup/TASKS.md#no-install) for the container path, or to doca-setup ## install (doca-setup/TASKS.md#configure) for hardware questions.
- Fewer devices than expected: re-run without --pci-addr to confirm the scope is not the cause; check the install version against the device's first-supported DOCA release in the public release notes (route through doca-public-knowledge-map/SKILL.md).
Library-capability mismatch. Tool runs, capabilities printed, but the user's library question ("why does library X say it doesn't support Y on my device?") goes beyond what doca_caps reports. Route to the matching libs/<library> skill — for Flow, that is doca-flow CAPABILITIES.md ## Capabilities and modes (doca-flow/CAPABILITIES.md#capabilities-and-modes).
Output schema confusion. The user is reading the capability snapshot and a field name does not look right. Re-fetch the public DOCA Capabilities Print Tool page (via doca-public-knowledge-map ## DOCA tools (doca-public-knowledge-map/SKILL.md#doca-tools)) on the user's installed DOCA version and quote it; the field inventory in CAPABILITIES.md ## Capabilities and modes reflects the documented surface but is not contractually frozen.

In every case: quote what the tool said. Do not paraphrase the output, do not reorder fields, do not "summarize" capability lines into prose. The whole point of doca_caps in a debug context is to break the agent out of the inference-from-model-number trap.

Command appendix

doca_caps-specific invocations the verbs above reach for. Every row is a class — the agent must not invent flags beyond --help on the installed binary. The four-family symmetry below is the load-bearing piece; one worked example per family is shown.

Purpose (class)	Invocation (shape)	Owning step	Reads as healthy when …
Discover available flags	`doca_caps --help`	`## run`	Prints the documented flag inventory; the agent uses this as the only source of truth for flag names.
Enumerate DOCA devices	`doca_caps --list-devs`	`## run` + `## test` step 1	Exit 0 and at least one device row, with the expected PCIe addresses present.
Enumerate representor devices	`doca_caps --list-rep-devs`	`## run`	Exit 0; the representor topology matches what `devlink dev show` reports.
Scope to one PCIe address	`doca_caps --pci-addr <bdf>`	`## run` + `## debug` layer "Library-capability mismatch"	The output is restricted to one device; rules out scope as the cause of an unexpectedly empty answer.
Scope to one DOCA library	The documented per-library flag (see `--help`)	`## run`	Returns the library's supported capabilities; empty output = not supported on this device/version.
Save a snapshot for debug	`doca_caps --list-devs > caps.txt` (and equivalents for the families above)	`## test` step 4 + `doca-debug ## test` (`doca-debug/TASKS.md#test`) step 3	The saved file is consumed by the debug session's read-only triple.
Re-confirm after a state change	Any of the above, re-run after driver / firmware / mode / container change	`## test` eval loop	The post-change output reflects the change; a stale snapshot is the failure mode.

Three cross-cutting rules for this appendix:

Never invent a doca_caps flag. --help is the contract; prose-derived flags are the most common hallucination failure for this skill.
Empty output is an answer. Re-running the same invocation hoping for different output is the wrong move; route to ## debug and walk the layers instead.
Cross-link instead of duplicate. Cross-cutting commands (pkg-config --modversion, dmesg, mlxconfig -d <bdf> q) live in doca-debug TASKS.md ## Command appendix (doca-debug/TASKS.md#command-appendix); this appendix names only doca_caps-specific invocations.

Deferred task verbs

The four verbs below are not doca_caps work and should be routed out before the agent does any of them under this skill's name.

install ⇒ doca-setup ## install (doca-setup/TASKS.md#configure) (and ## no-install (doca-setup/TASKS.md#no-install) for the public NGC DOCA container path). doca_caps is shipped by the install; this skill does not own the install workflow.
build a custom DOCA application ⇒ doca-programming-guide ## build (doca-programming-guide/TASKS.md#build) for the cross-library pattern, plus the matching libs/<library> skill for library-specific build details. doca_caps is not a template; it is a tool the user runs against an existing install.
library-internal capability check (e.g. Flow's pipe-creation capability matrix, RDMA's verbs-level features) ⇒ matching libs/<library> skill. doca_caps only exposes the coarse per-device per-library capability surface.
streaming telemetry / live metrics ⇒ not a doca_caps feature. The DOCA Telemetry Service (DTS) is the documented telemetry surface; routing belongs in doca-public-knowledge-map ## DOCA services (doca-public-knowledge-map/SKILL.md#doca-services).

Cross-cutting

A few rules that apply across every verb in this file, restated here so they are visible at the point of action and not buried in SKILL.md:

The public DOCA Capabilities Print Tool guide plus the installed --help are the joint source of truth. When they disagree (e.g. a flag landed in a release this skill was not written against), the installed --help wins for the user's actual run.
doca_caps is read-only and side-effect-free. Re-running it is always safe; an agent uncertain whether to run it should run it.
Quote, do not paraphrase. The capability snapshot is the artifact downstream debug consumes; reformatting it loses fidelity that the rest of the bundle's procedures depend on.
This skill assumes a healthy DOCA install (or the public NGC DOCA container) at the management endpoint. If the install is in doubt, route to doca-setup/SKILL.md before running anything else here.

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: Requires DOCA SDK ≥ 2.6.0 installed at /opt/mellanox/doca on Linux (Ubuntu 22.04/24.04 or RHEL/SLES) with a BlueField DPU or ConnectX NIC; runs identically on the host or on the BlueField Arm side. Invokes /opt/mellanox/doca/tools/doca_caps and reads `pkg-config doca-common` to confirm the install. The validation steps require a live DOCA install.

Security

What our scanner noticed· Medium risk

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-caps · commit fce3cca

Licence

Apache License 2.0 (redistribution allowed)

LICENSE (added by AutoGineer from LICENSE-APACHE)
ATTRIBUTION.md (written by AutoGineer)

Synced

2026-11-09

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-caps.zip