Refine research papers for clearer logic, tighter prose, stronger section structure, and venue-appropriate style. Use when editing abstracts, introductions, related work, methods, captions, conclusions, rebuttal text, or other academic writing, especially when a paper needs more concise claims, better transitions, or more consistent terminology and notation.
Refine research papers for clearer logic, tighter prose, stronger section structure, and venue-appropriate style. Use when editing abstracts, introductions, related work, methods, captions, conclusions, rebuttal text, or other academic writing, especially when a paper needs more concise claims, better transitions, or more consistent terminology and notation.
Paper Refinement Skills
Overview
Use this skill when revising academic papers section by section. Preserve verified technical claims, keep terminology consistent, and adapt tone and density to the target venue.
Workflow
Read the target sentence, paragraph, and immediate surrounding context before editing.
Identify whether the problem is structural or local: argument flow, scope, redundancy, terminology drift, or sentence quality.
Identify the paper story before polishing: dataset/benchmark, method, analysis, or system. Experiments should support that story, not read like a run log.
Revise conservatively: preserve verified claims, datasets, equations, and citations unless the user explicitly asks to change them.
When a passage is repeatedly misunderstood, fix the ambiguity at its source instead of only softening nearby claims.
When confusion comes from a category error, fix the category boundary before polishing the sentence. Separate dataset/protocol contents from diagnostic experiments, model design from evaluation controls, and baseline-conversion fairness from the paper's main contribution.
Check the revised passage against the rest of the paper for claim consistency, notation, references, figure/table links, and rendering risks.
After a figure or table changes, search nearby and later prose for stale
terminology, old row names, obsolete panel structure, and implementation
leakage. A consistent table has a matching body, caption, and local
explanatory paragraph. If a new row is added to a delta-coded or
reference-coded table, the prose must name the comparison reference and
report movement in the same direction as the table cells.
Promote only reusable cross-paper heuristics into this skill. Keep paper-specific conventions outside the skill unless the user explicitly asks for a project-local note.
Core Rules
Prefer direct, claim-driven prose over long setup or component lists.
Write for the paper reader, not for the experiment operator. Convert implementation steps, run bookkeeping, and parser mechanics into the smallest protocol statement needed for the claim, then move reproducibility details to appendix notes.
Use section-aware disclosure. Main text should include only details that affect the scientific conclusion, fairness, validity, or reader interpretation. Checkpoints, runner names, guard logic, adapters, local paths, download failures, failed attempts, and engineering patches belong in Appendix or internal records by default.
Do not sound anxious. Avoid stacking caveats in captions or result prose just because a reviewer might ask. If a detail does not change how the reader should interpret a result, move it out of the main narrative.
Keep technical terms precise and consistent.
Match the language to the section's altitude. Abstract, early Introduction, and Conclusion should use reader-facing claims and ordinary phrasing; reserve operator-facing protocol terms, conversion details, parser mechanics, and run-level bookkeeping for Experiments or Appendix.
A coined or technical term carries a burden of proof. If an ordinary phrase says the same thing without losing precision, use the ordinary phrase, especially in the abstract and first-page motivation.
Do not present ablations, controls, dry runs, parser diagnostics, conversion protocols, or resource gates as if they were core dataset or method components. State them as evaluation diagnostics, reproducibility details, or setup choices in the section where that role is clear.
Do not leave internal implementation terms such as runner names, alias labels,
old condition names, parser shorthand, or obsolete table logic in reader-facing
prose unless they are necessary for reproducibility and placed in the right
section.
Use idiomatic, natural academic English: clear, human-sounding sentences; no awkward AI-like filler, inflated phrasing, rare words, or needless synonym swapping.
Make prose clean and economical while preserving enough context for a reader to follow the logic.
Do not use em dashes in paper prose; prefer full sentences, commas, semicolons, parentheses, or sentence splits.
Use colons sparingly; avoid loose claim: explanation constructions when a cleaner full sentence is available.
Match every claim to the paper's actual evidence. If a claim cannot be supported by the current experiments, citations, equations, or figures, weaken it, qualify it, or ask the user rather than inventing support.
Avoid overclaiming, hidden guarantees, and wording that creates easy attack points. Prefer defensible formulations that state what the paper shows, under what setup, and with what scope.
Do not fabricate references; if one is missing, use a visible placeholder instead of guessing.
Section Heuristics
Abstract: compress to a problem-gap-method-result arc and avoid inventory-style method descriptions.
Introduction: make the motivation concrete, isolate the gap early, and connect each paragraph to the paper's central bottleneck.
Related Work: compare methods by limitation and relevance, not by laundry-list chronology.
Method: define the setting first, then modules, then why each module is needed. Keep the task definition method-agnostic unless the subsection explicitly introduces the paper's instantiation.
Experiments: distinguish setup, main results, ablations, and supplementary analysis. Keep fairness caveats factual and align every paragraph with its current table or figure.
Dataset/benchmark papers: foreground why the dataset is needed, what annotation/evidence signal was difficult to obtain, and how experiments demonstrate the benchmark's value. Avoid letting baseline implementation details become the main story.
Appendix: make supplementary sections reproducibility-oriented and calm; avoid turning them into hidden rebuttals.
Captions and conclusion: prefer one clear takeaway per paragraph. Conclusions should usually close on the paper's broader claim, not on module inventory.
Keep SKILL.md brief; put only reusable, cross-paper heuristics into the reference file.
When a citation, related-work claim, reviewer-facing claim, or factual support is uncertain, use $research-evidence for a non-writing evidence check before strengthening or preserving the claim.
Outside experimental sections, avoid adding concrete numbers unless they are already verified or required for correctness.
Maintain symbol consistency and define symbols on first use.
De-emphasize repeated secondary claims; keep them where they are needed for setup or reproducibility, not as a paper-wide slogan.
Do not treat adding numbers to a table as complete writing. First check the
table contract: whether cells require deltas, reference labels, color
semantics, confidence intervals, sample counts, or row-group notes. Then make
the caption and result paragraph explain the same comparison.
Treat baseline rows as normal method comparisons unless the qualification changes fairness, validity, or reproducibility. Disclose reproduction, conversion, checkpoint, or guard details in setup, captions, footnotes, or Appendix when they matter; do not make main-result prose sound like an incident report.
Respect venue- or project-specific punctuation, notation, and equation conventions when they are supplied.
