Claude Cursor Skill

cuopt-numerical-optimization-formulation

LP, MILP, QP — concepts, problem-text parsing, and formulation patterns (parameters, constraints, decisions, objective). Concepts only; no API.

LLM Mart · 0 points · 0 views 0 listing impressions 0 install-command copies
Virus-scanned Reviewed automatically before listing.

Full trust report

Download nvidia-skills-skills_cuopt-numerical-optimization-formulation-d8519c5.zip · 15 KB
nvidia/skills 3445 416 forks Apache-2.0 Updated 2d ago
Part of nvidia/skills — 26 skills

Install

skills CLI npx skills add https://github.com/NVIDIA/skills/tree/main/skills/cuopt-numerical-optimization-formulation
Claude Code claude plugin marketplace add https://llmmart.ai/marketplace.json && claude plugin install nvidia-skills@llmmart
Git git clone https://github.com/NVIDIA/skills.git

The skills CLI installs just this skill, for any of its supported agents. Claude Code installs the whole nvidia/skills collection as a plugin from our marketplace. Git is the plain clone.

Skill manifest

Numerical Optimization Formulation

Concepts and workflow for going from a problem description to a clear formulation across LP, MILP, and QP. No API code here.

What is LP / MILP / QP

  • LP: Linear objective, linear constraints, continuous variables.
  • MILP: Same as LP plus some integer or binary variables (e.g., scheduling, facility location, selection).
  • QP: Quadratic objective (e.g., x², x·y terms — portfolio variance, least squares), linear constraints. QP support in cuOpt is currently in beta.

Identifying problem type

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.

Required formulation questions

Ask these if not already clear:

  1. Decision variables — What are they? Bounds?
  2. Objective — Minimize or maximize? Linear or quadratic? For QP: any squared or cross terms (x², x·y)? If maximize a quadratic, the user must negate and minimize.
  3. Constraints — Linear inequalities/equalities? Convex quadratic constraints (inequality only) are also supported, handled as second-order cones; non-convex or equality quadratic constraints are not.
  4. Variable types — All continuous (LP / QP) or some integer/binary (MILP)?
  5. Convexity (QP only) — For minimization, the quadratic form (matrix Q) should be positive semi-definite for well-posed problems.

Typical modeling elements

  • Continuous variables — production amounts, flow, allocations, portfolio weights.
  • Binary variables — open/close, yes/no (e.g., facility open, item selected).
  • Linking constraints — e.g., production only if facility open (Big-M or indicator).
  • Resource constraints — linear cap on usage (materials, time, capacity).
  • Quadratic objective terms — variance (xᵀQx), squared error (‖Ax − b‖²), interaction terms.

Typical QP use cases

  • Portfolio optimization — minimize variance subject to return and budget.
  • Least squares — minimize ‖Ax − b‖² subject to linear constraints.
  • Other quadratic objectives with linear constraints.

Problem statement parsing

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.

🔒 MANDATORY: When in Doubt — Ask

  • If there is any doubt about whether a constraint or value should be included, ask the user and state the possible interpretations.

🔒 MANDATORY: Complete-Path Runs — Try All Variants

  • When the user asks to run the complete path (e.g., end-to-end, full pipeline), run all plausible variants and report all outcomes so the user can choose; do not assume a single interpretation.

Three labels

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.

Implicit constraints: committed vs optional phrasing

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.

Implicit objectives — do not miss

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.

Parsing workflow

  1. Split the problem text into sentences or logical clauses.
  2. Label each: parameter/given | constraint | decision | objective (if stated).
  3. Identify the objective (explicit or implicit): If the problem says "minimize/maximize X", that's the objective. If it only says "determine the plan" (or "find", "establish") but gives costs (and possibly revenues), the objective is implicit — state it (e.g., minimize total cost, or maximize profit) and confirm with the user if ambiguous.
  4. Flag implicit constraints: For each sentence, ask — "Does this state a fixed fact or a requirement (→ parameter/constraint), or something we choose (→ decision)?"
  5. Resolve ambiguity by checking verbs and modals:
    • "is", "has", "operates", "employs", "plans to" (fixed/committed) → parameter or implicit constraint.
    • "may", "can choose", "considers", "decides", "wants to" (optional) → decision or objective.
  6. 🔒 MANDATORY — If anything is still ambiguous (e.g., a value or constraint could be read two ways): ask the user which interpretation is correct, or solve all plausible interpretations and report all outcomes. Do not assume a single interpretation.
  7. Summarize for the user: list parameters, constraints (explicit + flagged implicit), decisions, and objective (explicit or inferred) before writing the math formulation.

