Proofread

Paper Proofreading

Overview

Systematically proofread an academic paper against six structured checks. Each check scans the full paper and collects concrete, line-level findings.

Two modes are available:

• Report mode (default): produces a single prioritized written report organized by check, with a summary scorecard at the top.
• Interactive mode: presents issues one at a time, lets the user decide how to resolve each one, and applies edits directly to the source files.

This skill targets LaTeX source files as primary input. Plain-text and PDF inputs are supported but yield less precise findings (line numbers will be approximate or absent).

When to Use This Skill

Use this skill when:

• Finishing a draft and want a full systematic review before submission — use report mode
• Sitting down to actively fix a paper issue by issue — use interactive mode
• Returning to a paper after a break and want to catch consistency issues
• Preparing a revision and need to verify all issues flagged by reviewers are resolved

Arguments

/proofread [path] [--check ] [--interactive]

• path — path to the paper's root .tex file or directory containing .tex files. Defaults to the current directory.
• --check — run only a specific check. IDs: intro, math-notation, stats, figures, grammar, abbrev. Omit to run all six.
• --interactive — enable interactive mode. Omit for report mode.

---

Core Workflow

Step 0: Collect Input Files

1. Resolve the input path. If a directory is given, find all .tex files recursively (find . -name "*.tex").
2. Read all .tex files into memory. Note the root file (typically main.tex) for structure analysis.
3. Concatenate files in document order (follow \input and \include chains from the root) to produce a single logical document for cross-section checks.
4. If no .tex files are found, attempt to read a plain-text or PDF version and warn the user that line numbers will be absent.

---

Check 1: Paper Structure

Goal: Verify that the abstract and introduction follow the expected structure of an academic paper: clear problem motivation, gap identification, proposed approach, quantitative results (abstract), explicit contributions, and a section roadmap. Check that the related work is discussed correctly. Check that the conclusion follows common guidelines.

1.1 Check abstract structure

The abstract must follow this fixed four-part structure, in order:

1. Motivate the problem — why does this problem matter? Showing real-world relevance strongly recommended.
2. Identify the gap — what do existing approaches fail to do?
3. State the proposed approach — what does this paper do?
4. Give key quantitative results — at least one concrete number supporting the main claim.

• [ERROR] if any of the four parts is entirely absent. [VIBE]
• [WARN] if the parts appear but are out of order (e.g., approach stated before gap). [VIBE]
• [WARN] if no quantitative result is given (e.g., only qualitative claims like "significantly improves"). [VIBE]
• [WARN] if the abstract exceeds 150 words (typical conference limit; adjust if venue is known). [HARD]

1.2 Check introduction structure

The introduction must contain, in roughly this order:

1. Motivation — a paragraph establishing why the problem is important and relevant. Showing real-world relevance strongly recommended.
2. State of the art and gap — a summary of related approaches and their shortcomings. The gap must be stated explicitly (e.g., "However, none of these methods...").
3. Proposed approach — a description of what this paper proposes and why it addresses the gap.
4. Contribution list — a very concrete list of explicit contributions (see 1.3).
5. Section roadmap — [OPTIONAL] a final paragraph describing the structure of the paper (see 1.4).

• [ERROR] if the contribution list is absent. [MIX]
• [INFO] if the section roadmap is absent. [MIX]
• [WARN] if the gap is not stated explicitly (related work is described but no "However,..." or equivalent contrast is made). [VIBE]
• [WARN] if the proposed approach is not re-stated in the introduction after the related work (it should appear both in the abstract and the introduction). [VIBE]
• [WARN] if the novelty of the work is not stated explicitly (e.g., "To the best of our knowledge, this is the first work to..."). [VIBE]
• [INFO] if the introduction order deviates significantly from the structure above. [VIBE]

1.3 Check contribution list

• [ERROR] if a contribution item is too encompassing. The contributions should very precisely list the new theoretical contributions to the field. These contributions must be elements that are not present in related work. New contributions should be supported by theorems, proofs, algorithms etc. [VIBE]
• [ERROR] if a contribution item is vague and not falsifiable — e.g., "We improve performance" without specifying what is improved or by how much. A good contribution names the specific claim: "We show that our method reduces collision rate by 30% compared to baseline X." [VIBE]
• [ERROR] if the word contribut..., e.g., contribute, contribution, is not used in the introduction. [HARD]
• [WARN] if contributions are not presented as a list (numbered or bulleted). A list is recommended, but a very clear sentence with (a), (b), and (c) or (i), (ii), and (iii) also works. [MIX]
• [INFO] if any contribution item does not begin with "We", "This work", "In this paper" etc. (e.g., "We propose...", "We show...", "We evaluate...", "We introduce...", "We demonstrate..."). [MIX]
• [INFO] if a contribution item uses passive voice instead of "We" (e.g., "A new method is proposed" → "We propose a new method"). [MIX]

