Skill: zihan-zhu/academic-writing-refiner (version 1.0.0)

--- name: academic-writing-refiner description: Refine academic writing for computer science research papers targeting top-tier venues (NeurIPS, ICLR, ICML, AAAI, IJCAI, ACL, EMNLP, NAACL, CVPR, WWW, KDD, SIGIR, CIKM, and similar). Use this skill whenever a user asks to improve, polish, refine, edit, or proofread academic or research writing — including paper drafts, abstracts, introductions, related work sections, methodology descriptions, experiment write-ups, or conclusion sections. Also trigger when users paste LaTeX content and ask for writing help, mention "camera-ready", "rebuttal", "paper revision", or reference any academic venue or conference. This skill handles both full paper refinement and section-by-section editing. --- # Academic Writing Refiner This skill transforms rough or intermediate academic drafts into polished, publication-ready prose for top-tier CS conferences. The goal is writing that is clear, precise, and accessible to a broad technical audience — the kind of writing that reviewers at venues like NeurIPS, ICML, or ACL appreciate because it respects their time and communicates ideas efficiently. ## Core Philosophy Top CS conferences share a common expectation: writing should be a transparent window into the ideas, not a display of vocabulary. The best papers at NeurIPS, ACL, or KDD succeed not because they use impressive words, but because every sentence earns its place and every paragraph advances the reader's understanding. This means: - **Clarity over cleverness**: Use the simplest word that precisely conveys the meaning. "Use" instead of "utilize", "show" instead of "demonstrate" (unless you mean a formal proof/demonstration), "many" instead of "a plethora of". - **Precision over vagueness**: Replace hedging language with specific claims. Instead of "our method performs quite well", say "our method achieves 94.3% accuracy, outperforming the strongest baseline by 2.1 points". - **Economy over verbosity**: Every sentence should do work. If removing a sentence doesn't lose information, remove it. - **Flow over fragmentation**: Guide the reader from one idea to the next with logical connectives, not abrupt jumps. ## How to Refine When a user provides text to refine, follow this process: ### 1. Understand the Context Before editing, figure out: - **What section is this?** (abstract, introduction, related work, methodology, experiments, conclusion) — each has different conventions. - **What venue?** If stated, tailor to that venue's style norms. ML venues (NeurIPS, ICML, ICLR) tend toward concise, equation-heavy writing. NLP venues (ACL, EMNLP, NAACL) often expect more linguistic precision and thorough related work. IR/Web venues (SIGIR, WWW, KDD, CIKM) often need clear problem motivation tied to practical impact. - **What stage?** A first draft needs structural help; a camera-ready needs polish. If the user doesn't specify, infer from content and ask only if genuinely ambiguous. ### 2. Apply Section-Specific Conventions Read `references/section-guide.md` for detailed conventions per section type. The key principles: **Abstract**: Should be self-contained, state the problem, approach, key result (with numbers), and significance — all in ~150–250 words. No citations, no undefined acronyms. **Introduction**: Problem → gap → contribution → brief results → paper outline. The reader should understand what you did and why it matters within the first page. **Related Work**: Group by theme, not by paper. Each paragraph should end by distinguishing the current work from what was just discussed. Avoid "laundry list" style (X did A. Y did B. Z did C.). **Methodology**: Present the approach in logical order. Define notation before using it. Use equations for precision but always provide intuition in words alongside them. **Experiments**: Lead with research questions or hypotheses, then describe setup, then results. Tables and figures should be self-contained with descriptive captions. **Conclusion**: Summarize contributions (not the whole paper), acknowledge limitations honestly, suggest concrete future directions. ### 3. Sentence-Level Refinement Consult `references/word-choice.md` for a quick-reference table of common substitutions (fancy → simple, filler → delete, hedging calibration, and transition connectives). Apply these transformations systematically: **Tighten prose**: - Remove filler phrases: "it is worth noting that", "it should be mentioned that", "in order to" → "to" - Eliminate redundancy: "completely eliminate" → "eliminate", "future plans" → "plans" - Convert passive to active where it improves clarity: "the model was trained by us" → "we trained the model" - But keep passive voice when the agent is unimportant: "the dataset was collected from public sources" is fine **Fix common academic writing issues**: - Dangling modifiers: "Using gradient descent, the loss decreases" → "Using gradient descent, we minimize the loss" - Noun pile-ups: "multi-task learning based pre-trained language model fine-tuning approach" → break it up with prepositions - Vague referents: "This shows that..." — what does "this" refer to? Make it explicit - Orphan claims: every claim about performance needs a citation or experimental reference **Strengthen transitions**: - Between sentences: use logical connectives that signal the relationship (however, therefore, specifically, in contrast, building on this) - Between paragraphs: the first sentence of each paragraph should connect to the previous paragraph's conclusion - Between sections: the last paragraph of a section should preview what comes next ### 4. LaTeX-Specific Handling When the input contains LaTeX: - Preserve all `\cite{}`, `\ref{}`, `\label{}`, equation environments, and custom macros exactly as written - Fix only the prose — do not modify mathematical content unless there is a clear notational inconsistency - Maintain `\textbf{}`, `\textit{}`, `\emph{}` formatting choices - Ensure consistent notation: if the user writes $\mathbf{x}$ in one place and $\boldsymbol{x}$ in another for the same quantity, flag it - Keep `~` (non-breaking spaces) before `\cite` and `\ref` - Preserve `%` comments - Do not add or remove `\paragraph{}`, `\subsubsection{}` etc. unless the user asks for structural changes ### 5. What NOT to Do These are equally important as what to do: - **Do not insert fancy vocabulary**. "Leverage" is almost never better than "use". "Elucidate" is almost never better than "explain". If the original uses a simple word correctly, keep it. - **Do not over-hedge**. Academic writing needs appropriate qualification ("may", "suggests"), but excessive hedging ("it could potentially be argued that this might possibly indicate") undermines confidence in the work. - **Do not add content**. Refine what is there. If something is missing (e.g., no related work comparison, no baseline), flag it as a suggestion but do not invent claims or results. - **Do not homogenize voice**. If the author has a distinct (but correct) style, preserve it. The goal is to polish, not to flatten. - **Do not use em-dashes excessively**. Parentheses or restructured sentences are usually cleaner in academic writing. One em-dash pair per paragraph at most. - **Do not introduce semicolons liberally**. Prefer shorter sentences joined by appropriate connectives over long semicolon-connected chains. ## Output Format When presenting refined text: 1. **Provide the refined version** as the primary output, clearly separated from commentary 2. **Add brief marginal notes** for substantive changes — explain why you changed something when the reason isn't obvious (e.g., "Restructured to lead with the contribution rather than the gap" or "Made the comparison to X explicit") 3. **Flag issues you cannot fix** — missing citations, unclear experimental details, potential factual concerns — as a separate list at the end 4. If the input is LaTeX, output LaTeX. If the input is plain text, output plain text. Match the format. ## Interaction Patterns **Full paper refinement**: If the user provides an entire paper (or most of one), work section by section. Start with whichever section the user indicates, or begin with the abstract and introduction since those set the tone. **Single section**: Apply the full refinement process to that section. **Quick polish**: If the user says "just fix the grammar" or "light edit only", respect that — fix spelling, grammar, and punctuation without restructuring or rewriting. **Iterative refinement**: After providing a refined version, be ready for feedback like "too formal", "I want to keep the original structure of paragraph 2", or "make the motivation stronger". Apply changes surgically without re-editing the rest. **Rebuttal writing**: When the user mentions a rebuttal or reviewer response, read `references/rebuttal-guide.md` for specific advice on crafting effective rebuttals. ## Common Venue-Specific Notes | Venue Group | Style Tendencies | |---|---| | NeurIPS, ICML, ICLR | Concise, equation-centric. Theoretical rigor valued. Anonymous review — remove self-identifying references. | | AAAI, IJCAI | Broader AI scope. Motivation and real-world relevance important. Slightly more expository than ML-focused venues. | | ACL, EMNLP, NAACL | Thorough related work expected. Linguistic precision in terminology. Error analysis and ablation studies valued. | | CVPR | Visual results critical. Qualitative examples alongside quantitative. Clear figure descriptions. | | WWW, KDD, SIGIR, CIKM | Problem-driven motivation. Scalability and practical impact often expected. Dataset descriptions need care. | These are tendencies, not rigid rules — good writing is good writing regardless of venue.

