DOCA Arg Parser

Where to start: This skill assumes DOCA is already installed and the user is doing hands-on CLI work on a DOCA sample or new DOCA-using app. Open TASKS.md if the user wants to do something (configure / build / modify / run / test / debug); open CAPABILITIES.md when the question is what can the Arg Parser express on this version. If the user has not installed DOCA yet, route to doca-setup first. If the user is about to rewrite a sample's CLI with getopt / argparse / custom parsing instead of reusing the Arg Parser, read the load-bearing rule in CAPABILITIES.md ## Capabilities and modes before any code change.

Example questions this skill answers well

The CLASSES of Arg Parser questions this skill is built to answer, each with one worked example. The agent should treat the class as the load-bearing piece — the worked example is a single instance.

• "How do I add a new flag to a DOCA sample without breaking the standard CLI?" — worked example: "add --my-flag to /opt/mellanox/doca/samples/doca_dma/dma_local_copy/ so the sample still accepts --device <PCI> and --sdk-log-level <level> the same way it did before". Answered by the reuse-the-Arg-Parser rule in CAPABILITIES.md ## Capabilities and modes
  • the register-before-start workflow in TASKS.md ## modify.
• "Why does doca_argp_param_set_* return BAD_STATE on my second call?" — worked example: "registering a new param after doca_argp_start has already parsed argv". Answered by the lifecycle order in CAPABILITIES.md ## Capabilities and modes
  • the error-taxonomy row in CAPABILITIES.md ## Error taxonomy for DOCA_ERROR_BAD_STATE.
• "Can I drive a sample from a JSON file instead of a long command line?" — worked example: "point a sample at ./my-config.json so the operator does not have to type out ten flags every time". Answered by the --json <path> integration in CAPABILITIES.md ## Capabilities and modes
  • the JSON-config-file workflow in TASKS.md ## modify and TASKS.md ## run.
• "My --my-flag X value is rejected as INVALID_VALUE — why?" — worked example: "declared the param as int but passed --my-flag 0x40". Answered by the parameter-type table in CAPABILITIES.md ## Capabilities and modes
  • the type-mismatch row in CAPABILITIES.md ## Error taxonomy.
• "Is doca-argp even on my installed DOCA?" — worked example: "a colleague's sample mentions doca-argp but I want to confirm before I depend on it". Answered by the presence
  • version-detection rule in CAPABILITIES.md ## Version compatibility, which cross-links the canonical detection chain in doca-version.
• "Should I use doca-argp here, or is this case actually outside its scope?" — worked example: "writing a host-side CLI tool that never calls a doca_* symbol". Answered by the path-selection rule in CAPABILITIES.md ## Capabilities and modes Use doca-argp when … / Do not use doca-argp when … bullets.

Audience

This skill serves external developers building or modifying DOCA-using applications — i.e., users whose code already calls doca_* (directly in C/C++, or through FFI/bindings from another language) and who need the standard DOCA CLI surface so operators of the resulting binary do not have to relearn how to invoke each sample. It is not for NVIDIA developers contributing to the Arg Parser library itself.

Language scope. DOCA Arg Parser ships as a C library with pkg-config module name doca-argp. The shipped samples are written in C. C and C++ consumers are the canonical case; the worked examples in TASKS.md assume that path. Other-language consumers (Rust, Go, Python, …) consume the same *.so through FFI or language-specific bindings; the skill's contribution in that case is to keep the lifecycle, parameter-type, JSON-config, standard-flag-surface, and error-taxonomy guidance language-neutral, and to route the agent to the public C ABI as the authoritative surface that any wrapper will eventually call.

When to load this skill

Load this skill when the user is doing hands-on DOCA Arg Parser work, in any language. Concretely:

• Adding, removing, or renaming a CLI flag on a shipped DOCA sample or on a new app that wants to share the standard DOCA CLI surface (--device <PCI>, --representor <name>, --rep-list, --json <path>, --sdk-log-level <level>).
• Wiring doca_argp_init / doca_argp_start / doca_argp_destroy into a main(), including the register-before-start lifecycle and the cleanup-on-exit contract.
• Registering a doca_argp_param (short name, long name, value callback, description for --help) with a parameter type drawn from the six-value public enum: string, int, boolean, device, device representor, or double. A JSON config file is an input surface for those parameters, not a parameter type.
• Reading complex configurations from a JSON file via the shared --json <path> flag instead of expanding the command line.
• Confirming the build- and runtime-side Arg Parser version on the user's install (pkg-config --exists doca-argp, pkg-config --modversion doca-argp) before depending on it.
• Debugging a DOCA_ERROR_* returned from a doca_argp_* call (lifecycle vs. type-mismatch vs. unknown JSON key vs. unreadable file).
• Designing or extending non-C bindings (Rust, Go, Python, …) that wrap the Arg Parser C ABI — for the lifecycle, parameter-type, JSON-config, and standard-flag rules the wrapper must honor.