Parsing checklist

  • Every sentence has a label (parameter | constraint | decision | objective if stated).
  • Objective is identified: Explicit ("minimize/maximize X") or implicit ("determine the plan" + costs → minimize total cost; + revenues → maximize profit). Never formulate without stating the objective.
  • Committed phrasing ("plans to", "operates", "employs") → not decisions.
  • Optional phrasing ("may", "can choose", "considers") → decisions.
  • Implicit constraints from committed phrasing are written out (e.g., "all X must be produced").
  • 🔒 MANDATORY — Ambiguity: Any phrase that could be read two ways → I asked the user or I will solve all interpretations and report all outcomes (no silent single interpretation).
  • Summary is produced before formulating (parameters, constraints, decisions, objective).

Example

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 rule: minimize only

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.

Common patterns

The remaining sections cover specific LP/MILP modeling patterns. Each is independent — read the one that matches your problem.

Piecewise-linear objectives with integer production

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.

Pattern

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.

Cutting stock / trim loss problems

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.

Correct 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).

Gotcha

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 (preemptive / lexicographic)

Goal programming optimizes multiple objectives in priority order. Implement it as sequential solves — one per priority level.

Formulation pattern

  1. Hard constraints — capacity limits, non-negativity, etc. These hold in every phase.
  2. Goal constraints — for each goal, introduce deviation variables (d⁻ for underachievement, d⁺ for overachievement) and write an equality: expression + d⁻ − d⁺ = target.
  3. Solve sequentially by priority:
    • Phase 1: minimize (or maximize) the relevant deviation for the highest-priority goal.
    • Phase k: fix all higher-priority deviations at their optimal values, then optimize priority k's deviation.

Variable types in goal programming

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.

Multi-period inventory / purchasing models

In problems with buying, selling, and warehouse capacity over multiple periods, decide which capacity constraints to include based on the problem's timing assumptions.

Pattern

For each period t with inventory balance stock[t] = stock[t-1] + buy[t] - sell[t]:

  • End-of-period capacity (variable bound): stock[t] <= capacity — always needed.
  • After-purchase capacity (explicit constraint): stock[t-1] + buy[t] <= capacity — prevents buying more than the warehouse can hold before any sales occur within the period.

When to include the after-purchase constraint

  • Include it when the problem states or implies that purchases are received before sales happen within a period (sequential operations), or when the warehouse physically cannot exceed capacity at any instant.
  • Omit it when buying and selling are concurrent within a period (common in textbook trading/inventory problems) and the capacity applies only to end-of-period stock. Many classic problems only constrain end-of-period inventory.

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.

Blending with shared mixing / intermediate processing

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.

Why the standard blending LP is wrong here

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.

Linearization strategies

  1. 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.

  2. 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.

  3. 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.

Profitability check

Before formulating, check whether using the intermediate in each product is profitable:

  • Compare the minimum cost per ton of the intermediate (using cheapest feasible raw material mix) against each product's selling price.
  • If 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].
  • This analysis often eliminates the need for a bilinear split entirely.
