paper-refinement-skills

name	paper-refinement-skills
description	Use when refining research-paper prose or section logic, including abstracts, introductions, related work, methods, captions, conclusions, and rebuttals. Improves clarity, concision, transitions, terminology, notation, and venue-appropriate style without inventing evidence.
license	MIT

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

1. Read the target sentence, paragraph, and immediate surrounding context before editing.
2. Identify whether the problem is structural or local: argument flow, scope, redundancy, terminology drift, or sentence quality.
3. Identify the paper story before polishing: dataset/benchmark, method, analysis, or system. Experiments should support that story, not read like a run log.
4. Freeze the claim hierarchy: one central paper claim first, with ablations, reliability studies, and diagnostics presented only as supporting evidence.
5. Revise conservatively: preserve verified claims, datasets, equations, and citations unless the user explicitly asks to change them.
6. When a passage is repeatedly misunderstood, fix the ambiguity at its source instead of only softening nearby claims.
7. 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.
8. Check the revised passage against the rest of the paper for claim consistency, notation, references, figure/table links, and rendering risks.
9. 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.
10. 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 manuscript content as the paper's author for reviewers. Insert only submission-ready prose, captions, equations, and table text. Keep advice to the user outside the manuscript; never insert author-facing instructions, editorial commentary, or internal status labels such as TODO, TBD, or pending into paper-facing text.
• 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.
• Treat repeated transitions, generic intensifiers, and abstract buzzwords as audit signals, not banned tokens. Remove or replace them only when they add no information; retain precise domain terms when the sentence genuinely needs them.
• Untangle overloaded sentences by making the main subject and action explicit, then splitting or reordering clauses when that improves comprehension. Use sentence length as a diagnostic rather than a universal word-count limit, and preserve the original logical relations.

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.

References

• Read references/refinement-guidelines.md before substantial revisions.
• Keep SKILL.md brief; put only reusable, cross-paper heuristics into the reference file.