path: references/rebuttal-guide.md
content: # Rebuttal and Author Response Guide

This reference covers writing effective rebuttals and author responses for top CS conference peer review. Use when a user is responding to reviewer comments.

## Principles

A rebuttal is a professional conversation, not a defense. The goal is to address concerns clearly, provide missing information, and demonstrate that the paper's contributions are sound. Reviewers are volunteers who gave time to read your work — treat their feedback with respect, even when you disagree.

## Structure

### Opening

Start with a brief thank-you (one sentence) and a summary of changes or clarifications you will provide. Do not be obsequious.

Example: "We thank the reviewers for their thoughtful feedback. Below we address each concern."

### Per-Reviewer Responses

Address each reviewer separately, quoting their concern and responding directly.

**Format**:
```
**Reviewer [X], Comment [N]**: [Brief quote or paraphrase of concern]

**Response**: [Your response]
```

### Response Types

**For factual corrections** (reviewer misunderstood something):
- Point to the specific location in the paper
- Quote the relevant text
- Explain what it means
- Offer to clarify the wording: "We will revise Section X to make this clearer"

**For missing experiments/analysis**:
- If you can run the experiment: provide the results directly in the rebuttal
- If you cannot: explain why (time/resource constraints) and commit to adding it in the revision
- Never promise what you cannot deliver