Files (skills)
  • evals
    • evals.json 5.2 KB 
      [
  {
    "id": "numopt-form-eval-001-parse-production-planning",
    "question": "A factory operates 3 production lines and employs 50 workers. It plans to produce products A, B, and C next month. Each product has a known per-unit cost and revenue. Determine the monthly production plan. Classify each sentence as parameter, constraint, decision, or objective, and state the (possibly implicit) objective.",
    "expected_skill": "cuopt-numerical-optimization-formulation",
    "expected_script": null,
    "ground_truth": "The agent classifies each sentence with the four-label framework (parameter / constraint / decision / objective), treats the fixed facts (3 production lines, 50 workers, known cost and revenue) as parameters and the production plan as the decision, and identifies the implicit objective as maximize profit (since both costs and revenues are given) \u2014 not minimize cost. Does not produce code.",
    "expected_behavior": [
      "Classifies each sentence using the four labels (parameter / constraint / decision / objective)",
      "Identifies the implicit objective as maximize profit (revenue \u2212 cost), not minimize cost, since both costs and revenues are given",
      "Does not produce code or an API call sequence \u2014 this skill is concepts only"
    ]
  },
  {
    "id": "numopt-form-eval-002-cutting-stock-objective",
    "question": "I am modeling a cutting stock problem. I have several cutting patterns, each with a different waste width. To minimize material waste, I plan to use this objective: minimize sum_j (waste_width_j * x_j), where x_j is the length cut using pattern j. Is this the correct objective? If not, what is wrong and what should I use instead?",
    "expected_skill": "cuopt-numerical-optimization-formulation",
    "expected_script": null,
    "ground_truth": "The proposed objective is incorrect. Using sum_j (waste_width_j * x_j) only captures trim loss \u2014 the unused strip width within each cutting pattern. It ignores over-production: excess strips produced beyond actual demand are also waste material, but are not penalized by this objective. The solver will over-produce narrow orders to fill patterns efficiently and appear to minimize waste while actually consuming more total material. The correct objective is to minimize total material area consumed: minimize sum_j (roll_width_j * x_j). Since the total useful area demanded is a fixed constant, minimizing total material area is equivalent to minimizing all waste (trim loss plus over-production). The waste can then be computed as: waste = total_material_area_consumed \u2212 required_useful_area, where required_useful_area = sum_i (order_width_i * order_length_i). The agent does not produce code.",
    "expected_behavior": [
      "Identifies the proposed objective as incorrect",
      "Explains that sum_j(waste_width_j * x_j) only captures trim loss and ignores over-production",
      "States that the correct objective is minimize sum_j(roll_width_j * x_j) \u2014 total material area consumed",
      "Explains that waste = total_material_area_consumed minus required_useful_area",
      "Does not produce code \u2014 this skill is formulation concepts only"
    ]
  },
  {
    "id": "numopt-form-eval-003-goal-programming-integer-decisions",
    "question": "I am using goal programming to optimize worker scheduling across two priority levels: first minimize overtime hours, then minimize idle time. I introduced deviation variables d_minus and d_plus for each goal. A colleague says all variables in goal programming are continuous because the deviation variables are continuous. Should the worker count variables also be continuous?",
    "expected_skill": "cuopt-numerical-optimization-formulation",
    "expected_script": null,
    "ground_truth": "The colleague is wrong. Deviation variables (d_minus, d_plus) are always continuous \u2014 they measure how much a goal is under- or over-achieved, which can be fractional. However, decision variables that represent discrete or countable quantities must remain INTEGER regardless of the goal programming structure. Worker counts are a discrete quantity (you cannot hire 2.7 workers), so those variables must be declared as INTEGER. Making them continuous because of the deviation variables is a formulation error: the LP relaxation may yield fractional worker counts that are infeasible in practice and produce a different (lower) objective than the true integer optimum. The agent also describes the standard goal programming pattern: write each goal as an equality with deviation variables (expression + d_minus - d_plus = target), then solve sequentially per priority, fixing higher-priority deviations before optimizing lower ones. Does not produce code.",
    "expected_behavior": [
      "States the colleague is wrong \u2014 deviation variables being continuous does not make all variables continuous",
      "Explains that decision variables representing discrete/countable quantities (like worker counts) must be INTEGER",
      "States that making worker counts continuous is a formulation error that can yield fractional (infeasible) solutions",
      "Describes the goal programming pattern: deviation variables in equality constraints, solved sequentially by priority",
      "Does not produce code \u2014 this skill is formulation concepts only"
    ]
  }
]
  • BENCHMARK.md 4.9 KB 
    # Skill Benchmark: cuopt-numerical-optimization-formulation

> ✅ **Overall verdict: PASS — Recommended for publication**

## Publication Recommendation

