MathModeling-skills turns a modeling contest into a chain of gates, with two of them yours to decide

The rewrite that turned an autopilot back into an assistant

The most important thing in this project is a change of direction, and the project documentation states it plainly. The earlier version ran the whole contest end to end and left the user only clicking confirm, which the author calls closer to ghost-writing, since it does not fit most contests' rules and does little for your own skills. The current version hands the key judgments back to the user, the AI returns to a supporting role, and the person running it stays in charge. The skill count went from 24 to 28 in that rewrite. The old behaviour is not deleted, it is kept intact on a branch called legacy-full-auto, and the documentation tells you to switch to it if you prefer the previous behaviour. The principle the project is built on is stated just as directly: the AI owns mechanical correctness, the user owns modeling judgment. Concretely, the tooling profiles data, runs method-specific risk probes, freezes numbers, render-checks figures and audits consistency. What it will not do is choose the method, decide what a number means, or invent the reasoning behind a choice.

The four ways a team usually loses, none of them about knowing models

The project explains its own existence with a list of failure modes, and it is worth reading because the list is about workflow rather than mathematics. Teams rarely lose a modeling contest because they did not know enough models. More often they misread what the problem was actually asking, or they skipped the baseline and went straight to a complex model that nobody could explain later, or the paper states a number that no script in the repository actually produces, or a bug gets fixed late in the process while the paper still carries the numbers from before the fix. Those are all workflow problems rather than modeling problems, and the arrangement of the skills is aimed at making them hard to hide. The last one is the most instructive, because a stale number is the kind of error that looks like a competent result and is discovered by whoever reads the code carefully, which is usually too late.

G1 through G6, and the two marks that belong to you

The pipeline is a single ordered chain, and each step is guarded by a named gate with a pass condition. The listing below is the sequence the project describes, from the orchestrator that reads the interaction mode and the rigor profile through to the final assembly.

workflow-orchestrator (reads interaction_mode + rigor_profile)
 ▼  problem-parser → problem-classifier → related-paper-analyzer       [ G1: PROBLEM_FRAMED ]
 ▼  symbol-table-builder + model-assumptions-builder + data-auditor-cleaner
 ▼  code-reviewer (router) → named-check JSON review                   [ G3: CODE_AND_EXPERIMENT_REVIEWED ]
 ▼  paper-section-writer                                               [ G5: PAPER_SECTION_READY ]
 ▼  submission-packager → final assembly

The gate names in the full listing are PROBLEM_FRAMED, METHOD_SCREENED, CHOSEN_BY_HUMAN, CODE_AND_EXPERIMENT_REVIEWED, JUDGED_BY_HUMAN, RESULTS_FROZEN, PAPER_SECTION_READY and AUDIT_LAYER_PASSED. Two of them are marked as judgments owned by the user, and the documentation names the two load-bearing boundaries explicitly. G2 catches assumption, concentration, feasibility and scale failures before a full implementation happens, and G4 prevents stale numbers from entering the paper. Everything downstream of a failed gate is marked stale rather than quietly continuing.

G2.5 is the point where the method choice goes back to you

This is the gate that defines the project, and the comparison table in the documentation is blunt about how it differs from a typical pipeline. In a typical pipeline the AI picks the method and writes the justification. Here you choose the trade-off, and the AI screens a main candidate, a usable baseline and at most one conditional fallback, and then you commit the route and the reason at gate G2.5. Before that point you set priorities, risks and budget, and the method selector works from that. The risk probe attached to G2 is time-bounded rather than exhaustive, and it checks data coverage, assumptions, output degeneracy, perturbation sensitivity and scale, with output concentration called out specifically. So the division of labour is narrow on purpose. The assistant narrows the field, the probe looks for the ways a candidate method can fail, and the human writes down why the chosen route is the right trade-off.

G3 replaces a code review that says looks fine

The comparison table draws the line between the two reviews bluntly. In a typical pipeline someone says looks fine. Here a compact JSON review has to pass named checks for syntax, input, method-alignment, reproducibility and output before the step is done. Method-alignment is the interesting one, since it is the check that the code actually implements the method that was committed at G2.5 rather than a different one that happens to run. The review is produced by a code-reviewer that acts as a router, and the surrounding pipeline makes the intent clear by ordering the work: the model code analyzer comes first, then the generator that writes either Python or MATLAB code, and only then the review. The point of the named checks is that they can fail, and a failing review is a stop rather than a note in a document nobody rereads.

G4 freezes the numbers, and a changed number means a logged change and a re-freeze

The pipeline diagram puts the freeze at the solution package builder, which emits a file called frozen_numbers.json at the G4 RESULTS_FROZEN gate. The comparison table describes the difference from the usual approach as re-read from the latest results each time versus frozen into frozen_numbers.json, and it adds the rule that matters. Changing one means logging the change and re-freezing. So the numbers that reach the paper are not a fresh read of whatever the last run produced, they are a specific recorded state, and any change to them has to be an explicit, logged act. That is the mechanism aimed at the failure where a bug is fixed late and the paper still carries the old figures, because with a frozen snapshot the mismatch between paper and code becomes a visible diff rather than a subtle inconsistency.

G6 needs three auditors to agree, and the rigor profile decides how much work runs

The final gate is not a single pass. The pipeline routes the work through an independent audit layer of three auditors, the consistency auditor, the completeness auditor and the quality assurance auditor, and all three must pass before the paper is considered ready. The comparison table describes the difference from a typical pipeline as one QA pass versus three separate final auditors, where any one failure means the paper does not ship. Below that sits the rigor profile, a second axis the orchestrator reads at the start of a session. The lean profile keeps manifests, decisions, probes and run summaries, while the submission profile adds the freeze, the paper and the final audits. So the cost of the machinery is tunable, and a team that only wants the structure during exploration can run lean and turn on the heavier stages for the version of the paper they submit.

What the repository actually ships, and the groundwork skills that start it

The top level of the repository holds the pieces a user needs before any of the gates matter. There are .claude and .codex directories for the two supported assistants, along with .claude-plugin and .agents directories, a plugins directory, an install.sh script, templates, scripts, skills-docs, tests and docs. Two documents are linked prominently from the top of the README, an Initial Prompt file and a project rules file called CLAUDE.md, and there is a Chinese README alongside the English one plus a Chinese version of the initial prompt. The stage one skills are the groundwork before any modeling starts, and each one writes to a predictable place. The problem parser breaks the problem into goals, objects, constraints, data, outputs and subquestions under planning/parse, the problem classifier labels each subquestion with a task type under planning/classification, and the symbol table builder maintains one shared table at planning/symbol_table.md. The related paper analyzer is described as finding relevant literature without fabricating citations, which is the same no-invention rule that shows up in the gates. The examples directory holds four worked cases, an evaluation problem, a hybrid problem, an optimization problem and a prediction problem, and the project is MIT licensed.

Editorial conclusion

MathModeling-skills fits a team that has been burned by a paper quoting a number no script produced, because the frozen snapshot and the re-freeze rule make that failure visible instead of silent. It is the wrong tool if you want the contest run for you, because the current version deliberately stops at the two decisions that matter, the method choice and the proceed or adjust call, and the earlier autopilot is parked on the legacy-full-auto branch instead. Before you rely on it, read the pipeline listing for the gate that covers your failure mode, and check the skill count, since the update note and the README badge do not agree on it. The licence is MIT, the repository has no tagged releases, and the last push was on 2026-09-24.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. README
4. zhnnky329/MathModeling-skills on GitHub