复制安装命令
用 Codex 或 Claude 安装复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它先审查 Skill 页面再帮你安装。
复制前请先查看来源、License 和安全提示。
SkillAtlasSkill 详情
doca-setup
Official, NVIDIA-verified Agent Skills for Claude Code, Codex, and other coding agents.
审核状态：已审核Quality 80Security 100
项目 README
来源文件：README.md
NVIDIA Agent Skills
Official, NVIDIA-verified Agent Skills for Claude Code, Codex, and other coding agents.
📖 Docs: docs.nvidia.com/skills · 📺 Livestream: From Vulnerable to Verified · 📝 Blog: NVIDIA Verified Agent Skills: Capability Governance for AI Agents
Skills are portable instruction sets that teach AI agents how to use NVIDIA software optimally: Physical AI and robotics workflows, simulation, CUDA-X libraries, RAG and AI Blueprints, and platform tools. This repository is a catalog: skills are maintained in their respective product repos, and mirrored here daily via an automated sync pipeline. Skills are being added continuously, so check back for updates. We are building this infrastructure in the open, and contributions are welcome. See the Roadmap for what is planned next.
Quickstart
Install NVIDIA skills with the default skills CLI flow:
npx skills add nvidia/skills
The CLI runs through npx and prompts you to choose a skill and install destination. You do not need to clone this repo or copy skill folders by hand.
Requires a current
skillsCLI (v1.5.16 or newer). Installing vianpx skills@latest add nvidia/skillsalways uses the latest. On older CLIs (v1.5.15 and earlier), skills may install but not appear in Claude Code — see Troubleshooting.
The skill is available the next time your agent loads skills and encounters a relevant task. For example, ask your agent to "solve a linear programming problem with cuOpt" and the skill guides it through the cuOpt Python API. In Claude Code, run /reload-skills to load newly installed skills in your current session.
Install One Skill Without Prompts
Use this when you already know the skill name and want to skip prompts.
npx skills add nvidia/skills --skill cuopt-numerical-optimization-api --yes
Replace cuopt-numerical-optimization-api with any skill name from the Skill Catalog.
Install for a Specific Agent
Use --agent to target a specific AI coding agent. Initially, we'll support common client targets, expanding the list over time. For the full list of clients supported by the spec, see the skills CLI Supported Agents table.
Claude Code
npx skills add nvidia/skills --skill cuopt-numerical-optimization-api --agent claude-code
Codex
npx skills add nvidia/skills --skill cuopt-numerical-optimization-api --agent codex
Snowflake CoCo
npx skills add nvidia/skills --skill cuopt-numerical-optimization-api --agent cortex
Cursor
npx skills add nvidia/skills --skill cuopt-numerical-optimization-api --agent cursor
Kiro
npx skills add nvidia/skills --skill cuopt-numerical-optimization-api --agent kiro-cli
Use --agent more than once to install the same skill into multiple agents.
npx skills add nvidia/skills \
--skill cuopt-numerical-optimization-api \
--agent claude-code \
--agent codex \
--agent cursor \
--agent kiro-cli
Keep Skills Up to Date
New skills land continuously, and existing ones are revised, renamed, or consolidated as the catalog evolves. Refresh what you have installed with:
npx skills update
Run it interactively and the CLI also flags skills that were removed or merged upstream (for example, when several skills are consolidated into one) and offers to remove the stale local copies. Use npx skills list to see what is installed and npx skills check to preview what is out of date first.
Browse the Catalog
Use this when you want to see available NVIDIA skills before installing anything.
npx skills add nvidia/skills --list
For non-interactive installs, global installs, agent-specific installs, updates, removals, and fallback manual copying, see Advanced installation.
Skill Catalog
Getting Help & Contributing
Where to file an issue depends on what's broken:
- Skill content issues (a specific skill has a bug, missing functionality, or incorrect content) — file in the source repo for that product, using the per-product table below.
- Catalog issues (catalog README errors, sync workflow problems, distribution channels, signing/verification flow, docs in this repo) — file here using the catalog issue templates: Bug Report, Feature Request, or Documentation Request or Correction.
- Questions or general discussion — use Discussions. The issue tracker is reserved for bug reports, feature proposals with a design, and documentation issues.
- Security vulnerabilities — follow the disclosure process in SECURITY.md; do not open a public issue.
Per-product source repo links:
For issues with this catalog repo itself (README, structure, listing a new product): open an issue here.
Verifying Skills
Every published skill ships with a detached OMS signature (skill.oms.sig). The sync pipeline drops any skill missing the required artifacts before publishing, so every skill in the catalog carries:
SKILL.md— the skill instructions consumed by the agentskill-card.md— skill identity and governance cardskill.oms.sig— detached OMS signature (verifiable againstnv-agent-root-cert.pem)- A Tier-3 evaluation dataset — accepted at
evals/evals.json,evals/*.json,eval/*.json, orbenchmark/evals.json BENCHMARK.md— generated benchmark report capturing verifiable uplift data
Verify a skill against the NVIDIA trust anchor nv-agent-root-cert.pem:
pip install model-signing
model_signing verify certificate SKILL_DIR \
--signature SKILL_DIR/skill.oms.sig \
--certificate_chain nv-agent-root-cert.pem \
--ignore_unsigned_files
A successful verification confirms that the skill contents have not been modified since signing by NVIDIA.
See Verify Signed Agent Skills for signature layout, the trust pipeline, and policy options.
Roadmap
- ✅ Public skills catalog with NVIDIA-verified skills across multiple products
- ✅ Automated sync pipeline with skills mirrored from product repos daily
- ✅ Security scanning for all published skills covering instruction safety and supply-chain integrity
- ✅ Skills signing so every published skill carries a verifiable NVIDIA signature
- ✅ Skills universal evaluation criteria and task-specific criteria
- ✅ Skill Card with machine-readable metadata for identity, provenance, quality, and behavioral boundaries
- ✅ Sync-time compliance gates — signature drift detection and missing-artifact enforcement
- ✅ Syndication to external marketplaces — Skills.sh, Codex plugin, Claude Code plugin, ClawHub, Hermes Hub
- 🔲 Syndication to additional MCP hubs and partner channels
Repository Structure
NVIDIA/skills/
├── skills/ # NVIDIA-verified skills (count grows continuously),
│ │ synced from upstream product repos
│ ├── README.md # Browser-facing install guidance
│ ├── <product-prefix>-*/ # Flat layout — one dir per skill, product-prefixed
│ │ # e.g. aiq-*, cuopt-*, cupynumeric-*,
│ │ # dali-*, deepstream-*, dicom-*, digital-health-*,
│ │ # dynamo-*, earth2studio-*, holoscan-*, hsb-*,
│ │ # jetson-*, launch-nemo-rl, mcore-*,
│ │ # nemo-automodel-*, nemo-data-designer-plugin,
│ │ # nemo-evaluator-plugin, nemo-mbridge-* (20 skills),
│ │ # nemo-retriever, nemo-rl-* (4 skills),
│ │ # nemoclaw-user-guide, nemotron-*, nemotron-speech,
│ │ # nv-* (medical AI), physicsnemo-*, rag-*,
│ │ # skill-card-generator, tao-*, tilegym-*,
│ │ # vss-* (15 skills), accelerated-computing-cudf,
│ │ # cudaq-guide, portfolio-optimization
│ ├── omniverse-*/ # Physical AI — manually staged (see manual-components.yml)
│ └── physical-ai-*/ # Physical AI — manually staged
├── components.d/ # Product registry — one file per component, teams onboard here
│ ├── README.md # Schema and onboarding instructions
│ └── <product>.yml # one file per registered product
├── plugins/ # Packaged plugin distributions
│ └── nvidia-skills/ # Curated NVIDIA skills bundle (Claude Code, Codex)
├── plugins.d/ # Plugin build registry — config for `build-plugins.py`
│ ├── README.md
│ ├── _defaults.yml
│ └── nvidia-skills.yml
├── .claude-plugin/ # Claude Code marketplace metadata
│ └── marketplace.json
├── .agents/plugins/ # Agent marketplace metadata (other clients)
│ └── marketplace.json
├── docs/ # Long-form documentation (published via Fern)
│ ├── README.md # How to build the docs locally
│ ├── index.mdx
│ ├── advanced-install.mdx
│ ├── agent-skill-trust-pipeline.mdx
│ ├── release-checklist.mdx
│ ├── scanning-agent-skills.mdx
│ ├── signing-agent-skills.mdx
│ └── skill-cards.mdx
├── fern/ # Fern docs site configuration
├── .github/
│ ├── workflows/ # Sync pipeline, plugin validation, DCO check, author verify
│ └── scripts/ # regenerate-readme.sh, build-plugins.py,
│ # manual-components.yml (temp Physical AI catalog
│ # exception, removed after Computex 2026),
│ # marketplace/metadata.json (skill metadata sidecar)
├── nv-agent-root-cert.pem # Trust anchor for OMS signature verification
├── skills.sh.json # Skills.sh marketplace grouping config
├── CHANGELOG.md
├── CONTRIBUTING.md # Contribution guidelines
├── SECURITY.md # Security reporting policy
├── CODE_OF_CONDUCT.md # Community code of conduct
├── LICENSE-APACHE # Apache 2.0 (source code)
└── LICENSE-CC-BY-4.0 # CC BY 4.0 (documentation/skills)
Skills are maintained in their respective product repos (see the Source column in the Skill Catalog) and synced to this repo daily. Products only appear under skills/ after the sync pipeline confirms each skill carries:
skill.oms.sig— detached OMS-format signature (verifiable againstnv-agent-root-cert.pem)skill-card.md— skill identity and governance card- A Tier-3 evaluation dataset — accepted at
evals/evals.json,evals/*.json,eval/*.json, orbenchmark/evals.json
When evaluation runs produce a BENCHMARK.md, it ships alongside the skill so consumers can see verifiable benchmark uplift data.
Standards & Compatibility
This repository adheres to the Agent Skills specification:
- Skills are portable directories with a
SKILL.mdfile at their root. - Metadata uses YAML frontmatter with required
nameanddescriptionfields. - Skills follow a progressive disclosure model — lightweight metadata loads at startup, full instructions load on activation.
- Validate your skill using the
skills-refreference library.
License
Copyright (c) 2026 NVIDIA CORPORATION & AFFILIATES. All rights reserved.
This code is dual-licensed with documentation/skills under the CC-BY-4.0 AND source code under Apache-2.0 license terms. The full license texts can be found in LICENSE-APACHE and LICENSE-CC-BY-4.0 respectively.
其他
低风险
- 来源需自行核对维护者身份。
- 未检测到明显脚本安装指令。
- 未检测到明显外部权限要求。
- 未检测到高风险命令。
- 扫描发现：0 条。
Codex — Git Clone 安装
- 安装前请先查看来源仓库和风险报告。
- 克隆仓库：git clone https://github.com/NVIDIA/skills.git
- 将 "skills/doca-setup" 文件夹复制到 Codex 的 skills 目录中。
- 重启 Codex 让新的 skill 生效。
Codex — 手动复制安装
- 安装前请先查看来源仓库和风险报告。
- 从源仓库下载 SKILL.md 及相关文件。
- 在 Codex 的 skills 目录中创建新文件夹。
- 将所有 skill 文件复制到新文件夹中。
- 重启 Codex 让新的 skill 生效。
Claude Code — Git Clone 安装
- 安装前请先查看来源仓库和风险报告。
- 克隆仓库：git clone https://github.com/NVIDIA/skills.git
- 将 "skills/doca-setup" 文件夹复制到 Claude Code 的 skills 目录中。
- 重启 Claude Code 让新的 skill 生效。
Claude Code — 手动复制安装
- 安装前请先查看来源仓库和风险报告。
- 从源仓库下载 SKILL.md 及相关文件。
- 在 Claude Code 的 skills 目录中创建新文件夹。
- 将所有 skill 文件复制到新文件夹中。
- 重启 Claude Code 让新的 skill 生效。
Cursor — Git Clone 安装
- 安装前请先查看来源仓库和风险报告。
- 克隆仓库：git clone https://github.com/NVIDIA/skills.git
- 将 "skills/doca-setup" 文件夹复制到 Cursor 的 skills 目录中。
- 重启 Cursor 让新的 skill 生效。
Cursor — 手动复制安装
- 安装前请先查看来源仓库和风险报告。
- 从源仓库下载 SKILL.md 及相关文件。
- 在 Cursor 的 skills 目录中创建新文件夹。
- 将所有 skill 文件复制到新文件夹中。
- 重启 Cursor 让新的 skill 生效。
GitHub Copilot — Git Clone 安装
- 安装前请先查看来源仓库和风险报告。
- 克隆仓库：git clone https://github.com/NVIDIA/skills.git
- 将 "skills/doca-setup" 文件夹复制到 GitHub Copilot 的 skills 目录中。
- 重启 GitHub Copilot 让新的 skill 生效。
GitHub Copilot — 手动复制安装
- 安装前请先查看来源仓库和风险报告。
- 从源仓库下载 SKILL.md 及相关文件。
- 在 GitHub Copilot 的 skills 目录中创建新文件夹。
- 将所有 skill 文件复制到新文件夹中。
- 重启 GitHub Copilot 让新的 skill 生效。
Windsurf — Git Clone 安装
- 安装前请先查看来源仓库和风险报告。
- 克隆仓库：git clone https://github.com/NVIDIA/skills.git
- 将 "skills/doca-setup" 文件夹复制到 Windsurf 的 skills 目录中。
- 重启 Windsurf 让新的 skill 生效。
Windsurf — 手动复制安装
- 安装前请先查看来源仓库和风险报告。
- 从源仓库下载 SKILL.md 及相关文件。
- 在 Windsurf 的 skills 目录中创建新文件夹。
- 将所有 skill 文件复制到新文件夹中。
- 重启 Windsurf 让新的 skill 生效。
查看 SKILL.md 原文
license: Apache-2.0 AND CC-BY-4.0
name: doca-setup
description: >
Use this skill when the user is dealing with the DOCA environment
around their workload — verifying an install is healthy, preparing
the build env (pkg-config, headers, LD_LIBRARY_PATH, hugepages,
devlink, representors), debugging env-class failures, deciding
container-vs-bare-metal deployment shape, or reaching a DOCA install
from a host that doesn't have one yet via the NGC DOCA container
Stage-1 fallback. Trigger even when the user does not explicitly
mention "DOCA setup" — typical implicit phrasings include "I just
got a BlueField, what now", "my code is built, how do I run it",
"pkg-config can't find doca-flow", "no free 2048 kB hugepages",
"representor X not found", "I'm on a Mac and want to learn DOCA".
Refuse and route elsewhere for library API specifics (Flow pipes,
RDMA queues), the modify-a-sample first-app workflow or DOCA_ERROR_*
program-side debugging, and "where is X documented" knowledge-map
questions — those belong to other skills.
metadata:
kind: library
compatibility: >
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 /opt/mellanox/doca. The agent must
have a target-host command channel or provide commands for the user
to run and return their exact output; local shell access must not be
assumed to reach the target.DOCA setup
Where to start: If the user's question is deployment-shaped
("how do I deploy", "how do I run my DOCA workload", "I just got a
BlueField, what now", "my code is built, what next"), walk
TASKS.md ## recognize first. It is the
bundle's front-door: it detects the system shape (host x86 / BlueField
Arm bare-metal / DPU-only / fresh laptop), asks the developer the
minimal set of questions needed to disambiguate, and routes to the
correct downstream skill — the container deployment path
(doca-container-deployment),
the bare-metal hardware deployment path
(doca-bare-metal-deployment),
or the no-hardware fallback
(TASKS.md ## no-install). The wrong failure
mode is to silently steer every developer onto containers because the
agent loaded that skill first; ## recognize exists to prevent that.
If the user does not have DOCA installed yet and the request is not
deployment-shaped, jump straight to
TASKS.md ## no-install for the NGC container
path. Deployment-shaped requests still enter ## recognize first,
which routes fresh-laptop cases to ## no-install. Otherwise read
## When to load this skill to confirm the
question is env-class, then route to the section below that matches the
user's intent.
Example questions this skill answers well
The CLASSES this skill is built to handle, each with one worked example. The skill must answer the class; the worked example is illustrative.
- "I want to deploy a DOCA workload — what is the right path?" —
worked example: "I just got a BlueField; my code is built; what
now?" Resolved by the front-door decision tree in
TASKS.md ## recognize, which detects the system shape, asks the minimum residual question, and routes to either the container or the bare-metal deployment skill. - "Verify DOCA is installed and healthy." — worked example:
"Is DOCA Flow actually available on this box?" Resolved by the
install-health snapshot in
TASKS.md ## testplus the version-detection rules inCAPABILITIES.md ## Capabilities and modes. - "I do not have DOCA installed — what now?" — worked example: "I'm
on macOS and want to learn DOCA before I get a BlueField." Resolved
by
TASKS.md ## no-install(NGC DOCA container as universal Stage-1). - "Prepare the build environment for any DOCA library." — worked
example: "
pkg-config --cflags doca-flowreturns nothing — what's missing?" Resolved by the build-prep workflow inTASKS.md ## configureand the build-class error taxonomy inCAPABILITIES.md ## Error taxonomy. - "Prepare the runtime preconditions on a real DPU box." — worked
example: "hugepages / representors / devlink — what's the minimum set
before I run my first DOCA Flow program?" Resolved by
TASKS.md ## configureand the runtime observability rules inCAPABILITIES.md ## Observability. - "Diagnose an env-class failure (install / build / runtime)." —
worked example: "My DOCA Flow program built fine but says
pkg-configcannot find it at runtime." Resolved by the layered env-class debug workflow inTASKS.md ## debug. - "Change something about the environment safely." — worked
example: "I want to switch eswitch mode from legacy to switchdev."
Resolved by the safety constraints in
CAPABILITIES.md ## Safety policy.
If the question is library-API-shaped (Flow pipe construction, RDMA
queue setup, …) or program-shaped (how to build, modify a sample, debug
the program itself), route to
doca-programming-guide or the
matching library skill instead — env-class only lives here.
When to load this skill
Load this skill when the user is dealing with the environment around DOCA — installing it, verifying the install is healthy, preparing the build / runtime preconditions, debugging env-class failures, figuring out how to reach an install from a host that doesn't have one yet, or asking a deployment-shaped question that hasn't yet been routed (containers vs. bare-metal) — the front-door routing decision lives here. Concretely:
- The deployment-shape routing front door: "I just got a BlueField, what now?", "my code is built, how do I run it?", "how do I deploy this?" All of these load
## recognizefirst so the agent does not silently push the user onto the wrong path. - Verifying that the DOCA install is healthy and that the build environment can find it (
pkg-config, headers, library paths). - Preparing the runtime: hugepages,
devlinkdevice visibility, representor enumeration, kernel-module prerequisites. - Diagnosing common setup-class failures: missing
*.pcfile, hugepages not mounted, representor not visible, header-vs-runtime version mismatch. - The I have no install yet path: the user is on macOS, Windows, or a Linux box without DOCA, and needs to reach an environment where DOCA is actually installed. The canonical Stage-1 answer is the public NGC DOCA container at
nvcr.io/nvidia/doca/doca(works on any OS that runs Docker; no NVIDIA hardware required for the build / read / learn loop). SeeTASKS.md ## no-install.
Do not load this skill for:
- "What is DOCA?", "where is the developer guide?", "where is the install layout documented?" — those are routing questions; use
doca-public-knowledge-map. - "How do I derive a custom first application from a sample?", "how do I structure a DOCA build?", "what does
DOCA_ERROR_BAD_STATEmean?" — those are programming-class questions and live indoca-programming-guide, which owns the universal## modify(first-app derivation), the canonical## buildpattern, the universal lifecycle, and the cross-libraryDOCA_ERROR_*taxonomy. - Library-internal API questions (Flow pipe construction, RDMA queue setup, etc.) — those belong in the matching library skill (e.g.
doca-flow). This skill stops at "the install is healthy and the env is ready"; it does not own program semantics.
What this skill provides
This is a thin loader. The body keeps only the orientation needed to pick the right next file. The substantive env material lives in two companion files:
CAPABILITIES.md— what the install / build / runtime environment surface looks like: install profiles (doca-all,doca-ofed,doca-networking), where the build flavors (release vs trace) live on disk and how to pointLD_LIBRARY_PATHat them, the env-side version-detection rules, the env-class error taxonomy (pkg-confignot findingdoca-flow, hugepages not reserved, representors not visible), what a healthy install looks like under observation, and the safety constraints on environment changes (hugepages global,mlxconfigreset, eswitch mode change).TASKS.md— env workflows:recognize(the front-door system-shape detect + dev-Q decision tree that routes deployment-shaped questions to either container or bare-metal),configure(env prep),test(install health snapshot),debug(env-class layered diagnosis), andno-install(the I have no install yet procedure with the NGC container as Path 0). Three other anchors (build,modify,run) exist for lint compliance and route todoca-programming-guide, which owns those verbs after the env / program split.
This skill assumes nothing about whether DOCA is installed — the ## no-install workflow exists precisely for the fresh laptop case.
Loading order
- Read this
SKILL.mdand classify the question as programming, knowledge-map, beginner orientation, deployment routing, or environment work. Programming and knowledge-map questions route to their owning skill and stop here. - For beginner orientation, show the
TASKS.md ## no-installStage 1 vs Stage 2 roadmap before any command. Then route Stage 1/container learning to## no-installPath 0 and Stage 2/hardware runtime to## no-installPaths A/C, followed by## recognizebefore selecting container versus bare-metal. Ask one clarifying question when the stage is unknown; if it remains unknown or no reply is available in unattended execution, stop withconfirmation_requiredand both paths explained rather than guessing. - For deployment routing, walk TASKS.md ## recognize first only when the container-versus-bare-metal path is not already established. If it is established, proceed directly to the matching env workflow.
- Before a change recommendation on an installed/hardware target, load the mandatory Universal verification contract and walk all applicable steps through an auditable green signal. Hardware-touching answers also load the hardware binding-layer command stanza. The Stage-1 no-hardware path instead uses its own container install/smoke green signal; never fabricate unavailable PCIe, representor, or hardware evidence.
- For env workflows —
configure,test,debug, andno-install— see TASKS.md. Thebuild,modify, andrunanchors route todoca-programming-guide. - Once the env is healthy, hand off to the selected deployment skill,
then
doca-programming-guide, then the matching library skill.
Both companion files cross-link to each other and to doca-public-knowledge-map whenever the right answer is "look it up in the public docs or the installed package layout" rather than "setup-specific guidance".
Related skills
doca-container-deployment— the container deployment runtime (kubelet standalone + YAML pod-spec drop) for any DOCA service container on BlueField.## recognizehere routes to this skill when the developer's workload + system shape land on the container path.doca-bare-metal-deployment— the bare-metal hardware deployment runtime (host x86 OR BlueField Arm direct launch — systemd / tmux / direct invocation, hardware-resource binding, per-tenant isolation, restart discipline) for a DOCA-linked binary.## recognizehere routes to this skill when the developer's workload + system shape land on the bare-metal path.doca-public-knowledge-map— public DOCA documentation routing and the on-disk layout of an installed DOCA package. This skill defers all "where is X documented", "where on disk is Y", and "how do I check the installed version" questions to the knowledge-map.doca-programming-guide— general DOCA programming patterns once the env is healthy: the canonicalpkg-config doca-<library>build pattern, the universal derive a custom first app from a sample workflow (with C / C++ + non-C tracks), the universal lifecycle, and the cross-libraryDOCA_ERROR_*taxonomy. Anything beyond "is the install healthy and the env ready" lives there.doca-flow— DOCA Flow on BlueField. Builds on this skill for env preparation and ondoca-programming-guidefor the universal first-app derivation, then layers Flow-specific overrides on top.
评论 (0)
暂无评论，成为第一个评论者吧！