1.4 Check section roadmap

The last paragraph of the introduction should describe the structure of the remainder of the paper.

• [WARN] if no roadmap paragraph is present in the introduction. [MIX]
• [ERROR] if the roadmap references a section number or name that does not match the actual sections in the document (verify against \section{} commands). [MIX]
• [WARN] if the roadmap uses future tense ("will be presented") instead of present tense ("is presented", "presents"). [MIX]
• [WARN] if not all major sections are mentioned in the roadmap (every top-level \section{} except the introduction itself should appear). [MIX]
• [INFO] if the roadmap does not open with a standard linking phrase such as "The remainder of this paper is structured as follows" or "This paper is organized as follows". [MIX]

1.5 Check problem statement

If the paper has a dedicated problem statement section or subsection:

• [ERROR] if the problem statement mentions the proposed solution (e.g., "we use a safety shield"). The problem statement must describe what needs to be solved, not how. [VIBE]
• [WARN] if the problem statement includes implementation details that belong in the method section. [VIBE]

1.6 Check related work structure

• [ERROR] if related work is organized chronologically rather than thematically by approach category. Each category must open with a clear topic sentence. [VIBE]
• [WARN] if the related work section does not end with a gap statement that clearly identifies what prior methods cannot do and thus motivates the proposed work. [VIBE]
• [ERROR] if the related work section explicitly describes or evaluates the proposed method (e.g., "In contrast to prior work, our method does X"). Related work discusses others' work only. [VIBE]

1.7 Check experiments and hypotheses

• [WARN] if the experiments section does not state hypotheses explicitly before presenting results (e.g., "H1: ..., H2: ..."). Explicit hypotheses are a frequently recurring professor comment. [VIBE]
• [WARN] if a conclusion generalizes a result to "all cases" or "any environment" when the experiment only covered one or two settings. [VIBE]

1.8 Check conclusions

• [WARN] if the conclusion does not explain why the results are better than prior work. [VIBE]
• [WARN] if the conclusion does not reiterate the unique features of the approach. [VIBE]
• [WARN] if the conclusion does not mention at least one key quantitative result. [VIBE]
• [INFO] if the conclusion introduces new content not discussed anywhere else in the paper. [VIBE]

1.9 Check motivation scope

Motivation — establishing why the problem matters, why existing approaches fall short, or why the task is challenging — belongs exclusively in the introduction (and, briefly, the related work gap statement). Method sections must describe what the approach does and how it works, not re-argue why the problem is worth solving. Flag motivational content in the methodology section(s) and experiment/result section(s):

• [ERROR] if a method paragraph opens with a sentence that re-states the problem motivation from the introduction (e.g., "Ensuring safety is critical in human-robot interaction because...", "Existing methods fail to handle..."). [VIBE]
• [ERROR] if a method paragraph introduces new motivation not present in the introduction — a reason the problem is hard or important that was not established earlier (e.g., "Another challenge is that sensors are noisy, which makes..."). [VIBE]
• [WARN] if transitional sentences between subsections of the method re-introduce the gap or limitation of prior work (e.g., "Since prior methods cannot handle X, we instead..."). A single back-reference is acceptable; repeated gap re-statements across multiple method subsections are not. [VIBE]

---

Check 2: Math Symbols and Notation

Goal: Verify that every math symbol is defined before first use, that equations are properly integrated into the text, and that LaTeX notation follows best practices.

2.1 Collect all math symbols

Scan all math environments ($...$, $$...$$, \(...\), \[...\], equation, align, gather, multline, and their starred variants) and build a list of every distinct symbol used. A symbol is any single letter, Greek letter, calligraphic/bold/hat/dot-decorated letter, or named operator that carries semantic meaning (e.g., x, \mathcal{X}, \boldsymbol{\theta}, \hat{f}, \dot{x}, J, \pi).

Exclude pure syntax tokens (=, +, -, \leq, \in, \forall, etc.) — these do not require definition.

2.2 Check symbol definitions

For each symbol, find its first use in document order.

