What does this skill do, and when should you use it?
This skill serves developers using DOCA Telemetry reader libraries to read PCC, DPA, DIAG, ADP_RETX, PHY, or PCI hardware counters from a doca_dev. It covers capability checks, per-domain context creation, startup, sample-window configuration, snapshot reads, and error handling. It requires the DOCA SDK on Linux and a supported BlueField DPU or ConnectX NIC. It does not publish or export metrics and does not cover DOCA Telemetry Service, NetFlow, IPFIX, or local-socket collection.
Guides selection of the appropriate doca_telemetry_<domain> header and library; checks whether the device exposes a counter domain; creates and starts a per-domain context on a doca_dev; configures the sample window and reads the latest hardware-counter snapshot; explains DOCA_ERROR_* results, NOT_SUPPORTED, AGAIN, permission, and driver conditions; and supplies lifecycle and error-handling rules for C/C++ applications and FFI wrappers in other languages.
- A C/C++ developer reading PCC counters from a BlueField application can use the skill to select the PCC reader API and perform capability checks.
- A developer sampling DPA counter exports can use the per-domain context and sample-window guidance to read hardware snapshots.
- A network-device developer exposing PHY, PCI, or DIAG counters can query the relevant capabilities before attempting reads.
- A Rust, Go, or Python developer wrapping the DOCA Telemetry C ABI can use the skill to preserve the per-domain lifecycle and error rules.
How do you install this skill?
- The supplied license metadata is NOASSERTION, while the included files claim Apache-2.0 and Apache-2.0 AND CC-BY-4.0; reconcile and verify licensing before publication.
- The benchmark report says PASS, but the raw eight-task dataset is unavailable and cannot substitute for independent reproduction.
- Execution guidance touches real BlueField/ConnectX hardware and domain-specific privileges; verify device capabilities, version alignment, and permissions rather than defaulting to global sudo.
- clear-on-read resets underlying counters; obtain explicit confirmation and assess impact on other readers before enabling it.
- Shell / CLI
- Local filesystem
DOCA SDK at /opt/mellanox/docaLinux (Ubuntu 22.04/24.04 or RHEL/SLES)BlueField DPU or ConnectX NICpkg-config
Install the named skill with the NVIDIA skills CLI:
npx skills add nvidia/skills --skill doca-telemetry --yes
This command is supported by the repository README. The skill becomes available when the agent loads a relevant task. Installing the DOCA SDK itself is outside this skill.
tmp="$(mktemp -d)"
git clone --depth 1 https://github.com/NVIDIA/skills.git "$tmp"
mkdir -p ~/.claude/skills
cp -R "$tmp/skills/doca-telemetry" ~/.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:
- read PCC counters from my BlueField app
- sample DPA counter exports.
On a Linux host with the DOCA SDK installed and a BlueField DPU or ConnectX NIC attached, give the agent a concrete reader request such as “read PCC counters from my BlueField app” or “sample DPA counter exports.” For configure, build, modify, run, test, or debug work, continue with TASKS.md in the skill directory; for supported counter domains, consult CAPABILITIES.md.
What are this skill's strengths and limitations?
- Covers six per-domain hardware-counter reader libraries.
- Enforces capability checks before attempting domain reads.
- Provides guidance for per-domain lifecycle, sampling windows, and read-error classification.
- Applies to C/C++ and can guide FFI wrappers in other languages.
- Requires a preinstalled DOCA SDK and a BlueField DPU or ConnectX NIC.
- Covers counter reading only, not Prometheus, OTLP, or other publishing/export workflows.
- Excludes DOCA Telemetry Service, NetFlow, IPFIX, and local-socket collection.
- Detailed workflows are delegated to TASKS.md and CAPABILITIES.md, whose contents were not supplied here.
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 Hardware Telemetry Counter Reader this page ✓ NVIDIA · Official | 60 · Recommended | ★ 3.6k | 13d ago | Apache-2.0 |
| DOCA Telemetry Exporter Development ✓ NVIDIA · Official | 55 · Use with care | ★ 3.6k | 13d ago | Apache-2.0 |
| DOCA Device Management Development Skill ✓ NVIDIA · Official | 53 · Use with care | ★ 3.6k | 13d ago | Apache-2.0 |
| DOCA SHA OpenSSL Offload Engine ✓ NVIDIA · Official | 52 · Use with care | ★ 3.6k | 13d ago | Apache-2.0 |
| DOCA Flow DPA Performance ✓ NVIDIA · Official | 58 · Recommended | ★ 3.6k | 13d ago | Apache-2.0 |
For publishing or exporting counter values, use the separately named doca-telemetry-exporter skill; for plain structured stdout logging, consider doca-log; for non-DOCA counter sources, use a generic Prometheus or OpenTelemetry client; for a deployed aggregator, consider DOCA Telemetry Service.
How did FollowSkills review this skill?
The documentation scopes the skill to local DOCA hardware-counter reads, requires capability checks and domain-specific privileges, classifies errors, and warns about the destructive effects of clear-on-read. No malicious behavior or covert exfiltration is shown. However, permission boundaries, user confirmation, rollback, and full data-flow disclosure are incomplete, and the supplied license metadata says NOASSERTION while the files claim Apache-2.0, so points are deducted.
SKILL.md, CAPABILITIES.md, and TASKS.md give a fairly consistent static account of the six domains, lifecycle, error taxonomy, and sample-window retries. There are no executable key-path tests, several dependencies are external or installation-specific, and the benchmark dataset is unavailable for verification. Static calibration therefore caps the score at 10 and uncertainty lowers it further.
Audience, trigger phrases, non-fit scenarios, reader-versus-exporter boundaries, and the PCI capability-query exception are clearly stated. Chinese-language guidance and mainland-China reachability evidence are absent. The core function depends on local DOCA and hardware rather than an overseas service, so no core network deduction is applied, but boundary evidence remains incomplete.
The material uses layered loader, capability, task, and reference documents and includes example questions, limitations, version routing, and issue intake. However, stable release versioning, changelog information, and explicit maintenance ownership are incomplete; generated skill-card version and signature fields remain TBD, and the benchmark records missing recommended sections, author metadata, and nonstandard file findings. Points are deducted accordingly.
The material covers domain selection, capability discovery, build, run, test, and debugging workflows and maps errors to actions. It is documentation-only and supplies no directly runnable implementation, while success depends on the user's local SDK, device, and related skills. Under static calibration, 7 is the justified ceiling.
The documents expose traceable symbols, commands, paths, and error semantics, and include a benchmark report. The original dataset and independently reproducible test materials are not supplied, so the evidence does not meet the standard for multiple corroborating evidence types; only limited static verifiability is awarded.
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 →