复制安装命令
用 Codex 或 Claude 安装复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它先审查 Skill 页面再帮你安装。
复制前请先查看来源、License 和安全提示。
Official, NVIDIA-verified Agent Skills for Claude Code, Codex, and other coding agents.
用 Codex 或 Claude 安装复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它先审查 Skill 页面再帮你安装。
复制前请先查看来源、License 和安全提示。
来源文件:README.md
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.
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.
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.
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
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.
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.
Where to file an issue depends on what's broken:
Per-product source repo links:
For issues with this catalog repo itself (README, structure, listing a new product): open an issue here.
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 against nv-agent-root-cert.pem)evals/evals.json, evals/*.json, eval/*.json, or benchmark/evals.jsonBENCHMARK.md — generated benchmark report capturing verifiable uplift dataVerify 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.
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-*, cufolio, 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
│ ├── 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 against nv-agent-root-cert.pem)skill-card.md — skill identity and governance cardevals/evals.json, evals/*.json, eval/*.json, or benchmark/evals.jsonWhen evaluation runs produce a BENCHMARK.md, it ships alongside the skill so consumers can see verifiable benchmark uplift data.
This repository adheres to the Agent Skills specification:
SKILL.md file at their root.name and description fields.skills-ref reference library.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.
name: cuopt-numerical-optimization-formulation
version: "26.08.00"
description: LP, MILP, QP — concepts, problem-text parsing, and formulation patterns (parameters, constraints, decisions, objective). Concepts only; no API.
license: Apache-2.0
metadata:
author: NVIDIA cuOpt Team
tags:
- linear-programming
- milp
- qp
- formulation
- conceptsConcepts and workflow for going from a problem description to a clear formulation across LP, MILP, and QP. No API code here.
| Property | LP | MILP | QP |
|---|---|---|---|
| Objective | Linear | Linear | Quadratic (xᵀQx + cᵀx) |
| Constraints | Linear | Linear | Linear + convex quadratic (inequality only) via second-order cones |
| Variables | Continuous | Mixed: continuous + integer/binary | Continuous |
| Sense | min or max | min or max | minimize only (negate to max) |
| Duals / sensitivity | Dual values + reduced costs | None (integer optima) | Dual values + reduced costs |
If the objective is purely linear, prefer LP/MILP — do not artificially introduce quadratic terms. If any variable is integer or binary, the problem is MILP regardless of the rest.
Post-solve sensitivity (LP / QP only). Continuous LP and QP solutions expose dual values (the marginal objective change per unit a binding constraint is relaxed: where to invest to improve the outcome) and reduced costs (for a variable the optimizer left at zero, how far it must improve to enter the solution: a near-miss). MILP solutions have no duals — integer optima are not continuous, so there are none to return. Duals are also unavailable when the model includes quadratic constraints — the second-order cone path returns primal values only. See the language-specific API skills for how to retrieve them after a solve.
Ask these if not already clear:
When the user gives problem text, classify every sentence and then summarize before formulating. The parsing framework below applies regardless of LP / MILP / QP.
Classify every sentence as parameter/given, constraint, decision, or objective. Watch for implicit constraints (e.g., committed vs optional phrasing) and implicit objectives (e.g., "determine the plan" + costs → minimize total cost).
Ambiguity: If anything is still ambiguous, ask the user or solve all plausible interpretations and report all outcomes; do not assume a single interpretation.
| Label | Meaning | Examples (sentence type) |
|---|---|---|
| Parameter / given | Fixed data, inputs, facts. Not chosen by the model. | "Demand is 100 units." "There are 3 factories." "Costs are $5 per unit." |
| Constraint | Something that must hold. May be explicit or implicit from phrasing. | "Capacity is 200." "All demand must be met." "At least 2 shifts must be staffed." |
| Decision | Something we choose or optimize. | "How much to produce." "Which facilities to open." "How many workers to hire." |
| Objective | What to minimize or maximize. May be explicit ("minimize cost") or implicit ("determine the plan" with costs given). | "Minimize total cost." "Determine the production plan" (with costs) → minimize total cost. |
Committed/fixed phrasing → treat as parameter or implicit constraint (everything mentioned is given or must happen). Not a decision.
| Phrasing | Interpretation | Why |
|---|---|---|
| "Plans to produce X products" | Constraint: all X must be produced. | Commitment; production level is fixed. |
| "Operates 3 factories" | Parameter: all 3 are open. Not a location-selection problem. | Current state is fixed. |
| "Employs N workers" | Parameter: all N are employed. Not a hiring decision. | Workforce size is given. |
| "Has a capacity of C" | Parameter (C) + constraint: usage ≤ C. | Capacity is fixed. |
| "Must meet all demand" | Constraint: demand satisfaction. | Explicit requirement. |
Optional/decision phrasing → treat as decision.
| Phrasing | Interpretation | Why |
|---|---|---|
| "May produce up to …" | Decision: how much to produce. | Optional level. |
| "Can choose to open" (factories, sites) | Decision: which to open. | Selection is decided. |
| "Considers hiring" | Decision: how many to hire. | Hiring is under consideration. |
| "Decides how much to order" | Decision: order quantities. | Explicit decision. |
| "Wants to minimize/maximize …" | Objective (drives decisions). | Goal; decisions are the levers. |
If the problem asks to "determine the plan" (or similar) but does not state "minimize" or "maximize" explicitly, the objective is often implicit. You MUST identify it and state it before formulating; do not build a model with no objective.
| Phrasing / context | Likely implicit objective | Why |
|---|---|---|
| "Determine the production plan" + costs given (per unit, per hour, etc.) | Minimize total cost (production + inspection/sales + overtime, etc.) | Plan is chosen; costs are specified → natural goal is to minimize total cost. |
| "Determine the plan" + costs and revenues given | Maximize profit (revenue − cost) | Both sides of the ledger → optimize profit. |
| "Try to determine the monthly production plan" + workshop hour costs, inspection/sales costs | Minimize total cost | All cost components are given; no revenue to maximize → minimize total cost. |
Rule: When the problem gives cost (or cost and revenue) data and asks to "determine", "find", or "establish" the plan, always state the objective explicitly (e.g., "I'm treating the objective as minimize total cost, since only costs are given."). If both cost and revenue are present, state whether you use "minimize cost" or "maximize profit". Ask the user if unclear.
Text: "The company operates 3 factories and plans to produce 500 units. It may use overtime at extra cost. Minimize total cost."
| Sentence / phrase | Label | Note |
|---|---|---|
| "Operates 3 factories" | Parameter | All 3 open; not facility selection. |
| "Plans to produce 500 units" | Constraint (implicit) | All 500 must be produced. |
| "May use overtime at extra cost" | Decision | How much overtime is a decision. |
| "Minimize total cost" | Objective | Drives decisions. |
Result: Parameters = 3 factories, 500 units target. Constraints = produce exactly 500 (implicit from "plans to produce"). Decisions = production allocation across factories, overtime amounts. Objective = minimize cost.
Implicit-objective example: A problem that asks to "determine the production plan" (or similar) and gives cost components (e.g., workshop, inspection, sales) but does not state "minimize" or "maximize" → Objective is implicit: minimize total cost. Always state it explicitly: "The objective is to minimize total cost."
QP objectives must be minimization. To maximize a quadratic expression, negate it and minimize; then negate the optimal value.
For minimization to be well-posed, the quadratic form Q should be positive semi-definite. If Q is indefinite, the problem is non-convex and may not have a finite optimum.
The remaining sections cover specific LP/MILP modeling patterns. Each is independent — read the one that matches your problem.
When modeling concave piecewise-linear profit/cost functions (e.g., decreasing marginal profit for bulk sales), the standard approach uses continuous segment variables with upper bounds equal to each segment's width. For a maximization with concave profit, the solver fills higher-profit segments first naturally.
Gotcha: If the quantity being produced is discrete (pieces, units, items), the total production variable must be INTEGER, even though segment variables can remain CONTINUOUS. Without this, the LP relaxation may yield a fractional total that produces a different (higher or lower) objective than the true integer optimum.
x_total — INTEGER (total production of a product)
s1, s2, … — CONTINUOUS (amount sold in each price segment, bounded by segment width)
Link: x_total = s1 + s2 + …
Resource constraints use x_total.
Objective uses segment variables × segment profit rates.
In cutting stock problems, waste area includes both trim loss (unused width within each cutting pattern) and over-production (excess strips produced beyond demand). Minimizing only trim loss (waste width × length per pattern) ignores over-production and yields an incorrect objective.
Since the total useful area demanded is a constant, minimizing waste is equivalent to minimizing total material area consumed:
minimize sum_j (roll_width_j × x_j)
where x_j is the length cut using pattern j. The waste area is then:
waste = total_material_area − required_useful_area
where required_useful_area = sum_i (order_width_i × order_length_i).
Using sum_j (waste_width_j × x_j) as the objective only captures trim loss — the unused strip within each pattern. It does not penalize over-production of an order. The solver will over-produce narrow orders to fill patterns efficiently, but that excess material is still waste. Always use total material area as the objective.
Goal programming optimizes multiple objectives in priority order. Implement it as sequential solves — one per priority level.
expression + d⁻ − d⁺ = target.Deviation variables (d⁻, d⁺) and slack/idle-time variables are always continuous. However, decision variables must still be INTEGER when they represent discrete/countable quantities (units produced, vehicles, workers, etc.). Do not let the presence of continuous deviation variables cause you to make all variables continuous — the integrality of decision variables directly affects feasibility and objective values.
In problems with buying, selling, and warehouse capacity over multiple periods, decide which capacity constraints to include based on the problem's timing assumptions.
For each period t with inventory balance stock[t] = stock[t-1] + buy[t] - sell[t]:
stock[t] <= capacity — always needed.stock[t-1] + buy[t] <= capacity — prevents buying more than the warehouse can hold before any sales occur within the period.Key interaction with the sell constraint: If the model already has sell[t] <= stock[t-1] (grain bought this period cannot be sold this period), the model is bounded even without the after-purchase constraint. The sell constraint prevents unbounded buy-sell cycling. The after-purchase constraint is then an additional physical restriction, not a mathematical necessity.
Default: If the problem does not specify timing within a period, use only end-of-period capacity (stock[t] <= capacity). Add the after-purchase constraint only if the problem explicitly requires it.
In some blending problems, a subset of raw materials must be mixed together first (e.g., in a mixing tank) before being allocated to different products. The resulting intermediate has a uniform composition — you cannot independently assign different raw materials to different products.
The standard blending LP uses variables x[i][j] (amount of raw material i in product j) and freely allocates each raw material to each product. When raw materials share a mixing step, the proportions of those raw materials must be identical in every product that receives the intermediate. This proportionality constraint is bilinear (x[A,1]*x[B,2] = x[B,1]*x[A,2]) and cannot be directly expressed in an LP.
Single-product allocation: If analysis shows the intermediate is profitable in only one product, allocate all intermediate to that product (set intermediate allocation to other products to zero). The proportionality constraint becomes trivially satisfied. This is the most common case — check profitability of intermediate in each product before attempting a general split.
Parametric over intermediate concentration: Fix the sulfur/quality concentration of the intermediate as a parameter σ. For each fixed σ, the problem is a standard LP (intermediate becomes a virtual raw material with known properties). Solve for a grid of σ values or use the structure to find the optimum analytically.
Scenario enumeration: When only 2–3 products exist, enumerate which products receive the intermediate (all-to-A, all-to-B, split). For each scenario with a single recipient, the LP is standard. For split scenarios, use strategy 2.
Before formulating, check whether using the intermediate in each product is profitable:
cost_intermediate > sell_price[j] for some product j, the intermediate should not be allocated to product j. Raw material C (or other direct inputs) alone may also be unprofitable if cost_C > sell_price[j].
评论 (0)
暂无评论,成为第一个评论者吧!