Doca Urom

NVIDIAOfficialCreated by NVIDIA

Skill
Tool integration
Software development
Apache-2.0
Medium risk

From the author

Host-side DOCA UROM library (doca_urom_*): offload an HPC / UCX / MPI application's remote memory operations (puts, gets, atomics, collectives) from the host CPU onto a BlueField DPU. Trigger on "MPI all-reduce burning host CPU", "push UCX traffic onto the BlueField", "first doca_urom call returns NOT_PERMITTED", or "host library and DPU service look out of sync", even without naming DOCA UROM. An offload needs both halves: this host library and the UROM Service on the DPU (doca-urom-svc), which owns deploying that container. Covers creating UROM Service contexts (doca_urom_service_*) and Worker contexts (doca_urom_worker_*) that run plugins on the DPU, discovering plugins via doca_urom_service_get_plugins_list, progressing completions, and DOCA_ERROR_* from doca_urom_* calls. Route elsewhere for UROM Service deployment on the DPU side, MPI / UCX collective algorithm design, and RDMA / RoCE / IB substrate bring-up.

— the description by NVIDIA

AutoGineer summary

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

The doca-urom skill provides guidance for developers using the host-side DOCA UROM library to offload remote memory operations, such as puts, gets, atomics, and collectives, from the host CPU to a BlueField DPU. It focuses on the host-side implementation, including creating UROM Service and Worker contexts, discovering plugins, and managing the lifecycle of offloaded tasks. This skill assumes the user has a functional DOCA installation and a running UROM Service on the DPU, acting as a paired contract between the host library and the DPU-side executor.

What it does

Initializes UROM Service and Worker contexts on the host.
Enqueues remote memory operations like puts, gets, and atomics for DPU execution.
Discovers supported operation types via plugin listing.
Manages the DOCA progress engine for operation completions.
Provides error taxonomy and debugging guidance for host-side UROM calls.
Integrates with UCX-based HPC stacks to offload transport operations.

When to use it

When offloading MPI or UCX remote memory operations to reduce host CPU load.
When developing host-side applications that interact with the DOCA UROM library.
When debugging connectivity or version alignment between the host library and DPU service.
When verifying if specific atomic or collective operations are supported on the current device.

Advantages

Reduces host CPU overhead by offloading memory operations to the DPU.
Provides a structured approach to managing the host-DPU paired contract.
Enables discovery of device-specific capabilities through plugin enumeration.
Standardizes error handling and lifecycle management for UROM-based applications.

Usage examples

“How do I offload my MPI all-reduce operation to the BlueField DPU?”: The agent will guide you through initializing the UROM Service and Worker contexts, and using the host-side API to enqueue the collective operation for DPU execution.
“My first doca_urom call returns DOCA_ERROR_NOT_PERMITTED. What should I check?”: The agent will help you verify the version alignment between the host library and the DPU-side UROM service, and check the health of the underlying RDMA substrate.
“How do I check which atomic operations are supported on my device?”: The agent will instruct you to use doca_urom_service_get_plugins_list on a started service to discover the available plugin-defined operations.

Install

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

Documentation by NVIDIA

DOCA UROM

Examples

"Push UCX traffic onto the BlueField." — this is in scope. Stay on host-side doca-urom; do not deploy the DPU-side UROM Service here.
"First doca_urom call returns NOT_PERMITTED." — check host/service version alignment and the RDMA substrate first.

Instructions

Follow Loading order below. Open the tasks companion for configure / offload / debug. Open the capabilities companion for service vs worker contexts. Do not open every companion file.

