proof-step-review

Reviews one proof-step artifact with per-lemma audits, hidden subclaim scans, and rigor checks.

65|2|Updated Aug 10, 2026
One-click install
npx skills add https://github.com/DechenZhang/VALG-ML-Theory-Agent --skill proof-step-review-dechenzhang
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: proof-step-review
Source: https://github.com/DechenZhang/VALG-ML-Theory-Agent/tree/main/skills/proof-step-review
Command: npx skills add https://github.com/DechenZhang/VALG-ML-Theory-Agent --skill proof-step-review-dechenzhang

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Mathematical proof development in multi-stage research workflows needs independent verification of each proof step before downstream stages can rely on it. This Skill audits a single submitted proof-step artifact against its accepted setting, proof sketch, and dependency artifacts, catching local derivation errors, hidden subclaims, citation misuse, and interface drift before they propagate. ## Core Features & Use Cases - Per-Lemma Audit: Verifies every local proof unit in the lemma map has a self-contained statement, theorem-style label, and a valid line-by-line proof. - Hidden Subclaim and Assembly Scan: Detects independent nontrivial claims smuggled into prose or calculations and checks that accepted units jointly imply the exact target step claim. - Status-Based Routing: Emits exactly one verdict (ACCEPTED, REVISE_STEP, REVISE_SKETCH, or BLOCKED_BY_DEPENDENCY) with the smallest retry target so the controller repairs the minimal implicated object. - Use Case: In an ML theory research workflow, after a producer writes a proof for one sketch-row step, run this reviewer to confirm the step proves exactly the contracted claim under allowed assumptions before the final proof assembly consumes it. ## Quick Start Review the submitted proof for step S3 in perspective_1/idea_2 against its setting, accepted proof sketch, and dependency artifacts, then write the review.md verdict.

Frequently Asked Questions about proof-step-review

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I review a proof step in a theorem development workflow?

Load the setting, accepted proof sketch row, dependency artifacts, and the submitted step proof, then audit each local lemma, cited result, and the target-step assembly. Write a review.md with one status: ACCEPTED, REVISE_STEP, REVISE_SKETCH, or BLOCKED_BY_DEPENDENCY.

What inputs does proof-step-review require?

It requires the setting.md, proof_sketch.md, an accepted proof_sketch_review.md, the target Step ID, the step's proof.md, and accepted dependency proof and review artifacts when dependencies exist. It outputs a single review.md for that step.

When should a proof review route to REVISE_SKETCH instead of REVISE_STEP?

Route to REVISE_SKETCH when the proof can only work by changing the sketch-row claim, assumptions, dependencies, intended tool, output target, or required bridge step. REVISE_STEP is reserved for flaws local to the submitted proof itself.

Can the proof step reviewer modify the submitted proof?

No. The reviewer treats all artifacts as binding review targets and must not modify step proofs, sketches, trackers, or accepted results. It only names the smallest retry target for the controller to route.

What does BLOCKED_BY_DEPENDENCY mean in a step review?

It means the nearest flaw lies in an accepted dependency proof that can be repaired without changing its sketch row. The review names that dependency step as the smallest retry target, and a fresh accepted review is required before downstream use.