Agent skill · data analytics · nvidia
doca-version
DOCA version handling: detect the installed release and validate the four-way match across pkg-config doca-common, applications/VERSION, doca_caps --version, and bfver/mlnx-release on BlueField; reason about NGC tags; look up whether a capability exists on this release; diagnose build-vs-runtime drift. Use this skill alongside doca-debug when a symptom smells of version skew: "built but nothing on the wire", "undefined reference to a symbol the docs claim exists", "DOCA_ERROR_NOT_SUPPORTED at runtime", "what does latest mean for this tag", or "is my LTS still supported". Once all four sources match, the component's build / run workflow belongs to its own library, service or tool skill. Refuse install / package choice (doca-setup), per-library API questions (matching library skill), DOCA_ERROR_* taxonomy (doca-programming-guide), and the general debug ladder (doca-debug).
Why this skill is useful
Provides specific domain knowledge on DOCA version handling and validation processes that the AI wouldn't reliably generate on its own.
What it needs
Requires doca installed locally. About 7k tokens when loaded. Last updated 2026-08-07. 2,816 stars on the source repository.
What this skill does
DOCA version Examples "What DOCA version do I actually have installed?" — run the four-source detection chain and require a four-way match. "The program built but does nothing on the wire." — treat mixed-install drift as a version problem before rewriting application code. Instructions Follow Loading order below. Open the tasks companion for detect / validate / diagnose, and the capabilities companion for the four-way match and NGC tag rules. Do not open every companion file. Where to start: This skill is the bundle's single source of truth for DOCA version handling. Open the tasks companion if the user wants to do something with the version (detect / validate / diagnose mismatch); open the capabilities companion when the question is what does version handling cover (the four-way match, the detection chain, NGC semantics, the per-library overlay pattern). Every other skill in the bundle that touches version routes here — they MUST NOT redefine the rules. Example questions this skill answers well The CLASSES of version-handling 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. "What DOCA version do I actually have installed?" — worked example: "the docs say 3.3 but I'm not sure what's on this host". Answered by the canonical detection chain in configure + Capabilities and modes source-of-truth table. "My program built but does nothing on the wire — is my install consistent?" — worked example: "pkg-config --modversion says 3.3.0; docacaps --version says 3.2.0". Answered by the four-way match rule in Version compatibility the partial-install diagnosis in debug. "Is this DOCA capability / API / sample on the version I have?" — worked example: "is the symmetric-RSS hash mode in Flow 2.6.0". …
How to use it
Reference it in AdaL, Claude Code, Cursor or any coding agent — nothing to install:
@skills nvidia/doca-version