mathmod-writing

name	mathmod-writing
description	Evidence-to-communication Skill for mathematical-modeling competitions. Use it for evidence-grounded technical drafting, conceptual and quantitative visual briefs, document refinement, support packaging, and delivery checks without creating new scientific facts. For figure-focused tasks, hand off to the companion mathmod-figure M4 task skill.

MathMod Writing

ROLE

Translate current scientific meaning and formal evidence into a clear paper, figure briefs, visuals, and delivery artifacts. Choose the procedure that matches the current task.

mathmod-figure is the companion M4 task skill for figure triage, claim-first composition, submission-size design, rendering, conceptual image-generation routing, and rendered figure QA. Use it when the work is primarily a figure; keep paper narrative, captions, final placement, document refinement, packaging, and delivery here. Neither skill is M5, a runtime, or a release authority.

Codex is often useful for technical prose closely tied to formulas, code, tables, formal evidence, support packaging, and mechanical checks. ChatGPT Work is often useful for conceptual graphics, visual refinement, document organization, typography/layout, and DOCX/PDF presentation. These are practical defaults, not routing rules or permissions.

This Skill supplies communication procedures and scientific preservation rules. It does not manage agent lifecycle, task state, ownership, or scheduling.

READ

Start with the smallest context that can preserve scientific meaning:

1. AGENTS.md and CONTEXT.md when entering a fresh session.
2. The current task's relevant semantic context:
   • context/model.md for semantic decisions the prose/visual depends on;
   • context/evidence.md for current formal findings and artifact pointers;
   • context/paper.md for section responsibilities, symbols/terms, evidence use and gaps;
   • context/visuals.md for figure briefs, source semantics/data, Must preserve, May change;
   • a relevant handoff when task-specific context is needed.
3. For existing formal numbers, follow current_run.json for the relevant question and open that formal run's findings/artifacts unless comparison or provenance requires more.
4. Open exact formal artifacts or render-ready data only when the task needs a number, table, quantitative figure, or verification.
5. Use official rules/writing references when checking submission requirements.
6. Use Git/old runs only for conflict or provenance.

Do not inherit scientific truth from an old chat or visually estimate a number that exists in a formal artifact. When drafting a question's answer or conclusion, also read its original requested output; current evidence can be scientifically sound yet leave that request incomplete.

DO

Reader understanding: drafting and final review

For a complete draft or a substantive argument revision, load Reader Clarity in draft mode. Give the reader an explicit route from the requested output, through the decisive evidence and comparison, to the adopted answer and its conditions. This is not a fixed chapter template. Keep conclusion-changing uncertainty beside the answer; move only non-decisive implementation detail out of its way. An unsupported bridge is a science gap, not a sentence to invent.

Before returning a complete paper, use its review mode on the actual deliverable. Read the statement and paper before author explanations or earlier review findings, then check suspected conflicts against evidence. Reuse the existing final review allocation; keep readability findings separate from the scientific verdict. No new agent or routine full-project rerun is required. Scope-limited edits need only their affected reading path.

Technical writing

Build and maintain context/paper.md as an information map, not a copy of the paper. Draft paper/ from current semantics plus current formal evidence.

Keep every consequential quantitative or technical claim traceable to evidence. Preserve numbers, units, signs, formulas, symbols, variable meanings, grouping/time semantics, rounding policy, uncertainty, and claim strength.

A useful result paragraph often follows:

Observation → Explanation/Comparison → Consequence → Answer

When explanatory evidence is weak, prefer:

Observation → Scope/Uncertainty → Answer

Do not turn association into causation, feasibility into optimality, diagnostics into proof, or probe observations into formal results. If a needed number/evidence is missing, request compute work; if the underlying meaning is uncertain, return to reasoning.

Conceptual visual brief and paper integration

Use a narrow visual brief rather than loading the whole repository. Delegate figure-space triage, claim-first composition, rendering, image-generation decisions, and figure QA to mathmod-figure; keep caption, final placed size in the paper, placement, and paper integration here. A conceptual figure normally needs:

Purpose
Type: conceptual
Source semantics: context/model.md#...
Used in: paper/...
Must preserve
May change

Appearance may change, including visual style, layout, iconography, typography and hierarchy. The model relationship, direction, terminology, logical meaning and claim strength must remain unchanged.

If image generation is used, treat the result as an illustrative conceptual draft. It must not become the source of exact values, equations, tables, scales, or evidence-bearing geometry. Route the generation/review boundary through mathmod-figure/references/image-generation-workflow.md.

Quantitative visual brief and paper integration

Use exact render-ready data exported from current formal evidence. Delegate figure-space triage, claim-first composition, deterministic rendering, and rendered figure QA to mathmod-figure; keep caption, final document placement, and paper integration here. A quantitative brief normally includes:

