What does this skill do, and when should you use it?
DOCA Common is for developers building DOCA applications on a BlueField DPU or ConnectX NIC. It covers doca_ctx lifecycle management, device discovery and capability gating, zero-copy buffer wiring, progress-engine completion handling, and DOCA Log’s two-tier model. The skill is a thin loader that directs agents to CAPABILITIES.md and TASKS.md for substantive guidance. It assumes the DOCA SDK is already installed and does not cover installation or isolated per-library programming.
It directs the agent to inspect the local DOCA installation with pkg-config --modversion doca-common and the /opt/mellanox/doca/{lib,include,samples,applications} layout; plan lifecycles and connections for doca_devinfo, doca_dev, doca_ctx, doca_mmap, doca_buf_inventory, doca_buf, and doca_pe; gate feature use on doca_*_cap_* checks against the active device information; explain the distinction between --sdk-log-level and application-side log settings; and route installation, documentation lookup, and library-specific questions to related skills.
- A developer starting a BlueField-3 Flow, RDMA, or Ethernet application who needs the shared context and progress-engine skeleton first.
- A developer who must discover a device and decide at runtime whether its active capabilities support a feature.
- A developer sharing zero-copy buffers across doca-eth, doca-dma, and doca-rdma.
- A developer whose submitted tasks do not complete and who needs to inspect the doca_pe progress loop.
- A developer whose application `DOCA_LOG_DBG` lines remain invisible after setting `--sdk-log-level`.
- A developer designing Rust, Go, or Python bindings around the DOCA public C ABI.
How do you install this skill?
- This is a low-confidence static review; no commands, samples, or tests were executed.
- Before use, verify the local DOCA version, hardware capabilities, permissions, and API availability; the documented workflows are not verified code.
- License, version/signing, and maintenance metadata should be reconciled, with Chinese guidance, failure-output examples, confirmation requirements, and rollback boundaries added.
- Shell / CLI
- Local filesystem
DOCA SDK installed at /opt/mellanox/docaLinuxBlueField DPU or ConnectX NIC
Install the named skill using the repository README’s Skills CLI flow: npx skills add nvidia/skills --skill doca-common --yes. The CLI selects or writes the installation destination; manually cloning the repository or copying the folder is not required. The README does not document a separate doca-common package installer.
tmp="$(mktemp -d)"
git clone --depth 1 https://github.com/NVIDIA/skills.git "$tmp"
mkdir -p ~/.claude/skills
cp -R "$tmp/skills/doca-common" ~/.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?
On a Linux host with the DOCA SDK installed, ask the agent for a hands-on foundation task, for example: My doca_rdma tasks submit successfully but never complete; inspect the doca_pe and run loop. For universal primitives, have it read CAPABILITIES.md; for configure, build, modify, run, test, debug, use, or log workflows, have it read TASKS.md. Load the matching per-library skill alongside it for Flow, RDMA, Ethernet, or other library-specific work.
What are this skill's strengths and limitations?
- Covers the shared ctx, dev, buf, PE, and logging primitives used across DOCA applications.
- Treats capabilities on the active doca_devinfo as the runtime authority for feature use.
- Targets common lifecycle, cross-library zero-copy, completion, and logging failure modes.
- Keeps the foundation language-neutral for FFI and binding users while treating the public C ABI as authoritative.
- Requires a preinstalled DOCA SDK, Linux, and an attached BlueField DPU or ConnectX NIC; it does not install DOCA.
- The SKILL.md is a thin loader, so detailed procedures depend on CAPABILITIES.md and TASKS.md, whose contents are not included here.
- It deliberately provides no buildable application source, standalone build manifests, samples, bindings, or reference subtree.
- The source states supported Linux distributions but provides no independent test results or detailed hardware coverage matrix.
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 Common Foundation this page ✓ NVIDIA · Official | 55 · Use with care | ★ 3.6k | 13d ago | Apache-2.0 |
| DOCA Ethernet Queue Development ✓ NVIDIA · Official | 55 · Use with care | ★ 3.6k | 13d ago | Apache-2.0 |
| DOCA DMA Development Guide ✓ NVIDIA · Official | 54 · Use with care | ★ 3.6k | 13d ago | Apache-2.0 |
| DOCA Arg Parser CLI ✓ NVIDIA · Official | 55 · Use with care | ★ 3.6k | 13d ago | Apache-2.0 |
| DOCA RDMA Programming Guide ✓ NVIDIA · Official | 56 · Use with care | ★ 3.6k | 13d ago | Apache-2.0 |
How did FollowSkills review this skill?
The material is explicitly documentation guidance, states that no credentials are required, and routes installation, hardware safety, and debugging elsewhere. However, its run workflows involve devices, file redirection, and hardware-adjacent actions without a complete confirmation, least-privilege, rollback, or sensitive-data-handling procedure, so points are deducted.
SKILL.md, CAPABILITIES.md, and TASKS.md are broadly consistent on lifecycle order, capability checks, PE progress, and error routing, and commonly require stopping or escalating on failure. Static review cannot reproduce key paths; several API, version, and installation assumptions depend on the local environment, and test coverage and failure-output contracts are thin, so the score is capped and reduced.
Triggers, audience, examples, and non-fit boundaries are unusually explicit, including C/C++ and FFI consumers. There is no Chinese-language guidance or mainland-China reachability analysis, while core references and prerequisites depend on NVIDIA documentation, a local DOCA installation, and specialized hardware, so points are deducted.
The loader, capability reference, and task workflows provide good progressive structure, cross-links, examples, boundaries, evaluation notes, and security contacts. Version, signature, and scan fields remain TBD; maintenance ownership and change history are incomplete; and license statements conflict across files (Apache-2.0, Apache-2.0 AND CC-BY-4.0, and NOASSERTION metadata), so points are deducted.
The files directly address device discovery, capability gating, buffer lifecycles, contexts, progress engines, logging, and debugging routes, plausibly covering the core guidance task. They provide no directly compilable implementation or representative reproducible outputs, and BENCHMARK.md says the evaluation dataset is unavailable; static evidence cannot establish complete directly usable results, so the score is limited to the static ceiling.
Committed evals, BENCHMARK.md, SKILLCARD, and traceable symbol/workflow references provide limited auditability. The evaluation dataset is unavailable, reported results cannot be independently reproduced from the supplied files, and there is little corroboration across independent evidence types, so points are deducted.
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 →