CtrlK
BlogDocsLog inGet started
Tessl Logo
SkillPublic

proof-checker

Rigorous mathematical proof verification and fixing workflow. Reads a LaTeX proof, identifies gaps via cross-model review (external reviewer backend, ultra reasoning), fixes each gap with full derivations, re-reviews, and generates an audit report. Use when user says "检查证明", "verify proof", "proof check", "审证明", "check this proof", or wants rigorous mathematical verification of a theory paper.

Quality

85%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide
SecuritybySnyk

Passed

No findings from the security scan

SKILL.md
Quality
Evals
Security

Quality

Content

70%Weight 40%Scale 1-5

Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.

The body delivers outstanding operational specificity and workflow rigor — verbatim prompts, exact tool contracts, and validation checkpoints with genuine feedback loops at every phase. Its main weaknesses are token efficiency (the deep-fix and restatement-check specifications are each repeated three to four times across sections) and progressive disclosure (detailed schemas and algorithms are inlined in a 900-line monolith rather than split into reference files).

Suggestions

Consolidate the deep-fix and restatement-check specifications into one authoritative section each: the same opt-in guarantees (field omission when the flag is unset, 'unavailable' treated as absent, no verdict crosstalk) are currently restated in the phase description, the dedicated mode section, Submission Artifact Emission, and Key Rules — state each guarantee once and cross-reference it.

Move the detailed JSON artifact schemas (deep_fix_plans, restatement_drift, PROOF_AUDIT.json) and the research-wiki guard bash script into a reference file such as references/artifact-schemas.md, keeping SKILL.md as the overview with one-level-deep pointers.

Condense the Side-Condition Checklist for standard theorems (DCT, MCT, Fubini, Leibniz, Jensen, Cauchy-Schwarz, Weyl/Davis-Kahan) to a name-only list or move it to a reference — Claude already knows these conditions, and the taxonomy tables already flag when verification is required.

DimensionReasoningScore

Conciseness

The ~900-line body is noticeably repetitive: the deep-fix opt-in semantics ("omitted entirely when the flag is not set", "treat 'unavailable' identically to the field being absent") are spelled out four separate times (Phase 1 addendum, the Deep-Fix Mode section, Submission Artifact Emission, and Key Rules), and the restatement-check spec is likewise repeated three times; the Side-Condition Checklist table also restates conditions for standard theorems (DCT, MCT, Fubini, Jensen, Cauchy-Schwarz) Claude already knows. It is not a 1 because most of the content is skill-specific operational detail (ARIS reviewer routing, thread management) rather than general-concept padding.

2 / 5

Actionability

Guidance is fully executable: the exact verbatim reviewer prompt blocks, exact MCP call signatures with pinned values ("model: gpt-6-astra", config: {"model_reasoning_effort": "ultra"}), concrete compile commands ("pdflatex -interaction=nonstopmode <file>.tex ..."), copy-paste bash guard scripts for the wiki ledger, and exact JSON artifact schemas. It is not a 4 because both the common path and rare failure paths are covered with paste-ready specifics.

5 / 5

Workflow Clarity

Phases 0 through 5.5 are clearly sequenced with explicit validation checkpoints at every stage — the objective Acceptance Gate, per-fix compile checks, the fan-out coverage receipt with coverage_complete gating, blind re-review for FATAL/CRITICAL fixes, and the regression proof-audit — plus explicit feedback loops (repeat Phases 2-3 up to MAX_REVIEW_ROUNDS) and a defined failure path (Phase 3.9 Unrecoverable Protocol). It is not a 4 because validation is explicit and recoverable rather than implicit or partial.

5 / 5

Progressive Disclosure

Section structure and navigation are good and the sibling references are clearly signaled one level deep ("[shared-references/fan-out-pattern.md]", "shared-references/reviewer-routing.md", "[lean-formalize](../lean-formalize/SKILL.md)"), but no bundle files exist and roughly 400 lines of material — the deep-fix JSON schema spec, the Phase 3.6 restatement algorithm, the PROOF_AUDIT.json artifact schema, and the research-wiki bash guard script — are inlined in SKILL.md where they clearly belong in separate reference files. It is not a 4 because the bulk of detailed spec content is inlined rather than appropriately split; it is not a 2 because headers are clear, references are well-signaled, and navigation works.

3 / 5

Total

15

/

20

Passed

Description

100%Weight 40%Scale 1-5

Based on the skill's description, can an agent find and select it at the right time? Clear, specific descriptions lead to better discovery.

An exemplary description: it concisely states the complete what (five concrete pipeline actions) and an explicit when-clause with multiple natural trigger phrases including bilingual variants. Distinctiveness is high and conflict risk is minimal.

DimensionReasoningScore

Specificity

The description lists five concrete, distinct actions — "Reads a LaTeX proof, identifies gaps via cross-model review (external reviewer backend, ultra reasoning), fixes each gap with full derivations, re-reviews, and generates an audit report" — covering the entire pipeline end to end. It is not a 4 because the action coverage is comprehensive with no minor gaps, matching the 'lists multiple specific concrete actions; comprehensive coverage' anchor exactly.

5 / 5

Completeness

Both 'what' and 'when' are answered explicitly: the first two sentences state the full workflow (what), and "Use when user says '检查证明', 'verify proof', 'proof check', '审证明', 'check this proof'" is an explicit when-clause with concrete trigger phrases. It is not a 4 because the when-clause is fully explicit with literal trigger phrases, not merely present-but-imprecise.

5 / 5

Trigger Term Quality

Natural user phrasings are covered comprehensively with synonyms and variants: "verify proof", "proof check", "check this proof", plus bilingual triggers "检查证明" and "审证明", and the descriptive trigger "rigorous mathematical verification of a theory paper". It is not a 4 because it already includes multiple synonymous natural phrases rather than missing a few.

5 / 5

Distinctiveness Conflict Risk

It carves out a clear niche — rigorous mathematical proof verification/fixing of LaTeX proofs via cross-model review — with triggers unlikely to fire for unrelated skills (generic code review or text checking would not say 'verify proof' or '审证明'). It is not a 4 because the niche and its triggers are essentially unique, with no meaningful overlap with closely related skills.

5 / 5

Total

20

/

20

Passed

Validation

75%

Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.

Validation — 12 / 16 Passed

Validation for skill structure

CriteriaDescriptionResult

skill_md_line_count

SKILL.md is long (901 lines); consider splitting into references/ and linking

Warning

allowed_tools_field

'allowed-tools' contains unusual tool name(s)

Warning

frontmatter_unknown_keys

Unknown frontmatter key(s) found; consider removing or moving to metadata

Warning

relative_links

Relative link issues: 4 suspicious

Warning

Total

12

/

16

Passed

Repository

wanshuiyin/Auto-claude-code-research-in-sleep

Path

skills/proof-checker/SKILL.md

Reviewed

Table of Contents

Is this your skill?

If you maintain this skill, you can claim it as your own. Once claimed, you can manage eval scenarios, bundle related skills, attach documentation or rules, and ensure cross-agent compatibility.