What does this skill do, and when should you use it?
This skill serves external developers using DOCA Verbs inside DOCA Core to control QPs, CQs, PDs, MRs, SRQs, address handles, and related Ethernet queue primitives. It first checks whether the higher-level DOCA RDMA, Eth, or Rivermax API already covers the request, preventing unnecessary descent into raw verbs. For cases requiring low-level attributes, capability queries, libibverbs porting, or error diagnosis, it routes users to capability guidance and configure, build, modify, run, test, and debug workflows. The skill is guidance only: it does not ship application source, build manifests, bindings, or migration scripts.
It reads the user's installed DOCA headers, libraries, samples, and applications, and checks the doca-verbs pkg-config module. It selects between higher-level DOCA libraries and doca_verbs_* based on the requested semantic, and guides capability checks using doca_verbs_query_device and the doca_verbs_device_attr_get_* family. It explains how to port libibverbs code into the DOCA Core lifecycle and progress engine while enforcing a no-mixing rule for the two handle models. For DOCA_ERROR_* results, especially DOCA_ERROR_IO_FAILED, it directs investigation toward the completion-queue entry and provides entry points for configure, build, modify, run, test, and debug workflows.
- An RDMA developer needs a specific work-request flag or QP attribute that doca_rdma_task_* does not expose.
- A DOCA Core application requires explicit SRQ, completion-queue, or address-handle control.
- A C or C++ developer is moving an existing libibverbs sender or receiver into the DOCA Core lifecycle and progress engine.
- A developer needs to verify whether a device and DOCA version support a particular verb, opcode, WR flag, or QP feature.
- A developer receives a DOCA_ERROR_* result from doca_verbs_*, especially IO_FAILED during work-request submission.
- A developer is designing Rust, Go, Python, or another wrapper around the DOCA Verbs C ABI.
How do you install this skill?
- Do not treat the workflows as a verified runnable implementation; confirm symbols, pkg-config versions, device capabilities, and samples on the target host.
- Obtain explicit user authorization before device checks, sudo commands, or hardware-related configuration changes, and prepare a recoverable plan.
- The SKILL.md, SKILLCARD.yaml, and supplied license/provenance metadata are inconsistent and should be reconciled before publication.
- The benchmark report lacks its source dataset, so PASS and high percentages should not be treated as independently reproduced evidence.
- Shell / CLI
- Local filesystem
DOCA SDK installed at /opt/mellanox/docapkg-configLinux with Ubuntu 22.04/24.04 or RHEL/SLESBlueField DPU or ConnectX NIC
Install the specific skill with the repository's documented Skills CLI command: npx skills add nvidia/skills --skill doca-verbs --yes. You can also run npx skills add nvidia/skills --list to browse the catalog. Separately, the target Linux host or BlueField environment must already have the DOCA SDK installed at /opt/mellanox/doca; the supplied source does not document DOCA SDK installation.
tmp="$(mktemp -d)"
git clone --depth 1 https://github.com/NVIDIA/skills.git "$tmp"
mkdir -p ~/.claude/skills
cp -R "$tmp/skills/doca-verbs" ~/.claude/skills/
rm -rf "$tmp"Generated from the source repository and skill path; it copies only this skill's folder. If the author's install steps above differ, follow those first. To scope it to one project, replace ~/.claude/skills with that project's .claude/skills.
How do you use this skill?
Once installed, send your agent any of these to trigger it:
- My doca_rdma_task_* abstraction does not expose the raw WR flag I need; should I use doca-verbs?
- How do I port my libibverbs code into DOCA Core?
In an environment with DOCA installed, ask the agent about a confirmed raw-verbs requirement, for example: “My doca_rdma_task_* abstraction does not expose the raw WR flag I need; should I use doca-verbs?” or “How do I port my libibverbs code into DOCA Core?” The agent should first confirm that the higher-level library cannot express the semantic, then continue through CAPABILITIES.md and TASKS.md. General RDMA data movement, DOCA installation, and general libibverbs theory belong to other skills; the source provides no standalone doca-verbs application commands or code samples.
What are this skill's strengths and limitations?
- Clearly limits raw verbs to cases where higher-level DOCA APIs are insufficient.
- Covers low-level QP, CQ, PD, MR, SRQ, address-handle, Ethernet SQ/RQ, and congestion-control-group objects.
- Provides focused routing for capability discovery, the libibverbs boundary, DOCA Core lifecycle, and error diagnosis.
- Applies to C/C++ and to other languages using the same C ABI through FFI.
- Requires an installed DOCA SDK, a prepared Linux RDMA environment, and a BlueField DPU or ConnectX NIC.
- Uses an experimental ABI tier whose symbols may change between DOCA releases; local headers are authoritative.
- Ships no buildable source, build manifests, samples, bindings, reference subtree, or migration script.
- The supplied material provides no independent test results or platform-coverage evidence for this individual skill.
How does this skill compare with similar options?
Side by side with related skills; every score comes from the same FSRS standard.
| Skill | FS score | Stars | Last updated | License |
|---|---|---|---|---|
| DOCA Verbs Raw RDMA Control this page ✓ NVIDIA · Official | 56 · Use with care | ★ 3.8k | today | Apache-2.0 |
| DOCA GPUNetIO Development Skill ✓ NVIDIA · Official | 55 · Use with care | ★ 3.8k | today | Apache-2.0 |
| DOCA Device Management Development Skill ✓ NVIDIA · Official | 53 · Use with care | ★ 3.8k | today | Apache-2.0 |
| DOCA GPI GPU-Initiated RDMA Skill ✓ NVIDIA · Official | 52 · Use with care | ★ 3.8k | today | Apache-2.0 |
| DOCA Hardware Telemetry Counter Reader ✓ NVIDIA · Official | 60 · Recommended | ★ 3.8k | today | Apache-2.0 |
Compared with higher-level DOCA libraries such as doca-rdma, doca-eth, and doca-rmax, doca-verbs is a targeted escape hatch for specific verbs, opcodes, work-request flags, queue attributes, or capability queries that those APIs do not expose; it is not the default data-movement interface. Compared with libibverbs, it integrates verbs objects and lifecycle into DOCA Core and uses the DOCA progress engine for completion handling; the source explicitly rejects mechanically mixing the two handle models.
How did FollowSkills review this skill?
The documentation requires confirming that a higher-level library is insufficient, forbids mixing ibv_* handles, mandates capability queries, and discloses the experimental ABI; it contains no credential harvesting or covert exfiltration guidance. However, it involves device access, RDMA configuration, and sudo-based checks without explicit user confirmation, rollback guidance, strong least-privilege boundaries, or complete data-flow disclosure, so points are deducted.
The workflows, prerequisites, error taxonomy, completion inspection, and escalation paths are fairly detailed. Static review provides no executable reproduction, and several symbols must be confirmed from local headers, so key-path reliability cannot be established and the score remains conservatively below the static ceiling.
Triggers, non-fit cases, routing boundaries, and C/C++ plus FFI coverage are clearly described. The skill nevertheless depends heavily on Linux, an installed DOCA SDK, and BlueField or ConnectX hardware, with no explicit Chinese-language support or mainland-China reachability analysis, limiting environment-fit evidence.
The skill uses layered SKILL.md, CAPABILITIES.md, and TASKS.md documentation and includes installation, version, limitation, troubleshooting, maintenance, and evaluation material. However, the frontmatter lacks an author, the skill card has TBD version and signature fields, license metadata is inconsistent, and the static report notes missing recommended Instructions/Examples sections, so full marks are not justified.
It can route users away from unnecessary raw verbs and provides configure, build, modify, run, test, and debug workflows. It ships no directly buildable code or samples, the unified-diff renderer is deferred, and representative outputs were not verified in this review, so effectiveness is limited to the static-review ceiling.
The skill directs users to installed headers and runtime capability queries as authorities and includes benchmark results and evaluation assertions. The evaluation dataset is unavailable, there is no independently reproducible evidence or committed test suite covering key paths, and the evidence is primarily maintainer-authored documentation, so verification remains limited.
Open a dimension to read why it scored that way
Evidence confidence：Low — Mostly static review, author material or a limited demo; useful for discovery, not high-risk decisions.
See the full review method →