Lean Workflow
Use this when working on Lean4/mathlib proofs in any repo.
Core workflow (short)
- •Identify the first failing lemma or
sorry. - •Create a scratch file with the minimal imports.
- •Reproduce the goal with a tiny example (unnamed theorem).
- •Iterate in small steps; keep it compiling after each step.
- •When it works, port the proof back to the main file and re-run
lake env lean.
Practical rules
- •Prefer minimal imports first; if unsure, mirror the main file imports.
- •Keep the main file compiling; avoid large refactors until proof is stable.
- •Use
#check,#synth,#print,#reduceto inspect goals/types. - •If proofs are slow, isolate them into smaller lemmas and simplify the statement.
- •When shrinking imports, avoid
Mathlib.Tacticby rewriting tactic-only steps (e.g. usePolynomial.induction_on'directly instead ofinduction'). - •If
simpmakes no progress on a localset/let, unfold it explicitly withsimp [name]. - •Keep this skill doc updated with concise workflow gems discovered during the task.
- •When stuck: strip complexity to the smallest failing example, then rebuild from simpler working cases. If still unsolved, report both the minimal failing example and the closest working example side-by-side.
Scratch-file pattern
- •Name:
scratch_<topic>.leannext to the main file. - •Start with 1-2 trivial examples, then scale up to the real statement.
- •Use unnamed
exampleblocks to probe the proof state.
When to consult Claude (non-interactive)
If blocked or a tactic name is unknown:
- •Run
claude --helpto see CLI usage. - •Use non-interactive mode:
- •
claude -p "..."
- •
Keep Claude requests minimal: show the goal, key hypotheses, and the exact error.