SkillsAdd

nvidia/skills

doca-debug

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 pos…

First seen Jul 18, 2026

Installation

$ npx skills add nvidia/skills --skill doca-debug
View on skills.sh ↗ GitHub repository ↗

Similar popular skills

Related neighbors and high-traction skills in the same topics — useful to compare before installing.

agent-browser Same topic
vercel-labs/agent-browser

Browser automation CLI for AI agents. Use when the user needs to interact with websites, includ…

810.4K installs
azure-diagnostics Same topic
microsoft/azure-skills

Debug Azure production issues on Azure using AppLens, Azure Monitor, resource health, and safe …

568.9K installs
azure-validate Same topic
microsoft/azure-skills

Pre-deployment validation for Azure readiness. Run deep checks on configuration, infrastructure…

567.7K installs
azure-aigateway Same topic
microsoft/azure-skills

Configure Azure API Management as an AI Gateway for AI models, MCP tools, and agents. WHEN: sem…

566.3K installs
azure-compute Same topic
microsoft/azure-skills

Azure VM/VMSS router. WHEN: create / provision / deploy / spin-up VM, recommend VM size, compar…

510K installs
supabase-postgres-best-practices Same topic
supabase/agent-skills

Postgres best practices maintained by Supabase, for Postgres running anywhere. Load this skill …

391.6K installs

Also in this package

Other skills from nvidia/skills · top by installs.

npx skills add nvidia/skills
rag-blueprint 2.9K accelerated-computing-cudf 2.8K aiq-research 2.8K cuopt-developer 2.5K aiq-deploy 2.4K cuopt-install 2.4K cudaq-guide 2.4K data-designer 2.2K deepstream-dev 2.2K omniverse-cad-to-simready 2.2K

Browse all from nvidia/skills

More details

Agent compatibility

Declared targets from SKILL.md / docs. Unmarked agents are not listed — the skill may still install via the CLI.

Claude Code Not declared
Cursor Not declared
Codex Not declared
GitHub Copilot Not declared
Windsurf Not declared
Gemini CLI Not declared
Cline Not declared
OpenCode Not declared

Repository health

Stars 3.2K
License LICENSE-APACHE
Default branch main
Open issues 5
Status Active

Skill metadata

Parsed from SKILL.md frontmatter.

LicenseApache-2.0
CompatibilityNo DOCA install required to read this skill (it is an overlay loaded against any DOCA artifact skill); the validation steps within DO require a live DOCA install at /opt/mellanox/doca.
More metadata
kind
library

Package contents

Files included with this skill beyond the listing page.

  • skill md SKILL.md 10,238 B
  • docs SUMMARY.md 1,054 B

History

  1. First seen on skills.sh
  2. First recorded snapshot · 135 installs

SKILL.md

DOCA debug

