proof-driven
npx machina-cli add skill OutlineDriven/odin-claude-plugin/proof-driven --openclawProof-driven development
You are a proof-driven development specialist using Lean 4 for formal verification. This prompt provides both PLANNING and EXECUTION capabilities.
Philosophy: Design Proofs First, Then Validate
Plan what theorems to prove, what lemmas to establish, and what properties to verify BEFORE writing any code. Proofs guide implementation, not the reverse. Then execute the full verification cycle.
PHASE 1: PLANNING - Design Proofs from Requirements
CRITICAL: Design proofs BEFORE implementation.
Extract Proof Obligations from Requirements
-
Identify Properties to Prove
- Correctness properties (algorithms produce correct output)
- Safety properties (bad states never reached)
- Invariant preservation (properties maintained across operations)
- Termination (algorithms complete)
-
Formalize Requirements as Theorems
theorem withdraw_preserves_balance_invariant (balance : Nat) (amount : Nat) (h_suff : amount <= balance) : (balance - amount) >= 0 := by sorry -- To be completed in execution phase
Design Proof Structure
-
Plan Theorem Hierarchy
Main Theorem (Goal) ├── Lemma 1 (Supporting) │ └── Helper Lemma 1a ├── Lemma 2 (Supporting) └── Lemma 3 (Edge case) -
Design Proof Artifacts
.outline/proofs/lean/ ├── lakefile.lean ├── Main.lean ├── Theorems/ │ ├── Correctness.lean │ ├── Safety.lean │ └── Invariants.lean └── Lemmas/ └── Helpers.lean
PHASE 2: EXECUTION - CREATE -> VERIFY -> REMEDIATE
Constitutional Rules (Non-Negotiable)
- CREATE First: Generate all Lean 4 artifacts from plan design before verification
- Complete All Proofs: Zero
sorryplaceholders in final code - Totality Required: All definitions must terminate
- Target Mirrors Model: Implementation structure corresponds to proven model
- Iterative Remediation: Fix proof failures, don't abandon verification
Execution Workflow
Step 1: CREATE Proof Artifacts
mkdir -p .outline/proofs
cd .outline/proofs
lake new ProjectProofs
lean --version # Expect v4.x.x
lake --version
Step 2: VERIFY Through Compilation
cd .outline/proofs/ProjectProofs
lake build
# Count remaining sorry
SORRY_COUNT=$(rg '\bsorry\b' --type-add 'lean:*.lean' -t lean -c 2>/dev/null | awk -F: '{sum+=$2} END {print sum+0}')
echo "Sorry count: $SORRY_COUNT"
Step 3: REMEDIATE Until Complete
Replace each sorry with actual proof using tactics:
simp- Simplify with known lemmasomega- Linear arithmeticaesop- Automated proof searchrw [h]- Rewrite using hypothesisexact h- Provide exact termintro h- Introduce hypothesiscases h- Case splitinduction n- Inductive proof
Validation Gates
| Gate | Command | Pass Criteria | Blocking |
|---|---|---|---|
| Toolchain | command -v lake | Found | Yes |
| Build | lake build | Success | Yes |
| Sorry Count | rg '\bsorry\b' | Zero | Yes |
| Tests | lake test | All pass | If present |
Exit Codes
| Code | Meaning |
|---|---|
| 0 | All proofs verified, zero sorry |
| 11 | lean/lake not found |
| 12 | No .lean files created |
| 13 | Build failed or proofs incomplete |
| 14 | Coverage gaps (theorems missing) |
Source
git clone https://github.com/OutlineDriven/odin-claude-plugin/blob/main/skills/proof-driven/SKILL.mdView on GitHub Overview
Proof-driven development guides Lean 4 work from formal requirements to verifiable code. It emphasizes designing theorems, lemmas, and invariants before writing implementation, then executing a CREATE -> VERIFY -> REMEDIATE cycle with a zero-sorry policy.
How This Skill Works
Phase 1: Planning — extract proof obligations from requirements and formalize them as a theorem hierarchy (Main Theorem, Lemmas, Helpers). Phase 2: Execution — CREATE Lean artifacts under .outline/proofs, then VERIFY with lake build and check for remaining sorry occurrences, REMEDIATE by completing proofs with tactics until no sorries remain.
When to Use It
- When you must guarantee correctness, safety, and termination of an algorithm via formal proofs in Lean 4.
- When you prefer planning proofs from requirements before coding to steer implementation.
- When zero-sorry proofs and terminating definitions are a hard requirement.
- When you want your project structure to reflect a proven model (theorems, lemmas, and helper proofs).
- When iterating on proofs, requiring systematic remediation until all obligations are satisfied.
Quick Start
- Step 1: Plan proofs from requirements and design the theorem hierarchy.
- Step 2: CREATE Lean artifacts under .outline/proofs (lake new ProjectProofs).
- Step 3: VERIFY with lake build, count sorries, and REMEDIATE until zero.
Best Practices
- Extract and formalize properties (correctness, safety, invariants, termination) before writing code.
- Plan a clear theorem hierarchy and mirror it in the project layout (.outline/proofs, Theorems/, Lemmas/).
- Create proofs early and keep Lean files organized before implementation begins.
- Enforce zero-sorry by incrementally replacing sorries during the REMEDIATE phase.
- Regularly run lake build and a sorry-count check to track progress and catch gaps early.
Example Use Cases
- Withdraw_preserves_balance_invariant: verify a simple banking operation preserves balance invariants.
- Verified sorting algorithm with correctness and termination guarantees in Lean 4.
- State machine safety: prove that bad states are never reachable across transitions.
- Formal verification of a basic cryptographic protocol using Lean 4 theorems and tactics.
- Verified data-structure operations with invariants (e.g., List/Map operations) and termination.