Skip to main content

paper-refine

Use when a user wants to polish, revise, restructure, or translate existing academic manuscript text into clearer publication-ready English, including abstracts, introductions, results, discussions, methods, conclusions, titles, figure legends, Chinese research drafts, claim calibration, overclaim correction, and tracked before/after explanations; also when they ask for 润色论文, 英文润色, 学术润色, 论文改写, 中文转学术英文, or 过度主张检查. Not for writing a full paper from-scratch, literature search, citation discovery, peer-review reports, reviewer responses, paper-to-PPT, or general non-academic translation.

Source facts

Repository
wp-a/paper-refine
Last source activity
July 16, 2026 at 17:47
Detected SKILL.md language
English
Stars
3
Forks
1

Install options

The review-first prompt is selected by default. You can switch to a direct command or download a local copy.

Review the source files

Read SKILL.md and any companion files shown by SkillsMP before deciding whether to install.

Showing SKILL.md

SKILL.md
Source instructions · Read-only preview
name
paper-refine
description
Use when a user wants to polish, revise, restructure, or translate existing academic manuscript text into clearer publication-ready English, including abstracts, introductions, results, discussions, methods, conclusions, titles, figure legends, Chinese research drafts, claim calibration, overclaim correction, and tracked before/after explanations; also when they ask for 润色论文, 英文润色, 学术润色, 论文改写, 中文转学术英文, or 过度主张检查. Not for writing a full paper from-scratch, literature search, citation discovery, peer-review reports, reviewer responses, paper-to-PPT, or general non-academic translation.
# PaperRefine Revise existing academic text without changing the science behind it. Improve the argument before polishing its surface, and make every substantive change auditable. ## Non-negotiable integrity rules - Preserve the author's findings, direction of comparison, numerical values, uncertainty, scope, terminology, citations, and stated limitations. - Do not fabricate data, references, methods, mechanisms, statistical results, novelty, limitations, or supporting evidence. - Do not add plausible confounders, bias types, study structure, future study designs, or recommendations unless the supplied text states them. A safer claim must be the smallest evidence-matched rewrite, not a new methods lesson. - This evidence boundary applies to all output sections, including revision reasons and `Author checks`. Ask whether supporting evidence already exists; do not prescribe specific new experiments or infer cohort structure. - A source saying `one study` does not imply `one cohort`, one dataset, or one population. Describe missing support as “the supplied text does not provide it”; do not convert absence in the input into a fact about the study. - If the source states only a study design, use only that stated design to calibrate the claim. Do not present hypothetical alternatives or limitations absent from the source as facts, recommendations, or required author actions. - For an unsupported universal claim, prefer “the supplied text does not establish generalization to all populations.” Do not describe the number or composition of studied populations unless the source defines them. - For an unsupported mechanism claim, write “the supplied text does not establish the mechanism.” Do not turn missing passage-level support into the global claim that a mechanism is unknown or remains to be determined. - Never upgrade association to causation, partial evidence to proof, one cohort to universal generalization, or a proposed application to an achieved result. - Do not silently resolve ambiguous scientific meaning. Preserve the wording or mark it for `Author checks`. - Do not promise journal acceptance, “zero error”, human authorship, or a lower AI-detection score. - Prefer a justified unchanged sentence over cosmetic synonym churn. ## Route the request 1. Confirm that the user supplied existing academic text or a file containing it. If the text is missing, ask only for the text or path. 2. Infer the section, source language, desired output language, and format from the request and content. Ask one focused question only when a missing choice would materially change the result. 3. Use **Quick mode** for a sentence through roughly three paragraphs when the requested outcome is clear. 4. Use **Deep mode** for a long passage, a full section, repeated logic problems, cross-paragraph restructuring, or an explicit request for diagnosis and tracked revision. 5. If the request is outside the frontmatter scope, say which specialized workflow is needed and do not attempt the unrelated task here. Do not ask for a target journal by default. Apply a named venue's conventions only when the user supplies that venue or its current instructions. ## Quick mode Run one direct pass without pausing when the text and goal are clear: Run **Risk triage** before broad style editing. Inspect causal, mechanistic, novelty, generalization, and performance claims first, especially in the title, abstract conclusion, and contribution statements. Then address structure and prose in proportion to their effect on meaning. 1. **Protect** facts, numbers, comparisons, qualifiers, technical terms, citation anchors, and format-sensitive tokens. 2. **Diagnose** only the issues that materially affect meaning, logic, clarity, grammar, concision, or flow. 3. **Calibrate** claim strength against the evidence stated in the passage. 4. **Rewrite** for clear academic English while preserving the author's voice and the passage's section function. 5. **Verify** the rewrite against the protected items and output contract. Keep sound text substantially unchanged. Do not make a short request interactive merely to demonstrate a workflow. ## Deep mode For longer or structurally unstable text, use six explicit stages: 1. **Protect**: build a private ledger of facts, numbers, variables, named entities, citations, qualifiers, scope conditions, terminology, and syntax that must survive revision. 2. **Diagnose**: triage high-risk claims and locations first, then identify the section goal, the job of each paragraph, logic breaks, duplicated points, missing bridges, and sentences carrying multiple incompatible jobs. 3. **Calibrate**: map important claims to the evidence visible in the supplied text. Separate observation, association, prediction, causation, mechanism, novelty, and generalization. 4. **Rewrite**: repair argument order and paragraph roles first, then improve sentences. Do not add content merely to make the narrative look complete. 5. **Naturalize**: remove empty meta-discourse, promotional escalation, repetitive connectives, uniform sentence templates, and unnecessary nominalization only where they reduce readability. 6. **Verify**: compare the result with the protected ledger and recheck claims, terminology, numbers, citations, LaTeX, and unresolved author decisions. When the deep pass exposes a scientific choice rather than an editorial one, return the safe revision plus a concise author check instead of guessing. ## Section and language guidance Load only the guidance needed for the current request: - Read [claim and evidence boundaries](references/claim-evidence-boundaries.md) when calibrating causal, mechanistic, novelty, performance, clinical, universal, or generalization claims. - Read [section revision guides](references/section-revision-guides.md) when revising a named section, rebuilding paragraph order, or diagnosing section function. - Read [Chinese-to-English revision](references/chinese-to-english.md) for Chinese or mixed-language academic input. - Read [natural academic prose](references/natural-academic-prose.md) for substantial rewriting, translationese, repetitive style, or requests to make prose sound less templated. Do not use it as an authorship detector. - Read [LaTeX preservation](references/latex-preservation.md) before changing LaTeX or text containing commands, math, citations, labels, or environments. - Read [the change ledger contract](references/change-ledger.md) when the user requests before/after comparison, tracked changes, detailed explanations, or a revision audit. Style is venue- and field-dependent. Do not impose British spelling, passive voice, a universal tense, a fixed sentence length, or a journal-branded tone unless the user's target requires it. ## Output contract Default response order: Use the exact English heading labels below even when the explanations are in Chinese. Do not translate or rename the three labels. The response must start with `### Refined text`; omit mode announcements and editorial preambles. ### Refined text Return clean manuscript prose, not a code block, unless a code block is needed to preserve LaTeX or the user requested one. ### Why it is better Give no more than 3-5 concise bullets. For Chinese-speaking users, explain in Chinese by default. Tie each point to a real change in logic, claim strength, information order, clarity, grammar, concision, or rhythm. Explain only changes that appear in the delivered revision; do not list ideas that were excluded. ### Author checks Include this section only when the author must verify evidence, terminology, citations, priority, scope, or ambiguous scientific meaning. State the exact question; do not hide it in general advice. Ask whether support exists without inventing its form. Do not prescribe new evidence collection, study designs, or validation approaches absent from the source. Do not name examples of evidence forms, analyses, or study designs that the source does not supply. If the user asks for final wording only, return only `Refined text`. If the user asks for detailed comparison, use the change ledger instead of a generic list of edits. ## File handling - For file input, inspect the file and applicable repository instructions before editing. - By default, preserve the source and create a sibling with `_refined` before the extension, or return a patch when that better fits the repository. - Never overwrite a path that already exists. If `name_refined.ext` already exists, choose the next free numbered path such as `name_refined_2.ext`, or return a patch; report the chosen path to the user. - Edit in place only when the user explicitly requests it. - Preserve the source encoding and file format. Do not convert Markdown, LaTeX, or plain text into another format without being asked. - Keep LaTeX commands, math, citation keys, labels, cross-references, comments, and environments intact. Treat a format change as a separate author-visible decision. ## Failure handling - If required source text cannot be read, request the text or a readable path. - If evidence needed to support a claim is absent, narrow the claim or mark an author check; never invent the missing support. - If two interpretations are scientifically plausible, provide the safest minimally changed version and list the ambiguity. - For very long manuscripts, process coherent sections sequentially, maintain a terminology ledger, and verify cross-section claims before declaring the revision complete. - If the user asks for a capability outside this Skill, stop at a concise route to the appropriate workflow rather than returning a partial substitute. ## Final verification Before responding, confirm: - every protected number, comparison, qualifier, citation, and technical term is preserved or explicitly flagged; - no new scientific fact, reference, mechanism, or result was introduced; - claim strength does not exceed the supplied evidence; - section function and paragraph logic improved or remained intact; - revisions are useful rather than merely different; - output headings and author checks follow the requested level of detail.
View on GitHub