Lean 4 Skills plugin

A plugin for proving theorems in Lean 4: mathlib search, sorry-filling cycles, axiom checks and safety hooks

  • 486 ★ on the repository
  • Last commit
  • MIT
Plugin

Extended access

Why this level

  • The agent edits `.lean` files, runs builds and helper scripts, and `checkpoint` makes commits in your repository.
All reasons and checks

cameronfreer/lean4-skills

Install

In your terminal, with SkillFoxx CLI

npx skillfoxx add plugins/lean-4-skills

Detects the agents on your machine, shows the access level and pins the version.

Other ways to install

Access and checks

How we review

Extended accessThe tool runs code or makes network calls and only reads external data.

  • The agent edits `.lean` files, runs builds and helper scripts, and `checkpoint` makes commits in your repository.

This is third-party code. Review the repository files before installing.

What it does

Lean 4 Skills is a plugin for Claude Code and Codex that guides an agent through proof work in Lean 4. One main skill, `lean4`, kicks in when `.lean` files are edited, `lake build` fails, lemmas are searched in mathlib or mathematics is formalized. It leans on the language server (LSP): it first looks for a ready fact in mathlib, then writes tactics and builds the project after each step. The plugin has twelve workflows: `draft`, `formalize`, `autoformalize`, `prove`, `autoprove`, `disprove`, `checkpoint`, `review`, `refactor`, `golf`, `learn` and `diagnose`. In Claude Code they are called as `/lean4:prove` and so on. Four subagents handle filling `sorry` gaps, repairing errors, shortening proofs and removing extra axioms. The agent leaves theorem statements and signatures as they are until you ask otherwise. The `autoprove` mode runs with explicit cycle and time limits.

Who it is for. Mathematicians and developers who formalize theorems in Lean 4 with mathlib and hand the agent the job of filling proof gaps and untangling build errors.

Good fit when

  • A file has about ten `sorry` left, and the agent must fill them in cycles with a build check after each step.
  • A proof works but is long, and `golf` shortens it without losing meaning.
  • It must be confirmed that the final theorem relies only on standard axioms.
  • A statement looks wrong, and `disprove` searches for a counterexample with a certified refutation.

Not a fit when

  • Proofs are written in Coq, Agda or Isabelle: the skill description explicitly excludes other systems.
  • Theorem statements must be rewritten along the way: `formalize` and `autoformalize` exist for that, while `prove` keeps headers unchanged.
  • The project has never been built: run `lake build` before bringing in the agent, otherwise LSP checks run into timeouts.

Example request

Run /lean4:prove on Foo.lean, fill the sorry from line 42 and show which axioms the final theorem uses.

Limitations

Installation in Cursor, Windsurf, Gemini CLI and other agents is documented but not covered by automated tests, which cover just Claude Code and Codex. Installing through a skill manager gives instructions and references without the helper scripts, hooks and `/lean4:*` commands: those need the plugin or a portable clone. On Windows, Claude Code needs Git Bash or the VS Code extension. Live inspection of proof goals comes from the separate lean-lsp-mcp server: without it the agent relies on full builds and the cycle is noticeably slower.

How to disable. In Claude Code run `/plugin uninstall lean4`; for Codex, remove the plugin through `codex plugin`. The hooks and helper scripts go away with the plugin, and your `.lean` files stay as they are.

FAQ

How do I install the plugin in Claude Code?

Run `/plugin marketplace add cameronfreer/lean4-skills`, then `/plugin install lean4`. The skill triggers on its own when you work with `.lean` files, and `/lean4:diagnose` checks the installation.

How do I install the plugin in Codex?

Run `codex plugin marketplace add cameronfreer/lean4-skills --ref main`, then `codex plugin add lean4@lean4-skills`. Codex has no `/lean4:*` commands, and the skill is called through `$lean4`.

How do `prove` and `autoprove` differ?

`prove` goes cycle by cycle with you and stops at checkpoints. `autoprove` runs cycles on its own until it hits the set limits on cycle count and time.

Is the separate lean-lsp-mcp server required?

No, the plugin works without it, but with it goal inspection and mathlib search are faster than repeated full builds.

What does `checkpoint` do?

It saves a point: it builds the file and the project, checks axioms and makes a commit. `review`, by contrast, only reads code and changes nothing.

Discussion

No questions or reviews yet.

Plugins

Lean 4 skills for Codex and Claude Code: from project design to checking the statement against the source theorem

SkillMinimal access70Repository stars

MCP server for the Lean 4 language server: an agent reads proof goals and errors and searches for theorems inside your project

MCP serverExtended access550Repository stars

Millennium Harness checks Lean 4 and Dafny proofs and rejects fakes until an agent proves the theorem without loopholes.

CLIExtended access2.9KRepository stars

