[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill-nvidia-doca-mgmt":3,"mdc-5tdnbp-key":31,"related-org-nvidia-doca-mgmt":1482,"related-repo-nvidia-doca-mgmt":1643},{"slug":4,"name":4,"fn":5,"description":6,"org":7,"tags":11,"stars":20,"repoUrl":21,"updatedAt":22,"license":23,"forks":24,"topics":25,"repo":26,"sourceUrl":29,"mdContent":30},"doca-mgmt","program DOCA management and representor contexts","Use this skill when the user is doing hands-on DOCA Management programming against BlueField \u002F ConnectX devices — standing up a management or representor context (doca_mgmt_dev_ctx \u002F 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 \u002F DEBUG_READ_ONLY \u002F DEBUG_WRITE \u002F 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 \u002F firmware reflash, streaming telemetry, doca_caps CLI snapshots, or DOCA install itself — those belong to other skills.\n",{"slug":8,"name":9,"logoUrl":10,"githubOrg":9},"nvidia","NVIDIA","https:\u002F\u002Fpexgzepcugksgbtrxkhf.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Forg-logos\u002Fnvidia.png",[12,16,17],{"name":13,"slug":14,"type":15},"Operations","operations","tag",{"name":9,"slug":8,"type":15},{"name":18,"slug":19,"type":15},"Engineering","engineering",2473,"https:\u002F\u002Fgithub.com\u002FNVIDIA\u002Fskills","2026-07-20T06:24:24.885305","Apache-2.0",281,[],{"repoUrl":21,"stars":20,"forks":24,"topics":27,"description":28},[],"AI agent skills published by NVIDIA","https:\u002F\u002Fgithub.com\u002FNVIDIA\u002Fskills\u002Ftree\u002FHEAD\u002Fskills\u002Fdoca-mgmt","---\nlicense: Apache-2.0\nname: doca-mgmt\ndescription: >\n  Use this skill when the user is doing hands-on DOCA Management\n  programming against BlueField \u002F ConnectX devices — standing up a\n  management or representor context (doca_mgmt_dev_ctx \u002F\n  doca_mgmt_dev_rep_ctx), querying device caps (data-direct,\n  caps-general), toggling congestion-control global status, modifying\n  diagnostics-data, setting ICM quotas, or issuing a raw firmware\n  command via doca_mgmt_raw_cmd with the right scope (CONFIGURATION \u002F\n  DEBUG_READ_ONLY \u002F DEBUG_WRITE \u002F DEBUG_WRITE_FULL). Trigger even when\n  the user does not say \"DOCA Management\" — typical implicit phrasings\n  include \"fleet tool that walks every BlueField and reads device\n  state\", \"toggle data-direct on a VF\", \"set an ICM quota per\n  representor\", \"send a raw firmware command from C\",\n  \"DOCA_ERROR_IO_FAILED from raw_cmd\", or \"fwctl ioctl is failing\".\n  Refuse and route elsewhere for mlxconfig direct operation, BFB \u002F\n  firmware reflash, streaming telemetry, doca_caps CLI snapshots, or\n  DOCA install itself — those belong to other skills.\nmetadata:\n  kind: library\ncompatibility: >\n  Requires DOCA SDK installed at \u002Fopt\u002Fmellanox\u002Fdoca on Linux (Ubuntu\n  22.04\u002F24.04 or RHEL\u002FSLES) with a BlueField DPU or ConnectX NIC\n  attached. Reads the user's local install via `pkg-config doca-mgmt`\n  + `doca-common` and inspects\n  \u002Fopt\u002Fmellanox\u002Fdoca\u002F{lib,include,samples,applications}; runtime\n  operations require root (or device-admin\n  cap_*) and an \u002Fdev\u002Ffwctl* character device exposed by the host\n  kernel.\n---\n\n# DOCA Management\n\n**Where to start:** This skill assumes DOCA is already installed\nand the user is doing **hands-on management-plane work** against\na BlueField \u002F ConnectX device — typically a fleet-management or\norchestration tool that needs to query or modify device-level\nstate programmatically. Open [`TASKS.md`](TASKS.md) if the user\nwants to *do* something (install \u002F configure \u002F build \u002F modify \u002F\nrun \u002F test \u002F debug \u002F use); open [`CAPABILITIES.md`](CAPABILITIES.md)\nwhen the question is *what can doca-mgmt express on this version* —\nthe management context model, the raw-command scope ladder, the\nsub-domain surfaces (caps-general, cc-global-status, diagnostics-\ndata, icm-quota), version compatibility, and the safety overlay.\nIf the user has not installed DOCA yet, route to\n[`doca-setup`](..\u002F..\u002Fdoca-setup\u002FSKILL.md) first.\n\n## Example questions this skill answers well\n\nThe CLASSES of management-plane questions this skill is built to\nanswer, each with one worked example. The agent should treat the\n*class* as the load-bearing piece — the worked example is a\nsingle instance.\n\n- **\"Is `doca-mgmt` even the right surface, or do I want\n  telemetry \u002F bench \u002F caps?\"** — worked example: *\"I'm building a\n  fleet inventory tool — do I use doca-mgmt to query each\n  BlueField's data-direct capability, or doca-telemetry, or\n  doca_caps?\"*. Answered by the *management-plane vs\n  observability-plane vs read-only-CLI* selection rule in\n  [`CAPABILITIES.md ## Capabilities and modes`](CAPABILITIES.md#capabilities-and-modes)\n  surface-selection table.\n- **\"How do I stand up a management context on a device (and a\n  representor)?\"** — worked example: *\"open a `doca_mgmt_dev_ctx`\n  on the device, then a `doca_mgmt_dev_rep_ctx` on a specific\n  VF representor for caps-general programming\"*. Answered by\n  the management-context lifecycle in\n  [`CAPABILITIES.md ## Capabilities and modes`](CAPABILITIES.md#capabilities-and-modes)\n  + the configure walk in\n  [`TASKS.md ## configure`](TASKS.md#configure).\n- **\"How do I query a device capability — say, whether it\n  supports data-direct?\"** — worked example: *\"create a\n  caps-general handle, call `doca_mgmt_device_caps_general_get`\n  on the representor context, read the data-direct flag\"*.\n  Answered by the capability-query pattern in\n  [`CAPABILITIES.md ## Capabilities and modes`](CAPABILITIES.md#capabilities-and-modes)\n  + the test step in [`TASKS.md ## test`](TASKS.md#test).\n- **\"How do I modify a device-level feature flag safely?\"** —\n  worked example: *\"toggle `data_direct` on a representor;\n  capture pre-state, write, verify, prepare rollback\"*.\n  Answered by the apply-with-rollback workflow in\n  [`TASKS.md ## modify`](TASKS.md#modify) layered on the\n  bundle-wide hardware-safety meta-policy referenced from\n  [`CAPABILITIES.md ## Safety policy`](CAPABILITIES.md#safety-policy).\n- **\"What does the `doca_mgmt_raw_cmd` scope mean and which\n  scope should I use?\"** — worked example: *\"I have a vendor-\n  documented opcode for a `DEBUG_READ_ONLY` query — what scope\n  does that need and what is the blast radius?\"*. Answered by\n  the command-scope ladder in\n  [`CAPABILITIES.md ## Capabilities and modes`](CAPABILITIES.md#capabilities-and-modes)\n  + the raw-command verb in [`TASKS.md ## use`](TASKS.md#use).\n- **\"What does this `DOCA_ERROR_*` from a `doca_mgmt_*` call\n  mean and which layer caused it?\"** — worked example:\n  *\"`DOCA_ERROR_IO_FAILED` from `doca_mgmt_raw_cmd`\"*.\n  Answered by the mgmt overlay on the cross-library taxonomy\n  in [`CAPABILITIES.md ## Error taxonomy`](CAPABILITIES.md#error-taxonomy)\n  + the layered ladder in\n  [`TASKS.md ## debug`](TASKS.md#debug) that escalates to\n  [`doca-debug`](..\u002F..\u002Fdoca-debug\u002FSKILL.md) and to\n  [`doca-hardware-safety`](..\u002F..\u002Fdoca-hardware-safety\u002FSKILL.md)\n  when the cause is a device-state change.\n\n## Audience\n\nThis skill serves **external developers building fleet-management,\norchestration, or device-administration tools that programmatically\nquery and modify BlueField \u002F ConnectX device-level state** — i.e.,\nusers whose code calls `doca_mgmt_*` (directly in C\u002FC++, or\nthrough FFI\u002Fbindings from another language) to inspect device\ncapabilities, toggle device feature flags, query diagnostics\ncounters, set ICM quotas, or issue raw firmware-control commands.\nThe canonical caller is a fleet-management agent that walks every\nBlueField in a data center and applies a desired-state diff. This\nskill is *not* for NVIDIA developers contributing to DOCA\nManagement itself, and it is not the right surface for live\nperformance benchmarking or stream-based observability — those\nbelong to [`doca-bench`](..\u002F..\u002Ftools\u002Fdoca-bench\u002FSKILL.md),\n[`doca-telemetry`](..\u002Fdoca-telemetry\u002FSKILL.md), and\n[`doca-telemetry-exporter`](..\u002Fdoca-telemetry-exporter\u002FSKILL.md).\n\n## Language scope\n\nDOCA Management ships as a C library with the `pkg-config` module\nname `doca-mgmt`. The library's surface is C; the shipped samples\non a real install (where present) are C. C and C++ consumers are\nthe canonical case and the workflows in `TASKS.md` assume that\npath. Other-language consumers (Rust, Go, Python, …) consume the\nsame `*.so` library through FFI or language-specific bindings;\nthe skill's contribution in that case is to keep the management-\ncontext lifecycle, the command-scope ladder, the capability-query\npattern, the version-handling rule, and the safety overlay\nlanguage-neutral, and to route the agent to the public C ABI as\nthe authoritative surface that any wrapper will eventually call.\nThe skill does not author wrappers in any language.\n\n## When to load this skill\n\nLoad this skill when the user is doing **hands-on DOCA Management\nwork** on a host with one or more BlueField \u002F ConnectX devices.\nConcretely:\n\n- Standing up a `doca_mgmt_dev_ctx` on a `doca_dev` to inspect\n  or modify device-level state.\n- Standing up a `doca_mgmt_dev_rep_ctx` on a `doca_dev_rep` (or\n  via `doca_mgmt_dev_rep_ctx_create_by_pci_addr` when the\n  representor is not available) to inspect or modify a VF \u002F\n  function-level configuration.\n- Querying a device's general capabilities via\n  `doca_mgmt_device_caps_general_*` (data-direct support and\n  similar device-wide attributes).\n- Programming a representor's general capabilities via the same\n  `set` path.\n- Querying or modifying congestion-control global status via\n  `doca_mgmt_cc_global_status_*` (RP \u002F NP protocol type,\n  priority, enable \u002F disable).\n- Modifying or querying multi-domain diagnostics data via\n  `doca_mgmt_diagnostics_data_*` against a specific device.\n- Setting ICM quota limits per device or per representor via\n  `doca_mgmt_icm_quota_*` and reading the current allocation \u002F\n  max-reached.\n- Issuing a `doca_mgmt_raw_cmd` against the device's\n  firmware-control endpoint, choosing the right\n  `enum doca_mgmt_cmd_scope` for the operation's blast radius.\n- Debugging a `DOCA_ERROR_*` returned by a `doca_mgmt_*` call\n  and deciding whether the cause is a configuration mistake, a\n  lifecycle ordering bug, a missing capability on the device,\n  an `fwctl` ioctl failure, or a firmware-side rejection.\n\nDo **not** load this skill for general DOCA orientation, install\nof DOCA itself, live performance benchmarking, or stream-based\ntelemetry. For those, use\n[`doca-public-knowledge-map`](..\u002F..\u002Fdoca-public-knowledge-map\u002FSKILL.md),\n[`doca-setup`](..\u002F..\u002Fdoca-setup\u002FSKILL.md),\n[`doca-bench`](..\u002F..\u002Ftools\u002Fdoca-bench\u002FSKILL.md), and\n[`doca-telemetry`](..\u002Fdoca-telemetry\u002FSKILL.md) respectively.\n\n## What this skill provides\n\nThis is a **thin loader**. The body keeps only the orientation\nneeded to pick the right next file. The substantive\nmanagement-specific material lives in two companion files:\n\n- `CAPABILITIES.md` — what doca-mgmt can express on this\n  version: the management-context object model\n  (`doca_mgmt_dev_ctx` + `doca_mgmt_dev_rep_ctx`), the raw-\n  command scope ladder (`DOCA_MGMT_CMD_SCOPE_CONFIGURATION`,\n  `DOCA_MGMT_CMD_SCOPE_DEBUG_READ_ONLY`,\n  `DOCA_MGMT_CMD_SCOPE_DEBUG_WRITE`,\n  `DOCA_MGMT_CMD_SCOPE_DEBUG_WRITE_FULL`), the sub-domain\n  surfaces (caps-general, cc-global-status, diagnostics-data,\n  icm-quota) with their capability-query gates, the EXPERIMENTAL\n  symbol-set policy (every public `doca_mgmt_*` symbol is\n  tagged EXPERIMENTAL), the mgmt overlay on the cross-library\n  `DOCA_ERROR_*` taxonomy, the observability surface (pre-state\n  capture + post-write re-query), and the per-artifact safety\n  overlay on the bundle-wide hardware-safety meta-policy.\n- `TASKS.md` — step-by-step workflows for the eight in-scope\n  verbs: `install`, `configure`, `build`, `modify`, `run`,\n  `test`, `debug`, `use`. Plus a `Deferred task verbs` block\n  that points out-of-scope questions at the right next skill.\n\nThe skill assumes a host or BlueField where DOCA is already\ninstalled at the standard location and the user has the\nprivileges their public install profile expects (management-\nplane operations typically require root or an equivalent\ndevice-administration capability). It does not cover installing\nDOCA — that path goes through\n[`doca-setup`](..\u002F..\u002Fdoca-setup\u002FSKILL.md).\n\n## What this skill deliberately does not ship\n\nThis skill is **agent guidance**, not a samples or templates\nbundle. To keep the boundary clean, it deliberately does not\ncontain — and pull requests should not add:\n\n- **Pre-written DOCA Management application source code, in any\n  language.** Management-plane code touches device state and a\n  wrong write can take the device offline; authoring it from\n  documentation prose, especially against an EXPERIMENTAL\n  symbol set whose shape can change between releases, is\n  forbidden by this skill. The agent's job is to route the user\n  to verified reference code (the shipped DOCA samples on the\n  installed package set are the canonical worked examples) and\n  to prescribe a minimum-diff modification via the universal\n  modify-a-sample workflow in\n  [`doca-programming-guide`](..\u002F..\u002Fdoca-programming-guide\u002FSKILL.md).\n- **Standalone build manifests** parked inside the skill. The\n  agent constructs the build manifest *in the user's project\n  directory* against the user's installed DOCA, where\n  `pkg-config --modversion doca-mgmt` is the source of truth.\n- **Raw-command opcode catalogs.** The `doca_mgmt_raw_cmd`\n  in-payload and out-payload are device \u002F firmware specific;\n  the skill names the *scope* of a command class and the\n  *discipline* the agent applies (pre-state capture, scope\n  ladder, rollback path) but it does NOT enumerate opcodes —\n  those are vendor \u002F device documentation and looked up via\n  [`doca-public-knowledge-map`](..\u002F..\u002Fdoca-public-knowledge-map\u002FSKILL.md).\n- **A `samples\u002F`, `bindings\u002F`, or `reference\u002F` subtree** of any\n  kind. A mock or incomplete artifact in this skill's tree,\n  even one labeled \"reference\", is misleading: users will read\n  it as buildable.\n\n## Loading order\n\n1. Read this `SKILL.md` first to confirm the user's question is\n   in scope.\n2. **For the management-context object model, the raw-command\n   scope ladder, the sub-domain surfaces, version\n   compatibility, the error taxonomy, observability, and the\n   per-artifact safety overlay, see\n   [CAPABILITIES.md](CAPABILITIES.md).**\n3. **For step-by-step workflows — install, configure, build,\n   modify, run, test, debug, use — see [TASKS.md](TASKS.md).**\n\nBoth companion files cross-link to each other and to\n[`doca-public-knowledge-map`](..\u002F..\u002Fdoca-public-knowledge-map\u002FSKILL.md)\nwhenever the right answer is \"look it up in the public docs or\nthe installed package layout\" rather than \"mgmt-specific\nguidance\".\n\n## Related skills\n\n- [`doca-hardware-safety`](..\u002F..\u002Fdoca-hardware-safety\u002FSKILL.md) —\n  the bundle-wide hardware-safety meta-policy. Because\n  doca-mgmt is the surface through which agents most commonly\n  *modify* device state programmatically, the safety overlay\n  in `CAPABILITIES.md` cross-links the meta-policy\n  load-bearingly and the agent walks the hardware-safety\n  ladder whenever a write is recommended.\n- [`doca-telemetry`](..\u002Fdoca-telemetry\u002FSKILL.md) and\n  [`doca-telemetry-exporter`](..\u002Fdoca-telemetry-exporter\u002FSKILL.md) —\n  the observability surfaces for *streaming* telemetry from the\n  device. Use those when the user wants live metrics; use\n  doca-mgmt when the user wants point-in-time programmatic\n  query or modification.\n- [`doca-caps`](..\u002F..\u002Ftools\u002Fdoca-caps\u002FSKILL.md) — the\n  read-only CLI for inspecting device capabilities. Use the\n  tool when the user wants an interactive snapshot; use\n  doca-mgmt when the user wants the same information through\n  the C API in a fleet tool.\n- [`doca-bench`](..\u002F..\u002Ftools\u002Fdoca-bench\u002FSKILL.md) — the\n  live-performance benchmarking tool. Out of scope for\n  doca-mgmt; the skill names the boundary.\n- [`doca-pcc`](..\u002Fdoca-pcc\u002FSKILL.md) and\n  [`doca-pcc-counters`](..\u002F..\u002Ftools\u002Fdoca-pcc-counters\u002FSKILL.md) —\n  programmable congestion control. doca-mgmt's\n  `doca_mgmt_cc_global_status_*` surface is the *global\n  enable\u002Fdisable + protocol selection* control plane that\n  layers on the deeper programmable-CC surface owned by\n  doca-pcc.\n- [`doca-public-knowledge-map`](..\u002F..\u002Fdoca-public-knowledge-map\u002FSKILL.md) — the\n  routing table for every public DOCA documentation source and\n  the on-disk layout of an installed DOCA package.\n- [`doca-setup`](..\u002F..\u002Fdoca-setup\u002FSKILL.md) — env preparation,\n  install verification, and the *I have no install yet* path\n  with the public NGC DOCA container.\n- [`doca-programming-guide`](..\u002F..\u002Fdoca-programming-guide\u002FSKILL.md) —\n  general DOCA programming patterns shared by every library:\n  the canonical `pkg-config` + meson build pattern, the\n  universal modify-a-shipped-sample first-app workflow, the\n  cross-library `DOCA_ERROR_*` taxonomy. This skill layers\n  management-plane specifics on top.\n- [`doca-debug`](..\u002F..\u002Fdoca-debug\u002FSKILL.md) — the cross-cutting\n  debug ladder. Management-specific debug overlays on top of\n  it.\n- [`doca-version`](..\u002F..\u002Fdoca-version\u002FSKILL.md) — the version\n  detection \u002F four-way match rule every per-artifact `##\n  Version compatibility` anchor builds on. This skill quotes\n  the management-specific overlay only.\n- [`doca-structured-tools-contract`](..\u002F..\u002Fdoca-structured-tools-contract\u002FSKILL.md) —\n  the JSON-schema contracts for the agent-preferred structured\n  helpers; the `## Command appendix` in `TASKS.md` defers to\n  them before falling back to the manual chain.\n\n",{"data":32,"body":36},{"license":23,"name":4,"description":6,"metadata":33,"compatibility":35},{"kind":34},"library","Requires DOCA SDK installed at \u002Fopt\u002Fmellanox\u002Fdoca on Linux (Ubuntu 22.04\u002F24.04 or RHEL\u002FSLES) with a BlueField DPU or ConnectX NIC attached. Reads the user's local install via `pkg-config doca-mgmt` + `doca-common` and inspects \u002Fopt\u002Fmellanox\u002Fdoca\u002F{lib,include,samples,applications}; runtime operations require root (or device-admin cap_*) and an \u002Fdev\u002Ffwctl* character device exposed by the host kernel.\n",{"type":37,"children":38},"root",[39,48,118,125,137,504,510,571,577,612,618,630,791,841,847,859,1005,1019,1025,1037,1159,1165,1208,1223,1229],{"type":40,"tag":41,"props":42,"children":44},"element","h1",{"id":43},"doca-management",[45],{"type":46,"value":47},"text","DOCA Management",{"type":40,"tag":49,"props":50,"children":51},"p",{},[52,58,60,65,67,78,80,86,88,97,99,104,106,116],{"type":40,"tag":53,"props":54,"children":55},"strong",{},[56],{"type":46,"value":57},"Where to start:",{"type":46,"value":59}," This skill assumes DOCA is already installed\nand the user is doing ",{"type":40,"tag":53,"props":61,"children":62},{},[63],{"type":46,"value":64},"hands-on management-plane work",{"type":46,"value":66}," against\na BlueField \u002F ConnectX device — typically a fleet-management or\norchestration tool that needs to query or modify device-level\nstate programmatically. Open ",{"type":40,"tag":68,"props":69,"children":71},"a",{"href":70},"TASKS.md",[72],{"type":40,"tag":73,"props":74,"children":76},"code",{"className":75},[],[77],{"type":46,"value":70},{"type":46,"value":79}," if the user\nwants to ",{"type":40,"tag":81,"props":82,"children":83},"em",{},[84],{"type":46,"value":85},"do",{"type":46,"value":87}," something (install \u002F configure \u002F build \u002F modify \u002F\nrun \u002F test \u002F debug \u002F use); open ",{"type":40,"tag":68,"props":89,"children":91},{"href":90},"CAPABILITIES.md",[92],{"type":40,"tag":73,"props":93,"children":95},{"className":94},[],[96],{"type":46,"value":90},{"type":46,"value":98},"\nwhen the question is ",{"type":40,"tag":81,"props":100,"children":101},{},[102],{"type":46,"value":103},"what can doca-mgmt express on this version",{"type":46,"value":105}," —\nthe management context model, the raw-command scope ladder, the\nsub-domain surfaces (caps-general, cc-global-status, diagnostics-\ndata, icm-quota), version compatibility, and the safety overlay.\nIf the user has not installed DOCA yet, route to\n",{"type":40,"tag":68,"props":107,"children":109},{"href":108},"..\u002F..\u002Fdoca-setup\u002FSKILL.md",[110],{"type":40,"tag":73,"props":111,"children":113},{"className":112},[],[114],{"type":46,"value":115},"doca-setup",{"type":46,"value":117}," first.",{"type":40,"tag":119,"props":120,"children":122},"h2",{"id":121},"example-questions-this-skill-answers-well",[123],{"type":46,"value":124},"Example questions this skill answers well",{"type":40,"tag":49,"props":126,"children":127},{},[128,130,135],{"type":46,"value":129},"The CLASSES of management-plane questions this skill is built to\nanswer, each with one worked example. The agent should treat the\n",{"type":40,"tag":81,"props":131,"children":132},{},[133],{"type":46,"value":134},"class",{"type":46,"value":136}," as the load-bearing piece — the worked example is a\nsingle instance.",{"type":40,"tag":138,"props":139,"children":140},"ul",{},[141,185,245,296,344,403],{"type":40,"tag":142,"props":143,"children":144},"li",{},[145,157,159,164,166,171,173,183],{"type":40,"tag":53,"props":146,"children":147},{},[148,150,155],{"type":46,"value":149},"\"Is ",{"type":40,"tag":73,"props":151,"children":153},{"className":152},[],[154],{"type":46,"value":4},{"type":46,"value":156}," even the right surface, or do I want\ntelemetry \u002F bench \u002F caps?\"",{"type":46,"value":158}," — worked example: ",{"type":40,"tag":81,"props":160,"children":161},{},[162],{"type":46,"value":163},"\"I'm building a\nfleet inventory tool — do I use doca-mgmt to query each\nBlueField's data-direct capability, or doca-telemetry, or\ndoca_caps?\"",{"type":46,"value":165},". Answered by the ",{"type":40,"tag":81,"props":167,"children":168},{},[169],{"type":46,"value":170},"management-plane vs\nobservability-plane vs read-only-CLI",{"type":46,"value":172}," selection rule in\n",{"type":40,"tag":68,"props":174,"children":176},{"href":175},"CAPABILITIES.md#capabilities-and-modes",[177],{"type":40,"tag":73,"props":178,"children":180},{"className":179},[],[181],{"type":46,"value":182},"CAPABILITIES.md ## Capabilities and modes",{"type":46,"value":184},"\nsurface-selection table.",{"type":40,"tag":142,"props":186,"children":187},{},[188,193,194,215,217,225],{"type":40,"tag":53,"props":189,"children":190},{},[191],{"type":46,"value":192},"\"How do I stand up a management context on a device (and a\nrepresentor)?\"",{"type":46,"value":158},{"type":40,"tag":81,"props":195,"children":196},{},[197,199,205,207,213],{"type":46,"value":198},"\"open a ",{"type":40,"tag":73,"props":200,"children":202},{"className":201},[],[203],{"type":46,"value":204},"doca_mgmt_dev_ctx",{"type":46,"value":206},"\non the device, then a ",{"type":40,"tag":73,"props":208,"children":210},{"className":209},[],[211],{"type":46,"value":212},"doca_mgmt_dev_rep_ctx",{"type":46,"value":214}," on a specific\nVF representor for caps-general programming\"",{"type":46,"value":216},". Answered by\nthe management-context lifecycle in\n",{"type":40,"tag":68,"props":218,"children":219},{"href":175},[220],{"type":40,"tag":73,"props":221,"children":223},{"className":222},[],[224],{"type":46,"value":182},{"type":40,"tag":138,"props":226,"children":227},{},[228],{"type":40,"tag":142,"props":229,"children":230},{},[231,233,243],{"type":46,"value":232},"the configure walk in\n",{"type":40,"tag":68,"props":234,"children":236},{"href":235},"TASKS.md#configure",[237],{"type":40,"tag":73,"props":238,"children":240},{"className":239},[],[241],{"type":46,"value":242},"TASKS.md ## configure",{"type":46,"value":244},".",{"type":40,"tag":142,"props":246,"children":247},{},[248,253,254,267,269,277],{"type":40,"tag":53,"props":249,"children":250},{},[251],{"type":46,"value":252},"\"How do I query a device capability — say, whether it\nsupports data-direct?\"",{"type":46,"value":158},{"type":40,"tag":81,"props":255,"children":256},{},[257,259,265],{"type":46,"value":258},"\"create a\ncaps-general handle, call ",{"type":40,"tag":73,"props":260,"children":262},{"className":261},[],[263],{"type":46,"value":264},"doca_mgmt_device_caps_general_get",{"type":46,"value":266},"\non the representor context, read the data-direct flag\"",{"type":46,"value":268},".\nAnswered by the capability-query pattern in\n",{"type":40,"tag":68,"props":270,"children":271},{"href":175},[272],{"type":40,"tag":73,"props":273,"children":275},{"className":274},[],[276],{"type":46,"value":182},{"type":40,"tag":138,"props":278,"children":279},{},[280],{"type":40,"tag":142,"props":281,"children":282},{},[283,285,295],{"type":46,"value":284},"the test step in ",{"type":40,"tag":68,"props":286,"children":288},{"href":287},"TASKS.md#test",[289],{"type":40,"tag":73,"props":290,"children":292},{"className":291},[],[293],{"type":46,"value":294},"TASKS.md ## test",{"type":46,"value":244},{"type":40,"tag":142,"props":297,"children":298},{},[299,304,306,319,321,331,333,343],{"type":40,"tag":53,"props":300,"children":301},{},[302],{"type":46,"value":303},"\"How do I modify a device-level feature flag safely?\"",{"type":46,"value":305}," —\nworked example: ",{"type":40,"tag":81,"props":307,"children":308},{},[309,311,317],{"type":46,"value":310},"\"toggle ",{"type":40,"tag":73,"props":312,"children":314},{"className":313},[],[315],{"type":46,"value":316},"data_direct",{"type":46,"value":318}," on a representor;\ncapture pre-state, write, verify, prepare rollback\"",{"type":46,"value":320},".\nAnswered by the apply-with-rollback workflow in\n",{"type":40,"tag":68,"props":322,"children":324},{"href":323},"TASKS.md#modify",[325],{"type":40,"tag":73,"props":326,"children":328},{"className":327},[],[329],{"type":46,"value":330},"TASKS.md ## modify",{"type":46,"value":332}," layered on the\nbundle-wide hardware-safety meta-policy referenced from\n",{"type":40,"tag":68,"props":334,"children":336},{"href":335},"CAPABILITIES.md#safety-policy",[337],{"type":40,"tag":73,"props":338,"children":340},{"className":339},[],[341],{"type":46,"value":342},"CAPABILITIES.md ## Safety policy",{"type":46,"value":244},{"type":40,"tag":142,"props":345,"children":346},{},[347,360,361,374,376,384],{"type":40,"tag":53,"props":348,"children":349},{},[350,352,358],{"type":46,"value":351},"\"What does the ",{"type":40,"tag":73,"props":353,"children":355},{"className":354},[],[356],{"type":46,"value":357},"doca_mgmt_raw_cmd",{"type":46,"value":359}," scope mean and which\nscope should I use?\"",{"type":46,"value":158},{"type":40,"tag":81,"props":362,"children":363},{},[364,366,372],{"type":46,"value":365},"\"I have a vendor-\ndocumented opcode for a ",{"type":40,"tag":73,"props":367,"children":369},{"className":368},[],[370],{"type":46,"value":371},"DEBUG_READ_ONLY",{"type":46,"value":373}," query — what scope\ndoes that need and what is the blast radius?\"",{"type":46,"value":375},". Answered by\nthe command-scope ladder in\n",{"type":40,"tag":68,"props":377,"children":378},{"href":175},[379],{"type":40,"tag":73,"props":380,"children":382},{"className":381},[],[383],{"type":46,"value":182},{"type":40,"tag":138,"props":385,"children":386},{},[387],{"type":40,"tag":142,"props":388,"children":389},{},[390,392,402],{"type":46,"value":391},"the raw-command verb in ",{"type":40,"tag":68,"props":393,"children":395},{"href":394},"TASKS.md#use",[396],{"type":40,"tag":73,"props":397,"children":399},{"className":398},[],[400],{"type":46,"value":401},"TASKS.md ## use",{"type":46,"value":244},{"type":40,"tag":142,"props":404,"children":405},{},[406,427,429,448,450,460],{"type":40,"tag":53,"props":407,"children":408},{},[409,411,417,419,425],{"type":46,"value":410},"\"What does this ",{"type":40,"tag":73,"props":412,"children":414},{"className":413},[],[415],{"type":46,"value":416},"DOCA_ERROR_*",{"type":46,"value":418}," from a ",{"type":40,"tag":73,"props":420,"children":422},{"className":421},[],[423],{"type":46,"value":424},"doca_mgmt_*",{"type":46,"value":426}," call\nmean and which layer caused it?\"",{"type":46,"value":428}," — worked example:\n",{"type":40,"tag":81,"props":430,"children":431},{},[432,434,440,442,447],{"type":46,"value":433},"\"",{"type":40,"tag":73,"props":435,"children":437},{"className":436},[],[438],{"type":46,"value":439},"DOCA_ERROR_IO_FAILED",{"type":46,"value":441}," from ",{"type":40,"tag":73,"props":443,"children":445},{"className":444},[],[446],{"type":46,"value":357},{"type":46,"value":433},{"type":46,"value":449},".\nAnswered by the mgmt overlay on the cross-library taxonomy\nin ",{"type":40,"tag":68,"props":451,"children":453},{"href":452},"CAPABILITIES.md#error-taxonomy",[454],{"type":40,"tag":73,"props":455,"children":457},{"className":456},[],[458],{"type":46,"value":459},"CAPABILITIES.md ## Error taxonomy",{"type":40,"tag":138,"props":461,"children":462},{},[463],{"type":40,"tag":142,"props":464,"children":465},{},[466,468,478,480,490,492,502],{"type":46,"value":467},"the layered ladder in\n",{"type":40,"tag":68,"props":469,"children":471},{"href":470},"TASKS.md#debug",[472],{"type":40,"tag":73,"props":473,"children":475},{"className":474},[],[476],{"type":46,"value":477},"TASKS.md ## debug",{"type":46,"value":479}," that escalates to\n",{"type":40,"tag":68,"props":481,"children":483},{"href":482},"..\u002F..\u002Fdoca-debug\u002FSKILL.md",[484],{"type":40,"tag":73,"props":485,"children":487},{"className":486},[],[488],{"type":46,"value":489},"doca-debug",{"type":46,"value":491}," and to\n",{"type":40,"tag":68,"props":493,"children":495},{"href":494},"..\u002F..\u002Fdoca-hardware-safety\u002FSKILL.md",[496],{"type":40,"tag":73,"props":497,"children":499},{"className":498},[],[500],{"type":46,"value":501},"doca-hardware-safety",{"type":46,"value":503},"\nwhen the cause is a device-state change.",{"type":40,"tag":119,"props":505,"children":507},{"id":506},"audience",[508],{"type":46,"value":509},"Audience",{"type":40,"tag":49,"props":511,"children":512},{},[513,515,520,522,527,529,534,536,546,548,558,560,570],{"type":46,"value":514},"This skill serves ",{"type":40,"tag":53,"props":516,"children":517},{},[518],{"type":46,"value":519},"external developers building fleet-management,\norchestration, or device-administration tools that programmatically\nquery and modify BlueField \u002F ConnectX device-level state",{"type":46,"value":521}," — i.e.,\nusers whose code calls ",{"type":40,"tag":73,"props":523,"children":525},{"className":524},[],[526],{"type":46,"value":424},{"type":46,"value":528}," (directly in C\u002FC++, or\nthrough FFI\u002Fbindings from another language) to inspect device\ncapabilities, toggle device feature flags, query diagnostics\ncounters, set ICM quotas, or issue raw firmware-control commands.\nThe canonical caller is a fleet-management agent that walks every\nBlueField in a data center and applies a desired-state diff. This\nskill is ",{"type":40,"tag":81,"props":530,"children":531},{},[532],{"type":46,"value":533},"not",{"type":46,"value":535}," for NVIDIA developers contributing to DOCA\nManagement itself, and it is not the right surface for live\nperformance benchmarking or stream-based observability — those\nbelong to ",{"type":40,"tag":68,"props":537,"children":539},{"href":538},"..\u002F..\u002Ftools\u002Fdoca-bench\u002FSKILL.md",[540],{"type":40,"tag":73,"props":541,"children":543},{"className":542},[],[544],{"type":46,"value":545},"doca-bench",{"type":46,"value":547},",\n",{"type":40,"tag":68,"props":549,"children":551},{"href":550},"..\u002Fdoca-telemetry\u002FSKILL.md",[552],{"type":40,"tag":73,"props":553,"children":555},{"className":554},[],[556],{"type":46,"value":557},"doca-telemetry",{"type":46,"value":559},", and\n",{"type":40,"tag":68,"props":561,"children":563},{"href":562},"..\u002Fdoca-telemetry-exporter\u002FSKILL.md",[564],{"type":40,"tag":73,"props":565,"children":567},{"className":566},[],[568],{"type":46,"value":569},"doca-telemetry-exporter",{"type":46,"value":244},{"type":40,"tag":119,"props":572,"children":574},{"id":573},"language-scope",[575],{"type":46,"value":576},"Language scope",{"type":40,"tag":49,"props":578,"children":579},{},[580,582,588,590,595,597,602,604,610],{"type":46,"value":581},"DOCA Management ships as a C library with the ",{"type":40,"tag":73,"props":583,"children":585},{"className":584},[],[586],{"type":46,"value":587},"pkg-config",{"type":46,"value":589}," module\nname ",{"type":40,"tag":73,"props":591,"children":593},{"className":592},[],[594],{"type":46,"value":4},{"type":46,"value":596},". The library's surface is C; the shipped samples\non a real install (where present) are C. C and C++ consumers are\nthe canonical case and the workflows in ",{"type":40,"tag":73,"props":598,"children":600},{"className":599},[],[601],{"type":46,"value":70},{"type":46,"value":603}," assume that\npath. Other-language consumers (Rust, Go, Python, …) consume the\nsame ",{"type":40,"tag":73,"props":605,"children":607},{"className":606},[],[608],{"type":46,"value":609},"*.so",{"type":46,"value":611}," library through FFI or language-specific bindings;\nthe skill's contribution in that case is to keep the management-\ncontext lifecycle, the command-scope ladder, the capability-query\npattern, the version-handling rule, and the safety overlay\nlanguage-neutral, and to route the agent to the public C ABI as\nthe authoritative surface that any wrapper will eventually call.\nThe skill does not author wrappers in any language.",{"type":40,"tag":119,"props":613,"children":615},{"id":614},"when-to-load-this-skill",[616],{"type":46,"value":617},"When to load this skill",{"type":40,"tag":49,"props":619,"children":620},{},[621,623,628],{"type":46,"value":622},"Load this skill when the user is doing ",{"type":40,"tag":53,"props":624,"children":625},{},[626],{"type":46,"value":627},"hands-on DOCA Management\nwork",{"type":46,"value":629}," on a host with one or more BlueField \u002F ConnectX devices.\nConcretely:",{"type":40,"tag":138,"props":631,"children":632},{},[633,653,679,692,705,718,731,744,764],{"type":40,"tag":142,"props":634,"children":635},{},[636,638,643,645,651],{"type":46,"value":637},"Standing up a ",{"type":40,"tag":73,"props":639,"children":641},{"className":640},[],[642],{"type":46,"value":204},{"type":46,"value":644}," on a ",{"type":40,"tag":73,"props":646,"children":648},{"className":647},[],[649],{"type":46,"value":650},"doca_dev",{"type":46,"value":652}," to inspect\nor modify device-level state.",{"type":40,"tag":142,"props":654,"children":655},{},[656,657,662,663,669,671,677],{"type":46,"value":637},{"type":40,"tag":73,"props":658,"children":660},{"className":659},[],[661],{"type":46,"value":212},{"type":46,"value":644},{"type":40,"tag":73,"props":664,"children":666},{"className":665},[],[667],{"type":46,"value":668},"doca_dev_rep",{"type":46,"value":670}," (or\nvia ",{"type":40,"tag":73,"props":672,"children":674},{"className":673},[],[675],{"type":46,"value":676},"doca_mgmt_dev_rep_ctx_create_by_pci_addr",{"type":46,"value":678}," when the\nrepresentor is not available) to inspect or modify a VF \u002F\nfunction-level configuration.",{"type":40,"tag":142,"props":680,"children":681},{},[682,684,690],{"type":46,"value":683},"Querying a device's general capabilities via\n",{"type":40,"tag":73,"props":685,"children":687},{"className":686},[],[688],{"type":46,"value":689},"doca_mgmt_device_caps_general_*",{"type":46,"value":691}," (data-direct support and\nsimilar device-wide attributes).",{"type":40,"tag":142,"props":693,"children":694},{},[695,697,703],{"type":46,"value":696},"Programming a representor's general capabilities via the same\n",{"type":40,"tag":73,"props":698,"children":700},{"className":699},[],[701],{"type":46,"value":702},"set",{"type":46,"value":704}," path.",{"type":40,"tag":142,"props":706,"children":707},{},[708,710,716],{"type":46,"value":709},"Querying or modifying congestion-control global status via\n",{"type":40,"tag":73,"props":711,"children":713},{"className":712},[],[714],{"type":46,"value":715},"doca_mgmt_cc_global_status_*",{"type":46,"value":717}," (RP \u002F NP protocol type,\npriority, enable \u002F disable).",{"type":40,"tag":142,"props":719,"children":720},{},[721,723,729],{"type":46,"value":722},"Modifying or querying multi-domain diagnostics data via\n",{"type":40,"tag":73,"props":724,"children":726},{"className":725},[],[727],{"type":46,"value":728},"doca_mgmt_diagnostics_data_*",{"type":46,"value":730}," against a specific device.",{"type":40,"tag":142,"props":732,"children":733},{},[734,736,742],{"type":46,"value":735},"Setting ICM quota limits per device or per representor via\n",{"type":40,"tag":73,"props":737,"children":739},{"className":738},[],[740],{"type":46,"value":741},"doca_mgmt_icm_quota_*",{"type":46,"value":743}," and reading the current allocation \u002F\nmax-reached.",{"type":40,"tag":142,"props":745,"children":746},{},[747,749,754,756,762],{"type":46,"value":748},"Issuing a ",{"type":40,"tag":73,"props":750,"children":752},{"className":751},[],[753],{"type":46,"value":357},{"type":46,"value":755}," against the device's\nfirmware-control endpoint, choosing the right\n",{"type":40,"tag":73,"props":757,"children":759},{"className":758},[],[760],{"type":46,"value":761},"enum doca_mgmt_cmd_scope",{"type":46,"value":763}," for the operation's blast radius.",{"type":40,"tag":142,"props":765,"children":766},{},[767,769,774,776,781,783,789],{"type":46,"value":768},"Debugging a ",{"type":40,"tag":73,"props":770,"children":772},{"className":771},[],[773],{"type":46,"value":416},{"type":46,"value":775}," returned by a ",{"type":40,"tag":73,"props":777,"children":779},{"className":778},[],[780],{"type":46,"value":424},{"type":46,"value":782}," call\nand deciding whether the cause is a configuration mistake, a\nlifecycle ordering bug, a missing capability on the device,\nan ",{"type":40,"tag":73,"props":784,"children":786},{"className":785},[],[787],{"type":46,"value":788},"fwctl",{"type":46,"value":790}," ioctl failure, or a firmware-side rejection.",{"type":40,"tag":49,"props":792,"children":793},{},[794,796,800,802,812,813,821,822,830,831,839],{"type":46,"value":795},"Do ",{"type":40,"tag":53,"props":797,"children":798},{},[799],{"type":46,"value":533},{"type":46,"value":801}," load this skill for general DOCA orientation, install\nof DOCA itself, live performance benchmarking, or stream-based\ntelemetry. For those, use\n",{"type":40,"tag":68,"props":803,"children":805},{"href":804},"..\u002F..\u002Fdoca-public-knowledge-map\u002FSKILL.md",[806],{"type":40,"tag":73,"props":807,"children":809},{"className":808},[],[810],{"type":46,"value":811},"doca-public-knowledge-map",{"type":46,"value":547},{"type":40,"tag":68,"props":814,"children":815},{"href":108},[816],{"type":40,"tag":73,"props":817,"children":819},{"className":818},[],[820],{"type":46,"value":115},{"type":46,"value":547},{"type":40,"tag":68,"props":823,"children":824},{"href":538},[825],{"type":40,"tag":73,"props":826,"children":828},{"className":827},[],[829],{"type":46,"value":545},{"type":46,"value":559},{"type":40,"tag":68,"props":832,"children":833},{"href":550},[834],{"type":40,"tag":73,"props":835,"children":837},{"className":836},[],[838],{"type":46,"value":557},{"type":46,"value":840}," respectively.",{"type":40,"tag":119,"props":842,"children":844},{"id":843},"what-this-skill-provides",[845],{"type":46,"value":846},"What this skill provides",{"type":40,"tag":49,"props":848,"children":849},{},[850,852,857],{"type":46,"value":851},"This is a ",{"type":40,"tag":53,"props":853,"children":854},{},[855],{"type":46,"value":856},"thin loader",{"type":46,"value":858},". The body keeps only the orientation\nneeded to pick the right next file. The substantive\nmanagement-specific material lives in two companion files:",{"type":40,"tag":138,"props":860,"children":861},{},[862,929],{"type":40,"tag":142,"props":863,"children":864},{},[865,870,872,877,879,884,886,892,893,899,900,906,907,913,915,920,922,927],{"type":40,"tag":73,"props":866,"children":868},{"className":867},[],[869],{"type":46,"value":90},{"type":46,"value":871}," — what doca-mgmt can express on this\nversion: the management-context object model\n(",{"type":40,"tag":73,"props":873,"children":875},{"className":874},[],[876],{"type":46,"value":204},{"type":46,"value":878}," + ",{"type":40,"tag":73,"props":880,"children":882},{"className":881},[],[883],{"type":46,"value":212},{"type":46,"value":885},"), the raw-\ncommand scope ladder (",{"type":40,"tag":73,"props":887,"children":889},{"className":888},[],[890],{"type":46,"value":891},"DOCA_MGMT_CMD_SCOPE_CONFIGURATION",{"type":46,"value":547},{"type":40,"tag":73,"props":894,"children":896},{"className":895},[],[897],{"type":46,"value":898},"DOCA_MGMT_CMD_SCOPE_DEBUG_READ_ONLY",{"type":46,"value":547},{"type":40,"tag":73,"props":901,"children":903},{"className":902},[],[904],{"type":46,"value":905},"DOCA_MGMT_CMD_SCOPE_DEBUG_WRITE",{"type":46,"value":547},{"type":40,"tag":73,"props":908,"children":910},{"className":909},[],[911],{"type":46,"value":912},"DOCA_MGMT_CMD_SCOPE_DEBUG_WRITE_FULL",{"type":46,"value":914},"), the sub-domain\nsurfaces (caps-general, cc-global-status, diagnostics-data,\nicm-quota) with their capability-query gates, the EXPERIMENTAL\nsymbol-set policy (every public ",{"type":40,"tag":73,"props":916,"children":918},{"className":917},[],[919],{"type":46,"value":424},{"type":46,"value":921}," symbol is\ntagged EXPERIMENTAL), the mgmt overlay on the cross-library\n",{"type":40,"tag":73,"props":923,"children":925},{"className":924},[],[926],{"type":46,"value":416},{"type":46,"value":928}," taxonomy, the observability surface (pre-state\ncapture + post-write re-query), and the per-artifact safety\noverlay on the bundle-wide hardware-safety meta-policy.",{"type":40,"tag":142,"props":930,"children":931},{},[932,937,939,945,947,953,954,960,961,967,968,974,975,981,982,988,989,995,997,1003],{"type":40,"tag":73,"props":933,"children":935},{"className":934},[],[936],{"type":46,"value":70},{"type":46,"value":938}," — step-by-step workflows for the eight in-scope\nverbs: ",{"type":40,"tag":73,"props":940,"children":942},{"className":941},[],[943],{"type":46,"value":944},"install",{"type":46,"value":946},", ",{"type":40,"tag":73,"props":948,"children":950},{"className":949},[],[951],{"type":46,"value":952},"configure",{"type":46,"value":946},{"type":40,"tag":73,"props":955,"children":957},{"className":956},[],[958],{"type":46,"value":959},"build",{"type":46,"value":946},{"type":40,"tag":73,"props":962,"children":964},{"className":963},[],[965],{"type":46,"value":966},"modify",{"type":46,"value":946},{"type":40,"tag":73,"props":969,"children":971},{"className":970},[],[972],{"type":46,"value":973},"run",{"type":46,"value":547},{"type":40,"tag":73,"props":976,"children":978},{"className":977},[],[979],{"type":46,"value":980},"test",{"type":46,"value":946},{"type":40,"tag":73,"props":983,"children":985},{"className":984},[],[986],{"type":46,"value":987},"debug",{"type":46,"value":946},{"type":40,"tag":73,"props":990,"children":992},{"className":991},[],[993],{"type":46,"value":994},"use",{"type":46,"value":996},". Plus a ",{"type":40,"tag":73,"props":998,"children":1000},{"className":999},[],[1001],{"type":46,"value":1002},"Deferred task verbs",{"type":46,"value":1004}," block\nthat points out-of-scope questions at the right next skill.",{"type":40,"tag":49,"props":1006,"children":1007},{},[1008,1010,1018],{"type":46,"value":1009},"The skill assumes a host or BlueField where DOCA is already\ninstalled at the standard location and the user has the\nprivileges their public install profile expects (management-\nplane operations typically require root or an equivalent\ndevice-administration capability). It does not cover installing\nDOCA — that path goes through\n",{"type":40,"tag":68,"props":1011,"children":1012},{"href":108},[1013],{"type":40,"tag":73,"props":1014,"children":1016},{"className":1015},[],[1017],{"type":46,"value":115},{"type":46,"value":244},{"type":40,"tag":119,"props":1020,"children":1022},{"id":1021},"what-this-skill-deliberately-does-not-ship",[1023],{"type":46,"value":1024},"What this skill deliberately does not ship",{"type":40,"tag":49,"props":1026,"children":1027},{},[1028,1030,1035],{"type":46,"value":1029},"This skill is ",{"type":40,"tag":53,"props":1031,"children":1032},{},[1033],{"type":46,"value":1034},"agent guidance",{"type":46,"value":1036},", not a samples or templates\nbundle. To keep the boundary clean, it deliberately does not\ncontain — and pull requests should not add:",{"type":40,"tag":138,"props":1038,"children":1039},{},[1040,1061,1086,1126],{"type":40,"tag":142,"props":1041,"children":1042},{},[1043,1048,1050,1060],{"type":40,"tag":53,"props":1044,"children":1045},{},[1046],{"type":46,"value":1047},"Pre-written DOCA Management application source code, in any\nlanguage.",{"type":46,"value":1049}," Management-plane code touches device state and a\nwrong write can take the device offline; authoring it from\ndocumentation prose, especially against an EXPERIMENTAL\nsymbol set whose shape can change between releases, is\nforbidden by this skill. The agent's job is to route the user\nto verified reference code (the shipped DOCA samples on the\ninstalled package set are the canonical worked examples) and\nto prescribe a minimum-diff modification via the universal\nmodify-a-sample workflow in\n",{"type":40,"tag":68,"props":1051,"children":1053},{"href":1052},"..\u002F..\u002Fdoca-programming-guide\u002FSKILL.md",[1054],{"type":40,"tag":73,"props":1055,"children":1057},{"className":1056},[],[1058],{"type":46,"value":1059},"doca-programming-guide",{"type":46,"value":244},{"type":40,"tag":142,"props":1062,"children":1063},{},[1064,1069,1071,1076,1078,1084],{"type":40,"tag":53,"props":1065,"children":1066},{},[1067],{"type":46,"value":1068},"Standalone build manifests",{"type":46,"value":1070}," parked inside the skill. The\nagent constructs the build manifest ",{"type":40,"tag":81,"props":1072,"children":1073},{},[1074],{"type":46,"value":1075},"in the user's project\ndirectory",{"type":46,"value":1077}," against the user's installed DOCA, where\n",{"type":40,"tag":73,"props":1079,"children":1081},{"className":1080},[],[1082],{"type":46,"value":1083},"pkg-config --modversion doca-mgmt",{"type":46,"value":1085}," is the source of truth.",{"type":40,"tag":142,"props":1087,"children":1088},{},[1089,1094,1096,1101,1103,1108,1110,1115,1117,1125],{"type":40,"tag":53,"props":1090,"children":1091},{},[1092],{"type":46,"value":1093},"Raw-command opcode catalogs.",{"type":46,"value":1095}," The ",{"type":40,"tag":73,"props":1097,"children":1099},{"className":1098},[],[1100],{"type":46,"value":357},{"type":46,"value":1102},"\nin-payload and out-payload are device \u002F firmware specific;\nthe skill names the ",{"type":40,"tag":81,"props":1104,"children":1105},{},[1106],{"type":46,"value":1107},"scope",{"type":46,"value":1109}," of a command class and the\n",{"type":40,"tag":81,"props":1111,"children":1112},{},[1113],{"type":46,"value":1114},"discipline",{"type":46,"value":1116}," the agent applies (pre-state capture, scope\nladder, rollback path) but it does NOT enumerate opcodes —\nthose are vendor \u002F device documentation and looked up via\n",{"type":40,"tag":68,"props":1118,"children":1119},{"href":804},[1120],{"type":40,"tag":73,"props":1121,"children":1123},{"className":1122},[],[1124],{"type":46,"value":811},{"type":46,"value":244},{"type":40,"tag":142,"props":1127,"children":1128},{},[1129,1157],{"type":40,"tag":53,"props":1130,"children":1131},{},[1132,1134,1140,1141,1147,1149,1155],{"type":46,"value":1133},"A ",{"type":40,"tag":73,"props":1135,"children":1137},{"className":1136},[],[1138],{"type":46,"value":1139},"samples\u002F",{"type":46,"value":946},{"type":40,"tag":73,"props":1142,"children":1144},{"className":1143},[],[1145],{"type":46,"value":1146},"bindings\u002F",{"type":46,"value":1148},", or ",{"type":40,"tag":73,"props":1150,"children":1152},{"className":1151},[],[1153],{"type":46,"value":1154},"reference\u002F",{"type":46,"value":1156}," subtree",{"type":46,"value":1158}," of any\nkind. A mock or incomplete artifact in this skill's tree,\neven one labeled \"reference\", is misleading: users will read\nit as buildable.",{"type":40,"tag":119,"props":1160,"children":1162},{"id":1161},"loading-order",[1163],{"type":46,"value":1164},"Loading order",{"type":40,"tag":1166,"props":1167,"children":1168},"ol",{},[1169,1182,1195],{"type":40,"tag":142,"props":1170,"children":1171},{},[1172,1174,1180],{"type":46,"value":1173},"Read this ",{"type":40,"tag":73,"props":1175,"children":1177},{"className":1176},[],[1178],{"type":46,"value":1179},"SKILL.md",{"type":46,"value":1181}," first to confirm the user's question is\nin scope.",{"type":40,"tag":142,"props":1183,"children":1184},{},[1185],{"type":40,"tag":53,"props":1186,"children":1187},{},[1188,1190,1194],{"type":46,"value":1189},"For the management-context object model, the raw-command\nscope ladder, the sub-domain surfaces, version\ncompatibility, the error taxonomy, observability, and the\nper-artifact safety overlay, see\n",{"type":40,"tag":68,"props":1191,"children":1192},{"href":90},[1193],{"type":46,"value":90},{"type":46,"value":244},{"type":40,"tag":142,"props":1196,"children":1197},{},[1198],{"type":40,"tag":53,"props":1199,"children":1200},{},[1201,1203,1207],{"type":46,"value":1202},"For step-by-step workflows — install, configure, build,\nmodify, run, test, debug, use — see ",{"type":40,"tag":68,"props":1204,"children":1205},{"href":70},[1206],{"type":46,"value":70},{"type":46,"value":244},{"type":40,"tag":49,"props":1209,"children":1210},{},[1211,1213,1221],{"type":46,"value":1212},"Both companion files cross-link to each other and to\n",{"type":40,"tag":68,"props":1214,"children":1215},{"href":804},[1216],{"type":40,"tag":73,"props":1217,"children":1219},{"className":1218},[],[1220],{"type":46,"value":811},{"type":46,"value":1222},"\nwhenever the right answer is \"look it up in the public docs or\nthe installed package layout\" rather than \"mgmt-specific\nguidance\".",{"type":40,"tag":119,"props":1224,"children":1226},{"id":1225},"related-skills",[1227],{"type":46,"value":1228},"Related skills",{"type":40,"tag":138,"props":1230,"children":1231},{},[1232,1258,1288,1303,1316,1356,1369,1389,1416,1429,1452],{"type":40,"tag":142,"props":1233,"children":1234},{},[1235,1243,1245,1249,1251,1256],{"type":40,"tag":68,"props":1236,"children":1237},{"href":494},[1238],{"type":40,"tag":73,"props":1239,"children":1241},{"className":1240},[],[1242],{"type":46,"value":501},{"type":46,"value":1244}," —\nthe bundle-wide hardware-safety meta-policy. Because\ndoca-mgmt is the surface through which agents most commonly\n",{"type":40,"tag":81,"props":1246,"children":1247},{},[1248],{"type":46,"value":966},{"type":46,"value":1250}," device state programmatically, the safety overlay\nin ",{"type":40,"tag":73,"props":1252,"children":1254},{"className":1253},[],[1255],{"type":46,"value":90},{"type":46,"value":1257}," cross-links the meta-policy\nload-bearingly and the agent walks the hardware-safety\nladder whenever a write is recommended.",{"type":40,"tag":142,"props":1259,"children":1260},{},[1261,1269,1271,1279,1281,1286],{"type":40,"tag":68,"props":1262,"children":1263},{"href":550},[1264],{"type":40,"tag":73,"props":1265,"children":1267},{"className":1266},[],[1268],{"type":46,"value":557},{"type":46,"value":1270}," and\n",{"type":40,"tag":68,"props":1272,"children":1273},{"href":562},[1274],{"type":40,"tag":73,"props":1275,"children":1277},{"className":1276},[],[1278],{"type":46,"value":569},{"type":46,"value":1280}," —\nthe observability surfaces for ",{"type":40,"tag":81,"props":1282,"children":1283},{},[1284],{"type":46,"value":1285},"streaming",{"type":46,"value":1287}," telemetry from the\ndevice. Use those when the user wants live metrics; use\ndoca-mgmt when the user wants point-in-time programmatic\nquery or modification.",{"type":40,"tag":142,"props":1289,"children":1290},{},[1291,1301],{"type":40,"tag":68,"props":1292,"children":1294},{"href":1293},"..\u002F..\u002Ftools\u002Fdoca-caps\u002FSKILL.md",[1295],{"type":40,"tag":73,"props":1296,"children":1298},{"className":1297},[],[1299],{"type":46,"value":1300},"doca-caps",{"type":46,"value":1302}," — the\nread-only CLI for inspecting device capabilities. Use the\ntool when the user wants an interactive snapshot; use\ndoca-mgmt when the user wants the same information through\nthe C API in a fleet tool.",{"type":40,"tag":142,"props":1304,"children":1305},{},[1306,1314],{"type":40,"tag":68,"props":1307,"children":1308},{"href":538},[1309],{"type":40,"tag":73,"props":1310,"children":1312},{"className":1311},[],[1313],{"type":46,"value":545},{"type":46,"value":1315}," — the\nlive-performance benchmarking tool. Out of scope for\ndoca-mgmt; the skill names the boundary.",{"type":40,"tag":142,"props":1317,"children":1318},{},[1319,1329,1330,1340,1342,1347,1349,1354],{"type":40,"tag":68,"props":1320,"children":1322},{"href":1321},"..\u002Fdoca-pcc\u002FSKILL.md",[1323],{"type":40,"tag":73,"props":1324,"children":1326},{"className":1325},[],[1327],{"type":46,"value":1328},"doca-pcc",{"type":46,"value":1270},{"type":40,"tag":68,"props":1331,"children":1333},{"href":1332},"..\u002F..\u002Ftools\u002Fdoca-pcc-counters\u002FSKILL.md",[1334],{"type":40,"tag":73,"props":1335,"children":1337},{"className":1336},[],[1338],{"type":46,"value":1339},"doca-pcc-counters",{"type":46,"value":1341}," —\nprogrammable congestion control. doca-mgmt's\n",{"type":40,"tag":73,"props":1343,"children":1345},{"className":1344},[],[1346],{"type":46,"value":715},{"type":46,"value":1348}," surface is the ",{"type":40,"tag":81,"props":1350,"children":1351},{},[1352],{"type":46,"value":1353},"global\nenable\u002Fdisable + protocol selection",{"type":46,"value":1355}," control plane that\nlayers on the deeper programmable-CC surface owned by\ndoca-pcc.",{"type":40,"tag":142,"props":1357,"children":1358},{},[1359,1367],{"type":40,"tag":68,"props":1360,"children":1361},{"href":804},[1362],{"type":40,"tag":73,"props":1363,"children":1365},{"className":1364},[],[1366],{"type":46,"value":811},{"type":46,"value":1368}," — the\nrouting table for every public DOCA documentation source and\nthe on-disk layout of an installed DOCA package.",{"type":40,"tag":142,"props":1370,"children":1371},{},[1372,1380,1382,1387],{"type":40,"tag":68,"props":1373,"children":1374},{"href":108},[1375],{"type":40,"tag":73,"props":1376,"children":1378},{"className":1377},[],[1379],{"type":46,"value":115},{"type":46,"value":1381}," — env preparation,\ninstall verification, and the ",{"type":40,"tag":81,"props":1383,"children":1384},{},[1385],{"type":46,"value":1386},"I have no install yet",{"type":46,"value":1388}," path\nwith the public NGC DOCA container.",{"type":40,"tag":142,"props":1390,"children":1391},{},[1392,1400,1402,1407,1409,1414],{"type":40,"tag":68,"props":1393,"children":1394},{"href":1052},[1395],{"type":40,"tag":73,"props":1396,"children":1398},{"className":1397},[],[1399],{"type":46,"value":1059},{"type":46,"value":1401}," —\ngeneral DOCA programming patterns shared by every library:\nthe canonical ",{"type":40,"tag":73,"props":1403,"children":1405},{"className":1404},[],[1406],{"type":46,"value":587},{"type":46,"value":1408}," + meson build pattern, the\nuniversal modify-a-shipped-sample first-app workflow, the\ncross-library ",{"type":40,"tag":73,"props":1410,"children":1412},{"className":1411},[],[1413],{"type":46,"value":416},{"type":46,"value":1415}," taxonomy. This skill layers\nmanagement-plane specifics on top.",{"type":40,"tag":142,"props":1417,"children":1418},{},[1419,1427],{"type":40,"tag":68,"props":1420,"children":1421},{"href":482},[1422],{"type":40,"tag":73,"props":1423,"children":1425},{"className":1424},[],[1426],{"type":46,"value":489},{"type":46,"value":1428}," — the cross-cutting\ndebug ladder. Management-specific debug overlays on top of\nit.",{"type":40,"tag":142,"props":1430,"children":1431},{},[1432,1442,1444,1450],{"type":40,"tag":68,"props":1433,"children":1435},{"href":1434},"..\u002F..\u002Fdoca-version\u002FSKILL.md",[1436],{"type":40,"tag":73,"props":1437,"children":1439},{"className":1438},[],[1440],{"type":46,"value":1441},"doca-version",{"type":46,"value":1443}," — the version\ndetection \u002F four-way match rule every per-artifact ",{"type":40,"tag":73,"props":1445,"children":1447},{"className":1446},[],[1448],{"type":46,"value":1449},"## Version compatibility",{"type":46,"value":1451}," anchor builds on. This skill quotes\nthe management-specific overlay only.",{"type":40,"tag":142,"props":1453,"children":1454},{},[1455,1465,1467,1473,1475,1480],{"type":40,"tag":68,"props":1456,"children":1458},{"href":1457},"..\u002F..\u002Fdoca-structured-tools-contract\u002FSKILL.md",[1459],{"type":40,"tag":73,"props":1460,"children":1462},{"className":1461},[],[1463],{"type":46,"value":1464},"doca-structured-tools-contract",{"type":46,"value":1466}," —\nthe JSON-schema contracts for the agent-preferred structured\nhelpers; the ",{"type":40,"tag":73,"props":1468,"children":1470},{"className":1469},[],[1471],{"type":46,"value":1472},"## Command appendix",{"type":46,"value":1474}," in ",{"type":40,"tag":73,"props":1476,"children":1478},{"className":1477},[],[1479],{"type":46,"value":70},{"type":46,"value":1481}," defers to\nthem before falling back to the manual chain.",{"items":1483,"total":1642},[1484,1502,1520,1531,1543,1557,1570,1584,1597,1608,1622,1631],{"slug":1485,"name":1485,"fn":1486,"description":1487,"org":1488,"tags":1489,"stars":1499,"repoUrl":1500,"updatedAt":1501},"nemoclaw-user-guide","retrieve NemoClaw documentation and configuration","Guides human users' AI agents to the NemoClaw docs MCP server and canonical Fern documentation in Markdown form. Use when users ask how to install, configure, operate, troubleshoot, secure, or learn NemoClaw with an AI coding assistant. Trigger keywords - nemoclaw docs, use nemoclaw with ai agent, nemoclaw mcp docs, nemoclaw install help, nemoclaw quickstart, nemoclaw markdown docs, llms.txt, agent skills.",{"slug":8,"name":9,"logoUrl":10,"githubOrg":9},[1490,1493,1496],{"name":1491,"slug":1492,"type":15},"Documentation","documentation",{"name":1494,"slug":1495,"type":15},"MCP","mcp",{"name":1497,"slug":1498,"type":15},"Search","search",21777,"https:\u002F\u002Fgithub.com\u002FNVIDIA\u002FNemoClaw","2026-07-20T06:00:01.461044",{"slug":1503,"name":1503,"fn":1504,"description":1505,"org":1506,"tags":1507,"stars":1517,"repoUrl":1518,"updatedAt":1519},"mcore-build-and-dependency","manage Megatron-LM development environments","Container-based dev environment setup and dependency management for Megatron-LM. Covers acquiring and launching the CI container, uv package management, and updating uv.lock.",{"slug":8,"name":9,"logoUrl":10,"githubOrg":9},[1508,1511,1514],{"name":1509,"slug":1510,"type":15},"Containers","containers",{"name":1512,"slug":1513,"type":15},"Deployment","deployment",{"name":1515,"slug":1516,"type":15},"Python","python",17049,"https:\u002F\u002Fgithub.com\u002FNVIDIA\u002FMegatron-LM","2026-07-27T06:06:11.249662",{"slug":1521,"name":1521,"fn":1522,"description":1523,"org":1524,"tags":1525,"stars":1517,"repoUrl":1518,"updatedAt":1530},"mcore-bump-base-image","update NVIDIA PyTorch base images","Bump the NVIDIA PyTorch base image (`nvcr.io\u002Fnvidia\u002Fpytorch:YY.MM-py3`) used by Megatron-LM CI. Covers the two pin sites (GitHub CI in `docker\u002F.ngc_version.dev` and GitLab CI in `.gitlab\u002Fstages\u002F01.build.yml`), the post-bump CI loop (re-run functional tests, refresh golden values, mark broken tests), and the gotchas that bit PRs",{"slug":8,"name":9,"logoUrl":10,"githubOrg":9},[1526,1529],{"name":1527,"slug":1528,"type":15},"CI\u002FCD","ci-cd",{"name":1512,"slug":1513,"type":15},"2026-07-14T05:25:59.97109",{"slug":1532,"name":1532,"fn":1533,"description":1534,"org":1535,"tags":1536,"stars":1517,"repoUrl":1518,"updatedAt":1542},"mcore-cicd","manage CI\u002FCD pipelines for Megatron-LM","CI\u002FCD reference for Megatron-LM. Covers CI pipeline structure, PR scope labels, triggering internal GitLab CI (which force-pushes the current branch to a pull-request\u002FBRANCH ref — always dry-run and verify the destination first; never run against shared or protected branches), and CI failure investigation.",{"slug":8,"name":9,"logoUrl":10,"githubOrg":9},[1537,1538,1539],{"name":1527,"slug":1528,"type":15},{"name":1512,"slug":1513,"type":15},{"name":1540,"slug":1541,"type":15},"GitHub","github","2026-07-27T06:06:12.278222",{"slug":1544,"name":1544,"fn":1545,"description":1546,"org":1547,"tags":1548,"stars":1517,"repoUrl":1518,"updatedAt":1556},"mcore-create-issue","investigate CI failures and create issues","Investigate a failing GitHub Actions run or job and create a GitHub issue for the failure.",{"slug":8,"name":9,"logoUrl":10,"githubOrg":9},[1549,1552,1553],{"name":1550,"slug":1551,"type":15},"Debugging","debugging",{"name":1540,"slug":1541,"type":15},{"name":1554,"slug":1555,"type":15},"Triage","triage","2026-07-14T05:25:57.442089",{"slug":1558,"name":1558,"fn":1559,"description":1560,"org":1561,"tags":1562,"stars":1517,"repoUrl":1518,"updatedAt":1569},"mcore-linting-and-formatting","lint and format Megatron-LM code","Linting and formatting for Megatron-LM. Covers running autoformat.sh, tools (ruff, black, isort, pylint, mypy), and code style rules.",{"slug":8,"name":9,"logoUrl":10,"githubOrg":9},[1563,1566],{"name":1564,"slug":1565,"type":15},"Best Practices","best-practices",{"name":1567,"slug":1568,"type":15},"Code Analysis","code-analysis","2026-07-14T05:25:56.18433",{"slug":1571,"name":1571,"fn":1572,"description":1573,"org":1574,"tags":1575,"stars":1517,"repoUrl":1518,"updatedAt":1583},"mcore-migrate-gpt-to-hybrid","migrate Megatron-LM models to HybridModel","Migration guide for moving Megatron Core GPTModel checkpoints, model providers, training commands, and layer mappings to HybridModel.",{"slug":8,"name":9,"logoUrl":10,"githubOrg":9},[1576,1579,1582],{"name":1577,"slug":1578,"type":15},"Machine Learning","machine-learning",{"name":1580,"slug":1581,"type":15},"Migration","migration",{"name":9,"slug":8,"type":15},"2026-07-17T06:07:11.777011",{"slug":1585,"name":1585,"fn":1586,"description":1587,"org":1588,"tags":1589,"stars":1517,"repoUrl":1518,"updatedAt":1596},"mcore-onboard-gb200-1node-tests","onboard functional tests for GB200","Onboard 1-node GitHub MR functional tests for GB200 from existing mr-scoped 2-node tests.",{"slug":8,"name":9,"logoUrl":10,"githubOrg":9},[1590,1593],{"name":1591,"slug":1592,"type":15},"QA","qa",{"name":1594,"slug":1595,"type":15},"Testing","testing","2026-07-14T05:25:53.673039",{"slug":1598,"name":1598,"fn":1599,"description":1600,"org":1601,"tags":1602,"stars":1517,"repoUrl":1518,"updatedAt":1607},"mcore-run-on-slurm","launch distributed training jobs on SLURM","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.",{"slug":8,"name":9,"logoUrl":10,"githubOrg":9},[1603,1604],{"name":1512,"slug":1513,"type":15},{"name":1605,"slug":1606,"type":15},"Infrastructure","infrastructure","2026-07-14T05:25:49.362534",{"slug":1609,"name":1609,"fn":1610,"description":1611,"org":1612,"tags":1613,"stars":1517,"repoUrl":1518,"updatedAt":1621},"mcore-split-pr","split pull requests to reduce review load","Split a PR into multiple PRs to reduce the number of required CODEOWNERS reviewer groups.",{"slug":8,"name":9,"logoUrl":10,"githubOrg":9},[1614,1617,1618],{"name":1615,"slug":1616,"type":15},"Code Review","code-review",{"name":1540,"slug":1541,"type":15},{"name":1619,"slug":1620,"type":15},"Pull Requests","pull-requests","2026-07-14T05:26:01.226578",{"slug":1623,"name":1623,"fn":1624,"description":1625,"org":1626,"tags":1627,"stars":1517,"repoUrl":1518,"updatedAt":1630},"mcore-testing","run and manage Megatron-LM tests","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.",{"slug":8,"name":9,"logoUrl":10,"githubOrg":9},[1628,1629],{"name":1591,"slug":1592,"type":15},{"name":1594,"slug":1595,"type":15},"2026-07-14T05:25:54.928983",{"slug":1632,"name":1632,"fn":1633,"description":1634,"org":1635,"tags":1636,"stars":1517,"repoUrl":1518,"updatedAt":1641},"nightly-sync","manage nightly main-to-dev sync workflows","Domain knowledge for the nightly main-to-dev sync workflow. Covers merge strategy, CI architecture, failure investigation, and known issues.",{"slug":8,"name":9,"logoUrl":10,"githubOrg":9},[1637,1640],{"name":1638,"slug":1639,"type":15},"Automation","automation",{"name":1527,"slug":1528,"type":15},"2026-07-30T05:29:03.275638",496,{"items":1644,"total":1738},[1645,1662,1672,1686,1696,1711,1724],{"slug":1646,"name":1646,"fn":1647,"description":1648,"org":1649,"tags":1650,"stars":20,"repoUrl":21,"updatedAt":1661},"accelerated-computing-cudf","accelerate data processing with cuDF","Official NVIDIA-authored guidance for NVIDIA cuDF GPU DataFrames, pandas acceleration, dask-cuDF, ETL, joins, groupby, CSV\u002FParquet I\u002FO, nullable semantics, and multi-GPU DataFrame workloads.",{"slug":8,"name":9,"logoUrl":10,"githubOrg":9},[1651,1654,1657,1658],{"name":1652,"slug":1653,"type":15},"Data Analysis","data-analysis",{"name":1655,"slug":1656,"type":15},"Data Engineering","data-engineering",{"name":9,"slug":8,"type":15},{"name":1659,"slug":1660,"type":15},"Performance","performance","2026-07-14T05:28:43.176466",{"slug":1663,"name":1663,"fn":1664,"description":1665,"org":1666,"tags":1667,"stars":20,"repoUrl":21,"updatedAt":1671},"aiq-deploy","deploy and manage NVIDIA AI-Q infrastructure","Use when asked to install, deploy, run, validate, troubleshoot, or stop NVIDIA AI-Q Blueprint infrastructure.\n",{"slug":8,"name":9,"logoUrl":10,"githubOrg":9},[1668,1669,1670],{"name":1512,"slug":1513,"type":15},{"name":1605,"slug":1606,"type":15},{"name":9,"slug":8,"type":15},"2026-07-14T05:29:06.667109",{"slug":1673,"name":1673,"fn":1674,"description":1675,"org":1676,"tags":1677,"stars":20,"repoUrl":21,"updatedAt":1685},"aiq-research","conduct deep research with AI-Q","Use when asked to run deep research or AI-Q research through a reachable NVIDIA AI-Q Blueprint backend.\n",{"slug":8,"name":9,"logoUrl":10,"githubOrg":9},[1678,1681,1682],{"name":1679,"slug":1680,"type":15},"Agents","agents",{"name":9,"slug":8,"type":15},{"name":1683,"slug":1684,"type":15},"Research","research","2026-07-14T05:28:06.816956",{"slug":1687,"name":1687,"fn":1688,"description":1689,"org":1690,"tags":1691,"stars":20,"repoUrl":21,"updatedAt":1695},"amc-run-sample-calibration","run AMC sample dataset calibration","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'.",{"slug":8,"name":9,"logoUrl":10,"githubOrg":9},[1692,1693,1694],{"name":1652,"slug":1653,"type":15},{"name":9,"slug":8,"type":15},{"name":1594,"slug":1595,"type":15},"2026-07-17T05:29:03.913266",{"slug":1697,"name":1697,"fn":1698,"description":1699,"org":1700,"tags":1701,"stars":20,"repoUrl":21,"updatedAt":1710},"amc-run-video-calibration","calibrate video datasets with AutoMagicCalib","Calibrate a new dataset from pre-recorded video files via the AutoMagicCalib REST API. Use when user has local MP4s and says 'calibrate my videos', 'run AMC on these videos', or similar. For RTSP\u002Flive streams, use amc-run-rtsp-calibration instead.",{"slug":8,"name":9,"logoUrl":10,"githubOrg":9},[1702,1703,1706,1707],{"name":1638,"slug":1639,"type":15},{"name":1704,"slug":1705,"type":15},"Imaging","imaging",{"name":9,"slug":8,"type":15},{"name":1708,"slug":1709,"type":15},"Video","video","2026-07-17T05:28:53.905004",{"slug":1712,"name":1712,"fn":1713,"description":1714,"org":1715,"tags":1716,"stars":20,"repoUrl":21,"updatedAt":1723},"amc-setup-calibration-stack","deploy AutoMagicCalib microservice with Docker","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.",{"slug":8,"name":9,"logoUrl":10,"githubOrg":9},[1717,1718,1721,1722],{"name":1512,"slug":1513,"type":15},{"name":1719,"slug":1720,"type":15},"Docker","docker",{"name":9,"slug":8,"type":15},{"name":13,"slug":14,"type":15},"2026-07-17T05:28:56.913999",{"slug":1725,"name":1725,"fn":1726,"description":1727,"org":1728,"tags":1729,"stars":20,"repoUrl":21,"updatedAt":1737},"cudaq-guide","develop quantum applications with CUDA-Q","CUDA-Q onboarding guide for installation, test programs, GPU simulation, QPU hardware, and quantum applications.",{"slug":8,"name":9,"logoUrl":10,"githubOrg":9},[1730,1731,1734],{"name":9,"slug":8,"type":15},{"name":1732,"slug":1733,"type":15},"Quantum Computing","quantum-computing",{"name":1735,"slug":1736,"type":15},"Simulation","simulation","2026-07-14T05:26:58.898253",305]