**For conceptual disagreements**:
- Acknowledge the reviewer's perspective
- Present your reasoning clearly with evidence
- Cite relevant literature if helpful
- Be respectful — "We appreciate this perspective and would like to offer an alternative view" not "The reviewer is incorrect"

**For limitations/weaknesses acknowledged**:
- Agree when the reviewer is right
- Explain what you plan to do about it
- If it is out of scope, explain why while acknowledging the point

## Tone Guide

**Do**:
- Be direct and specific
- Provide evidence (numbers, citations, quotes from the paper)
- Acknowledge valid points
- Commit to concrete revisions
- Keep responses concise — word limits are tight

**Do not**:
- Be defensive or dismissive
- Say "the reviewer misunderstood" — instead, say "we will clarify"
- Make vague promises: "we will improve the paper"
- Ignore difficult questions — address everything
- Repeat large blocks of the paper — summarize and reference

## Word Count Management

Most venues have strict word or page limits for rebuttals. Prioritize:
1. Major concerns that could affect the accept/reject decision
2. Factual misunderstandings that change the assessment
3. Requests for additional experiments you can address
4. Minor points (address briefly or batch together)

## Common Reviewer Concerns and Response Patterns

**"The contribution is incremental"**:
Highlight what is novel. Provide quantitative evidence of improvement. Explain the practical or theoretical significance. Do not just restate the contributions — add context the reviewer may have missed.

**"Missing comparison to [method X]"**:
If you can add it: "We ran this comparison. [Method X] achieves [score] on [dataset], while ours achieves [score]."
If you cannot: Explain why the comparison is not straightforward (different setting, code unavailable, etc.) and cite any available related results.

**"The writing needs improvement"**:
Acknowledge and commit: "We will carefully revise the paper for clarity. Specifically, we will [concrete changes]."

**"Limited evaluation"**:
Add new results if possible. If not, explain the rationale for your current evaluation choices and commit to expanding in the revision.

**"The assumptions are too strong"**:
Discuss when the assumptions hold in practice. If possible, show empirical evidence that the method works even when assumptions are partially violated. Acknowledge the limitation and discuss relaxation as future work.


path: references/section-guide.md
content: # Section-by-Section Writing Guide for CS Research Papers

This reference provides detailed conventions for each major section of a computer science research paper. Use it when refining a specific section to ensure the output matches what reviewers at top venues expect.

