SuperAPI AI Directory
Partner with us中文AI newsFavorites
Skillslight-paper-polishing

light-paper-polishing

Writing & research

View repository

Updated 10-16 00:00

About this skill

Paper Polishing (Reviewer's Perspective)

Not just fixing grammar

Two levels:Surface(language, terminology, sentence patterns, readability) + Deep(logic, argumentation, structure, presentation of novelty). Deep takes priority — reviewers rarely reject because of grammar.

Deep dimension: the reviewer's five questions (go through each claim item by item)

The five questions are "what to review"; for the specific "how to revise", see references/argument_review.md— the Claim–Evidence–Boundary triad, the Hedging calibration ladder (claim strength matching evidence), section responsibility division (Results should not pile on mechanisms / Methods must pass the reproducibility test / only Discussion does hedging), and AI use disclosure. Use the two together. Organize by reviewer scoring dimensions (synthesizing Elsevier reviewer guidelines and conference-style review):

  1. soundness — method holds up: Does every claim have evidence (experiment/citation/derivation)? Mark "bare claims". Does causality hold, and are there "unargued leaps"?
  2. novelty — presentation of novelty: Are the contributions consistently and prominently worded in the abstract/introduction/conclusion? Contribution sentences should start with a verb and be measurable. Can readers grasp the point of difference at a glance?
  3. clarity — readability: Are there breakpoints between paragraphs? Does each paragraph have a topic sentence and serve only one argument ("what should this paragraph make the reviewer believe").
  4. reproducibility — reproducible: Are the method/settings/hyperparameters/data sufficient to reproduce? If experiments only report numbers without explanation, add the "why".
  5. related-work — sufficient citations: Are comparison and positioning in place? Missing citations go to m10. For in-text citation placeholders, uniformly use the machine-readable citekey \cite{authorYearWord}（first author's surname + year + first content word of the title, all lowercase, e.g. \cite{zhang2024deep}), found [Zhang 2019] -style free-text placeholders must be changed to this formula — otherwise typesetting reports an undefined citation; this formula is from the same source as the .bib key pinned by m10.

Align the introduction with the "four-paragraph pattern": background pain point → shortcomings of existing methods (motivation) → our insight/approach → contribution list.

Surface dimension: four language-level checks (borrowing Grammarly's four-part framework, with weights adjusted for academic manuscripts)

  1. correctness: grammar, spelling, punctuation, consistent tense and voice.
  2. clarity: remove redundancy, split long subordinate clauses, eliminate unclear reference ("don't make reviewer think").
  3. delivery/tone: maintain formal restraint; remove colloquialisms and exaggeration (use novel/significantly/very sparingly).
  4. consistency: keep terminology consistent (a07), define abbreviations at first occurrence, unify number and unit formats.

engagement/fancy wording is weakened in academic manuscripts — don't sacrifice precision for diversity. Preferred: can be run directly (free and anonymous): the LanguageTool public cloud endpoint POST https://api.languagetool.org/v2/check, parameter language=en-US(or auto）、level=picky(enable strict style rules),motherTongue=zh-CN; anonymous real-world test returned HTTP 200, returning matches[] with message/replacements/offset, checking item by item. For privacy/batch scenarios, switch to self-hosting. A one-line runnable example:

curl -s -X POST "https://api.languagetool.org/v2/check" \
  -d "language=en-US" -d "level=picky" \
  --data-urlencode "text=This sentence have a error." | python -m json.tool

DeepL rewriting requires a paid key and cannot be run anonymously：/v2/write/rewrite both hosts returned 404 in actual testing,/v2/translate returned 403 in actual testing (requires Authorization: DeepL-Auth-Key); therefore DeepL is used only as a "whole-sentence rewriting reference when a key is available,"writing_style=academic it tends toward whole-sentence rephrasing and easily alters terminology and the author's voice, so manual review is mandatory (for endpoint availability, see references.md). Academic wording should follow Writefull's approach of "expressions customary in published corpora" rather than general grammar.

How it works: a four-step pipeline (distill → critique → polish → audit)

  1. distill: first capture the core contribution and confirm which argument each paragraph serves (structure/storyline level, benchmarked against the strategist perspective).
  2. critique: list weaknesses from the reviewer's perspective—go through the "reviewer's five questions" item by item, mark the points most likely to be questioned or pressed further, and strengthen them in advance or add limitations.
  3. polish: revise the language—four language-level checks, processed module by module, with the user able to specify sections.
  4. audit: final check of consistency/terminology/format/abbreviations/citations (compliance threshold, benchmarked against pre-submission checks).

For each change, provide:problem → cause → revision plan → revised text, with before/after comparison when necessary. For major restructuring, explain the approach first, then revise. Preserve the author's voice and do not over-rewrite (DeepL-style whole-sentence rephrasing dilutes the voice, so use it cautiously). Rewrite the abstract/introduction/conclusion according to the high-level patterns in db02.

Example: polishing looks like this (every change must go through all four columns)

The output format is fixed as "original sentence → problem diagnosis → revised version → why it is better." The three examples below cover three categories: deep-level (soundness), surface-level (clarity), and contribution presentation (novelty).

Example 1 · deep-level / bare claim (soundness)

  • Original sentence：Our method significantly outperforms existing approaches and is much more efficient.
  • Problem diagnosis: ① "significantly/much more" is an unsupported exaggerated bare claim, and reviewers will immediately ask "by how much, compared with what, and where is the significance test?"; ② "existing approaches" is vague and does not specify the baseline; ③ the efficiency dimension is undefined (time? memory?).
  • Revised version：On ImageNet, our method improves top-1 accuracy by 2.3 points over ResNet-50 (76.1% vs. 73.8%) while reducing inference latency by 18% (12.4 ms vs. 15.1 ms per image, single A100).
  • Why it is better: replace adjectives with measurable numbers + a specific baseline + hardware conditions, turning the claim from "questionable" into "reproducible"; delete significantly and let the data speak for itself (echoing surface-level delivery: remove exaggeration).

Example 2 · surface-level / long subordinate clauses + unclear references (clarity)

  • Original sentence：The model, which is trained on the dataset that we collected and which contains various types of noise that may affect performance, achieves good results.
  • Problem diagnosis: ① three layers of nested subordinate clauses (which…that…which…that) force reviewers to reread, violating "don't make reviewer think"; ② "various types of noise" is vague in reference; ③ "good results" is an information-free phrase.
  • Revised version：We train the model on our collected dataset, which contains label noise and sensor artifacts. Despite this noise, the model reaches 89.2% F1.
  • Why it is better: split one long sentence into two short sentences, each carrying one meaning; make "various noise" concrete as two specific types of noise; change "good results" to specific metrics. Readability, correctness, and information density are all improved at the same time.

Example 3 · contribution presentation (novelty, consistent across the three places in the introduction/abstract)

  • Original sentence：In this paper, we study the problem of domain adaptation and propose some techniques to improve it.
  • Problem diagnosis: ① "study / some techniques / improve" are all soft verbs, so readers cannot grasp the point of difference; ② the contribution is not measurable and cannot be aligned with the abstract/conclusion; ③ it does not point out the "insight."
  • Revised version：We make three contributions: (1) we identify feature-norm collapse as the dominant failure mode in test-time domain adaptation; (2) we propose NormGuard, a regularizer that constrains feature norms during adaptation; (3) NormGuard raises mean accuracy by 3.1 points across five benchmarks.
  • Why it is better: Start with verbs (identify/propose/raise), contributions countable and measurable, point out the insight (feature-norm collapse); these three sentences can be reused verbatim in the abstract and conclusion, ensuring the wording is consistent in all three places (Peng Sida's "contributions consistent in three places").

Directly runnable scripts (scripts/)

The three artifacts turn the above method into runnable tools, outputtingisomorphic structured findings(schema see references/findings_schema.md）。downstream consumption: m14 review-rebuttal reads this findings JSON as pre-review input before simulating review—overclaim maps to major comments on Soundness/Significance,ai_tone/punctuation etc. map to Minor on Presentation (field mapping is in the m14 SKILL "Consume m08 polish findings" section), so the category values and the severity tiers in schema §4 must be stable; if field names change, sync both places.

  • scripts/polish.py: wraps the LanguageTool anonymous cloud endpoint POST https://api.languagetool.org/v2/check（level=picky、motherTongue=zh-CN). Automatically by paragraph/sentencechunking(single chunk <18000 characters, avoiding the anonymous ~20k limit), mapping each match's offset back to theoriginal text's absolute line/col. When the endpoint is unreachable or non-200,automatically degradeto local regex rules (mode=local-fallback），_meta.http_codes records the real runtime HTTP code, never fabricating cloud results.
    • Measured (2026-06-06 in this environment): built-in sample → mode=languagetool http=[200], returns EN_A_VS_AN/PLURAL_VERB_AFTER_THIS and other real rules.
    • How to run:python scripts/polish.py --file paper.txt --json or echo "..." | python scripts/polish.py。
  • scripts/mechanical_check.py（no API needed): scans ① overclaim blacklist (significant/seminal/novel/outperforms…) ② AI tone/filler phrases (in conclusion / it is worth noting / delve into / furthermore…) ③ hedge stacking ④ claim_strength: strong claim words (prove/conclusively/unprecedented/always…) give downgrade replacement suggestions from the Hedging ladder (connecting to references/argument_review.md §2) ⑤ paragraph passive-voice ratio exceeding threshold ⑥ punctuation hygiene (em-dash spacing, full-width punctuation mixed into English, multiple spaces, space before punctuation). Output {line,col,category,issue,suggestion,context}. Pure stdlib, runnable in any environment.
    • How to run:python scripts/mechanical_check.py --file paper.txt --json。
  • When the two scripts have no input, they runbuilt-in self-check samples, ensuring python <script> can always run through. LanguageTool handles surface grammar, mechanical_check handles the "academic tone/bare assertions" that LanguageTool misses; the two are complementary.
  • scripts/style_fingerprint.py（no API needed): style calibration. Generic polishing easily turns everyone into the same kind of "standard academic tone"; this script does the opposite—first from the user'spreviously approved past manuscriptsit measures a personal style fingerprint (sentence-length rhythm, passive ratio, first person, connector preferences, punctuation habits, high-frequency content words), and during polishing calibrates to the author's own voice rather than flattening it into a template.--build past*.txt --out style.json builds the fingerprint;--compare draft.txt --ref style.json marks the dimensions where the draft to be polished deviates most from the author's habits and gives adjustment hints. The fingerprint is only a statistical profile; "what to change it into" is still the author's judgment, and the script does not automatically rewrite.
    • How to run:python scripts/style_fingerprint.py --selftest, or after building the fingerprint --compare draft.txt --ref style.json。
    • connection: the fingerprint can be stored in a02 memory-pm's "user preferences (writing style)" and reused across projects.

Complete before/after examples

For a walkthrough of one passage through the four-step pipeline (raw paragraph → script hits → four-column item-by-item revision → final draft, including fixes for the four hit types overclaim/ai_tone/passive/hedge), see examples/full_pipeline_walkthrough.md. The "Demo: what polishing looks like" above already demonstrates the three single-sentence revision methods for soundness/clarity/novelty; the end-to-end full-paragraph demonstration has been moved to examples for on-demand reference.

Connections

Alternate and loop with m07; after revising, run m14 simulated peer review for validation; align terminology with db09; route citation issues to m10 (in the main text, \cite{} placeholder uses authorYearWord formula, sharing the same source as the citekey pinned by m10). Before delivery, pass the a08(light-self-review) self-check gate. Record each round's version to db09.

For item-by-item verification notes on tools and methods, see references.md(including real endpoint parameters for LanguageTool/DeepL, capability boundaries of Writefull/Paperpal/Grammarly, and workflows for each writing skill); for the structured findings field contract, see references/findings_schema.md; runnable scripts are in scripts/polish.py、scripts/mechanical_check.py。