From proofreader
Draft a clean, self-contained technical brief documenting a correctness finding — usable to share with coauthors, to record in a project log, or to drop into a paper revision as the basis for a fix. Produces LaTeX or Markdown depending on the user's preference. Use when the user says "write this up", "draft a finding for X", "write a brief on the Theorem N issue", or after `audit-proof` + `find-counterexample` + `stress-test-defense` have produced material to synthesize.
How this skill is triggered — by the user, by Claude, or both
Slash command
/proofreader:writeup-findingThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
You are drafting a concise technical brief for a finding produced by the proofreader pipeline. The brief is for the *author's own records* and possibly for sharing with coauthors — not for external publication. Optimize for:
You are drafting a concise technical brief for a finding produced by the proofreader pipeline. The brief is for the author's own records and possibly for sharing with coauthors — not for external publication. Optimize for:
The user may request latex (default, suitable for pasting into a paper-revision project) or markdown (suitable for a project log or GitHub issue). If unspecified, ask.
A finding brief can serve several audiences along a spectrum from private to public. The user's intent shapes the tone, the structural emphasis, and how much context the brief duplicates from the paper. Ask once if the intent isn't clear from the conversation:
Tone discipline across the spectrum: as the audience becomes more public, drop hedging language ("we believe", "appears to") in favor of declarative statements where evidence supports them — and conversely, do not declare an error you have only inferred. Public-facing briefs that overclaim are worse than private ones that hedge.
The eight-section Document Structure below is the maximum form; private and coauthor briefs may compress or merge sections (e.g., fold Background into Overview), while errata briefs may expand Suggested Fix into a full corrected proof.
Required:
audit-proof, identifying the specific flaw.Optional but improves output:
3. Counterexample — output of find-counterexample, including parameters, paper-vs-correct result, and verification method.
4. Stress-test verdict — output of stress-test-defense, including any defense considerations and the arbiter's verdict.
5. Paper bibliography entry — for the \cite{} reference.
The brief should have these sections, in order. Sections that lack source material may be omitted (e.g. no "Counterexample" section if none was constructed).
Lead with the finding, not the methodology. State:
result: likely_true + proof: unsound_but_recoverable, say so plainly: "The proof of Theorem 3 contains a load-bearing error, but the result itself is true via [alternative argument]. The author should rewrite the proof; no erratum is required for the claim."If the safety impact is limited (e.g. the issue affects optimality but not safety, or affects only the proof technique while the result stands), state this explicitly. The reader should know in 30 seconds whether to panic.
Enough context for a reader unfamiliar with the specific paper. Define key notation. State the system model assumptions that are relevant to the finding. Cite the paper using \cite{} (LaTeX) or a linked reference (Markdown).
Name this section to describe the specific flaw: "The Gap", "The Inversion", "Non-Termination of the Iteration", or simply "The Issue". 1–3 paragraphs.
Describe where in the proof the reasoning breaks down and why. Reference specific proof steps, equations, or lemmas from the paper. Be concrete: a reader should be able to put your brief next to the paper and follow along.
Present the counterexample using three subsections:
tabular+booktabs table (LaTeX) or a Markdown table.Three paragraphs:
If the stress test was not run, omit this section.
What change to the paper would resolve the issue? Be specific. Possibilities:
State whether the fix preserves downstream results that depend on this one, or whether they also need to change.
The paper itself, any cited prior work invoked in the discussion, and any external material (appendices, tech reports) that were referenced.
Start with:
\documentclass[11pt]{article}
\usepackage[margin=1in]{geometry}
\usepackage{amsmath,amssymb,amsthm}
\usepackage{hyperref}
\usepackage{booktabs}
\newtheorem{claim}{Claim}
\newtheorem{observation}{Observation}
Add \usepackage{tikz} + \usetikzlibrary{arrows.meta} only if a diagram genuinely clarifies the counterexample (e.g. a schedule visualization).
Output raw LaTeX. Do not wrap the output in Markdown code fences.
Use standard CommonMark. Use $...$ for inline math and $$...$$ for display math (most Markdown renderers + the user's LaTeX tooling handle this). For tables, use Markdown's pipe-table syntax.
likely_false_positive or inconclusive, say so in the overview. Don't write the brief as if the issue is confirmed when it isn't. The brief's job is to be a faithful record, not advocacy.A single document (LaTeX .tex source or Markdown .md), written to a file in the user's working directory if the tool supports file writes, or printed to the conversation otherwise. Filename suggestion: finding-<result-label>.tex or finding-<result-label>.md.
Provides a checklist for code reviews covering functionality, security, performance, maintainability, tests, and quality. Use for pull requests, audits, team standards, and developer training.
npx claudepluginhub binarybison/proofreader --plugin proofreader