Recommended for publication based on the completed evaluation evidence in this report.

## Evaluation Metadata

- Skill: `cuopt-numerical-optimization-formulation`
- Evaluation date: 2026-08-05
- Evaluator version: `1.0.0`
- Agents: Claude Code (`aws/anthropic/bedrock-claude-opus-4-8`), Codex (`openai/openai/gpt-5.5`)
- Tasks: 3 evaluation tasks (3 positive)
- Dataset digest: `sha256:7f39d48b2b7e50bd2a24f83c7f6172f1f16b1895a59e237bb4c345cf690cb71e` (skill-evaluator-dataset-snapshot/1)
- Attempts per task: 1
- Environment: `k8s-sandbox`
- Tier 3 evidence: required for publication

Each task attempt ran in its own isolated sandbox pod.

## What This Report Answers

The three-tier evaluation checks whether the skill:

- is safe to use;
- produces correct answers;
- is discovered and activated when needed;
- helps the agent complete the user's goal and expected workflow; and
- avoids wasted skill and tool usage.

## Results at a Glance

| Measure | Claude Code (Baseline → Skill Uplift) | Codex (Baseline → Skill Uplift) |
|---|---:|---:|
| Overall | 59% → 100% (+41 points) | 58% → 97% (+39 points) |
| Security | 100% → 100% (±0 points) | 100% → 100% (±0 points) |
| Correctness | 100% → 100% (±0 points) | 100% → 100% (±0 points) |
| Discoverability | 0% → 100% (+100 points) | 0% → 94% (+94 points) |
| Effectiveness | 97% → 100% (+3 points) | 91% → 90% (-1 points) |
| Efficiency | 0% → 100% (+100 points) | 0% → 100% (+100 points) |

**How to read this table:** baseline is the same task attempted without the target skill. Uplift is `skill score - baseline score`, shown in percentage points.

Example: `47% → 92% (+45 points)` means the skill-assisted run scored 92%, 45 percentage points above its 47% no-skill baseline.

## Tier Status

| Tier | Purpose | Status | Evidence |
|---|---|---|---|
| Tier 1 | Static validation | **PASSED WITH OBSERVATIONS** | 1 validator(s); 4 finding(s) |
| Tier 2 | Semantic deduplication | **NOT RUN** | No result was recorded |
| Tier 3 | Live agent evaluation | **PASS** | 2 agent(s); 3 task(s) |

## Findings and Observations

<details>
<summary>Show detailed findings and successful checks</summary>

- **MEDIUM** SCHEMA/frontmatter_field_placement: Root field 'version' is ignored; use 'metadata.version' (`skills/cuopt-numerical-optimization-formulation/SKILL.md`)
- **MEDIUM** SCHEMA/body_recommended_section: Missing recommended section: '## Instructions' (`skills/cuopt-numerical-optimization-formulation/SKILL.md`)
- **MEDIUM** SCHEMA/body_recommended_section: Missing recommended section: '## Examples' (`skills/cuopt-numerical-optimization-formulation/SKILL.md`)
- **LOW** SCHEMA/author_format: Author must be of the form 'Name <email@host>' (`skills/cuopt-numerical-optimization-formulation/SKILL.md`)

</details>

## Scoring Methodology

<details>
<summary>Show dimension definitions, source signals, and thresholds</summary>

| Dimension | Question | Scored signals |
|---|---|---|
| Security | Is it safe to use? | `security` (100%) |
| Correctness | Is the answer correct? | `accuracy` (100%) |
| Discoverability | Was the right skill loaded when needed? | `skill_execution` (100%) |
| Effectiveness | Did the skill help complete the task? | `goal_accuracy` (50%) + `behavior_check` (50%) |
| Efficiency | Did it avoid wasted tool or skill usage? | `skill_efficiency` (100%) |

- Dimension bands: PASS at 50% or above; NEUTRAL from 40% to below 50%; FAIL below 40%.
- Overall Tier 3 lift: PASS at +5 points or more; FAIL at -10 points or less; values between those bands are NEUTRAL.
- Overall verdict: PASS only when every configured dimension passes for at least one supported agent. Lift is reported as diagnostic evidence and does not override this gate.
- The 50% attempt pass threshold is a separate per-task gate; it is not the dimension pass threshold.
- Effectiveness is the equal-weight mean of goal completion (`goal_accuracy`) and expected workflow adherence (`behavior_check`).
- Token efficiency is a separate report-only signal. It does not change a dimension score or the overall verdict.