Where to start: This skill assumes DOCA is installed on both host and BlueField, the DOCA UROM Service is deployed and running on the BlueField, and the user is doing hands-on UROM work from the host side — using doca-urom from an HPC / UCX / MPI stack to enqueue remote memory operations (puts, gets, atomics, active messages, collectives) the DPU executes on the host's behalf. Open the tasks companion to do something (configure / build / modify / run / test / debug); open the capabilities companion for what the host-side UROM API expresses on this version + BlueField + UROM Service version. If DOCA is not installed, route to doca-setup/SKILL.md first; for the DPU-side UROM Service itself (deployment, container, lifecycle), that is a DIFFERENT artifact — route via doca-public-knowledge-map ## DOCA services (doca-public-knowledge-map/SKILL.md#doca-services) to the public DOCA UROM Service guide. This skill is the host-side library; the UROM Service is the DPU-side executor; they are a paired contract.

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. For out-of-scope requests, name the skill that owns them and stop.

Example questions this skill answers well

The CLASSES of UROM questions this skill answers, each with one worked example. The class is the load-bearing piece; the worked example is one instance.

"How do I offload my MPI / UCX remote memory operations from the host CPU to the BlueField?" — worked example: "my MPI all-reduce burns host CPU cycles I'd rather use for compute — how do I push that onto the BlueField via UROM?". Answered by the paired-contract model in the capabilities companion
- the host-side bring-up workflow in the tasks companion.
"Is the DOCA UROM Service even running on my BlueField, and why does that matter before I write doca_urom_* code?" — worked example: "my first doca_urom_* call returns DOCA_ERROR_NOT_PERMITTED on an otherwise-healthy host". Answered by the env-precondition matrix in the capabilities companion
- the service-deployed check in the tasks companion step 1, which routes service-side env questions to doca-public-knowledge-map ## DOCA services (doca-public-knowledge-map/SKILL.md#doca-services).
"Is this UROM operation type / atomic / collective supported on my device + DOCA install + UROM Service version?" — worked example: "does my BlueField support remote atomic Fetch-and-Add for an MPI window?". Answered by the plugin-discovery rule (doca_urom_service_get_plugins_list on a started Service — UROM operations are plugin-defined Command tasks, so the plugins list is the capability surface) in the capabilities companion
- the discovery step in the tasks companion.
"How does doca-urom relate to doca-rdma — am I replacing it, layering on top, or something else?" — worked example: "I already have raw doca-rdma working; should I rewrite to use UROM?". Answered by the path-selection rule in the capabilities companion (UROM rides the RDMA substrate but adds the DPU-offload contract; it is the right tool only when host CPU is the bottleneck — simple point-to-point cases stay on doca-rdma).
"Is this UROM API on my installed DOCA version?" — worked example: "is the collective-ops plugin discoverable via doca_urom_service_get_plugins_list on DOCA 3.x". Answered by the version-compatibility overlay in the capabilities companion, which cross-links the canonical detection chain in doca-version/SKILL.md and adds the host library + DPU service versions must match overlay.
"What does this DOCA_ERROR_* from a doca_urom_* call mean and which layer caused it?" — worked example: "DOCA_ERROR_NOT_PERMITTED on the first enqueue after doca_ctx_start() succeeded". Answered by the UROM overlay on the cross-library taxonomy in the capabilities companion
- the layered ladder in the tasks companion that escalates to doca-debug/SKILL.md.

Audience

This skill serves external developers building HPC / UCX / MPI applications that consume the DOCA UROM library from the host side — code calling doca_urom_* (directly in C / C++, through FFI / bindings, or through a UCX-based stack such as OpenMPI / MPICH wired to use UROM as a transport) to push remote memory operations onto the BlueField instead of the host CPU. It is not for NVIDIA developers contributing to DOCA UROM, nor the place to learn how to deploy / operate the UROM Service on the DPU side — that goes through the public DOCA UROM Service guide via doca-public-knowledge-map ## DOCA services (doca-public-knowledge-map/SKILL.md#doca-services).

Language scope. DOCA UROM ships as a host-side C library (pkg-config module doca-urom); shipped samples under /opt/mellanox/doca/samples/doca_urom/ are C. C / C++ consumers — including UCX-based stacks wrapping the library — are the canonical case the tasks companion assumes. Other-language consumers (Rust, Go, Python, …) reach the same *.so through FFI; the skill keeps its lifecycle, capability-discovery, error-taxonomy, and RDMA-substrate guidance language-neutral and routes to the public C ABI as the authoritative surface.

