---
title: "nvidia&#x2F;skills skills · skilld"
canonical_url: "https://skilld.dev/gh/nvidia/skills"
meta:
  description: "Agent Skills for NVIDIA products — install into Claude Code, Codex, and other coding agents to run Physical AI, robotics, simulation, CUDA, and RAG workflows end to end."
  "og:description": "Agent Skills for NVIDIA products — install into Claude Code, Codex, and other coding agents to run Physical AI, robotics, simulation, CUDA, and RAG workflows end to end."
  "og:title": "nvidia/skills skills"
  "twitter:description": "Agent Skills for NVIDIA products — install into Claude Code, Codex, and other coding agents to run Physical AI, robotics, simulation, CUDA, and RAG workflows end to end."
  "twitter:title": "nvidia/skills skills"
---

`

[All skills](https://skilld.dev/skills)

[![nvidia avatar](https://skilld.dev/_img/avatar?url=https%3A%2F%2Fgithub.com%2Fnvidia.png)](https://skilld.dev/gh/nvidia)

# **NVIDIA/skills**

Agent Skills for NVIDIA products — install into Claude Code, Codex, and other coding agents to run Physical AI, robotics, simulation, CUDA, and RAG workflows end to end.

main Updated 5 hours ago [GitHub](https://github.com/NVIDIA/skills)

![README badge for nvidia/skills](https://skilld.dev/b/nvidia/skills?theme=light&label=0)

## Repository statistics

- Indexed skills

  **175**
- Skill groups

  **1**
- GitHub stars

  **3,498**
- Forks

  **427**

## Skills

175 total

Sort skills

[<h3>**/i4h-lerobot-viz**</h3>Serve and visually inspect a converted LeRobot dataset in the browser. Use for videos and state/action timelines; do not use for raw workflow HDF5 or incomplete conversion output. /i4h-lerobot-viz](https://skilld.dev/gh/nvidia/skills/i4h-lerobot-viz)

Updated yesterday

[<h3>**/i4h-workflow**</h3>Orient users to the i4h workflow runtime and route them to the correct stage skill. Use for architecture, support, or where-to-start questions; do not execute a known stage. /i4h-workflow](https://skilld.dev/gh/nvidia/skills/i4h-workflow)

Updated yesterday

[<h3>**/i4h-workflow-create**</h3>Create a minimal blank Workflow scaffold with a Scene containing ground and light plus an idle run mode. Use for fast new Workflow scaffolding. /i4h-workflow-create](https://skilld.dev/gh/nvidia/skills/i4h-workflow-create)

Updated yesterday

[<h3>**/i4h-workflow-dataset-annotate**</h3>Grade or filter workflow HDF5 episodes with an OpenAI-compatible vision model. Use for visual success labels; do not use for replay, policy evaluation, or recordings without frames. /i4h-workflow-dataset-annotate](https://skilld.dev/gh/nvidia/skills/i4h-workflow-dataset-annotate)

Updated yesterday

[<h3>**/i4h-workflow-dataset-convert**</h3>Convert workflow HDF5 recordings to LeRobot datasets for training or browser inspection. Use for conversion; do not use for replay, augmentation, or raw-data repair. /i4h-workflow-dataset-convert](https://skilld.dev/gh/nvidia/skills/i4h-workflow-dataset-convert)

Updated yesterday

[<h3>**/i4h-workflow-dataset-mimic**</h3>Expand workflow HDF5 demonstrations with action jitter, optionally scoped to node segments. Use for synthetic variants; do not use to collect data, alter state directly, or generate new images. /i4h-workflow-dataset-mimic](https://skilld.dev/gh/nvidia/skills/i4h-workflow-dataset-mimic)

Updated yesterday

[<h3>**/i4h-workflow-dataset-replay**</h3>Replay a workflow HDF5 episode through its original Scene. Use for visual trajectory and recording verification; do not use for policy evaluation or LeRobot data. /i4h-workflow-dataset-replay](https://skilld.dev/gh/nvidia/skills/i4h-workflow-dataset-replay)

Updated yesterday

[<h3>**/i4h-workflow-dataset-teleop**</h3>Record demonstrations through a workflow's teleop Task into workflow HDF5. Use for keyboard, leader, VR, or bus input; do not use for policy evaluation or autonomous rule-based Tasks. /i4h-workflow-dataset-teleop](https://skilld.dev/gh/nvidia/skills/i4h-workflow-dataset-teleop)

Updated yesterday

[<h3>**/i4h-workflow-e2e**</h3>Run the maintained workflow data-to-policy pipeline from recording through checkpoint validation. Use for full end-to-end requests; do not use for one individual stage. /i4h-workflow-e2e](https://skilld.dev/gh/nvidia/skills/i4h-workflow-e2e)

Updated yesterday

[<h3>**/i4h-workflow-finetune**</h3>Fine-tune a manifest-backed GR00T or openpi remote Task on compatible LeRobot data. Use for training; do not use for inference-only Tasks or checkpoint rollout. /i4h-workflow-finetune](https://skilld.dev/gh/nvidia/skills/i4h-workflow-finetune)

Updated yesterday

[<h3>**/i4h-workflow-setup**</h3>Preflight and set up the root-level workflow runtime. Use for installation, missing component environments, or third-party failures; do not use for rollout validation. /i4h-workflow-setup](https://skilld.dev/gh/nvidia/skills/i4h-workflow-setup)

Updated yesterday

[<h3>**/jetson-video-benchmark**</h3>Use when measuring Jetson Video Codec SDK or PyNvVideoCodec encode/decode throughput, comparing presets or surfaces, testing codec-worker capacity with authenticated samples and user media, or producing a clearly labeled documentation-derived planning estimate when representative media is absent. Also use for a video request limited to PSNR or SSIM, to apply the terminal scope response. /jetson-video-benchmark](https://skilld.dev/gh/nvidia/skills/jetson-video-benchmark)

Updated last week

[<h3>**/jetson-video-capability**</h3>Use when Jetson codec, profile, chroma, bit-depth, dimension, engine-count, or operational support must be reconciled from live APIs, authenticated NVIDIA samples, and NVIDIA documentation; also applies the content-DRM scope. /jetson-video-capability](https://skilld.dev/gh/nvidia/skills/jetson-video-capability)

Updated last week

[<h3>**/jetson-video-pipeline**</h3>Use when planning, executing, and independently validating Jetson Video Codec SDK or PyNvVideoCodec encode/decode, transcode, segmentation, container decode, AV1, or concise acceptance workflows. /jetson-video-pipeline](https://skilld.dev/gh/nvidia/skills/jetson-video-pipeline)

Updated last week

[<h3>**/jetson-video-recipe**</h3>Use when turning a Jetson encoder use case into one surface-neutral recipe with native Video Codec SDK and PyNvVideoCodec projections. /jetson-video-recipe](https://skilld.dev/gh/nvidia/skills/jetson-video-recipe)

Updated last week

[<h3>**/jetson-video-setup**</h3>Use when installing, repairing, reusing, inspecting, or verifying readiness of the native NVIDIA Video Codec SDK or PyNvVideoCodec on Jetson, including the one-frame encode/decode smoke test with official samples, and when interpreting what those readiness results, including CPU-buffer and device-memory sample modes, do and do not establish. /jetson-video-setup](https://skilld.dev/gh/nvidia/skills/jetson-video-setup)

Updated last week

[<h3>**/accelerated-computing-cudf**</h3>Official NVIDIA-authored guidance for NVIDIA cuDF GPU DataFrames, pandas acceleration, dask-cuDF, ETL, joins, groupby, CSV/Parquet I/O, nullable semantics, and multi-GPU DataFrame workloads. /accelerated-computing-cudf](https://skilld.dev/gh/nvidia/skills/accelerated-computing-cudf)

Updated 2 weeks ago

[<h3>**/cuopt-server-api-python**</h3>cuOpt REST server — start server, endpoints, Python/curl client examples. Use when the user is deploying or calling the REST API. /cuopt-server-api-python](https://skilld.dev/gh/nvidia/skills/cuopt-server-api-python)

Updated 2 weeks ago

[<h3>**/dicom-metadata-extract**</h3>Used for extracting selected metadata from one DICOM file and flagging standard-tag PHI presence. Not for anonymization or clinical use. /dicom-metadata-extract](https://skilld.dev/gh/nvidia/skills/dicom-metadata-extract)

Updated 2 weeks ago

[<h3>**/dicom-series-preflight**</h3>Used for header-only preflight of one DICOM series folder before conversion or inference. Not for de-identification or clinical clearance. /dicom-series-preflight](https://skilld.dev/gh/nvidia/skills/dicom-series-preflight)

Updated 2 weeks ago

[<h3>**/dicom-series-to-volume**</h3>Used for converting one CT DICOM series folder to a HU NIfTI volume with affine evidence. Not for multi-frame DICOM or clinical use. /dicom-series-to-volume](https://skilld.dev/gh/nvidia/skills/dicom-series-to-volume)

Updated 2 weeks ago

[<h3>**/cudaq-guide**</h3>Use for CUDA-Q setup, simulation targets, QPU access, and @cudaq.kernel authoring guidance. /cudaq-guide](https://skilld.dev/gh/nvidia/skills/cudaq-guide)

Updated 3 weeks ago

[<h3>**/nemo-automodel-model-onboarding**</h3>Guide for onboarding new model architectures into NeMo AutoModel, including architecture discovery, implementation patterns, registration, and validation. /nemo-automodel-model-onboarding](https://skilld.dev/gh/nvidia/skills/nemo-automodel-model-onboarding)

Updated 3 weeks ago

[<h3>**/i4h-workflow-scene-edit**</h3>Edit an existing workflow Scene or task contract. Use for assets, layout, cameras, randomization, task text, or success rules; do not use to create a new workflow. /i4h-workflow-scene-edit](https://skilld.dev/gh/nvidia/skills/i4h-workflow-scene-edit)

Updated 4 weeks ago

[<h3>**/i4h-workflow-validate**</h3>Run the root-level workflow runtime policy or rule-based rollouts and verify simulator success. Use for evaluation, checkpoints, or local controllers; do not use for replay or dataset annotation. /i4h-workflow-validate](https://skilld.dev/gh/nvidia/skills/i4h-workflow-validate)

Updated 4 weeks ago

[<h3>**/amc-run-rtsp-calibration**</h3>Calibrate a new dataset from live RTSP camera streams via the AutoMagicCalib REST API. Use when the user provides RTSP URLs or asks to calibrate live cameras; VIOS records clips, AMC ingests them, then runs calibration. /amc-run-rtsp-calibration](https://skilld.dev/gh/nvidia/skills/amc-run-rtsp-calibration)

Updated last month

[<h3>**/amc-run-sample-calibration**</h3>Run end-to-end calibration on the shipped sample dataset (sdg\_08\_2\_sample\_data\_010926.zip) against a running AMC microservice. Use when user says 'test sample dataset', 'run sample calibration', 'verify AMC install', or 'launch and test'. /amc-run-sample-calibration](https://skilld.dev/gh/nvidia/skills/amc-run-sample-calibration)

Updated last month

[<h3>**/amc-run-video-calibration**</h3>Calibrates pre-recorded \`cam\_\*.mp4\` datasets through the AutoMagicCalib REST API. Use for user-supplied local MP4s; route live RTSP streams to \`amc-run-rtsp-calibration\`. /amc-run-video-calibration](https://skilld.dev/gh/nvidia/skills/amc-run-video-calibration)

Updated last month

[<h3>**/deepstream-dev**</h3>NVIDIA DeepStream SDK development with Python pyservicemaker API. Use when building video analytics pipelines, GStreamer-based video processing, TensorRT inference integration, object detection/tracking, or Kafka/message broker integration. /deepstream-dev](https://skilld.dev/gh/nvidia/skills/deepstream-dev)

Updated last month

[<h3>**/deepstream-import-vision-model**</h3>Use this skill to bring a supported object-detection vision model from HuggingFace or NVIDIA NGC into an NVIDIA DeepStream pipeline with end-to-end automation: ONNX download, SafeTensors export, TRT engine build, custom nvinfer bbox parser, multi-stream benchmark, and PDF report. Object detection models only. /deepstream-import-vision-model](https://skilld.dev/gh/nvidia/skills/deepstream-import-vision-model)

Updated last month

[<h3>**/cuopt-install**</h3>Install cuOpt for Python, C, or server via pip, conda, or Docker; verify the install. For building cuOpt from source, see cuopt-developer. /cuopt-install](https://skilld.dev/gh/nvidia/skills/cuopt-install)

Updated last month

[<h3>**/cuopt-routing-api-python**</h3>Vehicle routing (VRP, TSP, PDP) with cuOpt — Python API only. Use when the user is building or solving routing in Python. /cuopt-routing-api-python](https://skilld.dev/gh/nvidia/skills/cuopt-routing-api-python)

Updated 2 months ago

[<h3>**/deepstream-run-mv3dt**</h3>Run and operate the DeepStream Multi-View 3D Tracking reference app, also known as MV3DT. Use when the user asks to set up prerequisites, run shipped MV3DT samples, run Multi-View 3D Tracking on custom synchronized MP4 datasets, import camera calibration, delegate missing calibration to AutoMagicCalib, inspect OSD or BEV visualization, consume MV3DT Kafka metadata, or clean up MV3DT run state in the DeepStream MV3DT app directory. /deepstream-run-mv3dt](https://skilld.dev/gh/nvidia/skills/deepstream-run-mv3dt)

Updated 2 months ago

[<h3>**/cuopt-numerical-optimization-api**</h3>LP, MILP, and QP (beta) with cuOpt — Python, C, and CLI. Use when the user is solving LP, MILP, or QP with any cuOpt interface. /cuopt-numerical-optimization-api](https://skilld.dev/gh/nvidia/skills/cuopt-numerical-optimization-api)

Updated 2 months ago

[<h3>**/cuopt-numerical-optimization-formulation**</h3>LP, MILP, QP — concepts, problem-text parsing, and formulation patterns (parameters, constraints, decisions, objective). Concepts only; no API. /cuopt-numerical-optimization-formulation](https://skilld.dev/gh/nvidia/skills/cuopt-numerical-optimization-formulation)

Updated 2 months ago

[<h3>**/cuopt-multi-objective-exploration**</h3>Trace, complete, and interpret the Pareto frontier across competing objectives using repeated single-objective cuOpt solves (weighted-sum and ε-constraint). /cuopt-multi-objective-exploration](https://skilld.dev/gh/nvidia/skills/cuopt-multi-objective-exploration)

Updated 2 months ago

[<h3>**/holohub-app-lifecycle**</h3>Use for non-failing HoloHub app work with ./holohub: scaffold, build, run, test, visual evidence, lint, and flow benchmarking. /holohub-app-lifecycle](https://skilld.dev/gh/nvidia/skills/holohub-app-lifecycle)

Updated 2 months ago

[<h3>**/holohub-debug-build-run**</h3>Use when a concrete ./holohub command fails, hangs, regresses, or returns wrong output and needs reproducible diagnosis and verification. /holohub-debug-build-run](https://skilld.dev/gh/nvidia/skills/holohub-debug-build-run)

Updated 2 months ago

[<h3>**/holohub-module-lifecycle**</h3>Use for reusable Holoscan Module work with ./holohub: scaffold, tests, editable install, DEB/WHEEL packaging, and clean-consumer proof. /holohub-module-lifecycle](https://skilld.dev/gh/nvidia/skills/holohub-module-lifecycle)

Updated 2 months ago

[<h3>**/doca-telemetry-exporter**</h3>Use this skill when the user is doing hands-on DOCA Telemetry Exporter programming on a host where DOCA is installed — defining a doca\_telemetry\_exporter\_schema and event types, creating sources, picking a publish surface (typed events / opaque events / the metrics counter-gauge-histogram API / OTLP logs / NetFlow), walking the schema-then-source lifecycle, or debugging DOCA\_ERROR\_\* failures from the exporter API. Trigger even when the user does not explicitly mention "DOCA Telemetry Exporter" or "doca\_telemetry\_exporter\_\*" — typical implicit phrasings include "publishing counters from my DOCA app", "BAD\_STATE when I report an event", "consumer/DTS sees nothing but my report succeeded", "how do I export NetFlow/IPFIX records", or "should I link the exporter or the telemetry service". Refuse and route elsewhere for the receiving DOCA Telemetry Service (DTS), plain stdout logging via doca\_log, or real-time event subscription back into the app via doca-comch — those belong to other skills. /doca-telemetry-exporter](https://skilld.dev/gh/nvidia/skills/doca-telemetry-exporter)

Updated 2 months ago

[<h3>**/hsb-ip-create-top**</h3>Create or explain fixed-format HSB FPGA\_top.sv wrappers from validated HOLOLINK\_def.svh files. Do not use for def generation or validation. /hsb-ip-create-top](https://skilld.dev/gh/nvidia/skills/hsb-ip-create-top)

Updated 2 months ago

[<h3>**/hsb-ip-def**</h3>Generate, validate, compare, or explain HSB HOLOLINK\_def.svh macros. Do not use for FPGA\_top.sv wrappers or packetizer-only derivation. Generation runs bundled Python scripts locally through shell commands and writes validated .svh output files after user-confirmed paths. /hsb-ip-def](https://skilld.dev/gh/nvidia/skills/hsb-ip-def)

Updated 2 months ago

[<h3>**/hsb-ip-packetizer**</h3>Choose or explain HSB Sensor RX packetizer fields for HOLOLINK\_def.svh. Do not use for full defs, validation, or runtime APB programming. /hsb-ip-packetizer](https://skilld.dev/gh/nvidia/skills/hsb-ip-packetizer)

Updated 2 months ago

[<h3>**/nemo-automodel-distributed-training**</h3>Guide for selecting and configuring distributed training strategies in NeMo AutoModel, including FSDP2, Megatron FSDP, DDP, and parallelism settings. /nemo-automodel-distributed-training](https://skilld.dev/gh/nvidia/skills/nemo-automodel-distributed-training)

Updated 2 months ago

[<h3>**/doca-argp**</h3>Use this skill for hands-on DOCA Arg Parser CLI work on a shipped sample or new DOCA-using app — adding / removing / renaming flags; wiring \`doca\_argp\_init\` → register params → \`doca\_argp\_start\` → \`doca\_argp\_destroy\` in order; picking a parameter type from the full public enum (\`DOCA\_ARGP\_TYPE\_STRING\`, \`\_INT\`, \`\_BOOLEAN\`, \`\_DEVICE\`, \`\_DEVICE\_REP\`, \`\_DOUBLE\` — six values, not three); preserving the standard \`--device\` / \`--representor\` / \`--json\` (\`-j\`; real flag is \`--json\`, NOT \`--json-config\`) / \`--sdk-log-level\` surface; or debugging \`DOCA\_ERROR\_BAD\_STATE\` / \`INVALID\_VALUE\` / \`NOT\_SUPPORTED\` / \`IO\_FAILED\` from \`doca\_argp\_\*\`. Trigger on implicit phrasings: "add a custom flag to a DOCA sample", "should I use getopt here", "BAD\_STATE registering a new param", "my JSON config key is rejected", or "my sample's --json is ignored". Refuse and route elsewhere for variadic-flag / subcommand / shell-completion features, DOCA Core context, or DOCA Log internals. /doca-argp](https://skilld.dev/gh/nvidia/skills/doca-argp)

Updated 2 months ago

[<h3>**/doca-bare-metal-deployment**</h3>Use this skill for launching, supervising, debugging, OR platform lifecycle on a BlueField — BFB install, RShim/TMFIFO, host PF rebind, post-BFB recovery — taking a DOCA-linked binary to a healthy run directly on hardware (host x86 + BlueField NIC over PCIe, or BlueField Arm bare-metal). No container, no kubelet. Covers launch mode (direct, tmux, systemd), PCI/NUMA/ CPU/IRQ binding, co-tenant isolation (cgroup-v2/netns/numactl), a seven-layer error taxonomy, and a six-state BlueField lifecycle classifier. Trigger even when user does not say "bare-metal" — implicit phrasings include "binary exits 1 right after launch", "systemd keeps restarting it", "no matching device on the BF", "bfb-install exited 0 but DPU is dead", "ping 192.168.100.2 works but ssh fails", "host PFs aren't showing netdevs". Destructive firmware burn / mlxconfig set requires explicit confirmation via doca-hardware-safety; containers, library APIs, env prep, and build use other skills. /doca-bare-metal-deployment](https://skilld.dev/gh/nvidia/skills/doca-bare-metal-deployment)

Updated 2 months ago

[<h3>**/doca-bench**</h3>Run \`doca\_bench\` (DOCA 2.7.0 or newer) to measure throughput, bulk latency, precision latency, or maximum bandwidth for RDMA, Compress, AES-GCM, SHA, DMA, EC, Ethernet, Comch, or GPUNetIO on a host or BlueField Arm. Use it to discover enabled benchmark libraries, capture a reproducible command/version/device/environment baseline, compare stable runs against a declared tolerance, or diagnose configuration, device-binding, workload-precondition, and measurement failures. Trigger for requests such as measuring BlueField compression speed, NIC RDMA throughput, crypto latency, or a pre-upgrade baseline. Do not use for application end-to-end timing, custom benchmark code, DOCA installation, or binary patches. /doca-bench](https://skilld.dev/gh/nvidia/skills/doca-bench)

Updated 2 months ago

[<h3>**/doca-bf3-deployment**</h3>Use this skill for BlueField-3 (BF3) day-1 platform bring-up via the classic RShim/BFB path: pushing a BlueField bundle (BFB) to the DPU over RShim with bfb-install from the host, the host-to-DPU TMFIFO management channel (tmfifo\_net0, the 192.168.100.x convention), RShim daemon state and console-over-rshim, DPU mode selection (DPU/embedded-function vs separated-host/NIC mode) via mlxconfig, post-BFB recovery, a six-state BlueField-state classifier, and verifying the install (cat /etc/mlnx-release plus version checks). Trigger even when the user does not say "BF3" — typical phrasings include {push a BFB to my BlueField-3}, {bfb-install exited 0 but the DPU never came back}, {ping 192.168.100.2 works but ssh fails}, or {is DOCA on the host or the Arm side?}. BFB reflash, mlxconfig set, mode changes, and firmware burns are destructive: require explicit target-bound confirmation and load doca-hardware-safety. App launch, container deploy, env install, and the BF4 BMC-Redfish path route elsewhere. /doca-bf3-deployment](https://skilld.dev/gh/nvidia/skills/doca-bf3-deployment)

Updated 2 months ago

[<h3>**/doca-comm-channel-admin**</h3>Use this skill to enumerate host↔DPU DOCA comch (formerly Comm Channel) servers and connections via the shipped doca\_comm\_channel\_admin binary — listing comch-capable devices and decoding the per-device server / connection table (server name, PID, in-use / max, PCIe address). The shipped binary is a SINGLE-SHOT SCAN-AND-PRINT tool with no registered arguments — NO list / inspect / drain / restart subcommands; one inventory pass over every comch-capable doca\_dev on this side. Channel reset / drain / restart go to doca-comch (program side), doca-setup / doca-hardware-safety (driver reload), or BFB / RShim — NOT to this binary. Trigger on phrasings like "list comch servers", "which channels are active on this BlueField", or "verify admin tool sees same channel as program." Refuse and route elsewhere for the comch programming API, library install, protocol design, channel reset, or general orientation. /doca-comm-channel-admin](https://skilld.dev/gh/nvidia/skills/doca-comm-channel-admin)

Updated 2 months ago

[<h3>**/doca-compress**</h3>Use this skill for hands-on DOCA Compress programming on a BlueField DPU, ConnectX NIC, or host with DOCA — enabling compress-deflate, decompress-deflate, decompress-lz4-stream, or decompress-lz4-block tasks on a doca\_compress context (the hardware supports DEFLATE both directions plus LZ4 decompress; LZ4 encode is NOT supported), sizing source / destination doca\_buf against the per-task cap query, setting mmap permissions, deciding offload vs CPU zlib / zstd, validating with a round-trip smoke, or debugging DOCA\_ERROR\_\* from a Compress call. Trigger on phrasings like "offload this gzip", "decompress incoming network data", "compress task returns INVALID\_VALUE on alloc\_init", "submitted a task but no completion arrives", or "decompress LZ4 on the BlueField." Refuse and route elsewhere for non-DEFLATE / non-LZ4 algorithms (zstd / Snappy / brotli), LZ4 encode (route to a CPU LZ4 library), pure mmap-to-mmap copies (doca-dma), or DOCA Core lifecycle internals. /doca-compress](https://skilld.dev/gh/nvidia/skills/doca-compress)

Updated 2 months ago

[<h3>**/doca-container-deployment**</h3>Use this skill when the user is hands-on deploying an in-bundle DOCA service container (Argus, DMS, Firefly, or UROM service) on a BlueField — kubelet standalone watching a static-pod manifests directory, YAML pod-spec drop, kubelet status / ENTRYPOINT logs / per-service liveness, smoke-before-bulk, and the layered error taxonomy (pod-spec, scheduling, image pull, runtime, mount, network, version, host). Trigger even when the user does not say "container deployment" — typical implicit phrasings include "how do I run my built service on the BlueField?", "where do I drop the pod-spec YAML?", "pod stuck in Pending / ImagePullBackOff / CrashLoopBackOff", "container Running but service isn't ready", "pod restart-loops after edit", or "DMS and Firefly together". Refuse and route elsewhere for per-service config schemas, DOCA install, library-API questions, external NVIDIA services (BlueMan, HBN, SNAP, Virtio-net), or full Kubernetes-cluster ops — those belong to other skills. /doca-container-deployment](https://skilld.dev/gh/nvidia/skills/doca-container-deployment)

Updated 2 months ago

[<h3>**/doca-devemu**</h3>Use this skill when the user is doing hands-on DOCA Device Emulation on a BlueField DPU — exposing a custom emulated PCIe device the host sees as a real peripheral while DPU-side code runs the backend, picking the sub-library (PCI Generic, virtio-net, virtio-fs), wiring the per-sub-library Core context plus doorbell / DMA primitives, querying \`doca\_devemu\_\*\_cap\_\*\`, or debugging DOCA\_ERROR\_\* from a \`doca\_devemu\_\*\` call. Trigger even when the user does not say "devemu" — typical implicit phrasings include "expose a custom PCIe device from BlueField to the host", "host should see a virtio NIC backed by my DPU code", "lspci does not show my emulated device", "device enumerated but no driver binds", "DPU sees nothing when host kicks the queue", or "virtio feature negotiation failed at bind". Refuse and route elsewhere for the packaged DOCA SNAP / Virtio-net Services, host-side virtio kernel drivers, backend body design, or standard BlueField NIC behavior — those belong to other skills. /doca-devemu](https://skilld.dev/gh/nvidia/skills/doca-devemu)

Updated 2 months ago

[<h3>**/doca-dms**</h3>Operate NVIDIA DOCA Management Service (\`dmsd\` + \`dmspe\`) on a BlueField, Arm/x86 host, or Kubernetes pod: choose deployment and authentication, configure \`-allowed\_users\` and \`dmsgroup\`, use gNMI Get/Set/Subscribe, run supported gNOI workflows, and debug frontend/backend failures. Trigger even without "DMS" for "manage a remote BlueField over gRPC", "gNOI reboot from orchestrator", or fleet-management requests. SAFETY: reboot, OS install, factory-reset, and managed-file deletion are destructive and require target-bound explicit confirmation; never invoke them speculatively. Route installation and library/API build questions elsewhere, and route turnkey aggregation to the externally-productized DOCA Telemetry Service. /doca-dms](https://skilld.dev/gh/nvidia/skills/doca-dms)

Updated 2 months ago

[<h3>**/doca-firefly**</h3>Use this skill when the user is operating the DOCA Firefly Service container on BlueField — picking the four PTP configuration axes (role / profile / domain / interface), wiring the BlueField PHC + host follower + consumer workload pairing, deciding whether PTP-grade time is even needed (vs. chrony / NTP), or debugging a Firefly deployment where PTP isn't syncing or the host clock isn't following. Trigger even when the user does not explicitly mention "DOCA Firefly" or "PTP" — typical implicit phrasings include "container green but PTP never advances past LISTENING", "Firefly says synced but the host clock still drifts", "sync acquired but offset is tens of microseconds", "my Rivermax SMPTE workload needs PTP", or "is chrony good enough". Refuse and route elsewhere for installing DOCA, host-side chrony / ptp4l config bodies, PTP topology / boundary-clock design, building DOCA apps that read the disciplined PHC, or other DOCA services (DMS, Flow-Inspector, HBN) — those belong to other skills. /doca-firefly](https://skilld.dev/gh/nvidia/skills/doca-firefly)

Updated 2 months ago

[<h3>**/doca-flow**</h3>Build and debug DOCA Flow applications on supported NVIDIA NICs/DPUs: define match/action pipes, initialize ports and representors, choose forwarding targets, validate pipes before hardware programming, read counters, match the Flow version to the installed DOCA release, and diagnose Flow API errors. Trigger on DOCA packet steering, classifier, representor, rule-matching, hairpin, or 5-tuple-to-queue questions even when "DOCA Flow" is not named. Route plain DPDK \`rte\_flow\`, kernel TC, OVS, BFB bring-up, and DPU OS installation elsewhere. DPU OS installation is destructive and always requires explicit confirmation. /doca-flow](https://skilld.dev/gh/nvidia/skills/doca-flow)

Updated 2 months ago

[<h3>**/doca-flow-dpa-perf**</h3>Use this skill when the user is invoking doca\_flow\_dpa\_perf on DPA-capable hardware (ConnectX-7 minimum supported, ConnectX-8 recommended, or BlueField-3) to measure rule update / disable rates on the DPA-offloaded DOCA Flow path — picking the active / passive device split, choosing workload-shape axes (burst, queue, completion threshold, workers, hash pipe algo, PSL tables), or reading Kops/sec iteration stats and the optional self-test. Trigger even when the user does not explicitly mention "doca\_flow\_dpa\_perf" or "DPA Provider" — typical implicit phrasings include "how fast can the DPA program path-selector entries", "baseline rule-update rate on ConnectX-8", "tool reports zero ops on my BlueField", "self-test sentinel never shows on tcpdump", or "is my BlueField-2 DPA-capable". Refuse and route elsewhere for the host / DPU-CPU Flow path (doca-flow-perf), Flow pipeline tuning (doca-flow-tune), writing doca-flow / doca-dpa applications, or DOCA install — those belong to other skills. /doca-flow-dpa-perf](https://skilld.dev/gh/nvidia/skills/doca-flow-dpa-perf)

Updated 2 months ago

[<h3>**/doca-flow-grpc-server**</h3>PLAINTEXT-ONLY: the shipped \`doca\_flow\_grpc\` server uses \`grpc::InsecureServerCredentials()\` with NO TLS / mTLS / token-auth knob on the binary — transport security must come from external infrastructure (e.g. an mTLS proxy / sidecar) on a trusted segment. Use this skill when bringing up, configuring, hardening, or debugging \`doca\_flow\_grpc\` — the DOCA-shipped gRPC remote-control surface in front of \`doca-flow\` that lets non-C++ clients (Python, Go, Rust, Java) program Flow pipes and entries over RPC instead of linking \`libdoca\_flow.so\` directly. Trigger even when the user doesn't say 'doca-flow-grpc-server' or 'gRPC' — e.g. 'program Flow rules from Python on another host', 'remotely configure pipes on the BlueField', 'client times out connecting to the Flow server', 'where is the .proto for Flow', 'UNAUTHENTICATED / FAILED\_PRECONDITION on a Flow RPC'. Route elsewhere for the underlying doca-flow API, generic gRPC tooling (protoc, language bindings), or DOCA install / BFB bring-up. /doca-flow-grpc-server](https://skilld.dev/gh/nvidia/skills/doca-flow-grpc-server)

Updated 2 months ago

[<h3>**/doca-gpi**</h3>Use this skill for hands-on DOCA GPI programming — wiring a GPU-Packet-Initiator context so a CUDA kernel drives RDMA queues directly from GPU memory without host CPU mediation. Covers picking GPI vs doca-gpunetio, the doca\_gpi / domain / channel object model, the GPU-side handle handoff (doca\_gpu\_gpi\_channel\*), attaching GPU memory to a GPI domain, the domain and channel attribute objects, and debugging DOCA\_ERROR\_\* from doca\_gpi\_\* calls. Trigger even when the user does not explicitly mention "DOCA GPI" — implicit phrasings include "my CUDA kernel needs to post RDMA directly from GPU memory", "DOCA\_ERROR\_\* from doca\_gpi\_gpu\_channel\_get", "how do I hand a GPU handle to my CUDA kernel", "how many channels can a GPI domain hold", or "GPU kernel driving RDMA without the host CPU on the path". Refuse and route elsewhere for the doca-gpunetio Send/Receive surface, the doca-rdma queue lifecycle, DPA-side initiation (doca-rdmi), or the CUDA programming model — those belong to other skills. /doca-gpi](https://skilld.dev/gh/nvidia/skills/doca-gpi)

Updated 2 months ago

[<h3>**/doca-gpunetio**</h3>Use this skill when the user is doing hands-on DOCA GPUNetIO programming — wiring a CUDA kernel on an NVIDIA GPU to a doca-eth queue via doca\_gpu\_eth\_rxq / doca\_gpu\_eth\_txq, standing up the per-CUDA-device doca\_gpu context, designing the persistent CUDA kernel that drains the GPU-visible queue, running the dual capability check (DOCA cap-query plus cudaGetDeviceProperties), registering cudaMalloc pools via doca\_buf\_arr\_create\_\*, or debugging DOCA\_ERROR\_\* returns from the GPUNetIO API. Trigger even when the user does not explicitly mention "DOCA GPUNetIO" or "persistent kernel" — typical implicit phrasings include "CUDA kernel reading packets directly from the NIC", "GPU-initiated networking on BlueField", "DOCA\_ERROR\_DRIVER on doca\_gpu\_create", "nvidia\_peermem not loaded", "kernel-per-packet is too slow", or "which GPU supports GPU-side packet I/O". Refuse and route elsewhere for general CUDA programming, DOCA Ethernet queue bring-up, DOCA DPA, or DOCA install — those belong to other skills. /doca-gpunetio](https://skilld.dev/gh/nvidia/skills/doca-gpunetio)

Updated 2 months ago

[<h3>**/doca-gpunetio-ib-write-bw**</h3>Use this skill when the user is building, running, or interpreting the doca/tools/gpunetio\_ib\_write\_bw client+server benchmark — a CUDA kernel on the client posts RDMA WRITE work requests through the doca-gpunetio device-side surface to measure sustained GPU-driven WRITE bandwidth on a GPU+IB-device pair. Trigger even when the user does not explicitly mention "doca-gpunetio-ib-write-bw" or "GPUNetIO" — typical implicit phrasings include "measure WRITE BW when the GPU posts the WRs", "BW swings between runs on the same flags", "is the NIC saturated or am I CPU-bound on the CUDA kernel", "meson compile fails for the GPUNetIO bw tool", "nvidia\_peermem isn't picking up my GPU buffer", or "GPU-initiated WRITE throughput vs CPU-initiated perftest". Refuse and route elsewhere for general doca-gpunetio library work, DOCA install, the GPU-initiated WRITE latency analog, the CPU-initiated upstream perftest, or application-level end-to-end throughput — those belong to other skills. /doca-gpunetio-ib-write-bw](https://skilld.dev/gh/nvidia/skills/doca-gpunetio-ib-write-bw)

Updated 2 months ago

[<h3>**/doca-gpunetio-ib-write-lat**</h3>Use this skill when the user is measuring GPU-kernel-initiated RDMA WRITE latency through doca-gpunetio — building and running the \`gpunetio\_ib\_write\_lat\` client + server pair under \`doca/tools/gpunetio\_ib\_write\_lat/\`, checking GPU-NIC pairing, reading the half-iter / full-iter / CUDA-side usec columns, characterizing median / p99 / jitter for a real-time control loop, picking GPUNetIO vs GPI vs CPU-initiated \`perftest\`, or weighing the latency-vs-batching trade-off. Trigger even without 'GPUNetIO' or 'ib\_write\_lat': 'GPU kernel RDMA latency benchmark', 'how fast can a CUDA kernel post a WRITE', 'p99 RDMA latency on H100 + ConnectX', 'kernel-launched WR tail latency', or 'compare GPU-init vs CPU-init perftest'. Route elsewhere for bandwidth runs (doca-gpunetio-ib-write-bw), the GPI surface (doca-gpi), library debugging (doca-gpunetio), or DOCA install. /doca-gpunetio-ib-write-lat](https://skilld.dev/gh/nvidia/skills/doca-gpunetio-ib-write-lat)

Updated 2 months ago

[<h3>**/doca-hardware-safety**</h3>Use this skill whenever the agent is about to recommend or apply a change that touches DPU / NIC hardware state on a live system — mlxconfig firmware-parameter write, NIC firmware burn, BFB reflash, NIC ↔ DPU mode flip, SR-IOV or device-emulation slot enable, kernel boot-parameter change (IOMMU, hugepages, VFIO), PCIe rebind / rescan / link-state flip, or BlueField cold reboot. Wraps the change in pre-flight inventory, OOB reachability, a maintenance window, the mlxconfig cold-power-cycle rule, replica rehearsal, and rollback. Trigger even when the user does not say "hardware safety" — implicit phrasings: "flip BlueField mode over SSH", "enable SR-IOV and reboot", "burned firmware but mlxconfig shows old value", "reflashed BFB and lost representors", "reflash during business hours", "vendor says this is one-way". Refuse for general DOCA orientation (doca-public-knowledge-map), install or env debug (doca-setup), and program-side debug (doca-debug, doca-programming-guide) — those belong to other skills. /doca-hardware-safety](https://skilld.dev/gh/nvidia/skills/doca-hardware-safety)

Updated 2 months ago

[<h3>**/doca-pcc-counters**</h3>Use this skill when the user is invoking the DOCA PCC Counters tool — the \`pcc\_counters.sh\` bash script under the DOCA tools directory — to arm and read the fixed firmware/hardware PCC (Programmable Congestion Control) diagnostic counters (CNP, RTT, WRED-drop, etc.) on a ConnectX / BlueField device via mst + the mlx5 debugfs \`diag\_cnt\` interface. The script takes two positional args — \`set | query\` and an mst device path — with no \`--help\` or subcommands. Trigger even without "pcc\_counters.sh" or "PCC counters": "how do I read the CNP / RTT / WRED-drop counters", "PCC counter stuck at zero", "the script says Bad Device", or "is congestion control dropping packets on this port?". Route elsewhere for writing a custom PCC algorithm (doca-pcc), factory firmware PCC config, DOCA install, or fleet-wide CC tuning. /doca-pcc-counters](https://skilld.dev/gh/nvidia/skills/doca-pcc-counters)

Updated 2 months ago

[<h3>**/doca-public-knowledge-map**</h3>Use this skill when the user needs to locate authoritative information about NVIDIA DOCA without access to the source tree — finding the right docs.nvidia.com page for a library/service/tool, identifying which DOCA libraries are installed and at what version, locating a sample on disk or its public GitHub source, decoding an on-disk path under /opt/mellanox/doca, or recovering from a 404'd or renamed doc URL. Trigger even when the user does not explicitly mention 'DOCA' or 'docs.nvidia.com' — typical implicit phrasings include 'where can I read about this library', 'which version do I have installed', 'where is the sample for X', 'this NVIDIA URL is broken what is the new one', 'what is in /opt/mellanox/doca', or 'where can I ask NVIDIA about this'. Refuse and route elsewhere for hands-on programming patterns, env prep and install verification, library API tutorials, or hardware/firmware mutation — those belong to doca-programming-guide, doca-setup, the per-library skills, and doca-hardware-safety. /doca-public-knowledge-map](https://skilld.dev/gh/nvidia/skills/doca-public-knowledge-map)

Updated 2 months ago

[<h3>**/doca-rdma**</h3>Use this skill when the user is doing hands-on DOCA RDMA programming on a BlueField DPU, ConnectX NIC, or DOCA host — bringing up an RDMA context on a doca\_dev, picking a connection method (RDMA CM, bridge/OOB, or gRPC exchange of doca\_rdma\_export()), enabling one of the eleven task types (Send/Receive/Send-Imm, Read/Write/Write-Imm, Atomic CmpSwap/FetchAdd, Get/Set/Add Remote Sync Event), setting matching mmap + RDMA permissions, sizing queues and connections, querying doca\_rdma\_cap\_\*, or debugging DOCA\_ERROR\_\* from an RDMA call. Trigger even when the user does not mention "DOCA RDMA" — typical implicit phrasings include "one-sided read returns permission denied", "completions never arrive after submit", "connection callback never fires", "how do I do atomic compare-and-swap over RoCE", or "send queue hits DOCA\_ERROR\_FULL under burst". Refuse and route elsewhere for general RDMA / ibverbs theory (queue pairs, MRs, RoCE vs IB), installing DOCA itself, or non-RDMA DOCA libraries. /doca-rdma](https://skilld.dev/gh/nvidia/skills/doca-rdma)

Updated 2 months ago

[<h3>**/doca-rdmi**</h3>Use this skill when the user is doing hands-on DOCA RDMI (RDMA Initiator) programming — picking doca-rdmi vs doca-rdma for an accelerator-initiated one-sided RDMA flow, standing up a doca\_rdmi\_connection or doca\_rdmi\_poster, attaching a doca\_dpa\_completion or doca\_verbs\_cq before doca\_ctx\_start(), retrieving the DPA-side handle for a DPA kernel, auditing whether a doca\_rdmi\_\* symbol is EXPERIMENTAL on this DOCA, or debugging DOCA\_ERROR\_\* returns from RDMI calls. Trigger even when the user does not say "DOCA RDMI" or "initiator" — implicit phrasings include "my DPA kernel needs to post RDMA writes to a remote responder", "DPA kernel sees no completions", "function not found on doca\_rdmi\_\* at link time", "DOCA\_ERROR\_BAD\_STATE from completion attach", or "the DPA posted but the work request never arrived". Refuse and route elsewhere for two-sided or host-CPU RDMA, the DPA programming model, GPU-side RDMA initiation, or general RDMA/IB/RoCE concepts — those belong to other skills. /doca-rdmi](https://skilld.dev/gh/nvidia/skills/doca-rdmi)

Updated 2 months ago

[<h3>**/doca-rmax**</h3>Use this skill when the user is doing hands-on DOCA Rivermax work on a BlueField DPU or ConnectX host — standing up \`doca\_rmax\_in\_stream\` (receive) sessions for timing-precise media-over-IP (SMPTE ST 2110 video/audio, market data, scientific feeds), confirming the Rivermax SDK + license precondition before any DOCA-side code, running \`doca\_rmax\_get\_\*\_supported\` capability queries, pairing with \`doca-eth\` queues and \`doca-flow\` steering, or debugging \`DOCA\_ERROR\_\*\` from a Rivermax call. Trigger even when the user does not explicitly mention "DOCA Rivermax" or "rmax" — implicit phrasings include "ST 2110 receive isn't getting frames", "sub-microsecond jitter on BlueField", "NOT\_SUPPORTED from doca\_rmax\_init", "no recv events after stream start", or "license check failing on a media receiver". Refuse and route elsewhere for installing the Rivermax SDK or its license, programming the underlying queue (\`doca-eth\`), steering rules (\`doca-flow\`), or best-effort packet I/O — those belong to other skills. /doca-rmax](https://skilld.dev/gh/nvidia/skills/doca-rmax)

Updated 2 months ago

[<h3>**/doca-setup**</h3>Use this skill when the user is dealing with the DOCA environment around their workload — verifying an install is healthy, preparing the build env (pkg-config, headers, LD\_LIBRARY\_PATH, hugepages, devlink, representors), debugging env-class failures, deciding container-vs-bare-metal deployment shape, or reaching a DOCA install from a host that doesn't have one yet via the NGC DOCA container Stage-1 fallback. Trigger even when the user does not explicitly mention "DOCA setup" — typical implicit phrasings include "I just got a BlueField, what now", "my code is built, how do I run it", "pkg-config can't find doca-flow", "no free 2048 kB hugepages", "representor X not found", "I'm on a Mac and want to learn DOCA". Refuse and route elsewhere for library API specifics (Flow pipes, RDMA queues), the modify-a-sample first-app workflow or DOCA\_ERROR\_\* program-side debugging, and "where is X documented" knowledge-map questions — those belong to other skills. /doca-setup](https://skilld.dev/gh/nvidia/skills/doca-setup)

Updated 2 months ago

[<h3>**/doca-sha-offload-engine**</h3>Use this skill when wiring the DOCA SHA Offload Engine (an OpenSSL ENGINE) into an existing OpenSSL pipeline to offload one-shot SHA-1, SHA-256, or SHA-512 (EVP\_Digest) onto DOCA SHA hardware without rewriting against doca-sha. Covers engine load mechanics (\`openssl engine dynamic\`, \`set\_pci\_addr\` ctrl, \`-engine\_impl\`), the SHA-224 negative test that proves offload engaged, the message-size window where offload beats CPU SHA, and engine-vs-library selection. Trigger even when the user does not say "DOCA SHA Offload Engine" or "OpenSSL ENGINE" — typical implicit phrasings: "speed up openssl SHA on BlueField", "offload SHA without code changes", "is openssl using the accelerator or falling back to software", "prove DOCA SHA actually ran", "openssl dgst hashed but I'm not sure it was offloaded". Refuse and route elsewhere for new SHA pipelines (use doca-sha), MD5 / SHA-3 / SHA-224 / HMAC-SHA offload, incremental hashing via chained \`EVP\_DigestUpdate\`, or OpenSSL PROVIDER authoring. /doca-sha-offload-engine](https://skilld.dev/gh/nvidia/skills/doca-sha-offload-engine)

Updated 2 months ago

[<h3>**/doca-sta**</h3>Use this skill when the user is doing hands-on NVMe-over-Fabrics storage-target work on a BlueField DPU or ConnectX NIC with DOCA STA — standing up a doca\_sta DOCA Core context that accelerates the target-side NVMe-oF data path over RDMA, defining doca\_sta\_subsystem targets (NQN + namespaces) backed by local NVMe-PCI backend disks (doca\_sta\_be), checking device support via doca\_sta\_cap\_is\_supported, sizing the per-connection I/O queues, or debugging DOCA\_ERROR\_\* from a STA call. Trigger even when the user does not say "DOCA STA" — typical implicit phrasings include "my NVMe-oF Connect never completes", "Identify Controller times out over RoCE", "16 I/O queues at depth 1024 — does this BlueField support that", "offload the nvmf target onto the DPU", or "DOCA\_ERROR\_IO\_FAILED on an NVMe read". Refuse and route elsewhere for DOCA install, raw RDMA data movement, raw packet I/O, flow-rule programming, or initiator-side / host NVMe stack work — those belong to other skills. /doca-sta](https://skilld.dev/gh/nvidia/skills/doca-sta)

Updated 2 months ago

[<h3>**/doca-structured-tools-contract**</h3>Use this skill whenever another DOCA skill says "prefer the structured tool per doca-structured-tools-contract", or when the user wants a one-shot answer that consolidates info multiple manual commands would produce — DOCA env / version / devices / capabilities / validate / host vs DPU state. Trigger even when the user does not explicitly mention "structured tool" or "doca-env --json" — typical implicit phrasings include "is there one command that tells me everything about my DOCA install", "what version is X capability available since", "every PF/VF/SF visible on this BlueField with PCIe address", "will this pipe pass validate before commit", "diff host vs DPU state", or "why does the agent give a one-line answer on host A and five commands on host B". Refuse and route elsewhere for general DOCA orientation, specific library API how-to, or install-from-scratch guidance — those belong to the per-library skill, doca-public-knowledge-map, or doca-setup. /doca-structured-tools-contract](https://skilld.dev/gh/nvidia/skills/doca-structured-tools-contract)

Updated 2 months ago

[<h3>**/doca-telemetry**</h3>Use this skill to read DOCA hardware-counter events from a \`doca\_dev\` through the per-domain Telemetry reader libraries: \`doca\_telemetry\_pcc\`, \`\_dpa\`, \`\_diag\`, \`\_adp\_retx\`, \`\_phy\`, and \`\_pci\`. It covers capability checks, context creation, startup, and per-domain reads or samples. Trigger for implicit requests such as "read PCC counters from my BlueField app", "sample DPA counter exports", or "expose PHY, PCI, or DIAG counters from this doca\_dev". This is the counter-reader surface, not a NetFlow, IPFIX, or local-socket collector. Route publishing and export to \`doca-telemetry-exporter\`; route deployed DOCA Telemetry Service (DTS), collectors, and plain stdout logging elsewhere. /doca-telemetry](https://skilld.dev/gh/nvidia/skills/doca-telemetry)

Updated 2 months ago

[<h3>**/doca-upgrade**</h3>Use this skill when the user is contemplating a DOCA upgrade or downgrade — moving a host to a newer DOCA release, refreshing the BlueField BFB, bumping the NGC DOCA container tag, or rolling back. The discipline is detect → report → ASK → only-then guided upgrade: detect what is installed, discover what newer release exists, report the gap, then STOP and ask for explicit confirmation — never upgrade automatically. Trigger even without the word "upgrade": "is there a newer DOCA", "should I move to the next release", "I want the latest features", "my component is being deprecated, what now", or "roll me back". Route elsewhere for version detection (doca-version), first-time install (doca-setup), any hardware/firmware/reboot step (doca-hardware-safety), and public-docs / sunset routing (doca-public-knowledge-map). /doca-upgrade](https://skilld.dev/gh/nvidia/skills/doca-upgrade)

Updated 2 months ago

[<h3>**/doca-urom**</h3>Use this skill when the user is doing hands-on DOCA UROM library work from the host side — wiring doca-urom under an HPC / UCX / MPI stack to OFFLOAD remote memory operations (puts, gets, atomics, collectives) onto a BlueField DPU, creating a UROM Service context (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, or debugging DOCA\_ERROR\_\* from a doca\_urom\_\* call. Trigger even without "DOCA UROM": "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". Route elsewhere for UROM Service deployment on the DPU side, MPI / UCX collective algorithm design, and RDMA / RoCE / IB substrate bring-up. /doca-urom](https://skilld.dev/gh/nvidia/skills/doca-urom)

Updated 2 months ago

[<h3>**/doca-urom-svc**</h3>Operate the DOCA UROM Service container on BlueField Arm for remote memory operations (puts, gets, atomics, collectives) enqueued by a paired host using \`doca-urom\`: pull the NGC image, choose the UCX component, size queues, configure Comch pairing, and align host and service versions. SECURITY: the service has no standalone access control; Comch pairing and RDMA permissions are the boundary. Pair only intended hosts, expose least-privilege memory regions, and verify both views before start. Trigger for slow UCX collectives, unexpected NOT\_PERMITTED, or missing completions. Do not use for host application code, MPI/UCX integration design, or DOCA install. /doca-urom-svc](https://skilld.dev/gh/nvidia/skills/doca-urom-svc)

Updated 2 months ago

[<h3>**/doca-aes-gcm**</h3>Use this skill when the user is doing hands-on DOCA AES-GCM work on a BlueField DPU or ConnectX NIC — configuring \`doca\_aes\_gcm\_task\_encrypt\` / \`\_task\_decrypt\`, querying \`doca\_aes\_gcm\_cap\_\*\` for per-key-type (only \`DOCA\_AES\_GCM\_KEY\_128\` / \`\_256\` — AES-192 not supported) and per-task support, sizing plaintext against the max-buf cap, setting source / destination mmap permissions, validating with a NIST GCMVS or RFC 5288 vector, or debugging DOCA\_ERROR\_\* including the security-critical tag-verification-failed outcome on decrypt. Trigger even when the user does not explicitly mention "DOCA AES-GCM" or "AEAD" — typical implicit phrasings: "decrypt completion IO\_FAILED", "auth tag isn't verifying", "NOT\_PERMITTED on my encrypt buffer", "is AES-192-GCM on this BlueField" (no), or "encrypted record came back tampered". Refuse and route elsewhere for non-GCM AES modes (CBC / CTR / XTS — CPU OpenSSL), key management (KMS / HSM / rotation), SHA (doca-sha), or general AEAD background. /doca-aes-gcm](https://skilld.dev/gh/nvidia/skills/doca-aes-gcm)

Updated 3 months ago

[<h3>**/doca-argus**</h3>Use this skill when the user is deploying or operating the DOCA Argus Service — the packaged BlueField-side runtime-security container that watches the BlueField and attached host for suspicious activity, integrity violations, and operational anomalies, and forwards findings to a SIEM (Splunk / ELK / Sentinel / syslog). Covers the four-axis config (detection policy, forwarding, sampling, host coverage), running the NGC container on BlueField Arm, and wiring the forwarder. Trigger even without "DOCA Argus" by name — typical implicit phrasings: "container green but no findings arrive", "false-positive flood in Splunk", or "runtime security on a fleet of BlueField-3s". Refuse and route elsewhere for installing DOCA, SIEM-side ingest stanzas, pre-baked detection-rule packs, and metrics observability (DOCA Telemetry). Argus is NVIDIA's currently- promoted runtime-security framework, superseding the older App Shield library; name it first for new runtime-security work. /doca-argus](https://skilld.dev/gh/nvidia/skills/doca-argus)

Updated 3 months ago

[<h3>**/doca-bench-extension**</h3>Use this skill when the operator is authoring, building, loading, or debugging a custom doca-bench plug-in — a versioned shared library with DOCA\_EXPERIMENTAL-marked C entry points that doca-bench loads to measure a workload class its built-in modes do not cover, with doca\_bench\_cuda as the shipped reference exemplar. Trigger even when the user does not say "doca-bench-extension" or "doca\_bench\_cuda" — typical implicit phrasings include "no built-in doca-bench mode fits my workload", "how do I benchmark a CUDA GPUNetIO RX/TX kernel", "doca-bench cannot find or load my custom .so", "extension exported symbols do not match what the parent expects", "soversion mismatch after a DOCA upgrade", or "my GPU kernel hangs because stop\_flag was never set". Refuse and route elsewhere for questions about which built-in doca-bench mode to pick, DOCA GPUNetIO programming semantics, CUDA toolkit installation, or contributor work on in-tree extensions — those belong to other skills. /doca-bench-extension](https://skilld.dev/gh/nvidia/skills/doca-bench-extension)

Updated 3 months ago

[<h3>**/doca-bf4-deployment**</h3>WARNING: guides potentially IRREVERSIBLE BlueField-4 hardware operations (PLDM firmware burns, ISO reflashes, power cycles, BMC factory resets) that can brick firmware, corrupt boot media, or cause outages — a maintenance window and rollback plan are required, and every mutating step is governed by doca-hardware-safety, loaded alongside. Use this skill for BlueField-4 (BF4) day-1 platform bring-up from the BMC: installing the BlueField/DOCA bundle ISO onto the DPU (Grace, the Arm complex) over UEFI HTTP Boot, PXE, or Redfish Virtual Media; the PLDM firmware-update flow (BMC, NIC firmware, SBIOS, ERoT) via the Redfish UpdateService and pldmtool; and a Grace Ubuntu image with optional cloud-init. Trigger on BlueField-4/BF4 bring-up phrasings even without "BF4": {bring up my new BlueField-4}, {the BlueField ISO will not boot over HTTP from the BMC}, {attach BF4 virtual media via Redfish}, {BF4 firmware Task stuck at Running}. BF3 bring-up, application launch, and library APIs belong to other skills. /doca-bf4-deployment](https://skilld.dev/gh/nvidia/skills/doca-bf4-deployment)

Updated 3 months ago

[<h3>**/doca-caps**</h3>Use this skill when the user wants to invoke the read-only doca\_caps CLI to ask what DOCA sees on this host — listing DOCA devices and PCIe addresses, listing representor devices, asking which DOCA libraries are available on the current OS, checking per-device per-library capabilities, scoping output to a specific PCIe address, or capturing a side-effect-free capability snapshot for a debug session or install smoke-test. Trigger even when the user does not explicitly mention "doca\_caps" or "capabilities print tool" — typical implicit phrasings include "what does DOCA actually see on this box", "is my BlueField PF visible to DOCA", "is Flow available on my RHEL host", "enumerate VF representors for pf0", "doca\_caps: command not found", or "empty output for RDMA, is the tool broken". Refuse and route elsewhere for DOCA installation, library-internal capability matrices (Flow pipe creation, RDMA verbs features), streaming telemetry / DTS, or modifying the shipped binary — those belong to other skills. /doca-caps](https://skilld.dev/gh/nvidia/skills/doca-caps)

Updated 3 months ago

[<h3>**/doca-collectx-deployment**</h3>Use this skill to deploy and operate a CollectX (clx) based DOCA telemetry collector on a host or BlueField — wiring providers / counters into the collector, running the collection daemon, and shaping its exporters (Prometheus pull, Fluent Bit push, NetFlow, file / IPC) so the metrics actually leave the box. Trigger even when the user never says CollectX or clx — implicit phrasings: {collector emits nothing downstream}, {add a provider to the clx collector}, {turn on the Prometheus endpoint}, {ship counters to Fluent Bit from the DPU}, {daemon starts but no schema rows appear}. This skill owns the CollectX collection mechanism plus the operator's own doca-telemetry / doca-telemetry-exporter usage; it ROUTES the productized DOCA Telemetry Service (DTS) to public docs (AGENTS.md Non-goal #7), the reader API to doca-telemetry, and the publisher API to doca-telemetry-exporter. Refuse to invent clx symbols, provider names, schema fields, flags, or config paths — describe the class and route to the live source. /doca-collectx-deployment](https://skilld.dev/gh/nvidia/skills/doca-collectx-deployment)

Updated 3 months ago

[<h3>**/doca-comch**</h3>Use this skill when the user is doing hands-on DOCA Comch work on a host + BlueField pair — bringing up host ↔ DPU PCIe control-plane messaging, picking server (DPU) vs client (host) roles, choosing slow-path send-task / recv-callback vs fast-path producer / consumer, querying max-msg-size or max-clients capabilities, registering connection callbacks, or debugging DOCA\_ERROR\_\* returns from the Comch API. Trigger even when the user does not explicitly mention "DOCA Comch" or "Comm Channel" (renamed in DOCA 2.5) — typical implicit phrasings include "send a control message from host to BlueField over PCIe", "DPU can't see the host representor", "DOCA\_ERROR\_NOT\_PERMITTED on server\_create", "DOCA\_ERROR\_AGAIN on task\_send submit", "connect callback never fires", or "stream bulk data from a host driver to a DPU agent". Refuse and route elsewhere for installing DOCA itself, BFB / firmware bring-up, non-Comch DOCA libraries, or deploying Comch apps at scale — those belong to other skills. /doca-comch](https://skilld.dev/gh/nvidia/skills/doca-comch)

Updated 3 months ago

[<h3>**/doca-common**</h3>Use this skill whenever the user is doing hands-on DOCA programming on a BlueField DPU or ConnectX NIC and needs the foundation primitives every per-library context rests on — walking the doca\_ctx lifecycle, discovering doca\_dev / doca\_devinfo and gating on doca\_\*\_cap\_\* before trusting a feature, wiring doca\_mmap / doca\_buf\_inventory / doca\_buf for zero-copy I/O across libraries, driving doca\_pe for completions, or DOCA Log's two-tier (--sdk-log-level vs app-side) model. Trigger even when the user does not say "DOCA Common" — typical implicit phrasings include "my tasks submit but nothing completes", "DOCA\_ERROR\_BAD\_STATE from doca\_ctx\_start", "--sdk-log-level does nothing for my DOCA\_LOG\_DBG lines", "share a buf between doca\_dma and doca\_rdma", or "crashes far from the offending line". Refuse and route elsewhere for per-library questions in isolation (load doca-flow / doca-rdma / doca-eth alongside), installing DOCA (doca-setup), or doc lookup (doca-public-knowledge-map). /doca-common](https://skilld.dev/gh/nvidia/skills/doca-common)

Updated 3 months ago

[<h3>**/doca-debug**</h3>Use this skill when the user is debugging any DOCA symptom — a build that won't compile, a link step that can't resolve a doca\_\* symbol, a runtime call returning DOCA\_ERROR\_\*, a silent service or tool, or a stack trace / valgrind / core dump — and needs the layered ladder (install → version → build → link → runtime → program → driver), verbosity controls (--sdk-log-level, DOCA\_LOG\_LEVEL, the doca-{lib}-trace flavor), container-debug constraints, or how to capture state for a Developer Forum post. Trigger even when the user does not say "DOCA debug" — implicit phrasings include "undefined reference to doca\_\*", "how do I get more logs", "packets aren't reaching the wire", "doca\_caps returned nothing", or "hugepages empty in the container". Refuse and route elsewhere for library-specific debug (Flow pipe trace, RDMA QP, Comch stats), env-class pkg-config or hugepages symptoms, the DOCA\_ERROR\_\* taxonomy and lifecycle interpretation, and performance or incident-response work — those belong to other skills. /doca-debug](https://skilld.dev/gh/nvidia/skills/doca-debug)

Updated 3 months ago

[<h3>**/doca-dma**</h3>Use this skill when the user is doing hands-on DOCA DMA programming — bringing up a doca\_dma context, configuring the single doca\_dma\_task\_memcpy task type, sizing buffers via the doca\_dma\_cap\_task\_memcpy\_\* queries, setting LOCAL\_READ\_ONLY / LOCAL\_READ\_WRITE permissions on source / destination doca\_mmap regions (plus doca\_mmap\_export\_\* for cross-peer copies), driving the progress engine, or debugging DOCA\_ERROR\_\* returns. Trigger even when the user does not explicitly mention "DOCA DMA" or "doca\_mmap" — typical implicit phrasings include "memcpy host buffer to BlueField without using the CPU", "offload a bulk copy to the DPU", "copy returns NOT\_PERMITTED on first submit", "buffer too big for one DMA task", "task submitted but no completion", or "scatter-gather copy between two memory regions". Refuse and route elsewhere for cross-network copies (DOCA RDMA), producer/consumer messaging (DOCA Comch), DOCA Core / progress-engine internals, or DOCA install — those belong to other skills. /doca-dma](https://skilld.dev/gh/nvidia/skills/doca-dma)

Updated 3 months ago

[<h3>**/doca-dpa**</h3>Use this skill when the user is doing hands-on DOCA DPA host-side work on a BlueField — creating the \`doca\_dpa\` Core context, loading a DPACC-compiled DPA app image (\`doca\_dpa\_app\`), creating DPA threads, launching kernels via \`doca\_dpa\_kernel\_launch\_update\_\*\`, draining \`doca\_dpa\_completion\`, running \`doca\_dpa\_cap\_\*\` discovery, choosing between the DPA comm component (inter-DPA messaging) and the DPA verbs component (in-kernel RDMA), or debugging \`DOCA\_ERROR\_\*\` from \`doca\_dpa\_\*\`. Trigger even without "DOCA DPA" or "Data-Path Accelerator": "run compute on the DPA from my host", "DPA kernel hangs, no completion", "DOCA\_ERROR\_DRIVER on launch", "DOCA/DPACC version skew", or "does this BlueField expose a DPA". Route elsewhere for DPA-side kernel programming itself, DPACC compiler internals, host↔DPU messaging (doca-comch), host-side RDMA (doca-rdma), and GPU-initiated networking (doca-gpunetio). /doca-dpa](https://skilld.dev/gh/nvidia/skills/doca-dpa)

Updated 3 months ago

[<h3>**/doca-dpa-hl-tracer**</h3>Use this skill when the user runs doca\_dpa\_hl\_tracer to capture/decode DPA-side traces at the programming-events layer (kernel entry/exit, sync points, comm primitive calls, RDMA WR submission, completion drain) — picking TRACE vs CRIT, tuning the JSON config (file-size limits + file\_size\_limit\_policy, thread priorities/cores), decoding against the matching DPA-side ELF, or diagnosing empty/noisy captures. Trigger even when the user does not explicitly mention "DOCA DPA tracer" or "high-level tracer" — typical implicit phrasings include "DPA kernel returns wrong result but host completions look clean", "kernel-entry to first-comm latency is huge", "RDMA WR to drain gap on the DPA", "trace file truncated mid-run", "TRACE doubled my DPA latency", or "tracer wrote a file but parser shows zero events". Refuse and route elsewhere for writing DPA kernels, DPA-Comms/DPA-Verbs programming, raw per-cycle DPA profiling, host-side doca-dpa debugging, or production DPA telemetry — those belong to other skills. /doca-dpa-hl-tracer](https://skilld.dev/gh/nvidia/skills/doca-dpa-hl-tracer)

Updated 3 months ago

[<h3>**/doca-dpdk-bridge**</h3>Use this skill when the user has an existing DPDK application and is adding DOCA capabilities in-place — most commonly DOCA Flow hardware steering — without rewriting the data-plane in DOCA-native form: binding a DPDK port id to a \`doca\_dev\` (\`doca\_dpdk\_port\_probe\` / \`doca\_dpdk\_port\_as\_dev\`), converting \`rte\_mbuf\` ↔ \`doca\_buf\`, querying \`doca\_dpdk\_cap\_is\_rep\_port\_supported\`, or debugging \`DOCA\_ERROR\_\*\` from a bridge call. Trigger even without "DOCA DPDK Bridge": "how do I add DOCA Flow to my DPDK app", "make a DPDK port visible to DOCA", "the bridge loads but every operation returns errors", "pkg-config --exists doca-dpdk-bridge fails", or "DOCA\_ERROR\_NOT\_FOUND on port registration". Route elsewhere for fresh DOCA-native packet I/O (doca-eth), flow-rule programming (doca-flow), DOCA or DPDK install (doca-setup), or RDMA data movement (doca-rdma). /doca-dpdk-bridge](https://skilld.dev/gh/nvidia/skills/doca-dpdk-bridge)

Updated 3 months ago

[<h3>**/doca-erasure-coding**</h3>Use this skill when the user is doing hands-on DOCA Erasure Coding programming on a BlueField DPU, ConnectX NIC, or host — bringing up a doca\_ec context, picking among the create / recover / update tasks, choosing matrix type / N / K / block size, querying doca\_ec\_cap\_\* before sizing, setting doca\_mmap src/dst permissions, or debugging DOCA\_ERROR\_\* returns from doca\_ec\_task\_\*. Trigger even when the user does not name "DOCA Erasure Coding" or "Reed-Solomon" — typical implicit phrasings include "one data block changed, how do I refresh parity without re-encoding", "a disk failed and 2 parity blocks are gone, can I rebuild", "RAID-6 resilience across 12 disks", "my doca\_ec\_task\_create returns NOT\_PERMITTED", or "is this N+K layout still recoverable". Refuse and route elsewhere for non-Reed-Solomon codes (fountain / LDPC / raptor), pure-replication designs, network FEC, or other DOCA accelerator libraries (SHA / Compress / AES-GCM / DMA) — those belong to other skills. /doca-erasure-coding](https://skilld.dev/gh/nvidia/skills/doca-erasure-coding)

Updated 3 months ago

[<h3>**/doca-eth**</h3>Use this skill for hands-on DOCA Ethernet packet-queue work on a BlueField DPU or ConnectX NIC — bringing up a \`doca\_eth\_rxq\` or \`doca\_eth\_txq\` on a port / representor / SF, picking among the four \`enum doca\_eth\_rxq\_type\` values (\`\_REGULAR\` / \`\_CYCLIC\` / \`\_MANAGED\_MEMPOOL\` / \`\_SHARED\_MEMPOOL\`), sizing burst or scatter-gather length against the \`\_cap\_\*\` queries, submitting \`doca\_eth\_txq\_task\_send\` / \`\_lso\_send\` (carrying packet \`doca\_buf\`s — no \`doca\_eth\_frame\` struct exists), or debugging DOCA\_ERROR\_\* from an Ethernet call. Trigger on implicit phrasings: "my RX queue is up but no packets arrive", "send-task returns AGAIN at line rate", "which queue type for fixed-MTU ingress", "device open fails without sudo", or "is L3 checksum offload available here". Refuse and route elsewhere for installing DOCA, flow-rule / steering programming, host↔DPU control messaging, or RDMA data movement. /doca-eth](https://skilld.dev/gh/nvidia/skills/doca-eth)

Updated 3 months ago

[<h3>**/doca-flow-dpa-provider**</h3>Use this skill when the user is doing hands-on DOCA Flow DPA Provider work — exporting a \`doca-flow\` pipe or external resource (index-selector/memory) into BlueField DPA address space so a DPACC-built kernel can read counters, mutate hash-pipe entries, and update/read memory or index-selector resources inline with Flow. Covers per-port \`doca\_flow\_dpa\_ctx\`, three queue types (general/resources-write/resources-read), the order-sensitive export handshake (\`\_export\_prepare\` → add entries → \`\_export\` → \`\_get\_device\_addr\`), and DPA-side device API. Trigger even when the user does not say "DOCA Flow DPA Provider" — implicit phrasings include "DPA kernel never sees entries in the exported pipe", "BAD\_STATE from \`\_pipe\_export\`", "how do I disable a hash entry from a DPA kernel", "DPA memory read returns no value", or "DPA-side post keeps returning AGAIN". Refuse and route elsewhere for \`doca-flow\` pipe construction, generic host-side DPA (\`doca-dpa\`), or DPA-side kernel-writing — those belong to other skills. /doca-flow-dpa-provider](https://skilld.dev/gh/nvidia/skills/doca-flow-dpa-provider)

Updated 3 months ago

[<h3>**/doca-flow-perf**</h3>Use this skill when the user is measuring the host or DPU-CPU control-plane rate of a DOCA Flow pipeline with doca\_flow\_perf — picking a JSON policy from configs/, choosing the DPDK or DOCA backend, running the single-iteration smoke then the iterative eval loop, interpreting per-iteration CPU cycles and num\_pushed / num\_failed, or capturing the four-tuple (DOCA version, BlueField/firmware, JSON policy, worker/queue/burst config) that makes a Kops/sec number defensible. Trigger even when the user does not explicitly mention "doca-flow-perf" — typical implicit phrasings include "how many rules per second can my BlueField insert", "5-tuple hairpin rule rate", "Kops/sec for steering", "flow-perf number does not match release notes", "DPDK vs DOCA benchmark", or "rule-install variance too high". Refuse and route elsewhere for optimizing a live Flow app (doca-flow-tune), the DPA-offloaded path (doca-flow-dpa-perf), dataplane throughput or latency, or library-internal pipe semantics — those belong to other skills. /doca-flow-perf](https://skilld.dev/gh/nvidia/skills/doca-flow-perf)

Updated 3 months ago

[<h3>**/doca-flow-tune**</h3>Use this skill when the user is tuning a live or captured \`doca-flow\` pipeline with \`doca\_flow\_tune\` — snapshotting pipe / counter / KPI state, picking a tuning axis (rule placement, resource hints / table sizing, HW-offload mode) and a matching measurement (rule-install rate, lookup latency, hardware-counter delta), running offline or online (read-only or state-changing) modes, reading the dumper CSV / analyze JSON / visualize mermaid, or applying a recommendation back into the Flow program. Trigger even when the user does not explicitly mention "doca\_flow\_tune" — typical implicit phrasings include "Flow rule-install rate is low on BlueField", "table sizing looks wrong for this pipe", "tune visualize step is empty", "before/after counters don't move", or "which doca-flow knob does this recommendation hit". Refuse and route elsewhere for measuring baseline numbers (doca-flow-perf, doca-flow-dpa-perf), writing the doca-flow application, DOCA install, or streaming Flow telemetry — those belong to other skills. /doca-flow-tune](https://skilld.dev/gh/nvidia/skills/doca-flow-tune)

Updated 3 months ago

[<h3>**/doca-mgmt**</h3>Use this skill when the user is doing hands-on DOCA Management programming against BlueField / ConnectX devices — standing up a management or representor context (doca\_mgmt\_dev\_ctx / doca\_mgmt\_dev\_rep\_ctx), querying device caps (data-direct, caps-general), toggling congestion-control global status, modifying diagnostics-data, setting ICM quotas, or issuing a raw firmware command via doca\_mgmt\_raw\_cmd with the right scope (CONFIGURATION / DEBUG\_READ\_ONLY / DEBUG\_WRITE / DEBUG\_WRITE\_FULL). Trigger even when the user does not say "DOCA Management" — typical implicit phrasings include "fleet tool that walks every BlueField and reads device state", "toggle data-direct on a VF", "set an ICM quota per representor", "send a raw firmware command from C", "DOCA\_ERROR\_IO\_FAILED from raw\_cmd", or "fwctl ioctl is failing". Refuse and route elsewhere for mlxconfig direct operation, BFB / firmware reflash, streaming telemetry, doca\_caps CLI snapshots, or DOCA install itself — those belong to other skills. /doca-mgmt](https://skilld.dev/gh/nvidia/skills/doca-mgmt)

Updated 3 months ago

[<h3>**/doca-pcc**</h3>Use this skill when the user is doing hands-on host-side DOCA PCC work to load a CUSTOM Programmable Congestion Control algorithm onto a BlueField DPU — creating per-port \`doca\_pcc\` contexts, loading a \`dpacc\`-compiled \`doca\_pcc\_app\` onto the \`doca\_dev\` for the RoCE-bearing port, parameterizing it, walking triple-axis capability discovery (DOCA cap-query + DPA-capable BlueField + firmware custom-PCC slot enabled), or debugging \`DOCA\_ERROR\_\*\` from \`doca\_pcc\_\*\`. Trigger even without explicit "DOCA PCC" phrasing — implicit forms include "loading my own congestion control onto a BF port", "DOCA\_ERROR\_NOT\_PERMITTED on algorithm load", "DOCA\_ERROR\_DRIVER when I attach my custom algorithm", "my custom rate-update isn't affecting RoCE traffic", or "load succeeds but no on-wire change". Refuse and route elsewhere for DPA-side algorithm-body design, the \`pcc\_counters\` CLI, default factory PCC in ConnectX firmware, or setting up the RDMA / RoCE traffic — those belong to other skills. /doca-pcc](https://skilld.dev/gh/nvidia/skills/doca-pcc)

Updated 3 months ago

[<h3>**/doca-pcc-ztr-rttcc-algo**</h3>Use this skill when the user is doing hands-on deployment, tuning, or evaluation of the DOCA-shipped Zero-Touch RoCE RTT-based Congestion Control (ZTR RTTCC) reference algorithm on a BlueField-3 DPA — wiring \`doca\_pcc\_dev\_ztr\_rttcc\_algo\` into the shipped DOCA PCC sample, picking a variant (vanilla / PM / RX-rate / multipath / window-probeless) at DPACC build time, tuning host-set parameters, or diagnosing \`DOCA\_PCC\_DEV\_STATUS\_FAIL\` from the algorithm. Trigger even when the user does not say 'DOCA PCC' or 'ZTR RTTCC' — typical implicit phrasings: 'my RoCE-v2 flows aren't being throttled', 'PCC sample isn't dispatching to my algo', 'how do I pick the multipath PCC variant', 'set-params returns fail', 'algorithm loaded but counters are flat', or 'do I need a custom CC algorithm on BF3'. Refuse and route elsewhere for writing a custom PCC algorithm from scratch, read-only PCC counter inspection, the host-side \`doca-pcc\` lifecycle, or firmware-only pre-Programmable PCC — those belong to other skills. /doca-pcc-ztr-rttcc-algo](https://skilld.dev/gh/nvidia/skills/doca-pcc-ztr-rttcc-algo)

Updated 3 months ago

[<h3>**/doca-programming-guide**</h3>Use this skill when the user is writing their first DOCA app or asking a library-agnostic programming question — picking a shipped sample to copy and modify, wiring the canonical pkg-config doca-{library} + meson build (or FFI from Rust / Go / Python against the public C ABI), walking the cfg-create → init → start → use → stop → destroy lifecycle, validating a spec before commit, or decoding a DOCA\_ERROR\_\* return with doca\_error\_get\_descr(). Trigger even when the user does not say "DOCA programming guide" — implicit phrasings: "write my first DOCA program", "meson line for doca\_rdma\_\*", "got DOCA\_ERROR\_BAD\_STATE on my first call", "call DOCA from Rust without writing C", "built clean but nothing on the wire", "what order do doca\_\*\_pipe calls go in". Refuse and route for install / hugepages / pkg-config not resolving doca-{library} (doca-setup), docs or version lookup (doca-public-knowledge-map), and library-internal API construction like Flow pipe topology or RDMA QP setup (matching library skill). /doca-programming-guide](https://skilld.dev/gh/nvidia/skills/doca-programming-guide)

Updated 3 months ago

[<h3>**/doca-sha**</h3>Use this skill when the user is doing hands-on DOCA SHA programming — offloading SHA-1, SHA-256, or SHA-512 hashing onto a BlueField DPU or ConnectX accelerator, picking between one-shot \`doca\_sha\_task\_hash\` and incremental \`doca\_sha\_task\_partial\_hash\`, querying \`doca\_sha\_cap\_\*\` for algorithm support and min destination / max source buffer sizes, setting source / destination \`doca\_mmap\` permissions, or decoding DOCA\_ERROR\_\* returns from the SHA API. Trigger even when the user does not explicitly mention "DOCA SHA" or "doca\_sha\_task" — typical implicit phrasings include "hash a multi-GiB file on the DPU", "offload SHA-256 to the BlueField", "streaming hash over chunks", "partial hash returns BAD\_STATE", "destination buffer too small for digest", or "is SHA-512 available on this card". Refuse and route elsewhere for general cryptographic-hash theory (collision resistance, SHA-3 selection), other DOCA crypto libraries (AES-GCM, Compress, DMA), or DOCA install / BFB bring-up — those belong to other skills. /doca-sha](https://skilld.dev/gh/nvidia/skills/doca-sha)

Updated 3 months ago

[<h3>**/doca-socket-relay**</h3>Use this skill when the operator is driving the DOCA Socket Relay to bridge a socket-oriented host application onto a BlueField DPU peer without rewriting it — picking the deployment shape (in-process, sidecar, or BlueField service container), configuring the host-side socket and the DPU-side forwarding endpoint, walking the bind → connect → round-trip → admit-fleet smoke, or diagnosing a stuck/silent relay. Trigger even when the user does not explicitly mention "DOCA Socket Relay" — typical implicit phrasings include "move my socket app onto the BlueField without rewriting it", "host app gets ECONNREFUSED on the relay", "relay accepts the connection but bytes never arrive on the DPU side", "first round-trip works, the rest hang", "bridge an AF\_UNIX (UDS) socket to a DPU peer over Comch", or "I want a sidecar that forwards my socket to the BlueField". Refuse and route elsewhere for the comch programming API, line-rate raw packet I/O via doca-eth, and DOCA install/bring-up — those belong to other skills. /doca-socket-relay](https://skilld.dev/gh/nvidia/skills/doca-socket-relay)

Updated 3 months ago

[<h3>**/doca-spcx-cc**</h3>Use this skill when the user is invoking \`doca\_spcx\_cc\` (the host-side CLI under /opt/mellanox/doca/tools/) to load, parameterize, start, observe, or stop a Programmable Congestion Control (SPCX) algorithm on a BlueField with a DPA processor against a live RDMA / RoCE fabric, or picking SPCX vs the established \`doca-pcc\` surface. Trigger even when the user does not say "DOCA SPCX" or "doca\_spcx\_cc" — typical implicit phrasings include "I want to write a custom RTT-based CC algorithm for my RoCE fabric", "my SPCX session loaded but throughput / latency didn't change", "doca\_pcc status shows Active but factory CC seems to still be in charge", "DOCA\_PCC\_PS\_ERROR on start", "is the programmable-CC surface available on my install", or "DPA-side algorithm image won't load". Refuse and route elsewhere for DPA-side algorithm authoring detail, factory PCC firmware configuration, read-only PCC counter inspection, raw DPA cycle profiling, RDMA library programming, or general DOCA install — those belong to other skills. /doca-spcx-cc](https://skilld.dev/gh/nvidia/skills/doca-spcx-cc)

Updated 3 months ago

[<h3>**/doca-telemetry-utils**</h3>Use this skill when the user is invoking \`doca\_telemetry\_utils\` on a host with DOCA installed — discovering the diagnostic-counter schema, translating counter names to binary Data IDs, validating per-device counter support before committing a DOCA Telemetry exporter config, or reverse-resolving a captured Data ID. Trigger even when the user does not explicitly mention "doca\_telemetry\_utils" or "Data ID" — typical implicit phrasings include "my exporter ships but the collector sees nothing", "this metric silently drops downstream", "which counters does this BlueField expose", "translate this 0x... back to a counter name", "what do node / pcie\_index / depth mean here", or "is this counter supported on this device before I commit it". Refuse and route elsewhere for developer-side collector / exporter library programming, DTS deployment, or DOCA install / repair — those belong to doca-telemetry, doca-public-knowledge-map, and doca-setup. /doca-telemetry-utils](https://skilld.dev/gh/nvidia/skills/doca-telemetry-utils)

Updated 3 months ago

[<h3>**/doca-verbs**</h3>Use this skill when the user is dropping below the higher-level DOCA libraries (doca-rdma / doca-eth / doca-rmax) into the raw-verbs escape hatch — managing QP / CQ / PD / MR / SRQ / AH / CC-group / Ethernet-SQ-RQ primitives inside DOCA Core, porting libibverbs code into the DOCA Core model, capability-querying a specific verb / opcode / WR flag / QP attribute via doca\_verbs\_query\_device, or debugging DOCA\_ERROR\_\* from doca\_verbs\_\* calls. Trigger even when the user does not say "doca-verbs" — implicit phrasings include "raw QP attribute the task API doesn't expose", "keep my ibv\_\* code next to doca\_\* on the same QP", "IO\_FAILED on WR submit", "QP state transition rejected", "attach a congestion- control group", or "porting my libibverbs code". The skill's first job is to route MOST users back UP to the higher-level library. Refuse and route elsewhere for general doca-rdma / doca-eth / doca-rmax workloads, DOCA install, Core internals, and general libibverbs theory — those belong to other skills. /doca-verbs](https://skilld.dev/gh/nvidia/skills/doca-verbs)

Updated 3 months ago

[<h3>**/doca-version**</h3>Use this skill when the user is doing DOCA version handling — detecting the installed release, validating the four-way match across pkg-config doca-common, applications/VERSION, doca\_caps --version, and bfver/mlnx-release on BlueField, reasoning about NGC container tags, looking up whether a capability is on the installed release, or diagnosing build-vs-runtime drift. Trigger even when the user does not explicitly say "DOCA version" or "four-way match" — typical implicit phrasings include "program built but does nothing on the wire", "undefined reference to a symbol the docs claim exists", "DOCA\_ERROR\_NOT\_SUPPORTED at runtime", "counter didn't increment", "what does \`latest\` mean for this tag", or "is my LTS still supported". Refuse and route elsewhere for installing or choosing DOCA packages (doca-setup), per-library API/capability questions (matching library skill), the cross-library DOCA\_ERROR\_\* taxonomy (doca-programming-guide), or the general debug ladder (doca-debug) — those belong to other skills. /doca-version](https://skilld.dev/gh/nvidia/skills/doca-version)

Updated 3 months ago

[<h3>**/amc-setup-calibration-stack**</h3>Launch AutoMagicCalib microservice and web UI from NGC release images via Docker Compose. Use when user says 'deploy auto calibration', 'launch auto calibration', 'launch AMC', 'start MS+UI', or 'set up auto-magic-calib'. Requires NGC API key. /amc-setup-calibration-stack](https://skilld.dev/gh/nvidia/skills/amc-setup-calibration-stack)

Updated 3 months ago

[<h3>**/deepstream-generate-pipeline**</h3>Build DeepStream GStreamer pipelines interactively. Use when the user asks about pipelines for video/image inference, detection, tracking, or streaming — including natural phrases like 'pipeline to infer on image', 'run inference on video', 'detect objects in stream', 'save inference output', 'deepstream pipeline', 'gst-launch pipeline', 'process video with detection', 'build a pipeline', or any request involving GStreamer/DeepStream elements (nvinfer, nvstreammux, nvtracker, etc.). /deepstream-generate-pipeline](https://skilld.dev/gh/nvidia/skills/deepstream-generate-pipeline)

Updated 3 months ago

[<h3>**/deepstream-profile-pipeline**</h3>Profile a DeepStream pipeline with Nsight Systems and derive its configs from the measurement. Use when the user asks for an efficient, performant, or profiled pipeline — or to benchmark, tune, or measure FPS. /deepstream-profile-pipeline](https://skilld.dev/gh/nvidia/skills/deepstream-profile-pipeline)

Updated 3 months ago

[<h3>**/deepstream-sop**</h3>Use this skill when building, deploying, evaluating, debugging, or measuring latency for the DeepStream SOP Inference Microservice — a GPU-accelerated FastAPI service that detects whether operators perform assembly-line steps in order via event boundary detection (GEBD) plus VLM classification. Trigger even if the user does not name it: verify operator step sequence, detect missing or out-of-order SOP steps, score factory/work-cell video for procedure compliance, run VLM-based SOP checking on industrial cameras, or call /v1/chat/completions with a file, RTSP, or Basler camera. Also trigger for its internals: SOPVideoProcessor, DeepStream GEBD model (e.g. DDM) via Triton CAPI, nvds\_custom\_postprocess, Cosmos Reason 1/2 vLLM, SSE streaming, Kafka NvProto/JSON output, Basler/Pylon camera + emulation, Docker compose, chunk-level latency. Do NOT trigger for generic DeepStream pipelines, object detection/tracking, NIM imports, or video summarization. /deepstream-sop](https://skilld.dev/gh/nvidia/skills/deepstream-sop)

Updated 3 months ago

[<h3>**/earth2studio-create-datasource**</h3>Create and validate Earth2Studio data source wrappers (DataSource, ForecastSource, DataFrameSource, ForecastFrameSource) from remote stores. Do NOT use for fetching data with existing sources, model inference, or installation tasks. /earth2studio-create-datasource](https://skilld.dev/gh/nvidia/skills/earth2studio-create-datasource)

Updated 3 months ago

[<h3>**/earth2studio-create-diagnostic**</h3>Create Earth2Studio diagnostic model wrappers for single-step data transformations, including simple derived diagnostics, packaged AutoModel diagnostics, and generative or diffusion diagnostics. Do NOT use for prognostic time-stepping models, data sources, or installation. /earth2studio-create-diagnostic](https://skilld.dev/gh/nvidia/skills/earth2studio-create-diagnostic)

Updated 3 months ago

[<h3>**/earth2studio-create-prognostic**</h3>Create Earth2Studio prognostic (time-stepping forecast) model wrappers. Do NOT use for diagnostic models, data sources, or installation. /earth2studio-create-prognostic](https://skilld.dev/gh/nvidia/skills/earth2studio-create-prognostic)

Updated 3 months ago

[<h3>**/cuopt-developer**</h3>Modify, build, test, debug, and contribute to NVIDIA cuOpt (C++/CUDA, Python, server, CI). Use for solver internals, PRs, DCO, and code conventions. /cuopt-developer](https://skilld.dev/gh/nvidia/skills/cuopt-developer)

Updated 3 months ago

[<h3>**/jetson-build-source**</h3>Use when you need to rebuild the BSP overlay — DT, OOT modules, or kernel — from changes under bsp\_sources/. Triggers: build bsp, rebuild dtb, rebuild kernel. /jetson-build-source](https://skilld.dev/gh/nvidia/skills/jetson-build-source)

Updated 3 months ago

Requires [/jetson-promote-image](https://skilld.dev/gh/nvidia/skills/jetson-promote-image) [/jetson-init-image](https://skilld.dev/gh/nvidia/skills/jetson-init-image) [/jetson-init-source](https://skilld.dev/gh/nvidia/skills/jetson-init-source) +2

[<h3>**/jetson-customize-camera**</h3>Enable MIPI/GMSL camera sensors on a Jetson Thor or Orin custom carrier by rendering a kernel-DT overlay from the in-tree sensor DTSI. Do NOT use for UPHY lane allocation or ODMDATA edits. /jetson-customize-camera](https://skilld.dev/gh/nvidia/skills/jetson-customize-camera)

Updated 3 months ago

Requires [/jetson-build-source](https://skilld.dev/gh/nvidia/skills/jetson-build-source) [/jetson-init-source](https://skilld.dev/gh/nvidia/skills/jetson-init-source) [/jetson-derive-carrier](https://skilld.dev/gh/nvidia/skills/jetson-derive-carrier) +1

[<h3>**/jetson-customize-clocks**</h3>Use to lock/cap Jetson CPU/GPU/EMC clocks, toggle EMC/CPU DVFS, or change cpufreq governors by editing BPMP DTB and nvpower.sh pre-flash. Do NOT use for live tuning or nvpmodel edits. /jetson-customize-clocks](https://skilld.dev/gh/nvidia/skills/jetson-customize-clocks)

Updated 3 months ago

Requires [/jetson-customize-nvpmodel](https://skilld.dev/gh/nvidia/skills/jetson-customize-nvpmodel) [/jetson-set-target](https://skilld.dev/gh/nvidia/skills/jetson-set-target) [/jetson-init-target](https://skilld.dev/gh/nvidia/skills/jetson-init-target) +4

[<h3>**/jetson-customize-fan**</h3>Use when you need to add, remove, edit, list, or change the boot default of an nvfancontrol fan profile on a Jetson/Tegra (Orin, Thor) target. Triggers: edit fan profile, tune fan curve. /jetson-customize-fan](https://skilld.dev/gh/nvidia/skills/jetson-customize-fan)

Updated 3 months ago

Requires [/jetson-set-target](https://skilld.dev/gh/nvidia/skills/jetson-set-target) [/jetson-init-target](https://skilld.dev/gh/nvidia/skills/jetson-init-target) [/jetson-init-image](https://skilld.dev/gh/nvidia/skills/jetson-init-image) +3

[<h3>**/jetson-customize-mgbe**</h3>Enable Jetson Thor 25G/10G/1G MGBE QSFP via kernel-DT overlay. Do NOT use for UPHY lane allocation or ODMDATA edits. /jetson-customize-mgbe](https://skilld.dev/gh/nvidia/skills/jetson-customize-mgbe)

Updated 3 months ago

Requires [/jetson-customize-uphy](https://skilld.dev/gh/nvidia/skills/jetson-customize-uphy) [/jetson-build-source](https://skilld.dev/gh/nvidia/skills/jetson-build-source) [/jetson-init-source](https://skilld.dev/gh/nvidia/skills/jetson-init-source) +2

[<h3>**/jetson-customize-nvpmodel**</h3>Use when you need to add, remove, edit, list, or change the boot default of an nvpmodel power mode on a Jetson/Tegra (Orin, Thor) target. Triggers: edit power mode, tune frequency caps. /jetson-customize-nvpmodel](https://skilld.dev/gh/nvidia/skills/jetson-customize-nvpmodel)

Updated 3 months ago

Requires [/jetson-set-target](https://skilld.dev/gh/nvidia/skills/jetson-set-target) [/jetson-init-target](https://skilld.dev/gh/nvidia/skills/jetson-init-target) [/jetson-init-image](https://skilld.dev/gh/nvidia/skills/jetson-init-image) +3

[<h3>**/jetson-customize-pcie**</h3>Per-controller PCIe enable / disable / lanes / link-speed for a Jetson Thor or Orin custom carrier via ODMDATA + kernel-DT overlay. Do NOT use for UPHY lane allocation or endpoint-mode bring-up. /jetson-customize-pcie](https://skilld.dev/gh/nvidia/skills/jetson-customize-pcie)

Updated 3 months ago

Requires [/jetson-build-source](https://skilld.dev/gh/nvidia/skills/jetson-build-source) [/jetson-customize-uphy](https://skilld.dev/gh/nvidia/skills/jetson-customize-uphy) [/jetson-init-source](https://skilld.dev/gh/nvidia/skills/jetson-init-source) +1

[<h3>**/jetson-customize-pinmux**</h3>Per-pin SFIO / direction / initial-state configurator for a Jetson Orin or Thor custom carrier from the pinmux XLSM. Do NOT use for kernel-DT overlay or ODMDATA edits. /jetson-customize-pinmux](https://skilld.dev/gh/nvidia/skills/jetson-customize-pinmux)

Updated 3 months ago

Requires [/jetson-derive-carrier](https://skilld.dev/gh/nvidia/skills/jetson-derive-carrier) [/jetson-init-source](https://skilld.dev/gh/nvidia/skills/jetson-init-source)

[<h3>**/jetson-customize-uphy**</h3>Configure Jetson UPHY lane allocation (uphy0/uphy1-config) on Orin/Thor custom carriers. Do NOT use for pinmux or PCIe-only edits. /jetson-customize-uphy](https://skilld.dev/gh/nvidia/skills/jetson-customize-uphy)

Updated 3 months ago

Requires [/jetson-customize-pcie](https://skilld.dev/gh/nvidia/skills/jetson-customize-pcie) [/jetson-customize-mgbe](https://skilld.dev/gh/nvidia/skills/jetson-customize-mgbe) [/jetson-customize-usb](https://skilld.dev/gh/nvidia/skills/jetson-customize-usb) +3

[<h3>**/jetson-customize-usb**</h3>Enable/disable Jetson USB2/USB3 SS ports via kernel-DT overlay. Do NOT use for UPHY lane allocation or ODMDATA edits. /jetson-customize-usb](https://skilld.dev/gh/nvidia/skills/jetson-customize-usb)

Updated 3 months ago

Requires [/jetson-init-source](https://skilld.dev/gh/nvidia/skills/jetson-init-source) [/jetson-derive-carrier](https://skilld.dev/gh/nvidia/skills/jetson-derive-carrier) [/jetson-customize-uphy](https://skilld.dev/gh/nvidia/skills/jetson-customize-uphy) +2

[<h3>**/jetson-derive-carrier**</h3>Bootstrap a custom carrier board by forking carrier files and scaffolding a DT overlay from the reference devkit. Use after jetson-init-source; not for module-level or kernel-DTB changes. /jetson-derive-carrier](https://skilld.dev/gh/nvidia/skills/jetson-derive-carrier)

Updated 3 months ago

Requires [/jetson-init-source](https://skilld.dev/gh/nvidia/skills/jetson-init-source) [/jetson-init-image](https://skilld.dev/gh/nvidia/skills/jetson-init-image)

[<h3>**/jetson-diagnostic**</h3>Read-only Jetson health snapshot for identity, memory, GPU, thermal, power, storage, services, and top processes. /jetson-diagnostic](https://skilld.dev/gh/nvidia/skills/jetson-diagnostic)

Updated 3 months ago

[<h3>**/jetson-download-bsp**</h3>Download NVIDIA Jetson Linux BSP artifacts (BSP tarball, sample rootfs, public\_sources, x-tools, guides) for the active target. Use for Auto Setup; not for extraction or profile edits. /jetson-download-bsp](https://skilld.dev/gh/nvidia/skills/jetson-download-bsp)

Updated 3 months ago

Requires [/jetson-quick-start](https://skilld.dev/gh/nvidia/skills/jetson-quick-start) [/jetson-init-image](https://skilld.dev/gh/nvidia/skills/jetson-init-image) [/jetson-init-source](https://skilld.dev/gh/nvidia/skills/jetson-init-source) +2

[<h3>**/jetson-flash-image**</h3>Use to flash a promoted BSP image to a Jetson DUT in RCM mode via flash.sh or l4t\_initrd\_flash.sh. Do NOT use for BSP customization, image promotion, or carrier derivation. /jetson-flash-image](https://skilld.dev/gh/nvidia/skills/jetson-flash-image)

Updated 3 months ago

Requires [/jetson-promote-image](https://skilld.dev/gh/nvidia/skills/jetson-promote-image) [/jetson-derive-carrier](https://skilld.dev/gh/nvidia/skills/jetson-derive-carrier) [/jetson-init-image](https://skilld.dev/gh/nvidia/skills/jetson-init-image) +2

[<h3>**/jetson-generate-kb**</h3>Build a per-target knowledge-base markdown next to the active profile by walking the BSP root and source tree. Use after init-image / init-source; not for editing profile fields. /jetson-generate-kb](https://skilld.dev/gh/nvidia/skills/jetson-generate-kb)

Updated 3 months ago

Requires [/jetson-init-image](https://skilld.dev/gh/nvidia/skills/jetson-init-image) [/jetson-init-source](https://skilld.dev/gh/nvidia/skills/jetson-init-source) [/jetson-link-docs](https://skilld.dev/gh/nvidia/skills/jetson-link-docs)

[<h3>**/jetson-headless-mode**</h3>Plan and apply safe Jetson headless-mode changes to reclaim GUI and daemon memory. /jetson-headless-mode](https://skilld.dev/gh/nvidia/skills/jetson-headless-mode)

Updated 3 months ago

[<h3>**/jetson-inference-mem-tune**</h3>Pick the serving stack and per-runtime memory flags (vLLM, SGLang, llama.cpp, TensorRT Edge-LLM) for an LLM/VLM workload on any NVIDIA Jetson. /jetson-inference-mem-tune](https://skilld.dev/gh/nvidia/skills/jetson-inference-mem-tune)

Updated 3 months ago

[<h3>**/jetson-init-image**</h3>Extract Jetson Linux + sample-rootfs tarballs and run apply\_binaries.sh for the active target, then record bsp\_image in the profile. Use after jetson-init-target; not for source-tree setup. /jetson-init-image](https://skilld.dev/gh/nvidia/skills/jetson-init-image)

Updated 3 months ago

Requires [/jetson-init-source](https://skilld.dev/gh/nvidia/skills/jetson-init-source) [/jetson-download-bsp](https://skilld.dev/gh/nvidia/skills/jetson-download-bsp)

[<h3>**/jetson-init-source**</h3>Set up the BSP source workspace: Linux\_for\_Tegra overlay tracker, bsp\_sources, Crosstool-NG toolchain. Use after jetson-init-image; not for fetching inputs. /jetson-init-source](https://skilld.dev/gh/nvidia/skills/jetson-init-source)

Updated 3 months ago

Requires [/jetson-init-image](https://skilld.dev/gh/nvidia/skills/jetson-init-image) [/jetson-download-bsp](https://skilld.dev/gh/nvidia/skills/jetson-download-bsp)

[<h3>**/jetson-init-target**</h3>Author a new Jetson target-platform profile (reference\_devkit + optional custom\_carrier) and update the active pointer. Use to create a target; not for switching existing profiles. /jetson-init-target](https://skilld.dev/gh/nvidia/skills/jetson-init-target)

Updated 3 months ago

Requires [/jetson-init-image](https://skilld.dev/gh/nvidia/skills/jetson-init-image) [/jetson-init-source](https://skilld.dev/gh/nvidia/skills/jetson-init-source) [/jetson-link-docs](https://skilld.dev/gh/nvidia/skills/jetson-link-docs) +2

[<h3>**/jetson-link-docs**</h3>Bind pre-downloaded Jetson reference docs (developer guide, design guide, pinmux, schematics) into the active profile documents block. Use after staging docs on disk; not for downloading. /jetson-link-docs](https://skilld.dev/gh/nvidia/skills/jetson-link-docs)

Updated 3 months ago

Requires [/jetson-generate-kb](https://skilld.dev/gh/nvidia/skills/jetson-generate-kb) [/jetson-customize-pinmux](https://skilld.dev/gh/nvidia/skills/jetson-customize-pinmux) [/jetson-init-target](https://skilld.dev/gh/nvidia/skills/jetson-init-target)

[<h3>**/jetson-llm-benchmark**</h3>Benchmark Jetson LLM/VLM serving performance across vLLM, llama.cpp, and Ollama with structured JSON output. /jetson-llm-benchmark](https://skilld.dev/gh/nvidia/skills/jetson-llm-benchmark)

Updated 3 months ago

[<h3>**/jetson-llm-serve**</h3>Stand up vLLM or SGLang serving on Jetson, using upstream vLLM on Thor and Orin JetPack 7.2+, and NVIDIA-AI-IOT vLLM on older Orin. /jetson-llm-serve](https://skilld.dev/gh/nvidia/skills/jetson-llm-serve)

Updated 3 months ago

[<h3>**/jetson-memory-audit**</h3>Measure Jetson DRAM/NvMap usage and verify before/after memory reclamation with live audit data. /jetson-memory-audit](https://skilld.dev/gh/nvidia/skills/jetson-memory-audit)

Updated 3 months ago

[<h3>**/jetson-optimize-memory**</h3>Reclaim DRAM by disabling unused subsystems across MB1 BCT, MB2 BCT, kernel reserved-memory, and SWIOTLB. Use for headless or no-camera Jetson deployments; not for CPU/GPU frequency tuning. /jetson-optimize-memory](https://skilld.dev/gh/nvidia/skills/jetson-optimize-memory)

Updated 3 months ago

Requires [/jetson-init-image](https://skilld.dev/gh/nvidia/skills/jetson-init-image) [/jetson-init-source](https://skilld.dev/gh/nvidia/skills/jetson-init-source) [/jetson-promote-image](https://skilld.dev/gh/nvidia/skills/jetson-promote-image)

[<h3>**/jetson-package**</h3>Pick Jetson-compatible containers, vLLM runtime images, and Jetson AI Lab PyPI indexes; maps Orin SM 8.7 vs Thor SM 11.0 and JetPack-specific package choices. /jetson-package](https://skilld.dev/gh/nvidia/skills/jetson-package)

Updated 3 months ago

[<h3>**/jetson-print-bsp-info**</h3>Use when you need to print Jetson BSP info (L4T version, board configs, rootfs state) from a Linux\_for\_Tegra root on the host PC. This is an example skill. /jetson-print-bsp-info](https://skilld.dev/gh/nvidia/skills/jetson-print-bsp-info)

Updated 3 months ago

[<h3>**/jetson-print-device-info**</h3>Use when you need to print Jetson device info (module model, L4T version, kernel, OS version, current power mode) from a running Jetson target. This is an example skill. /jetson-print-device-info](https://skilld.dev/gh/nvidia/skills/jetson-print-device-info)

Updated 3 months ago

[<h3>**/jetson-promote-image**</h3>Use to promote overlay files and built artifacts into the staged BSP image. Do NOT use to flash or build. Triggers: promote bsp image. /jetson-promote-image](https://skilld.dev/gh/nvidia/skills/jetson-promote-image)

Updated 3 months ago

Requires [/jetson-flash-image](https://skilld.dev/gh/nvidia/skills/jetson-flash-image) [/jetson-init-source](https://skilld.dev/gh/nvidia/skills/jetson-init-source) [/jetson-init-image](https://skilld.dev/gh/nvidia/skills/jetson-init-image) +4

[<h3>**/jetson-quick-start**</h3>Entry skill for Jetson / IGX BSP customization. Asks one core click-to-select setup questionnaire and passes prefilled answers to downstream setup skills. /jetson-quick-start](https://skilld.dev/gh/nvidia/skills/jetson-quick-start)

Updated 3 months ago

Requires [/jetson-download-bsp](https://skilld.dev/gh/nvidia/skills/jetson-download-bsp) [/jetson-init-image](https://skilld.dev/gh/nvidia/skills/jetson-init-image) [/jetson-init-source](https://skilld.dev/gh/nvidia/skills/jetson-init-source) +11

[<h3>**/jetson-set-target**</h3>Switch the active Jetson target-platform pointer to an existing profile YAML. Use before customize/build/flash to change target; not for authoring profiles — use jetson-init-target instead. /jetson-set-target](https://skilld.dev/gh/nvidia/skills/jetson-set-target)

Updated 3 months ago

Requires [/jetson-init-target](https://skilld.dev/gh/nvidia/skills/jetson-init-target)

[<h3>**/jetson-speculative-decoding**</h3>Add EAGLE-3 or draft-model speculative decoding to a Jetson vLLM server when TPOT is the bottleneck. /jetson-speculative-decoding](https://skilld.dev/gh/nvidia/skills/jetson-speculative-decoding)

Updated 3 months ago

[<h3>**/jetson-validate-image**</h3>Use after jetson-flash-image to run static BSP checks, on-target smoke/regression tests on a flashed DUT, or both. Not for build or flash steps. Triggers: validate bsp, on-target validation. /jetson-validate-image](https://skilld.dev/gh/nvidia/skills/jetson-validate-image)

Updated 3 months ago

Requires [/jetson-init-image](https://skilld.dev/gh/nvidia/skills/jetson-init-image) [/jetson-flash-image](https://skilld.dev/gh/nvidia/skills/jetson-flash-image) [/jetson-promote-image](https://skilld.dev/gh/nvidia/skills/jetson-promote-image)

[<h3>**/dali-dynamic-mode**</h3>DALI imperative dynamic mode (\`nvidia.dali.experimental.dynamic\`, ndd): use when working on ndd code or migrating pipelines; skip pipeline-only tasks. /dali-dynamic-mode](https://skilld.dev/gh/nvidia/skills/dali-dynamic-mode)

Updated 4 months ago

[<h3>**/hsb-app**</h3>Discover and run Holoscan Sensor Bridge example applications on a connected devkit. Filters available apps by the user's platform, HSB software version, board type, and sensors. Supports timed execution, failure analysis, code-edit suggestions, and iterative re-runs. /hsb-app](https://skilld.dev/gh/nvidia/skills/hsb-app)

Updated 4 months ago

Requires [/hsb-setup](https://skilld.dev/gh/nvidia/skills/hsb-setup)

[<h3>**/hsb-flash**</h3>Flash the FPGA on an HSB board connected to an NVIDIA devkit. Supports HSB Lattice boards (FPGA versions 2407, 2412, 2507, 2510) and Leopard Imaging VB1940 "all-in-one" cameras (FPGA versions 2507, 2510). Uses release-specific YAML manifests and board-type-specific program commands. Lattice and VB1940 commands must never be mixed. /hsb-flash](https://skilld.dev/gh/nvidia/skills/hsb-flash)

Updated 4 months ago

Requires [/hsb-setup](https://skilld.dev/gh/nvidia/skills/hsb-setup)

[<h3>**/hsb-setup**</h3>Clone the latest NVIDIA Holoscan Sensor Bridge repo, ask which supported devkit is being used, configure the host per platform, build the correct demo container, run it, and verify HSB connectivity by pinging 192.168.0.2. Use for Holoscan Sensor Bridge setup, build, container launch, and first-connectivity bring-up. /hsb-setup](https://skilld.dev/gh/nvidia/skills/hsb-setup)

Updated 4 months ago

[<h3>**/hsb-test**</h3>Execute QA test plans on Holoscan Sensor Bridge hardware. Reads a user-provided test document, filters tests by the user's setup, determines which tests can run automatically, executes them with pass/fail evaluation, and produces a structured test results report. /hsb-test](https://skilld.dev/gh/nvidia/skills/hsb-test)

Updated 4 months ago

Requires [/hsb-setup](https://skilld.dev/gh/nvidia/skills/hsb-setup)

[<h3>**/earth2studio-deterministic-forecast**</h3>Build deterministic forecast scripts with Earth2Studio (model, data source, IO, inference). Do NOT use for ensemble, diagnostics, data-only fetch, or install. /earth2studio-deterministic-forecast](https://skilld.dev/gh/nvidia/skills/earth2studio-deterministic-forecast)

Updated 4 months ago

[<h3>**/data-designer**</h3>Use when the user wants to create a dataset, generate synthetic data, or build a data generation pipeline. /data-designer](https://skilld.dev/gh/nvidia/skills/data-designer)

Updated 4 months ago

[<h3>**/launch-nemo-rl**</h3>Playbook for launching, monitoring, stopping, and debugging NeMo-RL recipes on a Kubernetes cluster via the nrl-k8s CLI. Covers ephemeral vs long-lived RayCluster modes, iterating on runs, and debugging hung or failed training jobs. /launch-nemo-rl](https://skilld.dev/gh/nvidia/skills/launch-nemo-rl)

Updated 4 months ago

[<h3>**/holoscan-install-conda**</h3>Install Holoscan SDK v4.3+ via Conda in a CUDA 13 environment. Use for Conda installs; redirect CUDA 12 hosts to container/wheel. /holoscan-install-conda](https://skilld.dev/gh/nvidia/skills/holoscan-install-conda)

Updated 4 months ago

Requires [/holoscan-install-container](https://skilld.dev/gh/nvidia/skills/holoscan-install-container) [/holoscan-install-wheel](https://skilld.dev/gh/nvidia/skills/holoscan-install-wheel)

[<h3>**/holoscan-install-container**</h3>Install Holoscan SDK via the NGC Docker container. Use for container-based installs; not for native apt/pip/Conda installs. /holoscan-install-container](https://skilld.dev/gh/nvidia/skills/holoscan-install-container)

Updated 4 months ago

[<h3>**/holoscan-install-debian**</h3>Install Holoscan SDK natively on Ubuntu via apt. Use for C++ installs on Ubuntu; pair with /holoscan-install-wheel for Python. /holoscan-install-debian](https://skilld.dev/gh/nvidia/skills/holoscan-install-debian)

Updated 4 months ago

Requires [/holoscan-install-wheel](https://skilld.dev/gh/nvidia/skills/holoscan-install-wheel)

[<h3>**/holoscan-install-source**</h3>Build Holoscan SDK from source via the in-tree ./run script. Use only when published packages don't meet the user's needs. /holoscan-install-source](https://skilld.dev/gh/nvidia/skills/holoscan-install-source)

Updated 4 months ago

[<h3>**/holoscan-install-wheel**</h3>Install Holoscan SDK Python wheel via pip into a venv. Use for Python installs; not for native C++/apt or Conda installs. /holoscan-install-wheel](https://skilld.dev/gh/nvidia/skills/holoscan-install-wheel)

Updated 4 months ago

Requires [/holoscan-install-debian](https://skilld.dev/gh/nvidia/skills/holoscan-install-debian)

[<h3>**/holoscan-setup**</h3>Guides Holoscan SDK installation: inspects the host, assesses platform compatibility, recommends an install method, and delegates to the matching install skill. /holoscan-setup](https://skilld.dev/gh/nvidia/skills/holoscan-setup)

Updated 4 months ago

Requires [/holoscan-install-container](https://skilld.dev/gh/nvidia/skills/holoscan-install-container) [/holoscan-install-debian](https://skilld.dev/gh/nvidia/skills/holoscan-install-debian) [/holoscan-install-wheel](https://skilld.dev/gh/nvidia/skills/holoscan-install-wheel) +2

[<h3>**/mcore-create-issue**</h3>Investigate a failing GitHub Actions run or job and create a GitHub issue for the failure. /mcore-create-issue](https://skilld.dev/gh/nvidia/skills/mcore-create-issue)

Updated 4 months ago

[<h3>**/mcore-linting-and-formatting**</h3>Linting and formatting for Megatron-LM. Covers running autoformat.sh, tools (ruff, black, isort, pylint, mypy), and code style rules. /mcore-linting-and-formatting](https://skilld.dev/gh/nvidia/skills/mcore-linting-and-formatting)

Updated 4 months ago

[<h3>**/mcore-run-on-slurm**</h3>How to launch distributed Megatron-LM training jobs on a SLURM cluster. Covers a minimal sbatch skeleton, environment-variable setup for torch.distributed.run, CUDA\_DEVICE\_MAX\_CONNECTIONS rules across hardware and parallelism modes, container conventions, monitoring, and per-rank failure diagnosis. /mcore-run-on-slurm](https://skilld.dev/gh/nvidia/skills/mcore-run-on-slurm)

Updated 4 months ago

[<h3>**/mcore-split-pr**</h3>Split a PR into multiple PRs to reduce the number of required CODEOWNERS reviewer groups. /mcore-split-pr](https://skilld.dev/gh/nvidia/skills/mcore-split-pr)

Updated 4 months ago

[<h3>**/mcore-testing**</h3>Test system for Megatron-LM. Covers test layout, recipe YAML structure, adding and running unit and functional tests, golden values, marker filters, and CI parity. /mcore-testing](https://skilld.dev/gh/nvidia/skills/mcore-testing)

Updated 4 months ago

[<h3>**/earth2studio-data-fetch**</h3>Fetch weather/climate data via Earth2Studio data sources for specific variables and times. Do NOT use for inference pipelines, model discovery, or installation. /earth2studio-data-fetch](https://skilld.dev/gh/nvidia/skills/earth2studio-data-fetch)

Updated 4 months ago

[<h3>**/earth2studio-discover**</h3>Find Earth2Studio models, data sources, and examples for a weather/climate use case. Do NOT use for writing inference code, downloading data, or installation. /earth2studio-discover](https://skilld.dev/gh/nvidia/skills/earth2studio-discover)

Updated 4 months ago

[<h3>**/earth2studio-install**</h3>Guide installing Earth2Studio via uv or pip, selecting model extras, and configuring the environment. Do NOT use for writing inference code, choosing models, or PhysicsNeMo questions. /earth2studio-install](https://skilld.dev/gh/nvidia/skills/earth2studio-install)

Updated 4 months ago

[<h3>**/digital-health-clinical-asr-build**</h3>Stage 2 of the Clinical ASR Flywheel. Use when curating clinical terms, tagging IPA, and synthesizing a NeMo manifest. NOT for scoring (use /digital-health-clinical-asr-eval). /digital-health-clinical-asr-build](https://skilld.dev/gh/nvidia/skills/digital-health-clinical-asr-build)

Updated 4 months ago

Requires [/digital-health-clinical-asr-setup](https://skilld.dev/gh/nvidia/skills/digital-health-clinical-asr-setup) [/digital-health-clinical-asr-eval](https://skilld.dev/gh/nvidia/skills/digital-health-clinical-asr-eval) [/data-designer](https://skilld.dev/gh/nvidia/skills/data-designer) +1

[<h3>**/digital-health-clinical-asr-eval**</h3>Stage 3 of Clinical ASR Flywheel. Score a NeMo manifest, produce the five-section KER leaderboard (by-ipa\_source diagnostic). Not for ASR auth (/riva-asr). /digital-health-clinical-asr-eval](https://skilld.dev/gh/nvidia/skills/digital-health-clinical-asr-eval)

Updated 4 months ago

Requires [/digital-health-clinical-asr-build](https://skilld.dev/gh/nvidia/skills/digital-health-clinical-asr-build) [/digital-health-clinical-asr-finetune](https://skilld.dev/gh/nvidia/skills/digital-health-clinical-asr-finetune)

[<h3>**/digital-health-clinical-asr-finetune**</h3>Stage 4 of the Clinical ASR Flywheel. Use when priority KER is above 0.3 to run stock NeMo SFT on Parakeet TDT v2 and offline cycle N+1 re-eval. NOT for generic word boosting (use /finetune-asr). /digital-health-clinical-asr-finetune](https://skilld.dev/gh/nvidia/skills/digital-health-clinical-asr-finetune)

Updated 4 months ago

Requires [/digital-health-clinical-asr-eval](https://skilld.dev/gh/nvidia/skills/digital-health-clinical-asr-eval) [/digital-health-clinical-asr-build](https://skilld.dev/gh/nvidia/skills/digital-health-clinical-asr-build)

[<h3>**/digital-health-clinical-asr-setup**</h3>Stage 1 of Clinical ASR Flywheel. Use when bootstrapping a cycle: NVCF+MW disclosure, NVIDIA\_API\_KEY check, deps install, TTS+ASR smoke test. /digital-health-clinical-asr-setup](https://skilld.dev/gh/nvidia/skills/digital-health-clinical-asr-setup)

Updated 4 months ago

Requires [/digital-health-clinical-asr-build](https://skilld.dev/gh/nvidia/skills/digital-health-clinical-asr-build) [/data-designer](https://skilld.dev/gh/nvidia/skills/data-designer) [/digital-health-clinical-asr-eval](https://skilld.dev/gh/nvidia/skills/digital-health-clinical-asr-eval) +1

[<h3>**/dynamo-interconnect-check**</h3>Validate that a Dynamo deployment's NIXL/UCX/NCCL interconnect is ready for disaggregated serving over RDMA/NVLink. Use after recipe-runner brings a deployment up (especially disagg/multi-node) to confirm the KV transport is correct; use troubleshoot for diagnosing already-failed pods. /dynamo-interconnect-check](https://skilld.dev/gh/nvidia/skills/dynamo-interconnect-check)

Updated 4 months ago

[<h3>**/dynamo-recipe-runner**</h3>Select, validate, patch, and deploy existing NVIDIA Dynamo Kubernetes recipes. Use for model/backend/GPU/deployment-mode recipe bring-up; use router-starter for router-only mode work and troubleshoot for broken deployments. /dynamo-recipe-runner](https://skilld.dev/gh/nvidia/skills/dynamo-recipe-runner)

Updated 4 months ago

[<h3>**/dynamo-router-starter**</h3>Start or patch Dynamo router modes and run router endpoint smoke checks. Use for round-robin, KV-aware, least-loaded, or device-aware routing setup; use recipe-runner for recipe deployment and troubleshoot for failure diagnosis. /dynamo-router-starter](https://skilld.dev/gh/nvidia/skills/dynamo-router-starter)

Updated 4 months ago

[<h3>**/dynamo-troubleshoot**</h3>Diagnose failed or unhealthy Dynamo deployments. Use when pods, model-cache jobs, PVCs, workers, frontend/router health, endpoints, or benchmark jobs fail; use recipe-runner/router-starter before this for normal bring-up. /dynamo-troubleshoot](https://skilld.dev/gh/nvidia/skills/dynamo-troubleshoot)

Updated 4 months ago

[<h3>**/nemo-automodel-launcher-config**</h3>Configure NeMo AutoModel job launches for interactive runs, Slurm clusters, and SkyPilot cloud execution. /nemo-automodel-launcher-config](https://skilld.dev/gh/nvidia/skills/nemo-automodel-launcher-config)

Updated 4 months ago

## Add to your README

The badge links readers to this page. It shows the skilld mark and no counts, and it follows the reader's light or dark GitHub theme.

`<a href="https://skilld.dev/gh/nvidia/skills"> <picture> <source media="(prefers-color-scheme: dark)" srcset="https://skilld.dev/b/nvidia/skills?theme=dark"> <source media="(prefers-color-scheme: light)" srcset="https://skilld.dev/b/nvidia/skills?theme=light"> <img alt="Skill repository on skilld.dev" src="https://skilld.dev/b/nvidia/skills?theme=light"> </picture> </a>`