Signals present in this run:

- `security` (Security): unsafe operations, secret leakage, and unauthorized access.
- `skill_execution` (Skill Execution): whether the expected skill was found and executed.
- `skill_efficiency` (Efficiency): routing quality, workspace-aware skill reads, and productive tool use.
- `accuracy` (Accuracy): final-answer correctness against the reference answer.
- `goal_accuracy` (Goal Accuracy): whether the user's goal was achieved.
- `behavior_check` (Behavior Check): whether the expected workflow behavior was followed.

</details>

## Freshness

Regenerate this benchmark when the skill, evaluation dataset, target agent/model, evaluator version, environment, or scoring policy changes.
  • skill-card.md 3.7 KB 
    ## Description: <br>
LP, MILP, QP — concepts, problem-text parsing, and formulation patterns (parameters, constraints, decisions, objective). Concepts only; no API. <br>

This skill is ready for commercial/non-commercial use. <br>

## Owner
NVIDIA <br>

### License/Terms of Use: <br>
Apache-2.0 <br>
## Use Case: <br>
Developers and engineers use this skill to parse optimization problem descriptions and formulate LP, MILP, and QP models with correct parameters, constraints, decisions, and objectives. <br>

### Deployment Geography for Use: <br>
Global <br>

## Requirements / Dependencies: <br>
**Requires API Key or External Credential:** [No] <br>
**Credential Type(s):** [None] <br>

Do not include secrets in prompts/logs/output; use least-privilege credentials; rotate keys as appropriate. <br>

## Known Risks and Mitigations: <br>
Risk: Review before execution as proposals could introduce incorrect or misleading guidance into skills. <br>
Mitigation: Review and scan skill before deployment. <br>

## Reference(s): <br>


## Skill Output: <br>
**Output Type(s):** [Analysis] <br>
**Output Format:** [Markdown] <br>
**Output Parameters:** [1D] <br>
**Other Properties Related to Output:** [None] <br>

## Evaluation Agents Used: <br>
- Claude Code (`aws/anthropic/bedrock-claude-opus-4-8`) <br>
- Codex (`openai/openai/gpt-5.5`) <br>



## Evaluation Tasks: <br>
3 evaluation tasks (3 positive) from skill-evaluator-dataset-snapshot/1, each run in an isolated sandbox pod. <br>

## Evaluation Metrics Used: <br>
Reported benchmark dimensions: <br>
- Security: Checks for unsafe operations, secret leakage, and unauthorized access. <br>
- Correctness: Checks final-answer correctness against the reference answer. <br>
- Discoverability: Checks whether the expected skill was found and executed when needed. <br>
- Effectiveness: Checks whether the skill helped complete the user's goal (goal completion + expected workflow adherence). <br>
- Efficiency: Checks routing quality, workspace-aware skill reads, and productive tool use. <br>

Underlying evaluation signals used in this run: <br>
- `security`: Unsafe operations, secret leakage, and unauthorized access. <br>
- `skill_execution`: Whether the expected skill was found and executed. <br>
- `skill_efficiency`: Routing quality, workspace-aware skill reads, and productive tool use. <br>
- `accuracy`: Final-answer correctness against the reference answer. <br>
- `goal_accuracy`: Whether the user's goal was achieved. <br>
- `behavior_check`: Whether the expected workflow behavior was followed. <br>



## Evaluation Results: <br>
| Measure | Claude Code (Baseline → Skill Uplift) | Codex (Baseline → Skill Uplift) |
|---|---:|---:|
| Overall | 59% → 100% (+41 points) | 58% → 97% (+39 points) |
| Security | 100% → 100% (±0 points) | 100% → 100% (±0 points) |
| Correctness | 100% → 100% (±0 points) | 100% → 100% (±0 points) |
| Discoverability | 0% → 100% (+100 points) | 0% → 94% (+94 points) |
| Effectiveness | 97% → 100% (+3 points) | 91% → 90% (-1 points) |
| Efficiency | 0% → 100% (+100 points) | 0% → 100% (+100 points) |

