cuopt-skill-evolution

Skill Evolution

Skills improve through a single workflow: solve the user's problem, notice when a generalizable learning surfaced, score it if you can, then propose an update. The presence or absence of ground truth changes the confidence attached to a proposal, not the steps you take.

Trigger conditions

You MUST evaluate whether to enter the skill evolution workflow when ANY of these events occur during a conversation:

1. User correction — The user corrects your output (e.g., "the answer should be X", "no, use Y instead of Z"). A correction means the skill that guided you was missing information.
2. Retry after failure — Your code/formulation failed (wrong result, solver error, runtime exception) and you had to change approach. The fix likely contains a generalizable pattern.
3. Undocumented behavior — You discovered an API behavior, default value, or constraint not mentioned in the relevant skill.
4. Workaround — You had to work around a limitation or gotcha not documented in any skill.
5. Variable type or modeling error — You chose the wrong variable type (e.g., CONTINUOUS vs INTEGER), constraint form, or objective structure, and the correction changed the result.
6. Thrash before landing — You arrived at the right answer, but only after visibly thrashing: writing dead code that you then deleted, rewriting the same construct multiple times, or exploring 2+ approaches before settling. The final code looks fine, but the path to it shows the skill failed to point you at the right pattern from the start. The fix is usually a worked example or a "prefer X over Y" note that would have saved the detour.

When a trigger fires: Finish solving the user's problem first, then evaluate whether the learning is generalizable (not user-specific) before entering the workflow below.

Do NOT trigger for: Trivial typos, user-specific data/paths, one-off configuration issues, or problems already covered by existing skills.

Workflow

1. Solve the user's problem first. Read the relevant skills, produce a solution, ship the fix. Skill evolution never blocks the user's task.
2. Notice if a trigger fired (see Trigger conditions above). If nothing surfaced a generalizable learning, you are done.
3. Try to score the learning — when ground truth exists. A test exists, a known-correct answer is available, the solver returns a check-able status, etc. If the score fails, refine the candidate learning — tune the pattern, fix the example, add the missing detail — and re-score. Iterate until it scores or you conclude no version of it will; in the latter case, drop the proposal rather than ship an unscored claim. (See Scoring criteria below for what counts as ground truth.)
4. If no ground truth is available to score against — no test to run, no comparable answer to check against, no solver to invoke — skip step 3 and proceed with scored: no. This is normal during inference-style interactions where the learning is qualitative — the proposal is still useful, just lower-confidence.
5. Distill, place, and propose (see sections below). Apply only after the user approves.
6. Treat recurrence as evidence. When the same unscored insight surfaces in 2+ independent interactions, the recurrence is itself a signal. Promote the insight to a stronger proposal — note the prior occurrences in the trigger field rather than re-deriving from scratch.