Purpose
Type: quantitative
Render-ready data: visuals/...
Evidence source: context/evidence.md#... or formal artifact
Used in: paper/...
Must preserve: values, units, groups, uncertainty, ordering/scale semantics when meaningful
May change: typography, color, layout, legend, annotation position, visual hierarchy

Do not add/remove data points, regroup observations, alter units, smooth/interpolate without scientific authorization, crop/scale deceptively, or infer numbers from an old plot when exact data is available. Do not replace deterministic quantitative plotting with image generation.

Document polish

For DOCX/PDF pagination, table/figure placement, equation-display repair or final visual QA, load Paper Layout. Its scripts are optional structural and review-record helpers. Rendered page inspection remains necessary: correct source text and OMML properties do not guarantee correct PDF delimiters. Markdown-only drafting does not activate document conversion or install its optional dependencies.

Start from the current paper artifact and context/paper.md; read model/evidence only when a meaning question arises. Improve organization, hierarchy, layout, typography, figure/table placement and visual consistency without rewriting scientific facts.

When placing figures, review the actual paper width rather than trusting a standalone preview. If the document tool scales a figure, recheck readability at the placed size and return layout defects to mathmod-figure when the figure itself must change.

When a requested change would alter meaning, return the semantic decision to reasoning. When it requires a new number or computation, return it to compute.

Package and check

Use explicit repository-relative include lists for support packages rather than scanning and guessing the latest files. Use the existing Competition scripts for mechanical checks where applicable. Treat DOCX/PDF layout, pagination, image clarity and other visual properties as visual review tasks when they cannot be checked mechanically.

A passing mechanical checker is not a semantic review or release authority.

WRITE BACK

Write information to its native place:

• paper information structure, evidence responsibilities, terminology/symbols and gaps → context/paper.md;
• figure purpose/source/constraints/status → context/visuals.md;
• technical draft → paper/;
• render-ready inputs / rendered figures → visuals/;
• final/support artifacts → submission/;
• task-specific cross-host request → a narrow context/handoffs/*.md only when existing semantic homes are insufficient.

Do not copy the paper into context/paper.md or duplicate formal results into context/visuals.md.

Before a formal cross-host handoff, make sure the artifact and any durable semantic/status change are in the repository and use a meaningful Git synchronization point when possible.

Before stopping, reconcile CONTEXT.md, context/paper.md, and context/visuals.md so completed revisions no longer appear open and paper/figure status agrees with the artifacts.

CONFLICT RULE

If prose, visual, or layout work reveals a mismatch between current model semantics, evidence, numbers, formulas, units, grouping, time interpretation, or claim strength:

1. stop the affected claim or figure;
2. cite the conflicting paths and what differs;
3. identify the affected paper/visual artifacts;
4. return semantic decisions to reasoning or missing/recomputed evidence to compute;
5. revise the affected artifact after the source semantic home/evidence changes.

If the requested argument does not follow from current evidence, say precisely which inference is unsupported and return it to reasoning. Do not resolve scientific conflicts by polishing the wording until they disappear. Once reasoning has accepted a correction, apply the workspace's durable-truth rule before closing the repair: update the owning current semantic homes as well as the paper, preserve historical runs, and withdraw only adopted evidence that the correction actually invalidates.

HANDOFF SHAPE

When a handoff is needed, use the workspace's simple shape:

Objective
Why this matters
Read first
Current decisions to preserve
Open questions
Expected outputs
Write back
Escalate if

Reference existing context sections instead of repeating them.

REFERENCES: LOAD ON DEMAND

Use these direct routes instead of rediscovering the framework layout:

• technical writing → section routing → the relevant writing reference and evidence-bound writing;
• conceptual figure brief or paper integration → context/visuals.md → its referenced context/model.md section → the companion mathmod-figure Skill → image-generation workflow only when a generated conceptual panel is actually useful;
• quantitative figure brief or paper integration → context/visuals.md → exact visuals/data/ or the selected formal artifact → the companion mathmod-figure Skill;
• paper numbers → current_run.json → the selected runs/formal/<run-id>/ → evidence-bound writing;
• reader understanding while drafting or at final review → Reader Clarity;
• DOCX/PDF layout and rendered-page checks → Paper Layout;
• task-skill packaging, boundaries and validation → writing tasks;
• consistency review → audit matrix;
• format, disclosure, and delivery → format requirements, AI disclosure, and support packaging;

Open only the route that answers the current writing, visual, or delivery question, then follow a deeper linked source when correctness requires it. These are procedural aids, not sources of scientific truth. Official competition rules outrank generic writing advice. Current project semantics and formal evidence outrank historical module wording.

Do not add .mathmod, MCP, scheduler, coordinator, transaction, claim/lease, release runtime, per-host memory, or a context compiler for ordinary writing/visual work.