name: academic-paper-writing description: | Guides AI agents to write high-quality academic papers following top-tier conference standards.
Use this skill when:
- Writing or drafting academic papers for AI/systems conferences
- Designing paper structure, sections, or experimental methodology
- Creating figures, tables, or data visualizations for papers
- Performing literature review or managing citations
- Responding to reviewer comments or preparing rebuttal
- Any task involving academic writing workflow
Do NOT use for:
- Non-academic writing (blogs, marketing copy, documentation)
- Papers outside AI/systems domains without adaptation
- Simple formatting tasks that don't require domain expertise
Academic Paper Writing
Guide agents through the complete academic paper writing process, from initial draft to final submission.
Core Philosophy
Writing = Building Arguments, Not Recording Work
Papers must construct an irrefutable argument system, not simply document what was done. The goal: make reviewers conclude "this problem is important, this method is sound, these results are credible."
The Argument Loop
Observation → Insight → Design → Evidence
Every section must form a verifiable takeaway that closes this loop.
Reviewer Psychology
Four Axioms
- Default Distrust: Reviewers assume most papers are poor quality
- Limited Patience: Key information must appear early; conclusions go first
- Emotional Judgment: Visual presentation directly affects acceptance decisions
- Logical Closure: Arguments must be self-consistent; gaps invite rejection
Reviewers seek reasons to REJECT. Give them reasons to FIGHT for your paper.
Writing Workflow
Three-Phase Process
| Phase | Goal | Actions |
|---|---|---|
| Fast Output | Capture all ideas | Don't polish; write in Chinese then translate with LLM |
| Restructure | Rebuild logic | ~80% rewrite; refine figures; produce abstract and draft |
| Refine | Polish details | Adjust wording; add citations; fill pages; proofread |
Time Budget
| Work Type | Comfortable | Minimum |
|---|---|---|
| New work | 1 month | 2 weeks |
| Incremental | 3 weeks | 1 week |
| Resubmission | 1 week | 1 day |
Role Transition
Early phase: Engineer (deep in details)
Late phase: Researcher (above details)
Kill the Engineer in you; wake up the Researcher.
Paper Structure
Critical Sections (The Target)
These three sections define the problem and build consensus:
- Abstract: Mini Introduction; spend up to half on problem/motivation; show concrete numbers
- Introduction: Make reviewers want to read; structure: problem → gap → insight → contributions
- Background + Motivation: Not a tutorial; purposeful introduction; three-layer structure: Observation → Limitation → Opportunity
Supporting Sections
- Design: Explain trade-offs, not describe flow; modular presentation; abstract method, not implementation
- Implementation: Credibility boost, not workload display; keep brief
- Evaluation: Setup → Main results → Ablation → Supplementary; use concrete numbers in text
- Related Work: Categorize and contrast; highlight necessity of your approach
- Conclusion: Fill to full page; can include future work
Key Requirements
- Front two pages: include intuitive figures explaining the problem
- Design: minimum 3 points for top-tier; must cover all stated problems
- Evaluation: must close the loop—cover all design points and initial questions
Expression Standards
Paragraph Flow
Paragraphs should be like prayer beads—round, smooth bodies connected by a thread.
Each paragraph:承上 (connect up) → body → 启下 (connect down)
- Uniform length; no isolated short paragraphs
- Reader should flow through without thinking
Sentence Rules
| Problem | Fix |
|---|---|
| Clause trains | ... which ... which ... → .... It .... This ... |
| Head-heavy | Move long subject to It is common to see... |
| Colloquial | piece of cake → trivial to do |
Word Choice
| Avoid | Reason |
|---|---|
most, best | Extreme unless theoretically proven |
clever, genius | Subjective exaggeration |
| Rare terms | Unless domain-standard |
| Inconsistent naming | One term = one concept throughout |
Positive framing: fails to → is limited by → is designed for
Figure Standards
Information Density
- Compact layout; avoid "padding" accusations
- Unified color scheme across all figures
- Consider black-white printing; use textures
Dimensions
- Single column:
4inch × 100dpi = 400pt - Double column: 7 inches wide
- Reserve 1-2 double-column figures for page filling
Data Visualization
- Global color palette; explicit color in all code
- Must show average/mean values
- Caption explains figure; self-contained understanding
- Matplotlib:
bbox_inches='tight', pad_inches=0
Experimental Rigor
Structure
Setup → Main Experiment → Ablation → Supplementary
Analysis Formula
Phenomenon → Cause → Design Connection → Implication
Requirements
- SOTA comparison required: No strong baseline = unverifiable paper
- Ablation required: Prove gains come from design
- Anomaly analysis: Surprising/negative results need deep explanation
- Numbers in text: Don't make readers hunt in figures
Analysis should be thorough enough that reviewers don't want to read it.
Submission Process
Pre-submission
- Verify template (font size errors are fatal)
- Remove copyright information
- Collect all ORCID IDs early
Rebuttal Workflow
List questions → Answer each → Merge similar → Assign responsibility
Camera-ready
- Fix reviewer-identified issues
- Add copyright, authorship, acknowledgments
- Watch for page count changes
Common Pitfalls
Content Errors
| Mistake | Correct Approach |
|---|---|
| Writing as tutorial | Purposeful intro; highlight connection to your work |
| Writing as engineering report | Build argument system |
| Implementation dumping | Abstract method, not details |
Experiment Errors
| Mistake | Correct Approach |
|---|---|
| Data dumping | Guide understanding with text |
| Unattributed gains | Prove source is your design |
| Missing baseline | SOTA comparison mandatory |
AI Tool Usage
- LLM translation shows detectable patterns
- Use LLM for translation + polish, but apply your own voice
- Writing experience beats observation
Self-Check List
Format
- Template correct?
- Looks like a paper?
- Last page full?
Content
- Background/Related Work written as tutorial?
- Design covers all stated problems?
- Evaluation covers all Design points?
Structure
- No isolated paragraphs?
- No short paragraphs?
- No long sentences?
Data
- Concrete numbers in abstract/text?
- Average values on figures?
Consistency
- Terms consistent throughout?
- Figure colors unified?
Resources
- Technical paper writing: https://homes.cs.washington.edu/~mernst/advice/write-technical-paper.html
- Technical presentations: https://homes.cs.washington.edu/~mernst/advice/giving-talk.html
- Conference acceptance rates: https://csconferences.org/
Papers are labels you attach to yourself. What kind of person writes what kind of paper, and what kind of paper defines what kind of person.