Academic Paper Writing for AI/Systems Conferences

Description

--- 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 1. **Default Distrust**: Reviewers assume most papers are poor quality 2. **Limited Patience**: Key information must appear early; conclusions go first 3. **Emotional Judgment**: Visual presentation directly affects acceptance decisions 4. **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.

Security Status