• [ERROR] if a symbol is used in an equation or inline math before it is defined anywhere in the text. A definition is a prose statement of the form "where X is ..." or "let X denote ..." appearing in the same or an earlier paragraph, or a where clause immediately following the equation. [MIX]
• [ERROR] if a symbol is used in a figure caption or table caption before it has been defined in the main text at that point in reading order. [MIX]
• [WARN] if a symbol is defined but never used. [MIX]
• [INFO] if the definition appears after the equation rather than before (post-equation where clauses are acceptable but pre-definition is preferred). [MIX]

Subscripts and superscripts:

Treat each distinct subscript and superscript as a symbol in its own right if it carries semantic meaning (i.e., it is a variable or index, not a fixed label like \text{max}). Examples of semantic indices: i in x_i, t in s_t, k in g^{(k)}. Examples of non-semantic labels: \text{max}, \text{ref}, 0 as a constant initializer.

For each semantic subscript/superscript:

• [ERROR] if the index is used but never defined in prose (e.g., s_t appears but t is never explained as the time step index). [MIX]
• [ERROR] if a subscripted or superscripted symbol (e.g., x_i) is introduced without defining what the index ranges over (e.g., i \in \{1, \ldots, N\} or "for each joint i"). [MIX]
• [WARN] if an index is defined but the corresponding indexed family of symbols is only used once (indexing may be unnecessary). [MIX]
• [WARN] if the same index letter is used with different meanings in different parts of the paper (e.g., i denotes joint index in Section II but episode index in Section IV). Flag each such conflict with both locations. [MIX]

2.3 Check symbol consistency

This check verifies that notation is globally coherent: the same symbol always refers to the same concept, and the same concept is always referred to by the same symbol.

One symbol, one concept:

Build a map from each symbol to all prose definitions found for it across the document.

• [ERROR] if a symbol is defined to mean two different things in different parts of the paper (e.g., x is defined as "state" in Section II and as "position" in Section IV). Report both definition locations. [VIBE]
• [WARN] if a symbol is used in a context that is semantically inconsistent with its definition, even if not explicitly redefined (e.g., t defined as a continuous time variable but used as a discrete step index elsewhere). [VIBE]

One concept, one symbol:

Identify concept clusters: groups of symbols that appear to refer to the same entity based on their prose definitions and surrounding context.

• [WARN] if two different symbols appear to refer to the same concept without explanation (e.g., "goal state" is written as g in one section and as x_g in another). Flag as a potential inconsistency for the author to confirm. [VIBE]
• [WARN] if a concept is sometimes referred to by its symbol and sometimes by a synonymous term that suggests a different symbol could be used (e.g., "target" and "goal" used interchangeably but only one has a symbol). [VIBE]

Decoration consistency:

Decorations (\hat{}, \tilde{}, \bar{}, \boldsymbol{}, \mathcal{}) should carry consistent semantic meaning throughout the paper (e.g., \hat{x} always means "estimated x", \mathcal{X} always means "set of x").

• [WARN] if the same decoration is applied to different base symbols with different semantic meanings (e.g., \hat{x} means "estimate" but \hat{f} means "learned function" where a different convention might be expected). [VIBE]
• [WARN] if a concept that is decorated in one equation (e.g., \hat{x} for estimated state) appears without decoration in another equation where the estimated value is clearly intended. [VIBE]

2.4 Check variables in text

Single-letter variables and all math symbols appearing inline in prose must be wrapped in math mode.

• [ERROR] for any bare single letter used as a variable in prose without math delimiters, e.g., the value of N instead of the value of $N$. Use context to distinguish math variables from ordinary words — flag only when the letter clearly refers to a mathematical quantity. [MIX]
• [ERROR] for bare expressions like t+1 or x_i outside math mode. [HARD]

2.5 Check equation integration and punctuation

Equations must be part of the surrounding text flow and punctuated accordingly.

• [ERROR] if a displayed equation is not preceded by a colon, comma, or a sentence that flows into it grammatically. [VIBE]
• [ERROR] if a displayed equation is not followed by a punctuation mark (period, comma) where one is grammatically required by the surrounding sentence. [MIX]
• [ERROR] if an equation label is referenced before the equation appears in the document (forward reference to an equation). [MIX]

2.6 Check scalar, vector, matrix, and set notation

Goal: Identify the notation convention the paper uses for mathematical types, then verify it is applied consistently to every symbol.

Step 1 — Infer the convention

Scan the document for symbols whose type can be determined unambiguously from context. Use the following signals:

| Signal | Type inferred | |--------|--------------| | $x \in \mathbb{R}$ (no

…

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: JakobThumm
• Source: JakobThumm/proofreading
• License: MIT

Install and usage instructions live in the source repository linked above.