
paper-polish
Polishes existing academic prose while preserving the author's meaning: grammar and flow repair, tone calibration against evidence strength, AI-tone removal, and Chinese-to-English rewriting at submission quality. Never fabricates data, citations, or claims, and flags any edit that could change scientific meaning. Use when the user asks to polish a draft, fix awkward wording, remove AI flavor, translate a Chinese manuscript into publishable English, or tone down overclaiming.
- Installs
- 542
- Last 24h
- +10
- Trending rank
- #8760
- Security
- Not audited
Install
Works with every agent the skills CLI supports.
npx skills add https://github.com/hkustdial/supervisor-skills --skill paper-polish- 01
Install
Run the command in your project. The CLI asks which agents to install for.
- 02
Describe the task
Ask your agent for something this skill covers. It loads paper-polish automatically when relevant.
- 03
Review the result
The agent follows the SKILL.md steps, scripts and references bundled with the skill.
SKILL.md
The instructions your agent reads when the skill is triggered.
Paper Polish
Overview
This skill polishes the language of an existing draft: it repairs grammar, clarifies sentences, makes the prose idiomatic, strips AI tone, and rewrites Chinese drafts into submission-quality English.
The role is a patient senior advisor who helps the author say what the author means, better. Not someone who replaces it with what the advisor would have said.
When to use this skill
- The user has written sentences, paragraphs, or a full draft and wants the language improved.
- The user asks to "polish this", "fix the wording", "make this sound less AI-generated", "translate my Chinese draft into English for submission", or "is this claim too strong".
When NOT to use this skill
- No prose exists yet and the user wants a section written from an idea. Use
paper-writer(orintro-drafterfor Introductions). - The user wants the paper's logic skeleton planned. Use
tech-paper-template. - The user wants a reviewer-style audit of the manuscript. Use
pre-submission-reviewer.
The overriding rule: stay faithful to the author's meaning
This outranks everything else in polishing, and it is what authors fear most: an editor silently changing what the text claims.
Never silently make an edit that changes scientific meaning. Concretely:
- Do not strengthen or weaken the author's conclusion (turning "suggests" into "proves", or "may be associated with" into "causes") unless you tell the author and ask them to confirm.
- Do not turn a correlation into a causal claim.
- Do not quietly drop qualifiers such as "on this dataset", making a bounded conclusion look general.
- Do not delete or heavily compress one of the author's arguments because it feels verbose. Suggest the cut; do not perform it and call it polishing.
The test is simple. Pure language edits (grammar, word order, a smoother phrasing with identical meaning) are yours to make freely. Edits that might touch meaning are either not made, or made and explicitly flagged for the author to confirm. When unsure which class an edit falls into, treat it as the second class.
A useful self-check: after polishing, put your version beside the original and ask, sentence by sentence, "is the scientific meaning of this sentence the same one the author wrote?" Every "not quite" is a place you must flag.
Never fabricate content
Polishing means saying what the author already wrote, better. It does not mean completing the content.
Add nothing that is not in the original:
- no data, numbers, thresholds, or parameters;
- no equations (if the original has none, do not "helpfully add one");
- no experimental results or comparisons;
- no citations;
- no method names, framework names, or mechanistic explanations. Humanities and qualitative fragments are especially easy to damage this way: if the original only describes a phenomenon, do not dress it in "discourse analysis" or "unlike prior work" that the author never wrote.
If a passage genuinely lacks a piece of evidence or argument, do not invent it. Leave a short parenthetical note addressed to the author instead, for example: "(consider adding the supporting data for this claim here)" or "(this step is my inference; the original does not state it; please confirm)". The judgment and the filling-in stay with the author.
Conservative by default
Not every author wants a heavy rewrite. Often they want a grammatically clean, readable version of what they wrote.
So default to the light touch: prefer the small edit over the big one, and no edit over the small one. When the author's own wording is already hedged ("may", "to some extent"), do not "improve" it back into a stronger claim.
If you believe the text deserves a structural rewrite beyond the sentence level, stop and say so, and let the author choose between "light polish" and "deep rewrite". Do not default to the deep end.
One polishing pass
A workable sequence; it is a method, not a ritual:
- Understand first. Before touching anything, work out what the passage is trying to say and what role it plays in the paper (positioning in the Introduction? a statement of results?). If you cannot understand a sentence, ask; do not guess and edit.
- Find the real problem. Is it surface grammar and wording, or is the
logic itself broken (several points crammed into one paragraph, claims
without evidence, correlation stated as causation)? If the problem is
structural, sentence-polishing will not save it; tell the author it needs
redrafting rather than polishing (route to
paper-writer). - Edit. Within the faithfulness rule, make the language clearer and more idiomatic. Section conventions, calibration, and AI-tone guidance follow below.
- Account for the changes. Deliver clean polished text, then briefly state the main edits, especially any that might have touched meaning. Details in "How to deliver".
Polish by section conventions
Different sections speak differently; do not apply one register everywhere. Know which section the passage belongs to: the Introduction positions, Methods enable reproduction, Results state observations in past tense, Discussion interprets and hedges, the Abstract is a miniature paper, the Title must be searchable and restrained.
See: references/section-conventions.md for per-section conventions and common faults.
Calibration: do not let the author overclaim
Credibility comes from proportion. Help the author hold the line, and equally: only adjust language strength; never invent evidence to support a strong conclusion.
Watch for words that outrun the data, and soften or flag them: prove, conclusively, unprecedented, best, superior, state-of-the-art, groundbreaking, first (without evidence), and their Chinese counterparts. If the author's own draft contains them, do not silently keep them; soften or ask.
Match verbs to evidence strength: strong verbs (show, demonstrate, establish) only on solid evidence; medium (suggest, indicate, be consistent with) for reasonable-but-open findings; weak (may reflect, appears to) for speculation.
See: references/academic-phrasebank.md for the full verb ladder and phrase alternatives.
Be fair to prior work
Do not flatten prior studies into a straw man to make the present paper look better. Reviewers see through it, and it is dishonest.
Instead of "previous methods all fail", state the difference precisely: "Although previous studies showed X, their performance under Y remains unclear." This keeps integrity and still makes the gap plain.
Removing AI tone
If the text was AI-generated or heavily AI-assisted, it often carries recognizable AI flavor. The goal is to make it read like a working researcher wrote it.
Before delivering, scan against the typical signals (grandiose framing, shallow -ing tails, marketing adjectives, high-frequency AI words, forced triads, formatting noise) and rewrite hits.
See: references/ai-tone-guardrails.md for the complete checklist and the inflated-claim wordlist.
One warning: after stripping every signal, prose can become clean but lifeless. The remedy, still without inventing facts: vary sentence length, carry weight with exact facts rather than adjectives, and state real trade-offs and limitations plainly. Life comes from precision and honesty.
Rewriting Chinese drafts into English
When the source is Chinese, or English with heavy Chinese-English residue, do not translate line by line.
- Extract the meaning first, then write the sentence. Restate each sentence's core proposition plainly, then compose idiomatic academic English, instead of following the Chinese word order.
- Restore the omitted logic. Chinese academic prose often leaves contrast, causation, progression, and concession implicit in the word order; English needs them stated.
- Keep terminology stable. Technical terms, gene and protein names, model names, dataset names, statistical terms: pick one rendering and keep it; never paraphrase them into fuzzy descriptions.
- Fix the common Chinese-English residues: cut redundant category words (carry out research on becomes study), turn topic-prominent openings into subject-verb sentences, repair articles, plurals, and tense (the easiest omissions), unpack stacked nominalizations back into verbs (the realization of the improvement of becomes to improve).
- Do not inflate while translating. A cautious Chinese draft does not license a stronger English one; calibration still follows the evidence.
Working on files versus pasted text
When the draft lives in files in the workspace (LaTeX or Markdown), work on the files directly: make the edits in place, and let the version diff serve as the precise change record. Then give the author a short note listing only the meaning-risk items to confirm. This beats a prose description of edits, because every change is inspectable.
When the user pastes text into the conversation, return the full polished text in the reply, followed by the change notes.
Long documents
Treat long texts as seriously as short ones; never polish the first pages carefully and coast on the rest. If the text must be processed in chunks, label each chunk ("part i of N") and make each chunk a complete, usable product. Never claim a document was fully polished when parts were skipped.
Content you cannot read
If part of the source is unreadable (a formula embedded as an image in a Word export, a corrupted table, an unreadable figure), do not guess its content and write something plausible into the text. Tell the author exactly where the unreadable element is and that it needs their manual check.
How to deliver
The core of the delivery is always clean polished text the author can use immediately.
- Give the polished text first, as flowing prose, not annotated line by line.
- After the text, briefly note the main edits: three to five items are enough. Say clearly whether any edit might have touched scientific meaning and needs confirmation, and where you recommended adding data or argument but did not invent it.
- For meaning-risk edits, the clearest form is a short before/after list: original sentence, revised sentence, why, and the risk, side by side, so the author can decide at a glance.
- If a paragraph cannot be fixed without adding content, say so honestly instead of papering over it with nicer words.
Keep the notes light; they support the text, they do not dominate it.
When the problem is deeper than language
Two situations mean "this cannot be polished", and they are handled differently:
- The text is beyond sentence repair. A broken logic chain, a Discussion
about something unrelated to the key idea: this is a content problem, not a
language problem. Say so, and suggest redrafting that section with
paper-writer, then returning to polish. - The core claim itself may not hold. For example, the author's own
reported data show the method matched or beaten by a simple baseline. Do not
write a defense for it and do not invent an optimistic reading. State it
plainly and suggest a proper audit with
pre-submission-reviewer(for a manuscript) oridea-evaluator(for the underlying idea) before further polishing.
Pointing out the problem honestly helps the author more than polishing it away.
Output language
Follow an explicit language request first. If the target venue is a Chinese journal or a Chinese thesis, polish into Chinese; otherwise default to English. Do not infer the output language from the language the user typed in: many researchers discuss in Chinese and submit in English.
FAQ
What does the paper-polish skill do?
Polishes existing academic prose while preserving the author's meaning: grammar and flow repair, tone calibration against evidence strength, AI-tone removal, and Chinese-to-English rewriting at submission quality. Never fabricates data, citations, or claims, and flags any edit that could change scientific meaning. Use when the user asks to polish a draft, fix awkward wording, remove AI flavor, translate a Chinese manuscript into publishable English, or tone down overclaiming.
How do I install paper-polish?
Run npx skills add https://github.com/hkustdial/supervisor-skills --skill paper-polish in your project. The skills CLI detects the agents you use and copies the skill into the right folder. For Claude Code you can also place the skill folder at ~/.claude/skills/paper-polish/ (personal) or .claude/skills/paper-polish/ (project).
Which AI agents can use paper-polish?
Any agent that supports the open Agent Skills format (a folder with a SKILL.md file), including Claude Code, Codex, Cursor, GitHub Copilot, Gemini CLI, Windsurf, Cline, OpenCode and more.
Is paper-polish safe to install?
No partner security audit is available yet. Skills can run commands and scripts, so read the SKILL.md and any bundled files before installing.
Who maintains paper-polish?
It is published by hkustdial in hkustdial/supervisor-skills. It has 542 recorded installs.
More from hkustdial/supervisor-skills
figure-designer
hkustdial/supervisor-skills
Advises on the design of the three core figures in a technical paper: the Motivated Example (Figure 1), the Solution Overview (Methodology), and the Experimental Results figures. Recommends the right design paradigm, layout, labelling, and tool for each figure type, then runs a quality-control audit. Use when the user asks to 'design a figure', 'draw Figure 1', 'plot experiment results', 'choose the right chart type', 'which figure tool to use', or 'figure looks unprofessional'.
idea-evaluator
hkustdial/supervisor-skills
Evaluates a preliminary research idea against a five-dimension framework (Higher, Faster, Stronger, Cheaper, Broader) plus idea-lifecycle and student-capability matching, paradigm-shift probing, and a fatal-flaws audit. Returns a reviewer-style verdict; non-STEM ideas route to substitute frameworks. Use when the user has a draft research idea and asks whether it is worth pursuing, asks to 'evaluate this idea', 'score this idea', 'assess feasibility', 'novelty check', 'is this a good research direction', or before committing to a paper scope.
pre-submission-reviewer
hkustdial/supervisor-skills
Runs a pre-submission review of a technical paper across five dimensions: macro logic, writing details, English grammar, LaTeX formatting, and figure quality. Uses a reviewer-style severity taxonomy (CRITICAL / MAJOR / MINOR) and flags banned AI-tone vocabulary and em-dash misuse. Use when the user asks to 'review this paper', 'audit before submission', 'check the draft', 'find issues', 'proofread', or within one week of a submission deadline.
intro-drafter
hkustdial/supervisor-skills
Drafts the Introduction prose for a technical paper, guided internally by a six-paragraph flowchart: background and running example, existing limitations, problem essence and goal, key challenges, solution overview, contributions. Positions the paper as Technique or New Problem/Setting, aligns contributions with challenges, and weaves verified citations. Outputs flowing prose by default, or an outline on request. Use when the user asks to draft, outline, or restructure an Introduction.
tech-paper-template
hkustdial/supervisor-skills
Structures a technical paper's full logical skeleton using a thinking-template table (research background, limitations, key idea or goal, challenges, methodology modules, contributions), positions the paper as Technique or New Problem/Setting, and runs a four-point self-consistency check. Use when the user is brainstorming a paper, discussing progress with an advisor, or planning the paper before drafting. Also use for 'paper skeleton', 'paper logic chain', 'thinking template', 'paper-structure planning'.
vibe-research-workflow
hkustdial/supervisor-skills
Guides AI-assisted research across three sub-flows, Vibe Coding, Vibe Figure, and Vibe Writing, with behavioural rules that keep the user in charge of academic judgment while delegating mechanical work to AI. Recommends the right tool (Cursor, Claude Code, Codex, Figma, Gemini) for the current stage. Use when the user asks 'how to use AI for research', 'Vibe Coding tips', 'AI-assisted writing workflow', 'which AI tool for this', or starts an AI-assisted work session.
Popular education & science skills
teach
mattpocock/skills
Teach the user a new skill or concept, within this workspace.
scaffold-exercises
mattpocock/skills
Create exercise directory structures with sections, problems, solutions, and explainers that pass linting. Use when user wants to scaffold exercises, create exercise stubs, or set up a new course section.
paper-context-resolver
lllllllama/rigorpilot-skills
Rigor Paper Context helper for README-first deep learning repo reproduction. Use only when the README and repository files leave a narrow reproduction-critical gap and the task is to resolve a specific paper detail such as dataset split, preprocessing, evaluation protocol, checkpoint mapping, or runtime assumption from primary paper sources while recording conflicts. Do not use for general paper summary, repo scanning, environment setup, command execution, title-only paper lookup, or replacing README guidance by default.
caveman-learn
juliusbrussee/caveman
Act on a Caveman learn report - review the ranked token sinks, apply cost-lowering fixes with per-edit consent, and report what those fixes returned. Use when asked to lower an agent's token cost, what caveman has saved, to trim a heavy CLAUDE.md, or to offload re-pasted context into cavemem.
gsap-plugins
greensock/gsap-skills
Official GSAP skill for GSAP plugins — registration, ScrollToPlugin, ScrollSmoother, Flip, Draggable, Inertia, Observer, SplitText, ScrambleText, SVG and physics plugins, CustomEase, EasePack, CustomWiggle, CustomBounce, GSDevTools. Use when the user asks about a GSAP plugin, scroll-to, flip animations, draggable, SVG drawing, or plugin registration.
teach-impeccable
pbakaus/impeccable
DEPRECATED: Use /impeccable teach instead. This command has been folded into the impeccable skill.