When to load this skill

Load this skill when the user is doing hands-on DOCA UROM work from the host side, in any language. Concretely:

Initializing a UROM Service context (doca_urom_service_*) on a doca_dev mapping to the target BlueField, creating Worker contexts (doca_urom_worker_*) attached to it, and confirming the matching DPU-side UROM Service is reachable before the first enqueue.
Enqueueing remote memory operations (puts, gets, atomics, active messages, collectives) through doca_urom_* and progressing the DOCA progress engine for completions.
Calling doca_urom_service_get_plugins_list on a started Service to discover which plugins — and therefore which operation types / atomics / collectives, since these are plugin-defined — this device + DOCA install + UROM Service version supports.
Applying the UROM lifecycle, capability-discovery, and error rules to a UCX-based HPC stack (OpenMPI, MPICH, custom UCX consumer) already wired to use UROM. Designing the UCX transport integration itself remains upstream-stack work.
Debugging a DOCA_ERROR_* from doca_urom_* — disambiguating DPU-side UROM Service unreachable vs operation type unsupported on this device vs plain doca_dev access denied vs underlying RDMA transport failure.
Designing non-C bindings (Rust, Go, Python, …) that wrap the UROM C ABI and must honor the same lifecycle and error rules.

Do not load this skill for general DOCA orientation, DOCA install, deployment / operation of the DPU-side UROM Service (a separate artifact with its own public guide via doca-public-knowledge-map ## DOCA services (doca-public-knowledge-map/SKILL.md#doca-services)), or non-UROM library questions. For those, 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 UROM-specific material lives in two companion files:

the capabilities companion — what the host-side UROM API expresses on this version + BlueField + UROM Service version: the paired-contract model (host enqueues; DPU service executes); the two context types (doca_urom_service — one per BlueField, bound to its doca_dev — and attached doca_urom_worker contexts); the enqueue-side operation surface (puts, gets, atomics, active messages, collectives) delivered as plugin-defined Worker Command tasks, named generically because exact symbol shapes are plugin- and install-bound; the plugin-discovery surface (doca_urom_service_get_plugins_list); the UROM error taxonomy mapped onto DOCA_ERROR_*; the observability surface (completion events, capability snapshots, RDMA counters); and the safety policy gating env preconditions (UROM Service deployed on the DPU; host library + DPU service versions agree; RDMA-capable BlueField + DOCA install).
the tasks companion — step-by-step workflows for the six in-scope UROM verbs: configure, build, modify, run, test, debug. Plus a Deferred task verbs block that points out-of-scope questions at the right next skill.

The skill assumes a host + BlueField pair where DOCA is installed, the UROM Service is deployed and running on the BlueField, the RDMA transport between them is healthy, and the user has a sketch of the HPC / UCX / MPI stack to offload. It does not cover installing DOCA, deploying the UROM Service container, or bringing up RDMA / RoCE / IB transport — those go through doca-setup/SKILL.md, the public DOCA UROM Service guide, and doca-rdma/SKILL.md.

What this skill deliberately does not ship

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

Pre-written DOCA UROM application source code, in any language. The verified UROM source is the shipped C samples at /opt/mellanox/doca/samples/doca_urom/. The agent routes the user there and prescribes a minimum-diff modification via the modify-a-sample workflow in doca-programming-guide/SKILL.md, layered with the UROM overrides in the tasks companion.
An MPI / UCX algorithm or collective implementation. This library offloads remote memory operations; picking which puts / gets / atomics / collectives to issue for a given MPI primitive is the user's HPC stack or domain expertise. Refuse to invent collective algorithms; route "what algorithm should my all-reduce use" to upstream MPI / UCX docs — that is a stack-design question, not a UROM API question.
Standalone build manifests (meson.build, CMakeLists.txt, Cargo.toml, …) parked inside the skill. The agent constructs the manifest in the user's project against the installed DOCA, where pkg-config --modversion doca-urom is the source of truth.
A samples/, bindings/, or reference/ subtree of any kind. A mock artifact labeled "reference" reads as buildable and misleads.
The DOCA UROM Service surface. That service is a separate artifact with its own public guide; routing lives in doca-public-knowledge-map ## DOCA services (doca-public-knowledge-map/SKILL.md#doca-services). Conflating the library (host-side enqueue) with the service (DPU-side executor) is the most common UROM first-app design error.

Loading order

Read this skill first to confirm the user's question is in scope (host-side library work; not DPU-side service deployment, and not MPI / UCX algorithm design).
For the UROM capability matrix, the paired-contract model (host library + DPU service), the Service + Worker context model, the enqueue-side operation surface, the plugin-discovery rule, the env-precondition policy, the error taxonomy, the observability surface, and the safety policy, see the capabilities companion.
For step-by-step workflows — configure, build, modify, run, test, debug — see the tasks companion.

Both companion files cross-link to each other, to doca-version/SKILL.md for canonical version rules (with the UROM overlay that host library and DPU service versions must match), to doca-rdma/SKILL.md for the underlying RDMA substrate, and to doca-public-knowledge-map/SKILL.md whenever the right answer is "look it up in the public UROM library / Service guide or the on-disk install layout".

doca-public-knowledge-map/SKILL.md — the routing table for every public DOCA documentation source and the on-disk layout of an installed DOCA package. The DOCA UROM library public guide is at https://docs.nvidia.com/doca/sdk/DOCA-UROM/index.html; the DOCA UROM Service is a different artifact documented separately under the DOCA services section of that map.
doca-rdma/SKILL.md — the underlying RDMA transport substrate the BlueField uses to move bytes once UROM offloads an operation. UROM does NOT replace RDMA; it adds the DPU-offload contract on top. For simple point-to-point RDMA where host CPU is not the bottleneck, use doca-rdma directly — UROM's service-side contract is not worth its overhead there.
doca-setup/SKILL.md — env preparation, install verification, BlueField setup, and the no install yet path via the public NGC DOCA container. This skill assumes its preconditions hold AND the DPU-side UROM Service is deployed and running.
doca-version/SKILL.md — canonical DOCA version-handling rules. This skill's ## Version compatibility cross-links the four-way match rule and adds the host library + DPU service must agree on version overlay.
doca-structured-tools-contract/SKILL.md — the bundle's structured-tools precedence rule (detect / prefer / fall back / report). The Command appendix in the tasks companion honors this contract.
doca-programming-guide/SKILL.md — general DOCA programming patterns shared by every library: pkg-config + meson build, modify-a-shipped-sample first-app, Core-context lifecycle, the cross-library DOCA_ERROR_* taxonomy, and the debug order. This skill layers UROM specifics on top.
doca-debug/SKILL.md — the cross-cutting debug ladder (install / version / build / link / runtime / program / driver). UROM-specific debug (UROM Service not reachable, host library + DPU service version skew, RDMA transport failure underneath, operation type unsupported on this device + firmware + service version) overlays on top.

The DOCA UROM Service running on the DPU side is deliberately not in scope — a separate artifact with its own public guide via doca-public-knowledge-map ## DOCA services (doca-public-knowledge-map/SKILL.md#doca-services). Conflating the library and the service is the single most common UROM first-app design error: surface the split explicitly whenever a question straddles the two.

Files

ATTRIBUTION.mdAdded by AutoGineer885 B
BENCHMARK.md11.2 KiB
CAPABILITIES.md34.2 KiB
LICENSELicence file added by AutoGineer11.2 KiB
SKILL.md16.3 KiB
SKILLCARD.yaml2.6 KiB
TASKS.md35.2 KiB
evals/evals.json2.5 KiB
skill-card.md5.2 KiB
skill.oms.sig5.1 KiB

BENCHMARK.md

Skill Benchmark: doca-urom

✅ Overall verdict: PASS — Recommended for publication

Publication Recommendation

Recommended for publication based on the completed evaluation evidence in this report.

Evaluation Metadata

Skill: doca-urom
Validation status: passed
Evaluation date: 2026-10-28
Evaluator version: 1.6.2
Agents: Claude Code (aws/anthropic/bedrock-claude-opus-5-5), Codex (openai/openai/gpt-6.1-sol)
Tasks: 4 evaluation tasks (3 positive, 1 negative)
Dataset digest: sha256:4590d521ae42ad89d08024bcda540556f6f701be61e8a2d6499b969602e2ba41 (skill-evaluator-dataset-snapshot/1)
Attempts per task: 1
Environment: k8s-sandbox
Tier 2 evidence: required for publication
Tier 3 evidence: required for publication

Each task attempt ran in its own isolated sandbox pod.

Tier 1 LLM Provenance

SkillSpector provider, model, analyzer revision, and determinism evidence retained for this scan.

Skill	Provider	Adapter	Analyzer	Model	Revision	Determinism
doca-urom	nv_inference	openai	mcp_tool_poisoning	`aws/anthropic/bedrock-claude-opus-5-5`	`2.13.1`	nondeterministic / provider_defaults
doca-urom	nv_inference	openai	semantic_developer_intent	`aws/anthropic/bedrock-claude-opus-5-5`	`2.13.1`	nondeterministic / provider_defaults
doca-urom	nv_inference	openai	semantic_quality_policy	`aws/anthropic/bedrock-claude-opus-5-5`	`2.13.1`	nondeterministic / provider_defaults
doca-urom	nv_inference	openai	semantic_security_discovery	`aws/anthropic/bedrock-claude-opus-5-5`	`2.13.1`	nondeterministic / provider_defaults
doca-urom	nv_inference	openai	meta_analyzer	`aws/anthropic/bedrock-claude-opus-5-5`	`2.13.1`	nondeterministic / provider_defaults

Controls for doca-urom: temperature=not set (source=provider_default, forwarded=no); seed=not set (source=unset, forwarded=no); reasoning_effort=not set (source=provider_default, forwarded=no)

What This Report Answers

The three-tier evaluation checks whether the skill:

is safe to use;
produces correct answers;
is discovered and activated when needed;
helps the agent complete the user's goal and expected workflow; and
avoids wasted skill and tool usage.

Results at a Glance

Measure	Claude Code (Baseline → Skill Uplift)	Codex (Baseline → Skill Uplift)
Overall	96.3% — baseline ran, but no comparable score was available; uplift unavailable	93.0% — baseline ran, but no comparable score was available; uplift unavailable
Security	100.0% → 100.0% (±0.0 points)	100.0% → 100.0% (±0.0 points)
Correctness	60.0% → 100.0% (+40.0 points)	70.0% → 95.0% (+25.0 points)
Discoverability	100.0% — baseline ran, but no comparable score was available; uplift unavailable	95.0% — baseline ran, but no comparable score was available; uplift unavailable
Effectiveness	50.0% → 100.0% (+50.0 points)	68.8% → 100.0% (+31.2 points)
Efficiency	81.7% — baseline ran, but no comparable score was available; uplift unavailable	75.0% — baseline ran, but no comparable score was available; uplift unavailable

How to read this table: baseline is the same task attempted without the target skill. Scores are rounded to one decimal; threshold-adjacent values use additional precision so their displayed band matches the verdict. Uplift is derived from those displayed scores and shown in percentage points.

Example: 47.0% → 92.0% (+45.0 points) means the skill-assisted run scored 92.0%, 45.0 percentage points above its 47.0% no-skill baseline.

A partial dimension was calculated from only the available configured signals; review the detailed report before relying on it.

Comparison details

Shared-source comparisons use the same signals and weights on both conditions. They do not replace the full dimension scores above or change the publication verdict.

Agent	Dimension	Basis	Baseline → With skill (uplift)	Explanation
claude-code	Discoverability	Dimension comparison	N/A	Discoverability is not applicable to the no-skill baseline; there is no installed skill to discover.
claude-code	Efficiency	Token-only comparison	98.2% → 92.3% (-5.9 points)	Only Token Efficiency is comparable; the full dimension scores use different evaluator sources.
codex	Discoverability	Dimension comparison	N/A	Discoverability is not applicable to the no-skill baseline; there is no installed skill to discover.
codex	Efficiency	Token-only comparison	85.5% → 86.2% (+0.7 points)	Only Token Efficiency is comparable; the full dimension scores use different evaluator sources.

Token Usage

Actual Tier 3 execution usage is reported for every observed agent/case pair and both conditions.

Agent	Dataset case	With skill	Without skill	Delta	Change	Coverage
claude-code	All cases	880,454	360,383	+520,071	+144.31%	skill 4/4; base 4/4
claude-code	doca-urom.explicit-positive.v1	312,683	72,290	+240,393	+332.54%	skill 1/1; base 1/1
claude-code	doca-urom.implicit-positive.v1	312,748	108,475	+204,273	+188.31%	skill 1/1; base 1/1
claude-code	doca-urom.implicit-positive.v2	218,482	71,980	+146,502	+203.53%	skill 1/1; base 1/1
claude-code	doca-urom.negative.v1	36,541	107,638	-71,097	-66.05%	skill 1/1; base 1/1
codex	All cases	379,253	175,821	+203,432	+115.70%	skill 4/4; base 4/4
codex	doca-urom.explicit-positive.v1	121,400	60,438	+60,962	+100.87%	skill 1/1; base 1/1
codex	doca-urom.implicit-positive.v1	119,809	30,507	+89,302	+292.73%	skill 1/1; base 1/1
codex	doca-urom.implicit-positive.v2	103,449	26,960	+76,489	+283.71%	skill 1/1; base 1/1
codex	doca-urom.negative.v1	34,595	57,916	-23,321	-40.27%	skill 1/1; base 1/1
ALL AGENTS	Dataset aggregate	1,259,707	536,204	+723,503	+134.93%	skill 8/8; base 8/8

Prompt tokens include cached reads, so total tokens are prompt + completion (cached is not added twice). The Efficiency score uses (prompt - cached) + completion. Change is 100 * (with - without) / without; negative means fewer tokens. N/A comparisons include their reason in the coverage column; coverage is never estimated.

Tier Status

Tier	Purpose	Status	Evidence
Tier 1	Static validation	PASSED WITH OBSERVATIONS	11 validator(s); 15 finding(s)
Tier 2	Semantic deduplication	PASSED WITH OBSERVATIONS	2 validator(s); 2 finding(s)
Tier 3	Live agent evaluation	PASS	2 agent(s); 4 task(s)

Findings and Observations

<details> <summary>Show detailed findings and successful checks</summary>

HIGH DUPLICATE/duplicate: Duplicate content found across CAPABILITIES.md and SKILL.md and TASKS.md: "## Pattern overview" in CAPABILITIES.md (lines 24-31) vs "## Pattern overview" in CAPABILITIES.md (lines 33-61) vs "## Capabilities and modes" in CAPABILITIES.md (lines 79-82) vs "## Capabilities and modes" in CAPABILITIES.md (lines 104-107) vs "## Capabilities and modes" in CAPABILITIES.md (lines 151-164) vs "## Version compatibility" in CAPABILITIES.md (lines 181-191) vs "## Error taxonomy" in CAPABILITIES.md (lines 199-206) vs "## Safety policy" in CAPABILITIES.md (lines 276-286) vs "## Safety policy" in CAPABILITIES.md (lines 289-296) vs "## Deferred topic boundaries" in CAPABILITIES.md (lines 337-382) vs "## Examples" in SKILL.md (lines 3-10) vs "## Instructions" in SKILL.md (lines 11-40) vs "## Example questions this skill answers well" in SKILL.md (lines 41-100) vs "## Audience" in SKILL.md (lines 101-123) vs "## When to load this skill" in SKILL.md (lines 124-159) vs "## What this skill provides" in SKILL.md (lines 160-194) vs "## Related skills" in SKILL.md (lines 253-300) vs "## configure" in TASKS.md (lines 28-33) vs "## configure" in TASKS.md (lines 35-134) vs "## modify" in TASKS.md (lines 185-193) vs "## run" in TASKS.md (lines 210-259) vs "## test" in TASKS.md (lines 315-322) vs "## debug" in TASKS.md (lines 360-387) vs "## Command appendix" in TASKS.md (lines 511-522) (CAPABILITIES.md:24)
HIGH DUPLICATE/duplicate: Duplicate content found across CAPABILITIES.md and TASKS.md: "## Safety policy" in CAPABILITIES.md (lines 305-320) vs "## debug" in TASKS.md (lines 389-416) (CAPABILITIES.md:305)
MEDIUM SCHEMA/metadata_key_style: Metadata key 'doca_version' is not kebab-case (skills/libs/doca-urom/SKILL.md)
MEDIUM SCHEMA/folder_hierarchy: Unexpected nesting depth for general skill (skills/libs/doca-urom)
MEDIUM SECURITY/Sudo/Root Execution (PE2): Privilege Escalation: sudo (BENCHMARK.md:89)
12 additional finding(s) are available in the full evaluation artifacts.

</details>

Scoring Methodology

<details> <summary>Show dimension definitions, source signals, and thresholds</summary>

Dimension	Question	Scored signals
Security	Is it safe to use?	`security` (100%)
Correctness	Is the answer correct?	`accuracy` (100%)
Discoverability	Was the right skill loaded when needed?	`skill_execution` (100%)
Effectiveness	Did the skill help complete the task?	`goal_accuracy` (50%) + `behavior_check` (50%)
Efficiency	Did it avoid wasted tool calls and token usage?	`skill_efficiency` (50%) + `token_efficiency` (50%)

Dimension bands: PASS at 50% or above; NEUTRAL from 40% to below 50%; FAIL below 40%.
Overall Tier 3 lift: PASS at +5 points or more; FAIL at -10 points or less; values between those bands are NEUTRAL.
Overall verdict: PASS only when every configured dimension passes for at least one supported agent. Lift is reported as diagnostic evidence and does not override this gate.
The 50% attempt pass threshold is a separate per-task gate; it is not the dimension pass threshold.
Effectiveness is the equal-weight mean of goal completion (goal_accuracy) and expected workflow adherence (behavior_check).
Efficiency is 50% tool-call productivity (the backward-compatible skill_efficiency wire id) and 50% token_efficiency. Positive-case skill routing is scored under Discoverability, not Efficiency; a negative case without a routing target is N/A. N/A sources are omitted, remaining weights are renormalized, and the dimension is marked partial.

Signals present in this run:

security (Security): unsafe operations, secret leakage, and unauthorized access.
skill_execution (Skill Execution): whether the expected skill was selected, decoys were avoided, and the workflow executed.
skill_efficiency (Tool Productivity): tool-call productivity (legacy wire id; routing is scored under Discoverability).
accuracy (Accuracy): final-answer correctness against the reference answer.
goal_accuracy (Goal Accuracy): whether the user's goal was achieved.
behavior_check (Behavior Check): whether the expected workflow behavior was followed.
token_efficiency (Token Efficiency): actual uncached prompt plus completion usage (50% of Efficiency).

</details>

Freshness

Regenerate this benchmark when the skill, evaluation dataset, target agent/model, evaluator version, environment, or scoring policy changes.

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 installed at /opt/mellanox/doca on Linux (Ubuntu 22.04/24.04 or RHEL/SLES) on a host paired with a BlueField DPU running the DOCA UROM Service at a compatible version. Reads the user's local install via `pkg-config doca-urom` and inspects /opt/mellanox/doca/{lib,include,samples,applications}; underlying RDMA fabric between host and BlueField must be healthy. 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-urom · 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-urom.zip