Do not load this skill for general DOCA orientation, install of DOCA itself, or non-Arg-Parser library questions. For those, use doca-public-knowledge-map.

What this skill provides

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

• CAPABILITIES.md — what the Arg Parser can express on this version: the param-registration model, the small set of public parameter types, the standard DOCA CLI surface every sample shares, the --json <path> file integration, the register-before-start lifecycle, the Arg Parser error taxonomy (mapped onto the cross-library DOCA_ERROR_* set), the observability surface (the --help output and the DOCA Log channel), and the safety / path-selection policy (when reusing doca-argp is mandatory; when a language-native parser is the right answer).
• TASKS.md — step-by-step workflows for the six in-scope Arg Parser verbs: configure, build, modify, run, test, debug. Plus a Deferred task verbs block that points out-of-scope questions at the right next skill.

The skill assumes a host or BlueField where DOCA is already installed at the standard location. It does not cover installing DOCA — that path goes through doca-setup.

What this skill deliberately does not ship

This skill is agent guidance, not a samples or templates bundle. To keep the boundary clean, it deliberately does not contain — and pull requests should not add:

• Pre-written DOCA Arg Parser usage code, in any language. The verified Arg Parser usage is the *_main.c file in every shipped DOCA sample at /opt/mellanox/doca/samples/<library>/<sample>/. The agent's job is to route the user to that file and prescribe a minimum-diff modification on it via the universal modify-a-sample workflow in doca-programming-guide, layered with the Arg-Parser-specific overrides in TASKS.md ## modify.
• Standalone build manifests (meson.build, CMakeLists.txt, Cargo.toml, …) parked inside the skill. The agent constructs the build manifest in the user's project directory against the user's installed DOCA, where pkg-config --modversion doca-argp is the source of truth.
• A samples/, bindings/, or reference/ subtree of any kind. A mock or incomplete artifact in this skill's tree, even one labeled "reference", is misleading: users will read it as buildable.

Loading order

1. Read this SKILL.md first to confirm the user's question is in scope.
2. For the param-registration model, parameter types, the standard DOCA CLI surface, the --json <path> rule, the register-before-start lifecycle, error taxonomy, observability, and the path-selection / safety policy, see CAPABILITIES.md.
3. For step-by-step workflows — configure, build, modify, run, test, debug — see TASKS.md.

Both companion files cross-link to each other, doca-version for the canonical version-handling rules, and doca-public-knowledge-map whenever the right answer is "look it up in the public docs or the installed package layout" rather than "Arg-Parser-specific guidance".

Related skills

• doca-public-knowledge-map — the routing table for every public DOCA documentation source and the on-disk layout of an installed DOCA package. The Arg Parser URL is https://docs.nvidia.com/doca/sdk/DOCA-Arg-Parser/index.html; the canonical on-disk usage example is any sample's *_main.c under /opt/mellanox/doca/samples/.
• doca-setup — env preparation, install verification, and the I have no install yet path with the public NGC DOCA container. This skill assumes its preconditions are satisfied.
• doca-version — canonical DOCA version-handling rules. This skill's ## Version compatibility cross-links the four-way match rule and adds the Arg-Parser-specific presence-check overlay.
• doca-structured-tools-contract — the bundle's structured-tools precedence rule (detect / prefer / fall back / report). The Command appendix in TASKS.md honors this contract.
• doca-programming-guide — general DOCA programming patterns shared by every library: the canonical pkg-config + meson build pattern, the universal modify-a-shipped-sample first-app workflow, the universal lifecycle, the cross-library DOCA_ERROR_* taxonomy, and the program-side debug order. This skill layers Arg-Parser specifics on top.
• doca-debug — the cross-cutting debug ladder (install / version / build / link / runtime / program / driver). Arg-Parser-specific debug (lifecycle violations, type-mismatch on a registered param, unknown JSON key) overlays on top of that ladder.