菜单
Infer optimization structure from uploaded tables and identify minimal clarifications before cuOpt modeling.
默认使用会先检查来源的 Prompt；你也可以切换为直接命令，或下载本地副本。
决定是否安装前，请先阅读 SKILL.md，以及 SkillsMP 当前展示的配套文件。
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
直接命令不会经过审查 Prompt；运行前请先检查来源。
npx skills add https://github.com/NVIDIA/cuopt-examples --skill tabular-optimization-ingestion命令会保持在同一行。复制前请横向滚动并检查完整内容。
想先保存到本地？可下载 SkillsMP 当前能够提供的文件。
基于 SOC 职业分类
正在显示 SKILL.md
| name | tabular-optimization-ingestion |
| version | 26.06.01 |
| description | Infer optimization structure from uploaded tables and identify minimal clarifications before cuOpt modeling. |
| license | Apache-2.0 |
| metadata | {"author":"NVIDIA cuOpt Team","tags":["cuopt","nemoclaw","orchestration"]} |
| origin | skill-evolution |
Use this skill when the user provides raw or semi-structured data and asks a question that may require optimization.
The purpose of this skill is to bridge the gap between messy uploaded data and solver-ready model construction.
This skill does not solve the optimization problem itself. It inspects the data, infers likely modeling roles, and identifies what still needs clarification.
It does not authorize heuristic, greedy, or backtracking schedules as
answers. In the NemoClaw sandbox, read cuopt-sandbox: the first solver
that produces assignments or a schedule must be cuOpt after probe → env →
smoke gates pass. Ingestion output is a modeling interpretation (entities,
objective fields, constraints) — never a completed plan.
This skill refines the optimization interpretation using the uploaded data; it does not replace the earlier intent decision unless the data clearly contradicts it.
Users do not upload:
They upload things like:
This skill turns raw tables into a candidate optimization interpretation.
After inspection, produce a compact working interpretation containing:
For each uploaded source, determine:
Examples:
Always state the candidate row meaning before modeling from it.
Inspect column names and values for roles such as:
Objective-like fields:
Constraint-like fields:
Identifier / relationship fields:
Infer what the model is probably deciding.
Examples:
Do not overcommit when the data supports multiple plausible decisions. Note the candidates and ask one focused question if needed.
Use common table patterns:
Typical signs:
Typical signs:
Typical signs:
Before handing off, identify the smallest set of unanswered questions that block valid model construction.
Examples:
Do not ask broad generic questions if the data already strongly suggests the answer.
Summarize findings compactly:
This summary should be short enough that a downstream formulation skill can use it directly.
Use these heuristics carefully. They guide interpretation but do not prove it.
cost, unit_cost, shipping_cost, expense → likely minimization coefficientprofit, margin, contribution → likely maximization coefficientdistance, travel_time, duration → likely routing objective term or service constraintrisk, variance, covariance → likely QP signalcapacity, available, limit, max_* → upper bound / resource constraintdemand, required, need → demand fulfillment or service requirementmin_*, minimum_* → lower bound or service ruleTreat MILP as likely when the data or request suggests:
Treat routing as likely when the core question depends on path construction, not merely allocation.
Signs include:
Duplicate values in a foreign-key column across rows of a parent table usually signal a shared agent or resource — one entity serving multiple parents. Shared resources need a mutual-exclusion constraint that no other column states.
coach_id, driver_id, instructor_id, nurse_id, operator_id → shared agent; can serve only one parent at a timemachine_id, bay_id, tool_id → shared resource; can host only one job at a timedistinct_values < row_count → check whether simultaneous assignment is allowedA *_unavailability (or *_availability) table documents known absences; duplicated FK values document implicit conflicts. Treat both as constraint sources. Concrete check: for every FK-looking column in a parent table, compare distinct value count to row count, and surface the column when distinct < rows.
Before handing off to formulation, compare aggregate requirements against upper bounds implied by the tables:
If required appearances exceed what the time structure can host, flag the conflict before building the full MILP. Example: 8 required games per team with at most 1 game per team per week over 5 weeks allows only 5 games — infeasible without relaxing the weekly cap.
Files include:
products.csv with columns like product, profit, labor_hours, steel_unitscapacity.csv with columns like resource, availableLikely interpretation:
products.csv = one productcapacity.csv = one resource limitFiles include:
customers.csv with customer_id, demand, time_window_start, time_window_endvehicles.csv with vehicle_id, capacitytravel_times.csv with origin/destination or matrix-style travel timesLikely interpretation:
Files include patterns such as:
games.csv or jobs.csv — items to place (events, tasks, orders)time_slots.csv or shifts.csv — when placement can occurcourts.csv, machines.csv, or rooms.csv — resourcesteams.csv or workers.csv — entities tied to shared agents (coaches, operators)*_unavailability.csv — blocked (resource, slot) or (agent, slot) pairsLikely interpretation:
optimization-from-data-orchestrator + cuopt-sandbox before any custom scheduler codeFile includes:
sales_history.csv with order_id, date, region, revenue, units_soldLikely interpretation:
cost and capacity is automatically a valid optimization model.If the data suggests LP / MILP:
numerical-optimization-formulationcuopt-numerical-optimization-api-python (or
cuopt-numerical-optimization-api-cli for MPS inputs)If the data suggests QP:
numerical-optimization-formulationcuopt-numerical-optimization-api-pythonIf the data suggests routing:
routing-formulationcuopt-routing-api-pythonIf mode selection is still needed because replayability, audit, export, or reuse may matter:
optimization-mode-router before deep model constructionIf optimization intent itself is still uncertain:
optimization-intent-routerThis skill succeeds when the downstream model-building step can proceed with either:
It fails when it produces a vague restatement of the table without narrowing the modeling interpretation.