CUMCM Workflow
SkillFiles & storageBuild or resume a contest-ready CUMCM project from official files through modeling, one selected computation backend, bounded independent validation, fresh-context paper writing, and final delivery. Use for real CUMCM work; do not use for ordinary paper polishing or unsupported one-shot answers.
Available today. Use it from your connected AI after setup.
No other account needed.
Connect ahel once, and every AI you use reads what you have installed.
Then ask your AI: use the CUMCM Workflow skill
What this skill tells your AI
The instructions your AI receives, as published by lucasuiii/cumcm-workflow in .agents/skills/cumcm-workflow/SKILL.md and read by ahel’s review.
Spend reasoning on the problem, mathematics, experiments and explanation. Tools maintain execution records, hashes, snapshots and stage state. Do not create extra checklists or repeatedly edit contracts to silence warnings.
Start or resume
- Read the project's
.cumcm/state.jsonand the incoming handoff, if present. Resume exact0.6.0projects; older schemas are unsupported. - For a new project, use intake and
init_project.pywith the supplied official files. - Read only the active stage guide below. Consult a schema only when the guide and command help leave a specific field unresolved; do not load the checker to learn the workflow.
- Define
Sas the absolute path to this Skill'sscriptsdirectory. All examples usepython3 "$S/<command>.py"; the contest workspace does not contain these scripts. - After interruption, check pending human decisions before continuing. Existing downstream files do not establish approval. Never infer approval from a quota reset, a new task, or “continue”.
Three human stops
| Before | Show the user | Record after their explicit reply |
|---|---|---|
| Official computation | Objective, constraints, all candidates and their discriminating evidence, chosen scope, any unanswered requirement | model-design |
| Paper writing | Every claim's text, scope, evidence state, and open P0/P1 | validation |
| Final delivery | Current PDF pages, answers, remaining findings and actual delivery files | delivery |
Stop the dependent work after presenting the material. Model self-review is useful judgement, never human acceptance. A reply before the material was shown does not approve it. If a reviewed claim or model changes, show the revision and obtain a new decision; do not relabel the old acceptance.
After the user accepts all the presented current material, one command fills the existing checkpoint, records its snapshot and advances state:
python3 "$S/record_decision.py" --project <p> --stage <stage> \
--decision accepted --confirm-human --task-turn-ref <user-reply-ref> \
--summary <what-the-user-accepted>
No manual timestamps, presented-ID lists, hashes or state edits. Other stages are technical completions: use the same command without --confirm-human, after their checks pass, referencing the current task. They do not require another user confirmation. Reopen with --decision revision_requested; downstream approvals become unusable. Decisions are honest conversation records, not cryptographic proof that a person answered.
Working and finalizing
workingpermits incomplete model drafts and cheap exploratory runs. Failed exploration never blocks. Usepreflightwhile drafting: pending review is visible but does not fail the command.enforcerequires the three human stops in both modes. Official recording and paper entry also check the corresponding stop, so skipping a checker does not silently replace approval with self-review.finalizingrequires complete current evidence, decisions, independent review and delivery binding. Switch withset_mode.py. Do not run full finalizing checks before exploratory model selection: formal assertions do not exist yet.
python3 "$S/cumcm_check.py" --project <p> --stage <stage> --gate-mode preflight
Warnings remain visible; they are not a request to rewrite upstream evidence. An error requires repair; awaiting_review means present the material and wait. Passing does not prove mathematical correctness.
Stage guides
| Work | Read | Outgoing handoff |
|---|---|---|
| Problem analysis | 02-problem-analysis.md | — |
| Model candidates and cheap comparisons | 03-model-design.md | modeling-computation |
| One backend, official runs and result indexing | 04-computation.md | computation-validation |
| Independent review and conclusions | 05-validation.md | validation-paper |
| Reader-facing paper and visual QA | 06-paper-writing.md | paper-delivery |
| Actual delivery packages | 07-compile-delivery.md | final package |
Build handoffs with build_handoff.py; read handoffs only at a crossing. computation-validation and validation-paper must cross into fresh tasks. Task refs are a paste guard, not proof of independence; same-model new-context review remains correlated. After a full review finds P0, the package builder defaults to targeted re-review of those findings.
Evidence without paperwork
- Preserve official files.
record_run.pyrecords real execution and freezes declared evidence;index_result.pyreads values from outputs. Never type machine facts into contracts. - Choose a model after cheap candidate evaluation; officially implement one backend. MATLAB preference breaks ties, not task suitability. No parity implementation unless requested.
- Runs are append-only. A rerun uses
--rerun, never overwrites its parent. Only successful official descendants supersede.plan_redo.pyscopes affected work; it does not waive checks. - P0: wrong computation/data, task mismatch, scope beyond evidence, stale evidence, fabricated approval/review, or unusable delivery. P1: weaknesses within a supported and task-relevant scope. P2: optional improvements. Narrowing a claim cannot erase an unanswered requirement.
- Derive review priorities from the current task, not previous failure examples. Check task coverage, model assumptions, solution validity and claim scope using a few tests or independent arguments that could expose a plausible wrong answer. Choose applicable mathematical properties; do not require every problem to run the same tests. A repair must address the failure mechanism and affected conclusions, not only the failing example.
- Claims use
supported_not_reproducedunless an isolated rerun and comparison establishreproduced. Label simulations and synthetic scenarios explicitly. - Keep workflow IDs and evidence bookkeeping out of reader-facing prose. Compilation logs do not establish visual quality; inspect rendered pages.
refresh_evidence.py --only delivery --packagebuilds declared ZIPs with project-relative directories and refreshes their existing metadata. It never refreshes official sources. No-change refreshes do not rewrite files.
Use artifact contracts only for an unfamiliar artifact and evidence rules for unresolved evidence semantics. Do not read every reference at startup.
Signals
- GitHub stars
- 76
- Forks
- 5
- Last commit
- Sep 2026
Advanced
- Catalog kind
- skill
- Gateway key
cumcm-workflow- Source
- github.com/lucasuiii/cumcm-workflow