## Skill Version(s): <br>
26.10.00 (source: frontmatter) <br>

## Ethical Considerations: <br>
NVIDIA believes Trustworthy AI is a shared responsibility and we have established policies and practices to enable development for a wide array of AI applications. When downloaded or used in accordance with our terms of service, developers should work with their internal team to ensure this skill meets requirements for the relevant industry and use case and addresses unforeseen product misuse. <br>

(For Release on NVIDIA Platforms Only) <br>
Please report quality, risk, security vulnerabilities or NVIDIA AI Concerns [here](https://app.intigriti.com/programs/nvidia/nvidiavdp/detail). <br>
  • SKILL.md 19.1 KB 
    ---
name: cuopt-numerical-optimization-formulation
version: "26.10.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
    - concepts
---




# Numerical Optimization Formulation

Concepts and workflow for going from a problem description to a clear formulation across LP, MILP, and QP. No API code here.

## What is LP / MILP / QP

- **LP**: Linear objective, linear constraints, continuous variables.
- **MILP**: Same as LP plus some integer or binary variables (e.g., scheduling, facility location, selection).
- **QP**: Quadratic objective (e.g., x², x·y terms — portfolio variance, least squares), linear constraints. **QP support in cuOpt is currently in beta.**

## Identifying problem type

| 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.

## Required formulation questions

Ask these if not already clear:

1. **Decision variables** — What are they? Bounds?
2. **Objective** — Minimize or maximize? Linear or quadratic? For QP: any squared or cross terms (x², x·y)? If maximize a quadratic, the user must negate and minimize.
3. **Constraints** — Linear inequalities/equalities? Convex quadratic constraints (inequality only) are also supported, handled as second-order cones; non-convex or equality quadratic constraints are not.
4. **Variable types** — All continuous (LP / QP) or some integer/binary (MILP)?
5. **Convexity (QP only)** — For minimization, the quadratic form (matrix Q) should be positive semi-definite for well-posed problems.

## Typical modeling elements

- **Continuous variables** — production amounts, flow, allocations, portfolio weights.
- **Binary variables** — open/close, yes/no (e.g., facility open, item selected).
- **Linking constraints** — e.g., production only if facility open (Big-M or indicator).
- **Resource constraints** — linear cap on usage (materials, time, capacity).
- **Quadratic objective terms** — variance (xᵀQx), squared error (‖Ax − b‖²), interaction terms.

## Typical QP use cases

- Portfolio optimization — minimize variance subject to return and budget.
- Least squares — minimize ‖Ax − b‖² subject to linear constraints.
- Other quadratic objectives with linear constraints.

---

## Problem statement parsing

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.

### 🔒 MANDATORY: When in Doubt — Ask

- If there is **any doubt** about whether a constraint or value should be included, **ask the user** and state the possible interpretations.

### 🔒 MANDATORY: Complete-Path Runs — Try All Variants

- When the user asks to **run the complete path** (e.g., end-to-end, full pipeline), run all plausible variants and **report all outcomes** so the user can choose; do not assume a single interpretation.

### Three labels

| 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. |

### Implicit constraints: committed vs optional phrasing

**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. |

### Implicit objectives — do not miss

**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.

### Parsing workflow

1. **Split** the problem text into sentences or logical clauses.
2. **Label** each: parameter/given | constraint | decision | **objective** (if stated).
3. **Identify the objective (explicit or implicit):** If the problem says "minimize/maximize X", that's the objective. If it only says "determine the plan" (or "find", "establish") but gives costs (and possibly revenues), the objective is **implicit** — state it (e.g., minimize total cost, or maximize profit) and confirm with the user if ambiguous.
4. **Flag implicit constraints**: For each sentence, ask — "Does this state a fixed fact or a requirement (→ parameter/constraint), or something we choose (→ decision)?"
5. **Resolve ambiguity** by checking verbs and modals:
   - "is", "has", "operates", "employs", "plans to" (fixed/committed) → parameter or implicit constraint.
   - "may", "can choose", "considers", "decides", "wants to" (optional) → decision or objective.
6. **🔒 MANDATORY — If anything is still ambiguous** (e.g., a value or constraint could be read two ways): ask the user which interpretation is correct, or solve all plausible interpretations and report all outcomes. Do not assume a single interpretation.
7. **Summarize** for the user: list parameters, constraints (explicit + flagged implicit), decisions, and **objective (explicit or inferred)** before writing the math formulation.

### Parsing checklist

- [ ] Every sentence has a label (parameter | constraint | decision | objective if stated).
- [ ] **Objective is identified:** Explicit ("minimize/maximize X") or implicit ("determine the plan" + costs → minimize total cost; + revenues → maximize profit). Never formulate without stating the objective.
- [ ] Committed phrasing ("plans to", "operates", "employs") → not decisions.
- [ ] Optional phrasing ("may", "can choose", "considers") → decisions.
- [ ] Implicit constraints from committed phrasing are written out (e.g., "all X must be produced").
- [ ] **🔒 MANDATORY — Ambiguity:** Any phrase that could be read two ways → I asked the user or I will solve all interpretations and report all outcomes (no silent single interpretation).
- [ ] Summary is produced before formulating (parameters, constraints, decisions, **objective**).

### Example

**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 rule: minimize only

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.

---

## Common patterns

The remaining sections cover specific LP/MILP modeling patterns. Each is independent — read the one that matches your problem.

### Piecewise-linear objectives with integer production

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.

#### Pattern

```
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.
```

### Cutting stock / trim loss problems

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.

#### Correct 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)`.

#### Gotcha

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 (preemptive / lexicographic)

Goal programming optimizes multiple objectives in priority order. Implement it as **sequential solves** — one per priority level.

#### Formulation pattern

1. **Hard constraints** — capacity limits, non-negativity, etc. These hold in every phase.
2. **Goal constraints** — for each goal, introduce deviation variables (d⁻ for underachievement, d⁺ for overachievement) and write an equality: `expression + d⁻ − d⁺ = target`.
3. **Solve sequentially by priority:**
   - Phase 1: minimize (or maximize) the relevant deviation for the highest-priority goal.
   - Phase k: fix all higher-priority deviations at their optimal values, then optimize priority k's deviation.

#### Variable types in goal programming

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.

### Multi-period inventory / purchasing models

In problems with buying, selling, and warehouse capacity over multiple periods, decide which capacity constraints to include based on the problem's timing assumptions.

#### Pattern

For each period *t* with inventory balance `stock[t] = stock[t-1] + buy[t] - sell[t]`:

- **End-of-period capacity** (variable bound): `stock[t] <= capacity` — always needed.
- **After-purchase capacity** (explicit constraint): `stock[t-1] + buy[t] <= capacity` — prevents buying more than the warehouse can hold before any sales occur within the period.

#### When to include the after-purchase constraint

- **Include it** when the problem states or implies that purchases are received before sales happen within a period (sequential operations), or when the warehouse physically cannot exceed capacity at any instant.
- **Omit it** when buying and selling are concurrent within a period (common in textbook trading/inventory problems) and the capacity applies only to end-of-period stock. Many classic problems only constrain end-of-period inventory.

**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.

### Blending with shared mixing / intermediate processing

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.

#### Why the standard blending LP is wrong here

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.

#### Linearization strategies

1. **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.

2. **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.

3. **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.

#### Profitability check

Before formulating, check whether using the intermediate in each product is profitable:
- Compare the **minimum cost per ton** of the intermediate (using cheapest feasible raw material mix) against each product's **selling price**.
- If `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]`.
- This analysis often eliminates the need for a bilinear split entirely.
  • skill.oms.sig 4.5 KB · in bundle

Comments (0)

Sign in to join the conversation.

No comments yet.

Reviews (0)

No reviews yet.

Related

Claude Prompt
Tighten-my-prose editing prompt
Claude Skill
Adversarial code-review skill for Claude
Claude Workflow
Deep-research workflow (fan-out + verify)
Claude Skill
Conventional-commit writer for Claude