[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill-nvidia-doca-container-deployment":3,"mdc--tseqh1-key":34,"related-repo-nvidia-doca-container-deployment":648,"related-org-nvidia-doca-container-deployment":752},{"slug":4,"name":4,"fn":5,"description":6,"org":7,"tags":11,"stars":23,"repoUrl":24,"updatedAt":25,"license":26,"forks":27,"topics":28,"repo":29,"sourceUrl":32,"mdContent":33},"doca-container-deployment","deploy DOCA service containers on BlueField","Use this skill when the user is hands-on deploying an in-bundle DOCA service container (Argus, DMS, Firefly, or UROM service) on a BlueField — kubelet standalone watching a static-pod manifests directory, YAML pod-spec drop, kubelet status \u002F ENTRYPOINT logs \u002F per-service liveness, smoke-before-bulk, and the layered error taxonomy (pod-spec, scheduling, image pull, runtime, mount, network, version, host). Trigger even when the user does not say \"container deployment\" — typical implicit phrasings include \"how do I run my built service on the BlueField?\", \"where do I drop the pod-spec YAML?\", \"pod stuck in Pending \u002F ImagePullBackOff \u002F CrashLoopBackOff\", \"container Running but service isn't ready\", \"pod restart-loops after edit\", or \"DMS and Firefly together\". Refuse and route elsewhere for per-service config schemas, DOCA install, library-API questions, external NVIDIA services (BlueMan, HBN, SNAP, Virtio-net), or full Kubernetes-cluster ops — those belong to other skills.\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,19,20],{"name":13,"slug":14,"type":15},"Containers","containers","tag",{"name":17,"slug":18,"type":15},"Deployment","deployment",{"name":9,"slug":8,"type":15},{"name":21,"slug":22,"type":15},"Engineering","engineering",2473,"https:\u002F\u002Fgithub.com\u002FNVIDIA\u002Fskills","2026-07-30T05:28:33.386251","Apache-2.0",281,[],{"repoUrl":24,"stars":23,"forks":27,"topics":30,"description":31},[],"AI agent skills published by NVIDIA","https:\u002F\u002Fgithub.com\u002FNVIDIA\u002Fskills\u002Ftree\u002FHEAD\u002Fskills\u002Fdoca-container-deployment","---\nlicense: Apache-2.0\nname: doca-container-deployment\ndescription: >\n  Use this skill when the user is hands-on deploying an in-bundle DOCA\n  service container (Argus, DMS, Firefly, or UROM service) on a\n  BlueField — kubelet standalone watching a\n  static-pod manifests directory, YAML pod-spec drop, kubelet status \u002F\n  ENTRYPOINT logs \u002F per-service liveness, smoke-before-bulk, and the\n  layered error taxonomy (pod-spec, scheduling, image pull, runtime,\n  mount, network, version, host). Trigger even when the user does not\n  say \"container deployment\" — typical implicit phrasings include \"how\n  do I run my built service on the BlueField?\", \"where do I drop the\n  pod-spec YAML?\", \"pod stuck in Pending \u002F ImagePullBackOff \u002F\n  CrashLoopBackOff\", \"container Running but service isn't ready\", \"pod\n  restart-loops after edit\", or \"DMS and Firefly together\". Refuse and\n  route elsewhere for per-service config schemas, DOCA install,\n  library-API questions, external NVIDIA services (BlueMan, HBN, SNAP,\n  Virtio-net), or full Kubernetes-cluster ops — those belong to other\n  skills.\nmetadata:\n  kind: library\ncompatibility: >\n  No DOCA install required to read this skill (it is an overlay loaded\n  against any DOCA artifact skill); the validation steps within DO\n  require a live DOCA install at \u002Fopt\u002Fmellanox\u002Fdoca.\n---\n\n# DOCA container deployment\n\n**Where to start:** This skill is for *operating* the cross-cutting\nDOCA container-deployment runtime — the shared pattern every DOCA\nservice on the BlueField uses to come up (kubelet standalone agent\non the BlueField Arm watching a static-pod manifests directory; the\noperator drops a YAML pod spec into that directory; kubelet schedules\nthe pod and runs the container).\n\n**If the developer has NOT yet decided container vs. bare-metal**\n(*\"I just got a BlueField, what now?\"*, *\"my code is built, how do I\nrun it?\"*, *\"how do I deploy this?\"*), route them BACK to\n[`doca-setup ## recognize`](..\u002Fdoca-setup\u002FTASKS.md#recognize) first.\nThat is the front-door routing decision. The wrong failure mode is\nto silently push every developer onto the container path because the\nagent loaded this skill first. `## recognize` detects the system\nshape, asks the minimum residual question, and lands the developer on\neither this skill (when the workload is a packaged DOCA service to\ndrop on a BlueField) or the bare-metal-path sibling\n[`doca-bare-metal-deployment`](..\u002Fdoca-bare-metal-deployment\u002FSKILL.md)\n(when the workload is a DOCA-linked application binary the developer\nlaunches directly).\n\n**If the developer is already on the container path**, open\n[`TASKS.md`](TASKS.md) and start at\n[`## configure`](TASKS.md#configure). If the question is *what shape\nof runtime is this and what does the deployment contract look like*,\nstart at [`CAPABILITIES.md`](CAPABILITIES.md). For per-service\noverlays, follow the per-service skill under `skills\u002Fservices\u002F` that\nlayers on top of this one — the supported overlays are Argus, DMS,\nFirefly, and UROM service. Flow-Inspector and OS-Inspector are\npolicy-excluded from this public bundle; route them through\n[`doca-public-knowledge-map`](..\u002Fdoca-public-knowledge-map\u002FSKILL.md)\ninstead of applying this runtime overlay. Externally-productized\nNVIDIA services (BlueMan, HBN, SNAP, Virtio-net, DOCA Telemetry\nService as productized, …) are also out of scope and route through\nthat map. If DOCA is\nnot installed on the BlueField target yet, route to\n[`doca-setup`](..\u002Fdoca-setup\u002FSKILL.md) first.\n\n## Audience\n\nThis skill serves **external operators and platform teams who deploy\nDOCA service containers on BlueField** — i.e., people who have a\nBlueField with DOCA installed on the Arm side, a container runtime\nplus the kubelet standalone agent already present per the BlueField\nOS image, and the host-OS permissions the public DOCA Container\nDeployment Guide names for the chosen service. The skill is the\nshared deployment runtime; each per-service skill in the bundle\n(see the list in [`## Related skills`](#related-skills)) supplies\nthe service-specific config schema, paired-workload contract, and\n\"healthy\" definition.\n\nIt is **not** for NVIDIA developers contributing to the BlueField\ncontainer runtime or to kubelet itself, and it is **not** a generic\nKubernetes tutorial. Kubelet runs on the BlueField in *standalone*\nmode here — no full Kubernetes control plane, no `kubectl` against\na cluster API server — and the substantive answer to most\ncontainer-deployment questions on the BlueField is the public DOCA\nContainer Deployment Guide. This skill teaches the agent which\nguide to quote, in what order to walk it, and how to map a symptom\nto a layer; it does NOT re-invent kubelet flags, pod-spec field\nnames, or static-pod path strings. The shared deployment runtime\ndescribed here is the cross-cutting layer; the per-service skill\n(`doca-argus`, `doca-dms`, `doca-firefly`,\n`doca-urom-svc`) supplies the per-service\nconfig schema, paired-workload contract, and \"healthy\" definition.\n\n## When to load this skill\n\nLoad this skill when the user is doing **hands-on container\ndeployment of any DOCA service** on a BlueField target, or asking a\ncross-service deployment question that is not specific to one\nservice's config schema. Concretely:\n\n- Dropping a YAML pod spec into the documented static-pod manifests\n  directory on the BlueField Arm so kubelet standalone schedules the\n  pod and runs the DOCA service container.\n- Inspecting pod status, container logs, and the documented\n  liveness signal for any supported in-bundle DOCA service container\n  — Argus, DMS, Firefly, or UROM service — so the\n  agent answers \"did the container come up, and is the service\n  inside actually ready\" the same way for every service.\n- Walking the smoke-before-bulk loop (pod reaches `Running`;\n  ENTRYPOINT logs are clean; service answers a trivial liveness\n  probe) BEFORE the BlueField is put under workload.\n- Diagnosing a deployment that is misbehaving — pod-spec YAML is in\n  the directory but the pod never schedules; pod schedules but\n  image-pull fails; image pulls but container ENTRYPOINT\n  immediately exits; container runs but the service inside never\n  answers; container is in a restart loop after a config edit; a\n  volume mount the pod spec names is missing on the host; a network\n  policy or host-firewall rule is blocking the service.\n- Cross-service questions: *\"can I have DMS and Firefly on the\n  same BlueField\"*, *\"how do I list every DOCA service pod that is\n  currently running\"*, *\"what is the documented stop \u002F restart\n  semantics if I edit a pod-spec file in place\"*.\n\nDo **not** load this skill for per-service config schema questions\n(those belong to the matching per-service skill); for installing\nDOCA itself or preparing the BlueField env (use\n[`doca-setup`](..\u002Fdoca-setup\u002FSKILL.md)); for library-API\nquestions (use the matching `libs\u002F\u003Clibrary>` skill); or for general\nKubernetes-cluster operations (this skill covers kubelet *standalone*\nmode on the BlueField, not a full Kubernetes control plane).\n\n## What this skill provides\n\nThis is a **thin loader**. Substantive material lives in two\ncompanion files:\n\n- `CAPABILITIES.md` — the cross-cutting DOCA container-deployment\n  runtime contract on the BlueField (kubelet standalone agent on\n  BlueField Arm watching a documented static-pod manifests\n  directory; YAML pod-spec drop is the unit of operator input; the\n  same pattern applies across every DOCA service), the BlueField\n  preconditions (DOCA install, container runtime, BFB version,\n  per-service firmware slot when the service emulates a device,\n  image-pull reachability to NGC, host-OS permissions), the\n  observability surface (kubelet status, container logs, service-\n  side liveness signal — three layers, each with its own owner),\n  the cross-cutting error taxonomy (pod-spec syntax → pod\n  scheduling → image pull → runtime → volume mount → network policy\n  → version → cross-cutting host) covering exactly eight layers, and the\n  safety policy (smoke before bulk; failed pod is high-stakes —\n  clear the root cause before letting kubelet restart-loop the\n  pod; do NOT invent pod-spec field names \u002F kubelet flags \u002F image\n  tags from memory).\n- `TASKS.md` — step-by-step workflows for the in-scope deployment\n  verbs: `configure`, `build`, `modify`, `run`, `test`, `debug`,\n  plus a `Deferred task verbs` block routing per-service config\n  questions, host-firmware-slot work, paired-workload work, and\n  full-Kubernetes-cluster work out to their owning skills.\n\nThe skill assumes a BlueField target where DOCA is already installed\non the Arm side, the BlueField OS image ships kubelet standalone +\nthe container runtime per the public DOCA Container Deployment\nGuide, and the operator has the host-OS permissions that guide\nnames. It does not cover installing DOCA — that path goes through\n[`doca-setup`](..\u002Fdoca-setup\u002FSKILL.md) — and it does not\nre-document the per-service config schema, which is the canonical\nconcern of each DOCA service's public guide reached through\n[`doca-public-knowledge-map`](..\u002Fdoca-public-knowledge-map\u002FSKILL.md).\n\n## Loading order\n\n1. Read this `SKILL.md` first to confirm the user's question is in\n   scope (cross-cutting deployment runtime, NOT a per-service\n   config-schema question).\n2. **For the kubelet-standalone-mode runtime shape, the static-pod\n   manifests directory rule, the host-OS \u002F BFB \u002F firmware-slot \u002F\n   image-pull preconditions, the eight-layer error taxonomy, the\n   observability surface, and the safety \u002F smoke-before-bulk\n   policy, see [CAPABILITIES.md](CAPABILITIES.md).**\n3. **For step-by-step workflows — configure, build, modify, run,\n   test, debug — see [TASKS.md](TASKS.md).**\n\n## Example questions this skill answers well\n\nSee [`references\u002Fdetails.md`](references\u002Fdetails.md#example-questions-this-skill-answers-well).\n## What this skill deliberately does not ship\n\nSee [`references\u002Fdetails.md`](references\u002Fdetails.md#what-this-skill-deliberately-does-not-ship).\n## Related skills\n\nSee [`references\u002Fdetails.md`](references\u002Fdetails.md#related-skills).\n",{"data":35,"body":39},{"license":26,"name":4,"description":6,"metadata":36,"compatibility":38},{"kind":37},"library","No 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 \u002Fopt\u002Fmellanox\u002Fdoca.\n",{"type":40,"children":41},"root",[42,50,70,134,217,224,248,311,317,329,386,421,427,439,513,537,543,586,592,608,614,628,634],{"type":43,"tag":44,"props":45,"children":46},"element","h1",{"id":4},[47],{"type":48,"value":49},"text","DOCA container deployment",{"type":43,"tag":51,"props":52,"children":53},"p",{},[54,60,62,68],{"type":43,"tag":55,"props":56,"children":57},"strong",{},[58],{"type":48,"value":59},"Where to start:",{"type":48,"value":61}," This skill is for ",{"type":43,"tag":63,"props":64,"children":65},"em",{},[66],{"type":48,"value":67},"operating",{"type":48,"value":69}," the cross-cutting\nDOCA container-deployment runtime — the shared pattern every DOCA\nservice on the BlueField uses to come up (kubelet standalone agent\non the BlueField Arm watching a static-pod manifests directory; the\noperator drops a YAML pod spec into that directory; kubelet schedules\nthe pod and runs the container).",{"type":43,"tag":51,"props":71,"children":72},{},[73,78,80,85,87,92,93,98,100,112,114,120,122,132],{"type":43,"tag":55,"props":74,"children":75},{},[76],{"type":48,"value":77},"If the developer has NOT yet decided container vs. bare-metal",{"type":48,"value":79},"\n(",{"type":43,"tag":63,"props":81,"children":82},{},[83],{"type":48,"value":84},"\"I just got a BlueField, what now?\"",{"type":48,"value":86},", ",{"type":43,"tag":63,"props":88,"children":89},{},[90],{"type":48,"value":91},"\"my code is built, how do I\nrun it?\"",{"type":48,"value":86},{"type":43,"tag":63,"props":94,"children":95},{},[96],{"type":48,"value":97},"\"how do I deploy this?\"",{"type":48,"value":99},"), route them BACK to\n",{"type":43,"tag":101,"props":102,"children":104},"a",{"href":103},"..\u002Fdoca-setup\u002FTASKS.md#recognize",[105],{"type":43,"tag":106,"props":107,"children":109},"code",{"className":108},[],[110],{"type":48,"value":111},"doca-setup ## recognize",{"type":48,"value":113}," first.\nThat is the front-door routing decision. The wrong failure mode is\nto silently push every developer onto the container path because the\nagent loaded this skill first. ",{"type":43,"tag":106,"props":115,"children":117},{"className":116},[],[118],{"type":48,"value":119},"## recognize",{"type":48,"value":121}," detects the system\nshape, asks the minimum residual question, and lands the developer on\neither this skill (when the workload is a packaged DOCA service to\ndrop on a BlueField) or the bare-metal-path sibling\n",{"type":43,"tag":101,"props":123,"children":125},{"href":124},"..\u002Fdoca-bare-metal-deployment\u002FSKILL.md",[126],{"type":43,"tag":106,"props":127,"children":129},{"className":128},[],[130],{"type":48,"value":131},"doca-bare-metal-deployment",{"type":48,"value":133},"\n(when the workload is a DOCA-linked application binary the developer\nlaunches directly).",{"type":43,"tag":51,"props":135,"children":136},{},[137,142,144,153,155,165,167,172,174,183,185,191,193,203,205,215],{"type":43,"tag":55,"props":138,"children":139},{},[140],{"type":48,"value":141},"If the developer is already on the container path",{"type":48,"value":143},", open\n",{"type":43,"tag":101,"props":145,"children":147},{"href":146},"TASKS.md",[148],{"type":43,"tag":106,"props":149,"children":151},{"className":150},[],[152],{"type":48,"value":146},{"type":48,"value":154}," and start at\n",{"type":43,"tag":101,"props":156,"children":158},{"href":157},"TASKS.md#configure",[159],{"type":43,"tag":106,"props":160,"children":162},{"className":161},[],[163],{"type":48,"value":164},"## configure",{"type":48,"value":166},". If the question is ",{"type":43,"tag":63,"props":168,"children":169},{},[170],{"type":48,"value":171},"what shape\nof runtime is this and what does the deployment contract look like",{"type":48,"value":173},",\nstart at ",{"type":43,"tag":101,"props":175,"children":177},{"href":176},"CAPABILITIES.md",[178],{"type":43,"tag":106,"props":179,"children":181},{"className":180},[],[182],{"type":48,"value":176},{"type":48,"value":184},". For per-service\noverlays, follow the per-service skill under ",{"type":43,"tag":106,"props":186,"children":188},{"className":187},[],[189],{"type":48,"value":190},"skills\u002Fservices\u002F",{"type":48,"value":192}," that\nlayers on top of this one — the supported overlays are Argus, DMS,\nFirefly, and UROM service. Flow-Inspector and OS-Inspector are\npolicy-excluded from this public bundle; route them through\n",{"type":43,"tag":101,"props":194,"children":196},{"href":195},"..\u002Fdoca-public-knowledge-map\u002FSKILL.md",[197],{"type":43,"tag":106,"props":198,"children":200},{"className":199},[],[201],{"type":48,"value":202},"doca-public-knowledge-map",{"type":48,"value":204},"\ninstead of applying this runtime overlay. Externally-productized\nNVIDIA services (BlueMan, HBN, SNAP, Virtio-net, DOCA Telemetry\nService as productized, …) are also out of scope and route through\nthat map. If DOCA is\nnot installed on the BlueField target yet, route to\n",{"type":43,"tag":101,"props":206,"children":208},{"href":207},"..\u002Fdoca-setup\u002FSKILL.md",[209],{"type":43,"tag":106,"props":210,"children":212},{"className":211},[],[213],{"type":48,"value":214},"doca-setup",{"type":48,"value":216}," first.",{"type":43,"tag":218,"props":219,"children":221},"h2",{"id":220},"audience",[222],{"type":48,"value":223},"Audience",{"type":43,"tag":51,"props":225,"children":226},{},[227,229,234,236,246],{"type":48,"value":228},"This skill serves ",{"type":43,"tag":55,"props":230,"children":231},{},[232],{"type":48,"value":233},"external operators and platform teams who deploy\nDOCA service containers on BlueField",{"type":48,"value":235}," — i.e., people who have a\nBlueField with DOCA installed on the Arm side, a container runtime\nplus the kubelet standalone agent already present per the BlueField\nOS image, and the host-OS permissions the public DOCA Container\nDeployment Guide names for the chosen service. The skill is the\nshared deployment runtime; each per-service skill in the bundle\n(see the list in ",{"type":43,"tag":101,"props":237,"children":239},{"href":238},"#related-skills",[240],{"type":43,"tag":106,"props":241,"children":243},{"className":242},[],[244],{"type":48,"value":245},"## Related skills",{"type":48,"value":247},") supplies\nthe service-specific config schema, paired-workload contract, and\n\"healthy\" definition.",{"type":43,"tag":51,"props":249,"children":250},{},[251,253,258,260,264,266,271,273,279,281,287,288,294,295,301,303,309],{"type":48,"value":252},"It is ",{"type":43,"tag":55,"props":254,"children":255},{},[256],{"type":48,"value":257},"not",{"type":48,"value":259}," for NVIDIA developers contributing to the BlueField\ncontainer runtime or to kubelet itself, and it is ",{"type":43,"tag":55,"props":261,"children":262},{},[263],{"type":48,"value":257},{"type":48,"value":265}," a generic\nKubernetes tutorial. Kubelet runs on the BlueField in ",{"type":43,"tag":63,"props":267,"children":268},{},[269],{"type":48,"value":270},"standalone",{"type":48,"value":272},"\nmode here — no full Kubernetes control plane, no ",{"type":43,"tag":106,"props":274,"children":276},{"className":275},[],[277],{"type":48,"value":278},"kubectl",{"type":48,"value":280}," against\na cluster API server — and the substantive answer to most\ncontainer-deployment questions on the BlueField is the public DOCA\nContainer Deployment Guide. This skill teaches the agent which\nguide to quote, in what order to walk it, and how to map a symptom\nto a layer; it does NOT re-invent kubelet flags, pod-spec field\nnames, or static-pod path strings. The shared deployment runtime\ndescribed here is the cross-cutting layer; the per-service skill\n(",{"type":43,"tag":106,"props":282,"children":284},{"className":283},[],[285],{"type":48,"value":286},"doca-argus",{"type":48,"value":86},{"type":43,"tag":106,"props":289,"children":291},{"className":290},[],[292],{"type":48,"value":293},"doca-dms",{"type":48,"value":86},{"type":43,"tag":106,"props":296,"children":298},{"className":297},[],[299],{"type":48,"value":300},"doca-firefly",{"type":48,"value":302},",\n",{"type":43,"tag":106,"props":304,"children":306},{"className":305},[],[307],{"type":48,"value":308},"doca-urom-svc",{"type":48,"value":310},") supplies the per-service\nconfig schema, paired-workload contract, and \"healthy\" definition.",{"type":43,"tag":218,"props":312,"children":314},{"id":313},"when-to-load-this-skill",[315],{"type":48,"value":316},"When to load this skill",{"type":43,"tag":51,"props":318,"children":319},{},[320,322,327],{"type":48,"value":321},"Load this skill when the user is doing ",{"type":43,"tag":55,"props":323,"children":324},{},[325],{"type":48,"value":326},"hands-on container\ndeployment of any DOCA service",{"type":48,"value":328}," on a BlueField target, or asking a\ncross-service deployment question that is not specific to one\nservice's config schema. Concretely:",{"type":43,"tag":330,"props":331,"children":332},"ul",{},[333,339,344,357,362],{"type":43,"tag":334,"props":335,"children":336},"li",{},[337],{"type":48,"value":338},"Dropping a YAML pod spec into the documented static-pod manifests\ndirectory on the BlueField Arm so kubelet standalone schedules the\npod and runs the DOCA service container.",{"type":43,"tag":334,"props":340,"children":341},{},[342],{"type":48,"value":343},"Inspecting pod status, container logs, and the documented\nliveness signal for any supported in-bundle DOCA service container\n— Argus, DMS, Firefly, or UROM service — so the\nagent answers \"did the container come up, and is the service\ninside actually ready\" the same way for every service.",{"type":43,"tag":334,"props":345,"children":346},{},[347,349,355],{"type":48,"value":348},"Walking the smoke-before-bulk loop (pod reaches ",{"type":43,"tag":106,"props":350,"children":352},{"className":351},[],[353],{"type":48,"value":354},"Running",{"type":48,"value":356},";\nENTRYPOINT logs are clean; service answers a trivial liveness\nprobe) BEFORE the BlueField is put under workload.",{"type":43,"tag":334,"props":358,"children":359},{},[360],{"type":48,"value":361},"Diagnosing a deployment that is misbehaving — pod-spec YAML is in\nthe directory but the pod never schedules; pod schedules but\nimage-pull fails; image pulls but container ENTRYPOINT\nimmediately exits; container runs but the service inside never\nanswers; container is in a restart loop after a config edit; a\nvolume mount the pod spec names is missing on the host; a network\npolicy or host-firewall rule is blocking the service.",{"type":43,"tag":334,"props":363,"children":364},{},[365,367,372,373,378,379,384],{"type":48,"value":366},"Cross-service questions: ",{"type":43,"tag":63,"props":368,"children":369},{},[370],{"type":48,"value":371},"\"can I have DMS and Firefly on the\nsame BlueField\"",{"type":48,"value":86},{"type":43,"tag":63,"props":374,"children":375},{},[376],{"type":48,"value":377},"\"how do I list every DOCA service pod that is\ncurrently running\"",{"type":48,"value":86},{"type":43,"tag":63,"props":380,"children":381},{},[382],{"type":48,"value":383},"\"what is the documented stop \u002F restart\nsemantics if I edit a pod-spec file in place\"",{"type":48,"value":385},".",{"type":43,"tag":51,"props":387,"children":388},{},[389,391,395,397,405,407,413,415,419],{"type":48,"value":390},"Do ",{"type":43,"tag":55,"props":392,"children":393},{},[394],{"type":48,"value":257},{"type":48,"value":396}," load this skill for per-service config schema questions\n(those belong to the matching per-service skill); for installing\nDOCA itself or preparing the BlueField env (use\n",{"type":43,"tag":101,"props":398,"children":399},{"href":207},[400],{"type":43,"tag":106,"props":401,"children":403},{"className":402},[],[404],{"type":48,"value":214},{"type":48,"value":406},"); for library-API\nquestions (use the matching ",{"type":43,"tag":106,"props":408,"children":410},{"className":409},[],[411],{"type":48,"value":412},"libs\u002F\u003Clibrary>",{"type":48,"value":414}," skill); or for general\nKubernetes-cluster operations (this skill covers kubelet ",{"type":43,"tag":63,"props":416,"children":417},{},[418],{"type":48,"value":270},{"type":48,"value":420},"\nmode on the BlueField, not a full Kubernetes control plane).",{"type":43,"tag":218,"props":422,"children":424},{"id":423},"what-this-skill-provides",[425],{"type":48,"value":426},"What this skill provides",{"type":43,"tag":51,"props":428,"children":429},{},[430,432,437],{"type":48,"value":431},"This is a ",{"type":43,"tag":55,"props":433,"children":434},{},[435],{"type":48,"value":436},"thin loader",{"type":48,"value":438},". Substantive material lives in two\ncompanion files:",{"type":43,"tag":330,"props":440,"children":441},{},[442,452],{"type":43,"tag":334,"props":443,"children":444},{},[445,450],{"type":43,"tag":106,"props":446,"children":448},{"className":447},[],[449],{"type":48,"value":176},{"type":48,"value":451}," — the cross-cutting DOCA container-deployment\nruntime contract on the BlueField (kubelet standalone agent on\nBlueField Arm watching a documented static-pod manifests\ndirectory; YAML pod-spec drop is the unit of operator input; the\nsame pattern applies across every DOCA service), the BlueField\npreconditions (DOCA install, container runtime, BFB version,\nper-service firmware slot when the service emulates a device,\nimage-pull reachability to NGC, host-OS permissions), the\nobservability surface (kubelet status, container logs, service-\nside liveness signal — three layers, each with its own owner),\nthe cross-cutting error taxonomy (pod-spec syntax → pod\nscheduling → image pull → runtime → volume mount → network policy\n→ version → cross-cutting host) covering exactly eight layers, and the\nsafety policy (smoke before bulk; failed pod is high-stakes —\nclear the root cause before letting kubelet restart-loop the\npod; do NOT invent pod-spec field names \u002F kubelet flags \u002F image\ntags from memory).",{"type":43,"tag":334,"props":453,"children":454},{},[455,460,462,468,469,475,476,482,483,489,490,496,497,503,505,511],{"type":43,"tag":106,"props":456,"children":458},{"className":457},[],[459],{"type":48,"value":146},{"type":48,"value":461}," — step-by-step workflows for the in-scope deployment\nverbs: ",{"type":43,"tag":106,"props":463,"children":465},{"className":464},[],[466],{"type":48,"value":467},"configure",{"type":48,"value":86},{"type":43,"tag":106,"props":470,"children":472},{"className":471},[],[473],{"type":48,"value":474},"build",{"type":48,"value":86},{"type":43,"tag":106,"props":477,"children":479},{"className":478},[],[480],{"type":48,"value":481},"modify",{"type":48,"value":86},{"type":43,"tag":106,"props":484,"children":486},{"className":485},[],[487],{"type":48,"value":488},"run",{"type":48,"value":86},{"type":43,"tag":106,"props":491,"children":493},{"className":492},[],[494],{"type":48,"value":495},"test",{"type":48,"value":86},{"type":43,"tag":106,"props":498,"children":500},{"className":499},[],[501],{"type":48,"value":502},"debug",{"type":48,"value":504},",\nplus a ",{"type":43,"tag":106,"props":506,"children":508},{"className":507},[],[509],{"type":48,"value":510},"Deferred task verbs",{"type":48,"value":512}," block routing per-service config\nquestions, host-firmware-slot work, paired-workload work, and\nfull-Kubernetes-cluster work out to their owning skills.",{"type":43,"tag":51,"props":514,"children":515},{},[516,518,526,528,536],{"type":48,"value":517},"The skill assumes a BlueField target where DOCA is already installed\non the Arm side, the BlueField OS image ships kubelet standalone +\nthe container runtime per the public DOCA Container Deployment\nGuide, and the operator has the host-OS permissions that guide\nnames. It does not cover installing DOCA — that path goes through\n",{"type":43,"tag":101,"props":519,"children":520},{"href":207},[521],{"type":43,"tag":106,"props":522,"children":524},{"className":523},[],[525],{"type":48,"value":214},{"type":48,"value":527}," — and it does not\nre-document the per-service config schema, which is the canonical\nconcern of each DOCA service's public guide reached through\n",{"type":43,"tag":101,"props":529,"children":530},{"href":195},[531],{"type":43,"tag":106,"props":532,"children":534},{"className":533},[],[535],{"type":48,"value":202},{"type":48,"value":385},{"type":43,"tag":218,"props":538,"children":540},{"id":539},"loading-order",[541],{"type":48,"value":542},"Loading order",{"type":43,"tag":544,"props":545,"children":546},"ol",{},[547,560,573],{"type":43,"tag":334,"props":548,"children":549},{},[550,552,558],{"type":48,"value":551},"Read this ",{"type":43,"tag":106,"props":553,"children":555},{"className":554},[],[556],{"type":48,"value":557},"SKILL.md",{"type":48,"value":559}," first to confirm the user's question is in\nscope (cross-cutting deployment runtime, NOT a per-service\nconfig-schema question).",{"type":43,"tag":334,"props":561,"children":562},{},[563],{"type":43,"tag":55,"props":564,"children":565},{},[566,568,572],{"type":48,"value":567},"For the kubelet-standalone-mode runtime shape, the static-pod\nmanifests directory rule, the host-OS \u002F BFB \u002F firmware-slot \u002F\nimage-pull preconditions, the eight-layer error taxonomy, the\nobservability surface, and the safety \u002F smoke-before-bulk\npolicy, see ",{"type":43,"tag":101,"props":569,"children":570},{"href":176},[571],{"type":48,"value":176},{"type":48,"value":385},{"type":43,"tag":334,"props":574,"children":575},{},[576],{"type":43,"tag":55,"props":577,"children":578},{},[579,581,585],{"type":48,"value":580},"For step-by-step workflows — configure, build, modify, run,\ntest, debug — see ",{"type":43,"tag":101,"props":582,"children":583},{"href":146},[584],{"type":48,"value":146},{"type":48,"value":385},{"type":43,"tag":218,"props":587,"children":589},{"id":588},"example-questions-this-skill-answers-well",[590],{"type":48,"value":591},"Example questions this skill answers well",{"type":43,"tag":51,"props":593,"children":594},{},[595,597,607],{"type":48,"value":596},"See ",{"type":43,"tag":101,"props":598,"children":600},{"href":599},"references\u002Fdetails.md#example-questions-this-skill-answers-well",[601],{"type":43,"tag":106,"props":602,"children":604},{"className":603},[],[605],{"type":48,"value":606},"references\u002Fdetails.md",{"type":48,"value":385},{"type":43,"tag":218,"props":609,"children":611},{"id":610},"what-this-skill-deliberately-does-not-ship",[612],{"type":48,"value":613},"What this skill deliberately does not ship",{"type":43,"tag":51,"props":615,"children":616},{},[617,618,627],{"type":48,"value":596},{"type":43,"tag":101,"props":619,"children":621},{"href":620},"references\u002Fdetails.md#what-this-skill-deliberately-does-not-ship",[622],{"type":43,"tag":106,"props":623,"children":625},{"className":624},[],[626],{"type":48,"value":606},{"type":48,"value":385},{"type":43,"tag":218,"props":629,"children":631},{"id":630},"related-skills",[632],{"type":48,"value":633},"Related skills",{"type":43,"tag":51,"props":635,"children":636},{},[637,638,647],{"type":48,"value":596},{"type":43,"tag":101,"props":639,"children":641},{"href":640},"references\u002Fdetails.md#related-skills",[642],{"type":43,"tag":106,"props":643,"children":645},{"className":644},[],[646],{"type":48,"value":606},{"type":48,"value":385},{"items":649,"total":751},[650,667,679,693,705,722,737],{"slug":651,"name":651,"fn":652,"description":653,"org":654,"tags":655,"stars":23,"repoUrl":24,"updatedAt":666},"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},[656,659,662,663],{"name":657,"slug":658,"type":15},"Data Analysis","data-analysis",{"name":660,"slug":661,"type":15},"Data Engineering","data-engineering",{"name":9,"slug":8,"type":15},{"name":664,"slug":665,"type":15},"Performance","performance","2026-07-14T05:28:43.176466",{"slug":668,"name":668,"fn":669,"description":670,"org":671,"tags":672,"stars":23,"repoUrl":24,"updatedAt":678},"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},[673,674,677],{"name":17,"slug":18,"type":15},{"name":675,"slug":676,"type":15},"Infrastructure","infrastructure",{"name":9,"slug":8,"type":15},"2026-07-14T05:29:06.667109",{"slug":680,"name":680,"fn":681,"description":682,"org":683,"tags":684,"stars":23,"repoUrl":24,"updatedAt":692},"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},[685,688,689],{"name":686,"slug":687,"type":15},"Agents","agents",{"name":9,"slug":8,"type":15},{"name":690,"slug":691,"type":15},"Research","research","2026-07-14T05:28:06.816956",{"slug":694,"name":694,"fn":695,"description":696,"org":697,"tags":698,"stars":23,"repoUrl":24,"updatedAt":704},"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},[699,700,701],{"name":657,"slug":658,"type":15},{"name":9,"slug":8,"type":15},{"name":702,"slug":703,"type":15},"Testing","testing","2026-07-17T05:29:03.913266",{"slug":706,"name":706,"fn":707,"description":708,"org":709,"tags":710,"stars":23,"repoUrl":24,"updatedAt":721},"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},[711,714,717,718],{"name":712,"slug":713,"type":15},"Automation","automation",{"name":715,"slug":716,"type":15},"Imaging","imaging",{"name":9,"slug":8,"type":15},{"name":719,"slug":720,"type":15},"Video","video","2026-07-17T05:28:53.905004",{"slug":723,"name":723,"fn":724,"description":725,"org":726,"tags":727,"stars":23,"repoUrl":24,"updatedAt":736},"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},[728,729,732,733],{"name":17,"slug":18,"type":15},{"name":730,"slug":731,"type":15},"Docker","docker",{"name":9,"slug":8,"type":15},{"name":734,"slug":735,"type":15},"Operations","operations","2026-07-17T05:28:56.913999",{"slug":738,"name":738,"fn":739,"description":740,"org":741,"tags":742,"stars":23,"repoUrl":24,"updatedAt":750},"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},[743,744,747],{"name":9,"slug":8,"type":15},{"name":745,"slug":746,"type":15},"Quantum Computing","quantum-computing",{"name":748,"slug":749,"type":15},"Simulation","simulation","2026-07-14T05:26:58.898253",305,{"items":753,"total":902},[754,772,786,797,809,823,836,850,861,870,884,893],{"slug":755,"name":755,"fn":756,"description":757,"org":758,"tags":759,"stars":769,"repoUrl":770,"updatedAt":771},"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},[760,763,766],{"name":761,"slug":762,"type":15},"Documentation","documentation",{"name":764,"slug":765,"type":15},"MCP","mcp",{"name":767,"slug":768,"type":15},"Search","search",21777,"https:\u002F\u002Fgithub.com\u002FNVIDIA\u002FNemoClaw","2026-07-20T06:00:01.461044",{"slug":773,"name":773,"fn":774,"description":775,"org":776,"tags":777,"stars":783,"repoUrl":784,"updatedAt":785},"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},[778,779,780],{"name":13,"slug":14,"type":15},{"name":17,"slug":18,"type":15},{"name":781,"slug":782,"type":15},"Python","python",17049,"https:\u002F\u002Fgithub.com\u002FNVIDIA\u002FMegatron-LM","2026-07-27T06:06:11.249662",{"slug":787,"name":787,"fn":788,"description":789,"org":790,"tags":791,"stars":783,"repoUrl":784,"updatedAt":796},"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},[792,795],{"name":793,"slug":794,"type":15},"CI\u002FCD","ci-cd",{"name":17,"slug":18,"type":15},"2026-07-14T05:25:59.97109",{"slug":798,"name":798,"fn":799,"description":800,"org":801,"tags":802,"stars":783,"repoUrl":784,"updatedAt":808},"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},[803,804,805],{"name":793,"slug":794,"type":15},{"name":17,"slug":18,"type":15},{"name":806,"slug":807,"type":15},"GitHub","github","2026-07-27T06:06:12.278222",{"slug":810,"name":810,"fn":811,"description":812,"org":813,"tags":814,"stars":783,"repoUrl":784,"updatedAt":822},"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},[815,818,819],{"name":816,"slug":817,"type":15},"Debugging","debugging",{"name":806,"slug":807,"type":15},{"name":820,"slug":821,"type":15},"Triage","triage","2026-07-14T05:25:57.442089",{"slug":824,"name":824,"fn":825,"description":826,"org":827,"tags":828,"stars":783,"repoUrl":784,"updatedAt":835},"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},[829,832],{"name":830,"slug":831,"type":15},"Best Practices","best-practices",{"name":833,"slug":834,"type":15},"Code Analysis","code-analysis","2026-07-14T05:25:56.18433",{"slug":837,"name":837,"fn":838,"description":839,"org":840,"tags":841,"stars":783,"repoUrl":784,"updatedAt":849},"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},[842,845,848],{"name":843,"slug":844,"type":15},"Machine Learning","machine-learning",{"name":846,"slug":847,"type":15},"Migration","migration",{"name":9,"slug":8,"type":15},"2026-07-17T06:07:11.777011",{"slug":851,"name":851,"fn":852,"description":853,"org":854,"tags":855,"stars":783,"repoUrl":784,"updatedAt":860},"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},[856,859],{"name":857,"slug":858,"type":15},"QA","qa",{"name":702,"slug":703,"type":15},"2026-07-14T05:25:53.673039",{"slug":862,"name":862,"fn":863,"description":864,"org":865,"tags":866,"stars":783,"repoUrl":784,"updatedAt":869},"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},[867,868],{"name":17,"slug":18,"type":15},{"name":675,"slug":676,"type":15},"2026-07-14T05:25:49.362534",{"slug":871,"name":871,"fn":872,"description":873,"org":874,"tags":875,"stars":783,"repoUrl":784,"updatedAt":883},"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},[876,879,880],{"name":877,"slug":878,"type":15},"Code Review","code-review",{"name":806,"slug":807,"type":15},{"name":881,"slug":882,"type":15},"Pull Requests","pull-requests","2026-07-14T05:26:01.226578",{"slug":885,"name":885,"fn":886,"description":887,"org":888,"tags":889,"stars":783,"repoUrl":784,"updatedAt":892},"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},[890,891],{"name":857,"slug":858,"type":15},{"name":702,"slug":703,"type":15},"2026-07-14T05:25:54.928983",{"slug":894,"name":894,"fn":895,"description":896,"org":897,"tags":898,"stars":783,"repoUrl":784,"updatedAt":901},"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},[899,900],{"name":712,"slug":713,"type":15},{"name":793,"slug":794,"type":15},"2026-07-30T05:29:03.275638",496]