Get the FREE Ultimate OpenClaw Setup Guide →

proof-driven

npx machina-cli add skill OutlineDriven/odin-claude-plugin/proof-driven --openclaw
Files (1)
SKILL.md
3.9 KB

Proof-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

  1. 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)
  2. 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

  1. Plan Theorem Hierarchy

    Main Theorem (Goal)
    ├── Lemma 1 (Supporting)
    │   └── Helper Lemma 1a
    ├── Lemma 2 (Supporting)
    └── Lemma 3 (Edge case)
    
  2. 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)

  1. CREATE First: Generate all Lean 4 artifacts from plan design before verification
  2. Complete All Proofs: Zero sorry placeholders in final code
  3. Totality Required: All definitions must terminate
  4. Target Mirrors Model: Implementation structure corresponds to proven model
  5. 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 lemmas
  • omega - Linear arithmetic
  • aesop - Automated proof search
  • rw [h] - Rewrite using hypothesis
  • exact h - Provide exact term
  • intro h - Introduce hypothesis
  • cases h - Case split
  • induction n - Inductive proof

Validation Gates

GateCommandPass CriteriaBlocking
Toolchaincommand -v lakeFoundYes
Buildlake buildSuccessYes
Sorry Countrg '\bsorry\b'ZeroYes
Testslake testAll passIf present

Exit Codes

CodeMeaning
0All proofs verified, zero sorry
11lean/lake not found
12No .lean files created
13Build failed or proofs incomplete
14Coverage 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

  1. Step 1: Plan proofs from requirements and design the theorem hierarchy.
  2. Step 2: CREATE Lean artifacts under .outline/proofs (lake new ProjectProofs).
  3. 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.

Frequently Asked Questions

Add this skill to your agents
Sponsor this space

Reach thousands of developers