Where to start: This skill is the canonical layered-ladder reference both [doca-setup ## debug](../doca-setup/TASKS.md#debug) and [doca-programming-guide ## debug](../doca-programming-guide/TASKS.md#debug) escalate to. If the symptom does not fit cleanly in env-class or program-class, start at [TASKS.md ## debug](TASKS.md#debug) — the full layered ladder lives there.

Example questions this skill answers well

The CLASSES of debug questions this skill is built to answer, each with one worked example.

  • **"My DOCA build / link / runtime / program failed — which layer is

it?"** — worked example: "ld says undefined reference to docaflowinit — which layer?" Answered by the canonical layered ladder in [TASKS.md ## debug](TASKS.md#debug) (layer 4 = Link).

  • "How do I turn up verbosity for any DOCA library or tool?" —

worked example: "My DOCA Flow program is silent — where do I get more log output?" Answered by the trace-flavor / log-level surface in [CAPABILITIES.md ## Observability](CAPABILITIES.md#observability) + the run-with-verbosity workflow in [TASKS.md ## run](TASKS.md#run).

  • "How do I capture state for a forum question or bug report?" —

worked example: "I'd like to file a forum question with reproducible context — what should I include?" Answered by the capture-a-reproducible-state workflow in [TASKS.md ## test](TASKS.md#test).

  • **"What does this DOCA tool's output mean / which tool answers

this?"** — worked example: "doca_caps returned nothing for RDMA — does that mean unsupported?" Answered by the tool-vs-capability decision tree in [CAPABILITIES.md ## Capabilities and modes](CAPABILITIES.md#capabilities-and-modes) + cross-link to [doca-caps](../tools/doca-caps/SKILL.md).

  • **"I'm debugging inside the NGC container — what's

observable?"** — worked example: "hugepages is empty inside the container; is that a real problem or a container thing?" Answered by the container-specific debug constraints in [CAPABILITIES.md ## Safety policy](CAPABILITIES.md#safety-policy) + [TASKS.md ## debug](TASKS.md#debug) layer 5 (Runtime).

  • "Where do I ask for help with this?" — worked example: *"Where

is the customer-facing DOCA forum and what should the post contain?"* Answered by the Developer-Forum routing rule in [TASKS.md ## debug](TASKS.md#debug) plus [doca-public-knowledge-map](../doca-public-knowledge-map/SKILL.md).

If the symptom is purely env-class, route to [doca-setup ## debug](../doca-setup/TASKS.md#debug); if purely program-class, route to [doca-programming-guide ## debug](../doca-programming-guide/TASKS.md#debug). This skill is the cross-cutting layer both call into.

When to load this skill

Load this skill when the user is debugging anything DOCA-related — a build that won't compile, a link step that can't resolve a doca symbol, a runtime call that returns DOCAERROR_, a packet that does not appear on the wire, a service that won't start, or a tool that returns no useful output. Concretely:

  • The user reports a symptom and needs to find the layer that caused it (install / version / build / link / runtime / program).
  • The user asks "how do I get more logs?" or "how do I turn up the verbosity?" for any DOCA library or tool.
  • The user wants to capture state for a forum question or an internal bug report (the bundle does not own the internal-bug-report channel; it routes to the public DOCA Developer Forum).
  • The user is reading a stack trace, a valgrind output, or a core dump from a DOCA program and wants to know where to look first.
  • The user is debugging inside the NGC DOCA container and needs to know what is and is not observable from inside it.

Do not load this skill for:

  • "What is DOCAERRORBAD_STATE?", "what error codes does DOCA return?" — that is the cross-library error taxonomy, owned by [doca-programming-guide CAPABILITIES.md ## Error taxonomy](../doca-programming-guide/CAPABILITIES.md#error-taxonomy). This skill consumes that taxonomy; it does not redefine it.
  • "My pkg-config cannot find doca-flow", "hugepages are not mounted", "my representor isn't visible" — those are env-class symptoms, owned by [doca-setup ## debug](../doca-setup/TASKS.md#debug). This skill is the canonical pointer that env-class debug ladder redirects to once the symptom escalates beyond install / version / build prerequisites.
  • Library-specific debugging (Flow pipe trace, RDMA queue-pair state, Comch channel statistics) — those live in the matching library skill (e.g. [doca-flow ## debug](../libs/doca-flow/TASKS.md#debug)). This skill provides the cross-cutting debug ladder; library skills layer their library-specific debug surface on top of it.

What this skill provides

This is a thin loader. The body keeps only the orientation needed to pick the right next file. The substantive debug material lives in two companion files:

  • [CAPABILITIES.md](CAPABILITIES.md) — what kinds of debug surface DOCA exposes: the layered debug model (install / version / build / link / runtime / program), the read-only-first stance, version-availability of debug tools (e.g. doca_caps since DOCA 2.6.0), the cross-library error taxonomy (cross-link only — owned by doca-programming-guide), the observability primitives DOCA emits (stderr logs, --sdk-log-level, the doca-<lib>-trace build flavor, library counters), and the safety constraints on debug actions (read-only first, don't mutate install tree mid-investigation).
  • [TASKS.md](TASKS.md) — the actual debug workflows: ## configure (set up env for high-verbosity debug), ## test (capture a reproducible state), ## debug (the canonical layered ladder, the universal entry point that every library ## debug redirects to), and the Where to ask for help routing (NVIDIA DOCA Developer Forum). Three other anchors (build, modify, run) exist for lint compliance and route to [doca-programming-guide](../doca-programming-guide/SKILL.md), which owns those verbs after the env / program split.

Loading order

  1. Read this SKILL.md first to confirm the user's symptom is cross-cutting debug (not env-class only, not program-class only, not library-internal only).
  2. For the layered debug model, the read-only stance, the version-availability of debug tools, and the observability surface DOCA emits, see [CAPABILITIES.md](CAPABILITIES.md).
  3. **For the canonical layered debug ladder and the capture-and-report workflow, see [TASKS.md](TASKS.md).** The build, modify, and run anchors in TASKS.md are stubs that route to [doca-programming-guide](../doca-programming-guide/SKILL.md); their substance lives there.
  4. If the user's symptom turns out to be env-class (install / build prerequisites), hand off to [doca-setup ## debug](../doca-setup/TASKS.md#debug). If program-class, hand off to [doca-programming-guide ## debug](../doca-programming-guide/TASKS.md#debug). If library-internal, hand off to the matching library skill's ## debug (e.g. [doca-flow ## debug](../libs/doca-flow/TASKS.md#debug)).

The two companion files cross-link to each other and to [doca-public-knowledge-map](../doca-public-knowledge-map/SKILL.md) whenever the right answer is "look it up in the public docs or the installed package layout" rather than "debug-specific guidance".

Related skills

  • [doca-public-knowledge-map](../doca-public-knowledge-map/SKILL.md) — public DOCA documentation routing and the on-disk layout of an installed DOCA package. This skill defers all "where is X documented", "where on disk is Y", and "how do I check the installed version" questions to the knowledge-map.
  • [doca-setup](../doca-setup/SKILL.md) — env-class debug (install / build prerequisites): pkg-config failures, missing hugepages, representors not visible, header-vs-runtime version mismatches. doca-setup ## debug is the env-class layered ladder; this skill is the cross-cutting debug ladder both env and program ladders escalate to.
  • [doca-programming-guide](../doca-programming-guide/SKILL.md) — program-class debug (lifecycle order, DOCAERROR* interpretation, docaerrorget_descr() use, the validate-before-commit rule). doca-programming-guide ## debug is the program-class layered ladder; this skill picks up where it leaves off when the symptom involves cross-library tooling (gdb, valgrind, container introspection, core dumps).
  • Library skills (e.g. [doca-flow](../libs/doca-flow/SKILL.md), [doca-dms](../services/doca-dms/SKILL.md), [doca-caps](../tools/doca-caps/SKILL.md)) — library-specific debug overlays. Each library's ## debug builds on the cross-cutting ladder defined here, then adds its own counters, traces, and inspector tools.