菜单
Interactive Lean 4 proof development for this repo — the sorrify-then-fill loop driven over lean-lsp-mcp (goal state, diagnostics, Loogle search), with Duper/lean-auto escalation and a hard
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
| name | lean-prove |
| description | Interactive Lean 4 proof development for this repo — the sorrify-then-fill loop driven over lean-lsp-mcp (goal state, diagnostics, Loogle search), with Duper/lean-auto escalation and a hard |
| argument-hint | [package] (Validator | Ckd | ValidatorUPLC) |
Mathlib-free proof development. Set SKILL=skills/lean-prove. All builds in WSL with
export PATH=$HOME/.elan/bin:$HOME/.local/bin:$PATH.
sorry the body, lake build green.duper / lean-auto (Mathlib-free hammer) on leaf goals.#print axioms <thm> shows only allow-listed axioms (docs/lean/AXIOMS.md). Any
sorryAx / native_decide / off-list axiom = not done.axiom without adding it to docs/lean/AXIOMS.md with justification.Run the VibeSec canonical in-repo implementation auditor on a feature branch before merge — ground in the graphify code-graph, convene a security council to author a sectioned audit XML, dispatch an auditor swarm, adversarially verify (self-refute) findings, and emit committed findings + triage + a schema 1.2 machine-readable gate report. Use when the user says "run vibesec", "vibesec audit", "security-gate this branch", or before merging ANY feature branch in this custody-bearing repo (every dev sprint requires a green VibeSec gate). The gate is enforced in CI (.github/workflows/vibesec.yml).
Run the per-phase Lean review-council QA gate on the lean-spec-enhancement work — a tool-executing council of four expert lenses (axiom-hygiene guardian, spec<->code fidelity, proof nonvacuity, adversarial red-team) that build the proofs, run
Property-based spec<->code conformance for this repo — regenerate Lean-emitted vectors (lake exe vectorgen), replay them against Recovery.Logic with the Haskell tasty-hedgehog suite, and run the mutation sweep (each single-guard mutation must fail at least one vector). Use when validating that the Lean spec still verifies the Haskell implementation, or when the review council's fidelity/adversarial lenses need conformance evidence.