Evidence discipline for Claude Code: a claim without an artifact is rejected and tests are re-run before anything is called done.

PluginExtended access97Repository stars

A Claude Code plugin for large specs: requirements with proof obligations, a walking skeleton and audited sprints

PluginExtended access183Repository stars

Claude Code plugin with 17 skills: task sizing, design review, TDD, fresh-context subagents and a PR after three human decisions.

PluginExtended access97Repository stars

README in short

The shared cycle for proving workflows is plan, work, checkpoint, review, replan and then continue or stop. If the agent gets stuck, the cycle forces it to revisit the plan. Edits without a command get one bounded pass, after which the work is handed to the right workflow.

README badge

Original SKILL.md

---
name: lean4
description: "Use when editing .lean files, debugging Lean 4 builds (type mismatch, sorry, failed to synthesize instance, axiom warnings, lake build errors), searching mathlib for lemmas, formalizing mathematics in Lean, finding a counterexample to, refuting, or disproving a Lean statement, or learning Lean 4 concepts. Also trigger when the user asks for help with Lean 4, mathlib, or lakefile. Do NOT trigger for Coq/Rocq, Agda, Isabelle, HOL4, Mizar, Idris, Megalodon, or other non-Lean theorem provers."
license: MIT
---

# Lean 4 Theorem Proving

Use this skill whenever you're editing Lean 4 proofs, debugging Lean builds, formalizing mathematics in Lean, or learning Lean 4 concepts. It prioritizes LSP-based inspection and mathlib search, with scripted primitives for sorry analysis, axiom checking, and error parsing.

## Core Principles

**Search before prove.** Many mathematical facts already exist in mathlib. Search exhaustively before writing tactics.

**Build incrementally.** Lean's type checker is your test suite—if it compiles with no sorries and standard axioms only, the proof is sound.

**Respect scope.** Follow the user's preference: fill one sorry, its transitive dependencies, all sorries in a file, or everything. Ask if unclear.

**Use 100-character line width for Lean files.** Do not wrap lines at 80 characters — Lean and mathlib convention is 100. If a line fits within 100 characters, keep it on one line. See [mathlib-style](references/mathlib-style.md) for breaking strategies when lines exceed 100.

**Mathlib style quick check.** For ordinary mathematical lambdas, write `fun x ↦ ...` (`\mapsto`), not `fun x => ...`. Use `=>` for `match`/`do` branches and metaprogramming callback idioms. Prefer `show P by tac` for tactic proofs; use `show P from term` only for term proofs. See [mathlib-style](references/mathlib-style.md).

**Preserve statements and signatures — they're the file's contract.** Theorem/lemma statements and type signatures are off-limits unless the user explicitly requests changes; changing them can break callers or alter the theorem being proved. If a proof seems to require changing a statement or adding a custom axiom, stop and discuss first because that changes the contract or the proof's trust basis. Exception: within synthesis wrappers (`/lean4:formalize`, `/lean4:autoformalize`), session-generated declarations may be redrafted under the outer-loop statement-safety rules; see cycle-engine.md.

**Docstrings are scoped by workflow.** Existing docstrings are API. The default is **Rule A** — any workflow that mutates existing declarations follows it unless the user explicitly requests docstring changes:

| Mode | May do | Boundary |
|------|--------|----------|
| **A — editing existing declarations** (e.g. `/lean4:prove`, `sorry-filler-deep`, golf, refactor, any agent editing existing decls) | adjust inline comments in proof bodies | never rewrite an existing docstring — explicit user request only |
| **B — review** (`/lean4:review`) | flag weak/missing docstrings and propose replacement text in the report | read-only — never mutates files |
| **C — new-file / new-decl generation** (`/lean4:draft`, `/lean4:formalize`, `/lean4:autoformalize`) | emit module/declaration docstrings on files or declarations it newly creates | existing docstrings stay under Rule A |

Per-command policy lives in each command's doc. The docstring split applies in every project; when the mathlib Template Gate selects the mathlib header, Rule C fills its module-docstring slot — Rule C neither selects nor redefines the [template](references/mathlib-style.md#1-file-header-copyright-module-imports-critical).

## Commands

| Command | Purpose |
|---------|---------|
| `/lean4:draft` | Draft Lean declaration skeletons from informal claims |
| `/lean4:formalize` | Interactive formalization — drafting plus guided proving |
| `/lean4:autoformalize` | Autonomous end-to-end formalization from informal sources |
| `/lean4:prove` | Guided cycle-by-cycle theorem proving with explicit checkpoints |
| `/lean4:autoprove` | Autonomous multi-cycle theorem proving with explicit stop budgets |
| `/lean4:disprove` | Guided counterexample search with certified refutation |
| `/lean4:checkpoint` | Save progress with a safe commit checkpoint |

Report a problem