claude-plugins-official/plugins/math-olympiad/skills/math-olympiad/references/presentation_prompts.md

Presentation Pass — Prompts and Templates

Premise: Aletheia's PDFs are beautiful; raw IMO output is not. The difference is a presentation pass: after a proof is verified correct, a fresh agent — one who didn't sweat through the discovery — finds the cleanest way to say it. The discoverer is too attached to the scaffolding.

The Erdős paper even criticizes Aletheia's own output: "somewhat overkill; any f whose inverse is at most [X] would suffice, no need to take the double exponential." The presentation pass is where overkill goes to die.

---

1. The Presentation Pass Prompt

Paste this to a fresh subagent along with the verified proof. The agent must not have discovery-context; that's the point.

You are given a verified, correct proof. Your job is not to check it — it is correct. Your job is to find the cleanest presentation. The order it was discovered in is almost never the order it should be read in.

Work through these questions in order:

Hindsight shortcuts. Now that you know the answer, is there a 3-line argument? The discoverer built machinery to find the key step; you already have the key step. Can the machinery be discarded? (Classic: a long case-bash that, in hindsight, collapses once you spot the invariant.)

Overkill. Is any bound stronger than needed? Any construction more general than the problem requires? If a double exponential works but a linear function also works, use the linear one — the reader will wonder what the double exponential is hiding. Match the strength of each tool to the strength of what it's proving.

What to cut. Which steps verify without illuminating? Discovery leaves a debris field: sanity checks, dead ends backed out of, "note that X (we won't use this)". Delete them. If a paragraph can be removed and the proof still compiles in the reader's head, remove it.

Lemma granularity. Inline a lemma if it's used once and the proof is ≤3 lines. Keep it standalone if it's used twice, or if its statement alone clarifies the structure (even with a 1-line proof). Name standalone lemmas descriptively — "Combinatorial dimension bound", not "Lemma 2".

Order. Lead with the main statement. Then the one idea that makes it work. Then the details. Isolate the one genuinely clever step — there's almost always exactly one — and let everything else be obviously routine by contrast.

Step names. Number steps and name them: "Step 3: Fourier inversion and translation invariance." The name is a promise to the reader about what this block accomplishes. Signpost reductions explicitly: "We are reduced to showing that…"

Output clean LaTeX using the template below. Aim for: a strong grad student could reconstruct every suppressed detail, a professor could skim the step names alone and nod.

---

2. LaTeX Output Template

Minimal preamble — Aletheia's environments, none of its ornament. No tcolorbox, no custom colors.

\documentclass[11pt]{article}
\usepackage[margin=1.25in]{geometry}
\usepackage{amsmath, amssymb, amsthm, mathtools}
\usepackage[shortlabels]{enumitem}
\usepackage{hyperref}

\theoremstyle{plain}
\newtheorem{theorem}{Theorem}
\newtheorem{lemma}{Lemma}
\newtheorem{claim}{Claim}
\newtheorem{proposition}[theorem]{Proposition}

\theoremstyle{definition}
\newtheorem{definition}[theorem]{Definition}
\newtheorem*{remark}{Remark}

\begin{document}

\section*{Problem}
% Restate the problem exactly. No paraphrase.

\section*{Solution}

\begin{theorem}
% State what you will prove, in full. If the answer is "yes" or "no"
% or a specific value, state it here so the reader isn't kept in suspense.
\end{theorem}

% If a lemma is reused or structurally load-bearing, state it before
% the main proof. One-shot verifications get inlined below.
% \begin{lemma}\label{lem:key}
%   ...
% \end{lemma}
% \begin{proof} ... \end{proof}

\begin{proof}[Proof of Theorem]
\textbf{Step 1: [Descriptive name — what this step accomplishes].}
% e.g. "Reduction to the compact case." / "The key invariant."

% Display important equations; inline routine ones.
% End a reduction step with: "We are reduced to showing that ..."

\textbf{Step 2: [Name].}
% ...

\textbf{Step $n$: Conclusion.}
% One or two sentences. Make the contradiction / induction close / final
% computation land visibly.
\end{proof}

\end{document}

Style conventions lifted from the Aletheia samples:

• Display math for the equation a step produces; inline math for the algebra getting there.
• Cite precisely when invoking a named result: (Jacquet–Piatetski-Shapiro–Shalika, 1981) — not "by a well-known theorem".
• In contradiction proofs: state the false assumption plainly ("Suppose, for contradiction, that…"), and flag the collision plainly ("We are led to the contradiction 0 > 0.").
• Integer bounds earn the ceiling: if d \ge n/k and d \in \mathbb{Z}, write d \ge \lceil n/k \rceil. Free sharpness.

---

3. Anti-Patterns to Catch

The presentation agent should flag and fix these:

• Discovery-order exposition. "First I tried X, which led me to notice Y…" — the reader doesn't care. State Y.
• Overkill constructions. The tell: the bound you prove is parametrically stronger than what the next line consumes. Weaken it until it's tight.
• Proof by intimidation. "It is trivial to see that…", "Obviously…", "A standard argument shows…" — if it's trivial, one sentence suffices. Write the sentence.
• Unnecessary generality. Proving it for all n when the problem asks about n=3 and the general case adds no insight, only indices.
• Orphan lemmas. Stated, proved, cited once, three lines long. Inline it.
• Unlabeled case splits. Five cases, no indication of why five or what distinguishes them. Name the cases; say upfront which one carries the content.
• Missing signposts. A page of computation with no "we are reduced to" / "it suffices to show" markers. The reader shouldn't have to reverse-engineer your strategy.