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

light-paper-polishing

Writing & research

View repository

Updated 10-16 06:23

About this skill

Paper Polishing (Reviewer Perspective)

Not just fixing grammar

Two layers:Surface(language, terminology, sentence patterns, readability) + Deep(logic, argumentation, structure, presentation of innovation points). Deep first—reviewers rarely reject because of grammar.

Deep dimension: Reviewer's Five Questions (check every claim item by item)

The Five Questions are "what to review"; for specific "how to revise", see references/argument_review.md—the Claim–Evidence–Boundary trio, the Hedging calibration ladder (claim strength matches evidence), section responsibility division (Results do not pile on mechanisms / Methods pass reproducibility tests / Discussion is where hedging belongs), and AI use disclosure. Use the two together. Organize by review scoring dimensions (synthesizing Elsevier reviewer guidelines and conference-style review):

  1. soundness method validity: Does every claim have evidence (experiment/citation/derivation)? Mark "bare claims". Is causality valid, and are there "unargued jumps"?
  2. novelty presentation of innovation: Are contributions stated consistently and prominently in the abstract/introduction/conclusion? Contribution sentences should start with verbs and be measurable. Can readers grasp the differences at a glance?
  3. clarity readability: Are there breaks between paragraphs? Does each paragraph have a topic sentence and serve only one argument ("what should this paragraph make reviewers believe")?
  4. reproducibility: Are the methods/settings/hyperparameters/data sufficient for reproduction? If experiments only report numbers without explanation, add "why".
  5. related-work sufficient citations: Are comparison and positioning in place? Missing citations go to m10. For in-text citation placeholders, uniformly use 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 should be changed to this formula—otherwise typesetting reports undefined citation; this formula has 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 checks (borrowing Grammarly's four-part method, weighting according to academic manuscripts)

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

engagement/fancy wording is weakened in academic manuscripts—do not sacrifice precision for variety. Preferred directly runnable (free anonymous): LanguageTool public cloud endpoint POST https://api.languagetool.org/v2/check, parameters language=en-US(or auto）、level=picky(enable strict style rules),motherTongue=zh-CN; anonymous actual test HTTP 200, returns matches[] with message/replacements/offset, check item by item. For privacy/batch scenarios, switch to self-hosting. 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 tested returned 404,/v2/translate tested returned 403 (requires Authorization: DeepL-Auth-Key); therefore DeepL is only used as a "full-sentence rewriting reference when a key is available,"writing_style=academic it tends toward full-sentence restatement and easily alters terminology and authorial voice, so manual review is mandatory (see references.md for endpoint availability). For academic wording, align with Writefull's "expressions customary in published corpora" approach, 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/probed, and strengthen them in advance or add limitations.
  3. polish: revise the language—four language-level checks, processed module by module; the user may specify sections.
  4. audit: final check of consistency/terminology/format/abbreviations/citations (compliance threshold, benchmarked against pre-submission checks).

For each revision, provide:problem → reason → 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 avoid over-rewriting (DeepL-style full-sentence restatement dilutes the voice; use with caution). Rewrite the abstract/introduction/conclusion according to the high-level db02 formula (patterns_library methodology level, domain-neutral); this formula has already stripped away cs.AI/CV cultural endorsement, so when polishing non-CS manuscripts such as statistics/medicine/agriculture, do not copy "beat baseline/SOTA/open-source"-style expressions (see the subject-bias warning in samples_real Table D).

Demonstration: polishing looks like this (every revision 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; 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 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 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 with one meaning; make "various noise" concrete as two specific types of noise; change "good results" to specific metrics. Readability, correctness, and information density improve simultaneously.

Example 3 · Contribution presentation (novelty, consistent in 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 contributions are not measurable and cannot be aligned with the abstract/conclusion; ③ it does not point out the "insight".
  • After revision：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: starts with verbs (identify/propose/raise), contributions are countable and measurable, and it points 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: before m14 review-rebuttal simulates review, read this findings JSON as pre-review input—overclaim/claim_strength maps to major comments on Soundness/Significance,ai_tone/punctuation etc. map to Minor comments on Presentation (field mapping is in the m14 SKILL "Consume m08 polishing findings" section), so the category values and the severity tiers in schema §4 must be stable; if field names are changed, both places must be synchronized.

  • 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), maps each match's offset back to theoriginal text's absolute line/col。Fixed rate-limiting defect: changed toindependent degradation per chunk—if a chunk is non-200, only that chunk falls back to local regex, while LanguageTool results for the other chunks are retained (no longer discarding the whole document when one chunk fails,mode=mixed); sleep between chunks controls rate (~20 req/min), and 429/5xx are retried with exponential backoff._meta.http_codes records the real runtime HTTP code, and never fabricates 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 required): scans ① overclaim blacklist (significant/seminal/novel/outperforms…,statistical-context significant is context-exempt and not falsely reported) ② AI tone/filler words ③ hedge stacking ④ claim_strength: strong claim words (prove/conclusively/unprecedented/always…) get Hedging ladder downgrade suggestions (docking with references/argument_review.md §2, already incorporated into schema §3/§4) ⑤ paragraph passive-voice ratio exceeding threshold ⑥ punctuation hygiene.Fixed engineering defects：--latex first strip_latex to remove \cite/$...$/comments/environment before checking (preserving line numbers, fixing .tex false positives); sentence splitting adds abbreviation protection (et al./e.g./Fig. not falsely split);Chinese manuscript supportChinese exaggeration/AI-tone word list (显著/大幅提升/综上所述…). 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；.tex automatic or explicit --latex。
  • Both scripts run when there is no inputbuilt-in self-check samples, ensuring python <script> can always run through. LanguageTool handles surface grammar, and mechanical_check handles the "academic tone/bare assertions" that LanguageTool misses; the two are complementary.
  • scripts/style_fingerprint.py（No API required): style calibration. Generic polishing easily turns everyone into the same kind of "standard academic tone"; this script does the opposite—first from the user'sRecognized past manuscriptsMeasure an individual style fingerprint (sentence-length rhythm, passive ratio, first person, connector preferences, punctuation habits, high-frequency content words), and when polishing, calibrate to the author's own voice rather than flattening it into a template.--build past*.txt --out style.json Build fingerprint;--compare draft.txt --ref style.json Mark the dimensions in which the draft to be polished deviates most from the author's habits and give adjustment hints. A 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 an introduction passage going through the full four-step pipeline (original paragraph → run script hits → four-column item-by-item revisions → final draft, including fixes for the four hit types overclaim/ai_tone/passive/hedge), see examples/full_pipeline_walkthrough.md. The "Demo: polishing looks like this" above already demonstrates three single-sentence revision approaches for soundness/clarity/novelty; the end-to-end full-paragraph demonstration has been moved to examples for on-demand reference.

Connection

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

Artifact name for saving to disk (CONVENTIONS §6.1): m08 iteratively polishes on the same draft as m07's draft.md , without creating a new artifact name; version iterations are recorded in db09.

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