Proof Checker: Rigorous Mathematical Verification & Fixing
SkillAI & modelsLets your agent check a LaTeX math proof for gaps, fix them with full derivations, and produce an audit report.
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 Proof Checker: Rigorous Mathematical Verification & Fixing skill
About this capability
Rigorous mathematical proof verification and fixing workflow. Reads a LaTeX proof, identifies gaps via cross-model review (external reviewer backend, ultra reasoning), fixes each gap with full derivations, re-reviews, and generates an audit report. Use when user says "检查证明", "verify proof", "proof c
What this skill tells your AI
The instructions your AI receives, as published by wanshuiyin/auto-claude-code-research-in-sleep in skills/proof-checker/SKILL.md and read by ahel’s review.
🔒 Do not wrap this skill in
/loop,/schedule, orCronCreate. It is verdict-bearing — it judges proof validity across rounds, threading the reviewer's memory from Phase 1 → Phase 3 viacodex-replyso the reviewer can check whether a fix actually closed the gap it flagged. An external timer re-enters from the top each tick, starting a fresh thread and losing that memory. Schedule the external wait that precedes it, not the verdict. Seeshared-references/external-cadence.md.
Systematically verify a mathematical proof via cross-model adversarial review, fix identified gaps, re-review until convergence, and generate a detailed audit report with proof-obligation accounting.
Context: $ARGUMENTS
Constants
- MAX_REVIEW_ROUNDS = 3
- REVIEWER_MODEL =
gpt-6-astra— Default model for the Codex backend, reasoning effortultra(deep-audit tier; capability fallbackgpt-6-astra+xhigh→gpt-5.5+xhighpershared-references/reviewer-routing.md, capability errors only — never belowxhigh). Manual backend uses a model the user chooses, but it must be a non-Claude model ARIS can classify (OpenAI, Google, DeepSeek, Moonshot/Kimi, Qwen) — the executor is Claude, so routing the proof review into any Claude product makes Claude judge Claude and voids the cross-model invariant (seeshared-references/reviewer-routing.md). - REVIEWER_BACKEND =
codex— Default: Codex MCP (ultra). Override with— reviewer: oracle-profor Oracle MCP, or— reviewer: manualfor Manual Review MCP. If manual-review MCP is unavailable, stop and print the install command; do not fall back to Codex. Seeshared-references/reviewer-routing.md.
Reviewer Calling Convention
When calling the reviewer, branch on REVIEWER_BACKEND:
If REVIEWER_BACKEND = codex:
Use mcp__codex__codex for new review threads
(model: gpt-6-astra, config: {"model_reasoning_effort": "ultra"}).
Use mcp__codex__codex-reply for follow-up rounds (reuse threadId).
If REVIEWER_BACKEND = manual:
Use mcp__manual_review__review for new review threads with:
prompt: [exact same prompt that would go to Codex]
config: {"model_reasoning_effort": "xhigh", "executor_model": "", "require_reviewer_model": true}
Save the returned threadId.
Use mcp__manual_review__review_reply for follow-up rounds with:
threadId: [saved manual-review threadId]
prompt: [follow-up prompt]
config: {"model_reasoning_effort": "xhigh", "executor_model": "", "require_reviewer_model": true}
Prompt fidelity: the manual prompt must be exactly the same text that Codex would receive. Review tracing applies equally to both backends.
- AUDIT_DOC:
PROOF_AUDIT.mdat the paper directory root, alongsidemain.tex(cumulative log; when invoked via/paper-writing, this ispaper/PROOF_AUDIT.md) - REPORT_TEX:
proof_audit_report.tex(formal before/after PDF) - STATE_FILE:
PROOF_CHECK_STATE.json(for recovery) - SKELETON_DOC:
PROOF_SKELETON.md(micro-claim inventory) - RENDER_HTML = true — When
true(default), auto-renderPROOF_AUDIT.mdto HTML at workflow end via/render-html. Uses full Codex review gate (audit-class artifact — math-heavy content; render-fidelity check protects against MathJax breakage and matches the skill's cross-model audit invariant). Setfalseto skip, or pass— render html: false.
Acceptance Gate (objective, replaces subjective scoring)
The proof passes when ALL of the following hold:
- Zero open FATAL or CRITICAL issues
- Every theorem/lemma has: (i) explicit hypotheses, (ii) proof with all interchanges justified, (iii) every application discharges hypotheses in the ledger
- All big-O/Θ/o statements have declared parameter dependence and uniformity scope
- Counterexample pass executed on all key lemmas (log candidates even if none found)
Issue Taxonomy (20 categories, 4 groups)
Group A: Logic & Proof Structure
| Category | Description | Example |
|---|---|---|
| UNJUSTIFIED_ASSERTION | Claim stated without proof or reference | "The Hessian splits into Gram blocks" |
| UNPROVEN_SUBCLAIM | "Clearly" / "it follows" hides a nontrivial lemma | "By symmetry, the cross-terms vanish" without checking |
| QUANTIFIER_ERROR | Wrong order ∀/∃, missing "for sufficiently small κ" | "For all π, there exists ε" vs "there exists ε for all π" |
| IMPLICATION_REVERSAL | Uses (A⇒B) as (B⇒A), or claims equivalence with only one direction | |
| CASE_INCOMPLETE | Misses boundary/degenerate cases | Singular covariance, zero weight, non-unique argmin |
| CIRCULAR_DEPENDENCY | Lemma uses theorem that depends on it | |
| LOGICAL_GAP | A step is not justified by what precedes it | B=Θ(1) → β_K=0 without analyzing W |
Group B: Analysis & Measure Theory
| Category | Description | Example |
|---|---|---|
| ILLEGAL_INTERCHANGE | Swaps limit/expectation/derivative/integral without DCT/MCT/Fubini | Differentiating under E without domination |
| NONUNIFORM_CONVERGENCE | Pointwise convergence used as uniform | sup and limit swapped |
| MISSING_DOMINATION | DCT cited but no dominating function given | |
| INTEGRABILITY_GAP | Uses E | X |
| REGULARITY_GAP | Differentiability/Lipschitz/convexity used but not established | |
| STOCHASTIC_MODE_CONFUSION | Mixes a.s./in prob./in L²/in expectation |
Group C: Model & Parameter Tracking
| Category | Description | Example |
|---|---|---|
| MISSING_DERIVATION | A quantity is used but never derived from the model | Risk functional with undefined B, W |
| HIDDEN_ASSUMPTION | Proof silently uses a condition not in the theorem | Gaussianity assumed but not stated |
| INSUFFICIENT_ASSUMPTION | Hypotheses too weak for proof (counterexample exists) | Moment conditions admitting 2-point distributions |
| DIMENSION_TRACKING | Parameter dependence (d, n, K, ...) not explicit | d enters only through κ |
| NORMALIZATION_MISMATCH | Coordinate/scaling conventions inconsistent | Rescaled vs raw coordinates |
| CONSTANT_DEPENDENCE_HIDDEN | "C" depends on d,n,K but treated as universal |
Group D: Scope & Claims
| Category | Description | Example |
|---|---|---|
| SCOPE_OVERCLAIM | Conclusion stated more broadly than proof supports | "β_K=0" with only generic overlap |
| REFERENCE_MISMATCH | Cited theorem's hypotheses not verified at point of use |
Two-Axis Severity System
Axis A — Proof Status (what is wrong)
| Status | Meaning |
|---|---|
| INVALID | Statement false as written (counterexample exists or contradiction) |
| UNJUSTIFIED | Could be true, but current proof does not establish it |
| UNDERSTATED | True only after strengthening assumptions |
| OVERSTATED | True only after weakening conclusion / adding qualifiers |
| UNCLEAR | Ambiguous notation / definition drift (not wrong per se) |
Axis B — Impact (how much breaks)
| Impact | Meaning |
|---|---|
| GLOBAL | Breaks main theorem or core dependency chain |
| LOCAL | Affects a side result but not the main theorem |
| COSMETIC | Exposition only |
Severity Labels (derived)
| Label | Definition |
|---|---|
| FATAL | INVALID + GLOBAL |
| CRITICAL | (INVALID + LOCAL) or (UNJUSTIFIED + GLOBAL) |
| MAJOR | (UNJUSTIFIED + LOCAL) or (UNDERSTATED/OVERSTATED + GLOBAL) |
| MINOR | Clarity / notation / dimension bookkeeping that doesn't change claims |
Side-Condition Checklists for Common Theorems
When the proof invokes any of the following, require explicit verification of ALL listed conditions:
| Theorem | Required Conditions |
|---|---|
| DCT (Dominated Convergence) | Pointwise a.e. convergence + integrable dominating function |
| MCT (Monotone Convergence) | Monotone increasing + non-negative |
| Fubini/Tonelli | Product measurability + integrability (Fubini) or non-negative (Tonelli) |
| Leibniz integral rule | Continuity of integrand + dominating function for derivative |
| Implicit Function Theorem | Continuous differentiability + non-singular Jacobian |
| Taylor with remainder | Sufficient differentiability + remainder form (Lagrange/integral) |
| Jensen's inequality | Convexity of function + integrability |
| Cauchy-Schwarz | Correct inner product space + integrability of both factors |
| Weyl/Davis-Kahan | Symmetry/Hermiticity + perturbation bound conditions |
| Analytic continuation | Domain connectivity + identity theorem conditions |
| WLOG reduction | Invariance under claimed symmetry + reduction is reversible |
Workflow
Phase 0: Preparation
- Locate the proof: Find the main
.texfile(s). - Read the entire proof: Extract list of all theorems/lemmas/propositions/corollaries/definitions/assumptions.
- Read reference materials: Reference papers, prior results.
- Build a section map: Structured list with line numbers and key claims.
- Identify the main theorem: Central result, assumptions, claims.
Phase 0.5: Proof-Obligation Ledger
Fan-out (Tier-aware) — build the ledger in parallel; never judge in parallel. For a large multi-theorem paper, ledger construction is breadth over independent sections. Tier 1 (Workflow): spawn one Claude subagent per section/theorem to extract that unit's symbols, assumptions, micro-claims, and local quantified statements, each returning a structured ledger fragment. Tier 2: the same subagents via the Agent tool. Tier 3: walk the sections sequentially. This follows
shared-references/fan-out-pattern.md.Two hard rules:
- The shards EXTRACT, they do not ADJUDICATE. Building the ledger (inventorying obligations, typing symbols, restating with explicit quantifiers) is structural extraction. Whether a proof step is valid — whether an obligation is actually discharged — is a Type-B correctness verdict reserved for the cross-model jury in Phase 1 / Phase 3 (codex or manual,
ultra). A Claude shard MUST NOT mark a micro-claim "proved" or "sound"; it only records the obligation and where the paper claims to discharge it. Seeacceptance-gate.md— the loop may self-verify that the ledger is complete, never that the proofs are correct.
- This governs the ledger spec wording below. Where the artifacts say "WHERE each is verified", "or mark UNVERIFIED", or "where conditions are proven", a shard records a location pointer (
file:linethe paper claims discharge) — never its own judgment that the discharge is mathematically valid. A shard'sUNVERIFIEDmeans "the paper cites no discharge location", NOT "the shard checked the math and it fails". Soundness is the jury's verdict, not the shard's.Shard output (extraction schema, per
fan-out-pattern.md): each shard returns{shard_id: "<section/theorem id>", entries: [...]}— the typed ledger items (symbols, assumptions, micro-claims, canonical statements, limit-order facts) for that unit, each carrying its canonical id (e.g.MC-17, the symbol name) asdedup_key. Never prose-only; never a validity verdict field. 2. Global artifacts are a barrier, computed on the merged ledger, not per-shard. The Dependency DAG and its cycle detection (incl. semantic circularity), and cross-section symbol-type consistency, require the whole paper in view. Merge all shard fragments first, then compute these on the union — a per-shard DAG would miss exactly the cross-section cycles this phase exists to catch.
Build formal accounting artifacts. Save to PROOF_SKELETON.md:
1. Dependency DAG
Nodes = Definitions / Assumptions / Lemmas / Theorems. Edges = "uses". Detect cycles (including semantic circularity where Lemma A uses a corollary that quietly depends on A).
2. Assumption Ledger
For each theorem/lemma, list every hypothesis with WHERE each is verified — i.e. the location pointer the paper claims discharges it (file:line), not a judgment that the discharge is valid; mark "UNVERIFIED" when the paper cites no discharge location (not when you believe the math fails — that is the jury's call). Track usage-minimal assumption sets — which assumptions were actually used vs merely stated.
3. Typed Symbol Table
Each symbol must have a type signature:
κ : scalar ∈ (0,1), depends on (d, α_t, Σ, μ)
u* : vector ∈ ℝ^d, u* = C^{-1}m
B^even : matrix ∈ ℝ^{(L+1)×(L+1)}, symmetric PSD
Ψ_v : function ℝ → ℝ, analytic in (ζ,κ), parity determined by v
Flag any symbol whose meaning changes or whose type is inconsistent across uses.
4. Canonical Quantified Statements
For each theorem/lemma, rewrite the statement with explicit quantifiers, domains, and limit order:
∀K ≥ 3, ∀π ∈ Π_K^{ms,∘} \ E_K, ∃κ_0 > 0 such that ∀κ ∈ (0, κ_0):
h_act^{(K,π)} = Θ(κ^{α_K^act}) [uniform in π on compact subsets]
If you cannot restate a theorem this precisely, mark it UNCLEAR — needs disambiguation.
5. Micro-Claim Inventory
Every nontrivial step becomes a numbered micro-claim in sequent form:
MC-17: Context: [Lemma 3.1, κ < κ_0, Z_κ has bounded moments up to order 2m+2]
⊢ Goal: P̂_0 is positive definite
Rule: monomials linearly independent on support of continuous distribution
Side-conditions: positive density near origin — claimed discharge: §B.2 (paper argues via GMM weak convergence; validity is the jury's call, not the shard's)
Each micro-claim has: justification rule name + required conditions + where conditions are proven (a location pointer to where the paper claims to discharge them, not a validity judgment).
6. Limit-Order Map
Track every asymptotic statement's limit order and uniformity scope:
h_act = Θ(κ^α) [as κ→0, uniform in π on compact subsets of Π_K, for fixed K]
τ_act ~ (b/a)n [as n→∞, for fixed κ,K,π with x_K ≪ 1]
Flag any statement where limit order is ambiguous or uniformity is unclear.
Phase 1: First Review (reviewer backend, ultra reasoning)
Submit the complete proof content with the checklist below, using the selected backend.
For codex, call mcp__codex__codex and always pin model: gpt-6-astra + config: {"model_reasoning_effort": "ultra"} (deep-audit tier). For manual, call mcp__manual_review__review with the identity-bearing config from the Reviewer Calling Convention above — model, sandbox and cwd are Codex-only.
Use this exact prompt for both backends:
You are performing a rigorous mathematical proof review. For EVERY theorem,
lemma, and proposition, check ALL of the following:
## MANDATORY CHECKS
A. DEFINITIONS: List any symbol whose meaning is ambiguous or changes.
B. HYPOTHESIS DISCHARGE: For each lemma/theorem APPLICATION (not statement),
list each hypothesis and whether it was verified, with location.
C. INEQUALITY AUDIT: For each inequality chain, verify direction, missing
absolute values, missing conditions (convexity, PSD, integrability).
D. INTERCHANGE AUDIT: Flag every limit/derivative/expectation/integral
interchange. State which theorem justifies it (DCT/MCT/Fubini/Leibniz)
and which conditions are verified/missing.
E. PROBABILITY MODE: Track whether claims are a.s./in prob./in expectation/
w.h.p. Ensure transitions are justified.
F. UNIFORMITY & CONSTANTS: For every O(·), o(·), Θ(·), ≲, state whether
it is uniform over all parameters. List hidden parameter dependence.
G. EDGE/DEGENERATE CASES: Attempt to break each key lemma with a 1D,
low-rank, or extreme-parameter construction.
H. DEPENDENCY CONSISTENCY: Detect cycles or forward references to unproven
results.
## OUTPUT FORMAT (per issue)
For each issue found, provide:
- id: sequential number
- status: INVALID / UNJUSTIFIED / UNDERSTATED / OVERSTATED / UNCLEAR
- impact: GLOBAL / LOCAL / COSMETIC
- category: [from taxonomy]
- location: section/equation/line
- statement: what the proof claims
- why_invalid: why this is wrong or unjustified
- counterexample: YES (describe) / NO / CANDIDATE (describe attempt)
- affects: which downstream results break if this is wrong
- minimal_fix: how to fix it
[FULL PROOF CONTENT HERE]
Phase 1 addendum — --deep-fix opt-in
If the user passed --deep-fix on invocation, append the following block to the reviewer prompt after the OUTPUT FORMAT block above (do not modify the original block; the new fields are additive). Default invocations skip this block entirely and emit the original output schema unchanged.
## DEEP-FIX OUTPUT (opt-in, only when --deep-fix is set)
For EACH issue listed above, additionally provide a `deep_fix_plan`
that is repair-grade — sufficient for an executor to apply the fix
in one Edit pass without spawning a follow-up review thread:
- issue_id: same as the issue id above
- corrected_statement: the theorem/lemma statement as it should
read after the fix, with explicit quantifiers, regime conditions,
and uniformity scope (LaTeX, paste-ready)
- changed_equations: list of {before: <LaTeX>, after: <LaTeX>}
pairs for each equation that needs replacement
- downstream_labels: list of \label{...} keys whose statements or
proofs depend on this fix and must be re-checked or rewritten
- minimal_tex_patch_plan: ordered list of concrete edits, each as
{file: <path>, anchor_old: <unique LaTeX snippet to find>,
replacement_new: <LaTeX to insert>}; the executor will pass
these directly to its file-editing tool
- closure_tests: 2-5 sanity checks the executor must run after
applying the fix (e.g., "verify constant_dependence_diff matches
computed value", "limit case γ→0 reduces to identity",
"dimension count matches before/after")
## ALGEBRA / TYPE SANITY PASS (opt-in, only when --deep-fix is set)
If any issue invokes Schur test, Young's inequality, Cauchy-Schwarz,
Hölder, quadratic form, operator norm, or power counting, the
deep_fix_plan for that issue MUST also include an `algebra_sanity`
object:
- dimension_table: map of {symbol: type_signature}, e.g.
{"K(i,α)": "scalar ≥ 0",
"‖K‖_{2→2}": "scalar ≥ 0",
"Σ_i V_i^rem": "scalar quadratic in w"}
- power_count: number of times each operator-norm or Schur factor
appears on each side; flag mismatch as INVALID
- zero_coupling_check: evaluate the expression at γ=0 (or the
analogous degenerate point); confirm it reduces to the expected
identity / vanishing case
- constant_dependence_diff: list of constants whose dependence on
(d, K, n, ...) changes between BEFORE and AFTER, with the new
explicit dependence written out
Be precise. The executor will apply this plan literally; vague
prose ("strengthen the bound", "redo the Schur step") is not
acceptable in deep-fix mode. If you cannot produce a precise plan
for an issue, omit that issue's deep-fix block and signal the
deep-fix path is unavailable — do NOT emit a vague plan, and do
NOT add a deep-fix-only category (e.g. UNCLEAR_DEEP_FIX) into the
standard issue list, since that contaminates default-call output.
A verdict-bearing manual response MUST begin with
Reviewer-Model: <exact-model-id> — pass the model THIS session is actually
running as in executor_model. Missing, unknown, or same-family identity
cannot acquit; emit REVIEW_UNAVAILABLE rather than guessing. If the executor
model cannot be named, manual review's cross-family claim is unprovable — say
so in the report instead of asserting it.
Save the threadId. Parse into structured issue list. Write to PROOF_AUDIT.md.
Phase 1.5: Counterexample Red Team
For each CRITICAL or MAJOR issue, and for every key lemma that introduces:
- a new inequality bound
- an identifiability/uniqueness claim
- a curvature/PSD/strong convexity assertion
- a uniform-in-parameter claim
- a convergence mode upgrade (pointwise → uniform, in prob → w.h.p.)
Systematically attempt to construct counterexamples using:
| Strategy | Description |
|---|---|
| Dimensional collapse | Set d=1 or 2, K=2, n small |
| Degeneracy | Singular covariance, tiny weight, overlapping means, identical components |
| Extremal distributions | Two-point ±a, bounded non-subGaussian, heavy tails |
| Adversarial parameter scaling | Pick parameters making neglected terms dominate |
| Numeric falsification | Translate lemma to a function, brute-force optimize over small domain |
Rule: Label "counterexample found" ONLY if algebraically verified. Otherwise log as "candidate counterexample — needs verification."
Record all attempts (successful or not) in PROOF_AUDIT.md.
Phase 2: Fix Implementation
For each issue, ordered by severity (FATAL → CRITICAL → MAJOR → MINOR):
Step 2a: Choose fix strategy
For each issue, explicitly choose one of:
- ADD_DERIVATION: Write missing proof steps
- STRENGTHEN_ASSUMPTION: Add conditions to theorem statement
- WEAKEN_CLAIM: Reduce conclusion scope
- ADD_REFERENCE: Cite known result + verify its conditions apply
Log this choice — it is a scope-changing decision when it alters theorem statements.
Step 2b: Derive the fix mathematically
- Complete mathematical derivation, not just a claim
- If new proposition/lemma needed, write in full theorem-proof style
Step 2c: Implement in LaTeX
- Edit the
.texfile - Preserve existing
\labelreferences where possible
Step 2d: Record the fix
### Fix N: [SHORT TITLE]
**Issue**: [id] [CATEGORY] — [description]
**Severity**: FATAL / CRITICAL / MAJOR / MINOR
**Status**: INVALID / UNJUSTIFIED / UNDERSTATED / OVERSTATED
**Impact**: GLOBAL / LOCAL / COSMETIC
**Fix strategy**: ADD_DERIVATION / STRENGTHEN_ASSUMPTION / WEAKEN_CLAIM / ADD_REFERENCE
**Location**: Section X, Lines Y-Z
**BEFORE**: [what the proof originally did]
**WHY WRONG**: [mathematical problem, with counterexample if applicable]
**AFTER**: [what the fix does]
**KEY EQUATION**: [central new equation]
**PROOF OBLIGATIONS ADDED**: [new conditions/lemmas introduced]
**DOWNSTREAM EFFECTS**: [which results now need re-checking]
Step 2e: Compile check
pdflatex -interaction=nonstopmode <file>.tex 2>&1 | grep -E "Error|Warning|undefined"
Phase 3: Re-Review (reviewer backend, ultra reasoning)
Continue with the selected backend. For codex, use mcp__codex__codex-reply with the saved threadId. For manual, use mcp__manual_review__review_reply with the saved threadId. Include fix summaries. Request the same mandatory checklist.
Check acceptance gate. If not met, repeat Phases 2-3 (up to MAX_REVIEW_ROUNDS).
Phase 3.5: Global Closure & Independent Verification
Shortened here. Read the whole file on GitHub.
Signals
- GitHub stars
- 16k
- Forks
- 1k
- Last commit
- Sep 2026
Advanced
- Catalog kind
- skill
- Gateway key
proof-checker- Source
- github.com/wanshuiyin/auto-claude-code-research-in-sleep