## Table of Contents
1. [Title](#title)
2. [Abstract](#abstract)
3. [Introduction](#introduction)
4. [Related Work](#related-work)
5. [Methodology / Approach](#methodology)
6. [Experiments](#experiments)
7. [Results and Analysis](#results-and-analysis)
8. [Discussion](#discussion)
9. [Conclusion](#conclusion)
10. [Common Cross-Section Issues](#common-cross-section-issues)

---

## Title

A good title is specific, informative, and concise (typically 8–15 words).

**Patterns that work**:
- "[Method Name]: [What It Does] for [Problem Domain]"
- "[Verb]-ing [Problem] via [Approach]"
- "[Descriptive Phrase] for [Task]"

**Avoid**:
- Titles that are just a method name with no indication of what it does
- Questions as titles (unless the paper genuinely investigates a question and the venue accepts this style)
- Excessive punctuation, colons, or nested subtitles
- Clickbait or hype: "Revolutionary", "Game-Changing", "Towards Ultimate"

**Check**: Can a researcher scanning a proceedings page understand what this paper is about from the title alone?

---

## Abstract

Target: 150–250 words (check venue limits). Must be entirely self-contained.

**Structure** (roughly one sentence each, expand as needed):
1. **Context/Problem**: What problem exists and why it matters
2. **Gap**: What current approaches fail to address
3. **Approach**: What this paper proposes (name the method)
4. **Key insight**: What makes the approach work (the "why")
5. **Results**: Concrete numbers on primary benchmarks
6. **Significance**: Why these results matter

**Rules**:
- No citations (the abstract should stand alone)
- No undefined acronyms — spell out on first use or avoid
- Include at least one concrete quantitative result
- Do not start with "In this paper, we..." — start with the problem or context
- Avoid: "In recent years", "With the rapid development of", "has attracted growing attention"

**Quality test**: If a reader reads only the abstract, do they know (1) the problem, (2) the approach, (3) the main result?

---

## Introduction

Typically 1–1.5 pages. The most read section after the abstract.

**Structure**:
1. **Opening paragraph**: Establish the problem domain and its importance. Ground it in something concrete — a real-world need, a fundamental limitation, a compelling example. Avoid starting with truisms ("Deep learning has achieved remarkable success...").
2. **Problem specifics**: Narrow from the broad domain to the specific problem this paper addresses. What makes it challenging?
3. **Limitations of existing work**: What have others tried and where do they fall short? This should motivate your approach without being a full related work section. Be fair — characterize prior work accurately.
4. **Your approach**: Introduce your method at a high level. What is the key idea? Why should it work where others failed?
5. **Contributions**: Explicitly list 2–4 contributions using either a bulleted list or inline enumeration. Contributions should be specific and verifiable ("We propose X that achieves Y" not "We study the problem of Z").
6. **Results preview** (optional): Brief mention of headline results to build confidence.
7. **Paper outline** (optional, venue-dependent): "The remainder of this paper is organized as follows..." — some venues expect this, others find it wasteful. Include if the paper structure is non-standard.

**Common pitfalls**:
- Overclaiming: "We are the first to..." — be careful. "To the best of our knowledge" helps, but verify.
- Underclaiming: Burying the contribution in vague language. Be direct about what you did.
- Motivating a solution instead of a problem: Don't start by saying "We propose X". Start by saying why X is needed.

---

## Related Work

Typically 0.75–1.5 pages. Position your work within the landscape.

**Organize by theme, not by paper**. Group related papers under subheadings:
- "Graph Neural Networks for Molecular Property Prediction"
- "Uncertainty Quantification in Language Models"
- "Active Learning for Structured Prediction"

**Each paragraph should**:
1. Describe what this line of work does (collectively, not paper by paper)
2. Highlight key approaches and findings
3. Contrast with the current paper — what gap remains?

**Avoid "laundry list" style**:
- Bad: "Smith et al. (2020) proposed X. Jones et al. (2021) extended this to Y. Lee et al. (2022) further improved upon Y by using Z."
- Better: "Several approaches have addressed X by building on the framework of Smith et al. (2020). Jones et al. (2021) extended this to handle Y, while Lee et al. (2022) improved scalability through Z. However, these methods share a common limitation: they assume..."

**End each thematic group** by distinguishing your work: "In contrast to these approaches, our method..."

**Be generous and fair**: Cite relevant work thoroughly. Reviewers are often authors of papers you should be citing.

---

## Methodology

The core technical section. Length varies (2–4 pages typical).

**Structure recommendations**:
1. **Overview**: A high-level description (1 paragraph) and optionally a figure showing the architecture or pipeline
2. **Preliminaries/Problem Formulation**: Define the problem formally. Introduce notation. State assumptions.
3. **Method details**: Present in logical order — each component should build on what came before
4. **Key design choices**: Explain why you made the choices you did, not just what they are

**Writing principles**:
- **Define before use**: Every symbol, every term, every abbreviation — define it before or at first use
- **Equations need prose**: Every equation should be preceded by motivation ("To capture the interaction between X and Y, we define:") and followed by interpretation ("Intuitively, this measures...")
- **Number your equations** if you refer to them later. Do not number equations you never reference.
- **Consistent notation**: Pick a convention and stick with it. Lowercase bold for vectors ($\mathbf{x}$), uppercase bold for matrices ($\mathbf{W}$), calligraphic for sets ($\mathcal{D}$), etc.
- **Avoid notation overload**: If you have more than 15–20 symbols, consider a notation table

**Common issues**:
- Jumping into equations without motivation
- Defining notation in an equation environment (put variable definitions in text)
- Inconsistent subscript/superscript conventions
- Missing dimensionality information (what size is $\mathbf{W}$?)

---

## Experiments

Typically 2–3 pages. This is where you prove your claims.

**Structure**:
1. **Research questions or hypotheses** (optional but strong): "We design experiments to answer: (RQ1) Does X improve over Y? (RQ2) How does Z affect performance?"
2. **Datasets**: Name, size, domain, train/dev/test splits, preprocessing, why these datasets
3. **Baselines**: What you compare against, why these baselines, ensure they are fair comparisons
4. **Implementation details**: Hyperparameters, training procedure, hardware, runtime. Enough for reproducibility.
5. **Evaluation metrics**: What you measure and why

**Writing tips**:
- **Baselines should be strong and recent**. Reviewers will notice if you only compare against outdated methods.
- **Be explicit about what is fair**: Same data splits? Same pretraining? Same compute budget?
- **Hyperparameter reporting**: State how hyperparameters were selected (grid search, validation set, etc.)
- **Reproducibility**: Include random seeds, number of runs, variance/standard deviation where applicable

---

## Results and Analysis

Can be combined with Experiments or separate. This is where numbers meet narrative.

**Presenting results**:
- Lead with the main result table/figure, then walk the reader through it
- Highlight the most important comparisons — do not just list all numbers
- Report statistical significance or confidence intervals when possible
- Bold the best result in tables. Use underline or second-best marking if venue convention supports it.

**Analysis should**:
- **Explain why**, not just what: "Our method outperforms X by 3.2 points, which we attribute to the ability of component Y to capture long-range dependencies"
- **Include ablation studies**: What happens when you remove each component?
- **Show failure cases**: Where does your method struggle? This builds credibility.
- **Error analysis**: Especially valued at NLP venues (ACL, EMNLP). Categorize errors and explain patterns.

**Avoid**:
- Cherry-picking results — report performance on all standard metrics, even where you are not best
- Overclaiming marginal improvements — if the difference is within noise, say so
- Tables without discussion — never present a table and move on

---

## Discussion

Optional section (some papers fold this into Results or Conclusion).

**Include when**:
- The results raise interesting questions that deserve exploration
- There are limitations that need honest acknowledgment
- The work has broader implications worth discussing

**Limitations subsection**: Increasingly expected (NeurIPS requires it). Be specific and honest. "Our method assumes X, which may not hold when Y." This is a strength, not a weakness — it shows intellectual honesty and helps future researchers.

---

## Conclusion

Typically 0.5–0.75 pages. Do not repeat the abstract.

**Structure**:
1. One-sentence restatement of what you did and why
2. Key contributions (brief — the reader has seen the details)
3. Main takeaway or insight
4. Limitations (if no separate discussion section)
5. Future work — be specific. "Extending to other domains" is vague. "Applying our calibration method to multi-turn dialogue systems where confidence estimates are particularly critical" is concrete.

**Avoid**:
- Restating the full methodology
- Introducing new information
- Excessive hedging or false modesty
- Grandiose claims about impact

---

## Common Cross-Section Issues

**Tense consistency**:
- Use present tense for general truths and descriptions of your method: "Our model uses attention..."
- Use past tense for experimental actions: "We trained the model for 50 epochs"
- Use present tense for results in tables: "Table 2 shows that..."

**Citation style**:
- "Smith et al. (2023) showed..." (narrative citation — the authors are the subject)
- "This has been shown previously (Smith et al., 2023)" (parenthetical citation — the work supports a claim)
- Do not use "In [23]" — use author names for readability

**Figures and tables**:
- Every figure and table must be referenced in the text
- Captions should be self-contained — a reader should understand the figure without reading the main text
- Place figures/tables near their first reference
- Use consistent formatting across all tables

**Numbers and units**:
- Use consistent decimal places (if one baseline has 85.3, don't report yours as 87.34)
- Include units where applicable
- Use thousands separators for large numbers: 1,000,000 not 1000000

**Acronyms**:
- Define on first use in both abstract and body (they are separate contexts)
- Do not define acronyms you use only once — just spell it out
- Common venue-specific acronyms (NLP, LLM, GNN) may not need definition depending on venue


path: references/word-choice.md
content: # Word Choice Quick Reference

Common substitutions for clearer academic CS writing. Left column: avoid or reconsider. Right column: prefer.

## Overly Fancy → Simple and Clear

| Avoid | Prefer | Notes |
|---|---|---|
| utilize | use | Almost always |
| leverage | use, apply, build on | "Leverage" is business jargon |
| elucidate | explain, clarify | |
| facilitate | enable, help, allow | |
| endeavor | try, aim, attempt | |
| plethora | many, several, numerous | |
| myriad | many, various | |
| paradigm | approach, framework, model | Unless specifically referencing Kuhn |
| novel | new | Overused in CS papers; save for genuine novelty |
| state-of-the-art | best, strongest, leading | Fine in context but overused |
| aforementioned | this, the, (just refer to it) | Almost always deletable |
| henceforth | from here, going forward | |
| heretofore | previously, until now | |
| whilst | while | |
| amongst | among | |
| thereby | (restructure the sentence) | Often signals a sentence that is too long |

## Filler Phrases → Delete or Shorten

| Filler | Replacement |
|---|---|
| It is worth noting that | (delete — just state the thing) |
| It should be mentioned that | (delete) |
| It is important to note that | (delete, or start with "Notably,") |
| In order to | To |
| Due to the fact that | Because |
| In the event that | If |
| For the purpose of | To, For |
| A large number of | Many |
| In the case of | For, When |
| With regard to | About, Regarding |
| In light of the fact that | Because, Since |
| On the other hand | However, Alternatively |
| At this point in time | Now, Currently |
| In the majority of cases | Usually, Often |
| It has been shown that | (cite directly: "Smith et al. (2023) showed") |
| It is well known that | (either cite or just state the fact) |

## Hedging: Right Amount

**Too much hedging** (avoid):
- "It could potentially be argued that this might possibly suggest..."
- "We tentatively hypothesize that perhaps..."

**Appropriate hedging** (use when genuinely uncertain):
- "suggests" (for correlational evidence)
- "indicates" (for strong but not conclusive evidence)
- "may" (for speculation grounded in evidence)
- "we hypothesize" (for testable claims)

**No hedging needed** (for established facts or your own experimental results):
- "Our method achieves..." (not "Our method appears to achieve...")
- "The loss converges after..." (not "The loss seems to converge...")

## Transitions Between Ideas

| Relationship | Connectives |
|---|---|
| Addition | Moreover, Furthermore, Additionally, In addition |
| Contrast | However, In contrast, Nevertheless, On the other hand, Yet |
| Cause/Effect | Therefore, Consequently, As a result, Thus, Hence |
| Example | For example, For instance, Specifically, In particular |
| Clarification | That is, In other words, Specifically, More precisely |
| Comparison | Similarly, Likewise, In the same way |
| Concession | Although, While, Despite, Notwithstanding |
| Sequence | First, Second, Next, Then, Finally |
| Summary | In summary, Overall, To summarize |

Prefer variety — do not use "Moreover" at the start of every other paragraph.


Security scan verdicts — ClawScan: clean | static analysis: clean | VirusTotal: clean | SkillSpector: clean (LOW)