Ml Paper Writing

ML Paper Writing for Top AI Conferences

Expert-level guidance for writing publication-ready papers targeting NeurIPS, ICML, ICLR, ACL, AAAI, and COLM. This skill combines writing philosophy from top researchers (Nanda, Farquhar, Karpathy, Lipton, Steinhardt) with practical tools: LaTeX templates, citation verification APIs, and conference checklists.

Default operating order

Use this skill in the following order unless the task is unusually narrow: 1. lock the operating mode from references/OPERATING-MODES.md, 2. understand the repo or draft context, 3. use references/citation-workflow.md as the canonical citation authority, 4. load venue- or template-specific references only after the main writing path is clear.

Google Scholar may still help with manual discovery, but it is not the canonical verification authority in this skill. Default verification should use programmatic sources such as Semantic Scholar, CrossRef, and arXiv.

Claim ledger gate

Before a project plan, experiment note, or literature summary becomes manuscript prose:

• identify the Claim Candidate or Evidence Record that supports the sentence,
• preserve allowed wording and forbidden stronger wording,
• keep project plans as hypotheses unless experiment artifacts or verified papers support them,
• do not turn related-work motivation into evidence for the paper's own result,
• mark unsupported claims as [CLAIM NEEDS EVIDENCE] instead of polishing them.

If the repo context is clear enough for a first draft, still apply this gate before stating contributions, results, related-work contrasts, or rebuttal-facing claims.

Core Philosophy: Collaborative Writing

Paper writing is collaborative, but Claude should be proactive in delivering drafts.

The typical workflow starts with a research repository containing code, results, and experimental artifacts. Claude's role is to:

1. Understand the project by exploring the repo, results, and existing documentation 2. Deliver a complete first draft when confident about the contribution 3. Search literature using web search and APIs to find relevant citations 4. Refine through feedback cycles when the scientist provides input 5. Ask for clarification only when genuinely uncertain about key decisions

Key Principle: Be proactive. If the repo and results are clear, deliver a full draft. Don't block waiting for feedback on every section—scientists are busy. Produce something concrete they can react to, then iterate based on their response.

---

⚠️ CRITICAL: Never Hallucinate Citations

This is the most important rule in academic writing with AI assistance.

The Problem

AI-generated citations have a ~40% error rate. Hallucinated references—papers that don't exist, wrong authors, incorrect years, fabricated DOIs—are a serious form of academic misconduct that can result in desk rejection or retraction.

The Rule

NEVER generate BibTeX entries from memory. ALWAYS fetch programmatically.

When You Can't Verify a Citation

If you cannot programmatically verify a citation, you MUST:

% EXPLICIT PLACEHOLDER - requires human verification
\cite{PLACEHOLDER_author2024_verify_this}  % TODO: Verify this citation exists

Always tell the scientist: "I've marked [X] citations as placeholders that need verification. I could not confirm these papers exist."

Recommended: Install Exa MCP for Paper Search

For the best paper search experience, install Exa MCP which provides real-time academic search:

Claude Code:

claude mcp add exa -- npx -y mcp-remote "https://mcp.exa.ai/mcp"

Cursor / VS Code (add to MCP settings):

{
  "mcpServers": {
    "exa": {
      "type": "http",
      "url": "https://mcp.exa.ai/mcp"
    }
  }
}

Exa MCP enables searches like:

• "Find papers on RLHF for language models published after 2023"
• "Search for transformer architecture papers by Vaswani"
• "Get recent work on sparse autoencoders for interpretability"

Then verify results with Semantic Scholar API and fetch BibTeX via DOI.

---

Workflow 0: Starting from a Research Repository

When beginning paper writing, start by understanding the project:

Project Understanding:
- [ ] Step 1: Explore the repository structure
- [ ] Step 2: Read README, existing docs, and key results
- [ ] Step 3: Identify the main contribution with the scientist
- [ ] Step 4: Find papers already cited in the codebase
- [ ] Step 5: Search for additional relevant literature
- [ ] Step 6: Outline the paper structure together
- [ ] Step 7: Draft sections iteratively with feedback

Step 1: Explore the Repository

# Understand project structure
ls -la
find . -name "*.py" | head -20
find . -name "*.md" -o -name "*.txt" | xargs grep -l -i "result\|conclusion\|finding"

Look for:

• README.md - Project overview and claims
• results/, outputs/, experiments/ - Key findings
• configs/ - Experimental settings
• Existing .bib files or citation references
• Any draft documents or notes

Step 2: Identify Existing Citations

Check for papers already referenced in the codebase:

# Find existing citations
grep -r "arxiv\|doi\|cite" --include="*.md" --include="*.bib" --include="*.py"
find . -name "*.bib"

These are high-signal starting points for Related Work—the scientist has already deemed them relevant.

Step 3: Clarify the Contribution

Before writing, explicitly confirm with the scientist:

"Based on my understanding of the repo, the main contribution appears to be [X].

The key results show [Y]. Is this the framing you want for the paper,

or should we emphasize different aspects?"

Never assume the narrative—always verify with the human.

Step 4: Search for Additional Literature

Use web search to find relevant papers:

Search queries to try:
- "[main technique] + [application domain]"
- "[baseline method] comparison"
- "[problem name] state-of-the-art"
- Author names from existing citations

Then verify and retrieve BibTeX using the citation workflow below.

Step 5: Deliver a First Draft

Be proactive—deliver a complete draft rather than asking permission for each section.

If the repo provides clear results and the contribution is apparent: 1. Check the claim ledger gate for contribution and result claims 2. Write the full first draft end-to-end only for supported claims 3. Mark unsupported or speculative claims explicitly 4. Present the complete draft for feedback 5. Iterate based on scientist's response

If genuinely uncertain about framing or major claims: 1. Draft what you can confidently 2. Flag specific uncertainties: "I framed X as the main contribution—let me know if you'd prefer to emphasize Y instead" 3. Continue with the draft rather than blocking

Questions to include with the draft (not before):

• "I emphasized X as the main contribution—adjust if needed"
• "I highlighted results A, B, C—let me know if others are more important"
• "Related work section includes [papers]—add any I missed"

---

When to Use This Skill

Use this skill when:

• Starting from a research repo to write a paper
• Drafting or revising specific sections
• Conducting literature reviews and finding related work
• Discovering recent papers in your research area
• Finding and verifying citations for related work
• Formatting for conference submission
• Resubmitting to a different venue (format conversion)
• Iterating on drafts with scientist feedback

Always remember: First drafts are starting points for discussion, not final outputs.

---

Workflow: Literature Research & Paper Discovery

When conducting literature reviews, finding related work, or discovering recent papers, use this workflow to systematically search, evaluate, and select ML papers.

Workflow 5: Finding and Evaluating Papers

Literature Research Process:
- [ ] Step 1: Define search scope and keywords
- [ ] Step 2: Search arXiv and academic databases
- [ ] Step 3: Screen papers by title/abstract
- [ ] Step 4: Evaluate paper quality (5 dimensions)
- [ ] Step 5: Select top papers and extract citations
- [ ] Step 6: Verify citations programmatically

Step 1: Define Search Scope

Identify specific research areas, methods, or applications:

• Technique-focused: transformer architecture, graph neural networks, self-supervised learning
• Application-focused: medical image analysis, reinforcement learning for robotics, language model alignment
• Problem-focused: out-of-distribution generalization, continual learning, fairness in ML

Step 2: Search arXiv

Use arXiv search with targeted keywords:

URL Pattern:
https://arxiv.org/search/?searchtype=all&query=KEYWORDS&abstracts=show&order=-announced_date_first

Example Searches:
- https://arxiv.org/search/?searchtype=all&query=graph+neural+networks&abstracts=show&order=-announced_date_first
- https://arxiv.org/search/?cat:cs.LG+AND+all:transformer&abstracts=show&order=-announced_date_first

Tips:

• Combine keywords with + for AND
• Filter by categories: cs.LG, cs.AI, cs.CV, cs.CL
• Sort by announced_date_first for recent papers
• Use Chrome MCP tools when available for automation

Step 3: Screen Papers

Quick screening by title and abstract:

• Relevance to research topic
• Novelty of contribution
• Venue/reputation of authors
• Code availability (check for GitHub links)

Step 4: Evaluate Quality

Use the 5-dimension quality criteria:

Scoring: Rate each dimension 1-5, calculate weighted total

Step 5: Select and Extract

• Rank papers by total score
• Select top papers for detailed review
• Extract metadata: title, authors, arXiv ID, abstract
• Note code repository links

Step 6: Verify Citations

For selected papers, verify citations using Semantic Scholar API:

• Fetch BibTeX programmatically via DOI
• Mark unverified citations as [CITATION NEEDED]
• Store in bibliography with verification status

When to Use Literature Research

Use this workflow when:

• Starting a new project: Find related work and baselines
• Writing Related Work section: Discover recent papers in your area
• Staying updated: Track recent publications in your field
• Finding baselines: Identify state-of-the-art methods for comparison
• Literature review: Comprehensive survey of research area

Quality Thresholds

• Excellent: 4.0+ (include definitely)
• Good: 3.5-3.9 (include if relevant)
• Fair: 3.0-3.4 (include if highly relevant)
• Poor: <3.0 (exclude unless essential)

Reference Files

For detailed literature research guidance:

• `references/literature-research/arxiv-search-guide.md` - arXiv search strategies and URL patterns
• `references/literature-research/paper-quality-criteria.md` - Detailed 5-dimension evaluation rubrics

---

Knowledge Base: Paper-Miner Installed Writing Memory

This skill consumes the active installed writing memory maintained by paper-miner:

• references/knowledge/paper-miner-writing-memory.md

This memory belongs to the active installed skill home, not to the source checkout copy.

Even when paper-miner is invoked while working inside a specific repository, it still writes mined writing knowledge only into the active installed skill memory. It does not maintain project-local writing memory unless the user explicitly requests that.

Canonical memory structure

The maintained memory contains these sections:

How the memory is maintained

The paper-miner agent reads papers and merges reusable writing knowledge into this one file:

You: "Learn writing patterns from this paper: path/to/paper.pdf"
↓
paper-miner analyzes the paper
↓
Extracts reusable writing signals
↓
Updates paper-miner-writing-memory.md
↓
ml-paper-writing reuses that memory later

When to use this memory

Use the active installed paper-miner memory when you need:

• structure inspiration for intros, methods, results, or discussion,
• reusable transition phrases or framing templates,
• venue-facing writing signals,
• rebuttal phrasing and response structure ideas,
• examples of how strong papers support and sequence claims.

Default read order

When drafting or revising with ml-paper-writing, read this memory before writing if the task involves:

• introduction framing,
• related work organization,
• method exposition style,
• results narration,
• discussion framing,
• venue-facing polishing.

Use this read order: 1. references/knowledge/paper-miner-writing-memory.md 2. repo-local evidence and experiment artifacts 3. cited papers or notes if needed 4. venue template and formatting constraints

Read narrowly, not exhaustively:

• first scan How this helps our writing,
• then check Writing patterns mined and Structure signals,
• then inspect Reusable phrasing only for concrete wording help,
• use Venue-specific signals when targeting a known venue.

Contribution rule

Every paper mined by paper-miner should improve the same active installed memory.

Do not scatter newly mined knowledge across multiple maintained files. Do not create project-specific paper-miner memory. Do not duplicate near-identical patterns from the same source.

See references/knowledge/README.md for the detailed knowledge-base contract.

Balancing Proactivity and Collaboration

Default: Be proactive. Deliver drafts, then iterate.

Draft first, ask with the draft (not before):

Only block for input when:

• Target venue is unclear (affects page limits, framing)
• Multiple contradictory framings seem equally valid
• Results seem incomplete or inconsistent
• Explicit request to review before continuing

Don't block for:

• Word choice decisions
• Section ordering
• Which specific results to show (make a choice, flag it)
• Citation completeness (draft with what you find, note gaps)

---

The Narrative Principle

The single most critical insight: Your paper is not a collection of experiments—it's a story with one clear contribution supported by evidence.

Every successful ML paper centers on what Neel Nanda calls "the narrative": a short, rigorous, evidence-based technical story with a takeaway readers care about.

Three Pillars (must be crystal clear by end of introduction):

If you cannot state your contribution in one sentence, you don't yet have a paper.

---

Paper Structure Workflow

Workflow 1: Writing a Complete Paper (Iterative)

Copy this checklist and track progress. Each step involves drafting → feedback → revision:

Paper Writing Progress:
- [ ] Step 1: Define the one-sentence contribution (with scientist)
- [ ] Step 2: Draft Figure 1 → get feedback → revise
- [ ] Step 3: Draft abstract → get feedback → revise
- [ ] Step 4: Draft introduction → get feedback → revise
- [ ] Step 5: Draft methods → get feedback → revise
- [ ] Step 6: Draft experiments → get feedback → revise
- [ ] Step 7: Draft related work → get feedback → revise
- [ ] Step 8: Draft limitations → get feedback → revise
- [ ] Step 9: Complete paper checklist (required)
- [ ] Step 10: Final review cycle and submission

Step 1: Define the One-Sentence Contribution

This step requires explicit confirmation from the scientist.

Before writing anything, articulate and verify:

• What is the single thing your paper contributes?
• What was not obvious or present before your work?

"I propose framing the contribution as: '[one sentence]'. Does this capture

what you see as the main takeaway? Should we adjust the emphasis?"

Step 2: Draft Figure 1

Figure 1 deserves special attention—many readers skip directly to it.

• Convey core idea, approach, or most compelling result
• Use vector graphics (PDF/EPS for plots)
• Write captions that stand alone without main text
• Ensure readability in black-and-white (8% of men have color vision deficiency)

Step 3: Write Abstract (5-Sentence Formula)

From Sebastian Farquhar (DeepMind):

1. What you achieved: "We introduce...", "We prove...", "We demonstrate..."
2. Why this is hard and important
3. How you do it (with specialist keywords for discoverability)
4. What evidence you have
5. Your most remarkable number/result

Delete generic openings like "Large language models have achieved remarkable success..."

Step 4: Write Introduction (1-1.5 pages max)

Must include:

• 2-4 bullet contribution list (max 1-2 lines each in two-column format)
• Clear problem statement
• Brief approach overview
• Methods should start by page 2-3 maximum

Step 5: Methods Section

Enable reimplementation:

• Conceptual outline or pseudocode
• All hyperparameters listed
• Architectural details sufficient for reproduction
• Present final design decisions; ablations go in experiments

Step 6: Experiments Section

For each experiment, explicitly state:

• What claim it supports
• How it connects to main contribution
• Experimental setting (details in appendix)
• What to observe: "the blue line shows X, which demonstrates Y"

Requirements:

• Error bars with methodology (standard deviation vs standard error)
• Hyperparameter search ranges
• Compute infrastructure (GPU type, total hours)
• Seed-setting methods

Step 7: Related Work

Organize methodologically, not paper-by-paper:

Good: "One line of work uses Floogledoodle's assumption [refs] whereas we use Doobersnoddle's assumption because..."

Bad: "Snap et al. introduced X while Crackle et al. introduced Y."

Cite generously—reviewers likely authored relevant papers.

Step 8: Limitations Section (REQUIRED)

All major conferences require this. Counter-intuitively, honesty helps:

• Reviewers are instructed not to penalize honest limitation acknowledgment
• Pre-empt criticisms by identifying weaknesses first
• Explain why limitations don't undermine core claims

Step 9: Paper Checklist

NeurIPS, ICML, and ICLR all require paper checklists. See references/checklists.md.

---

Writing Philosophy for Top ML Conferences

This section distills the most important writing principles from leading ML researchers. These aren't optional style suggestions—they're what separates accepted papers from rejected ones.

"A paper is a short, rigorous, evidence-based technical story with a takeaway readers care about." — Neel Nanda

The Sources Behind This Guidance

This skill synthesizes writing philosophy from researchers who have published extensively at top venues:

For deeper dives into any of these, see:

• references/writing-guide.md - Full explanations with examples
• references/sources.md - Complete bibliography

Time Allocation (From Neel Nanda)

Spend approximately equal time on each of: 1. The abstract 2. The introduction 3. The figures 4. Everything else combined

Why? Most reviewers form judgments before reaching your methods. Readers encounter your paper as: title → abstract → introduction → figures → maybe the rest.

Writing Style Guidelines

Sentence-Level Clarity (Gopen & Swan's 7 Principles)

These principles are based on how readers actually process prose. Violating them forces readers to spend cognitive effort on structure rather than content.

Full 7 principles with detailed examples: See references/writing-guide.md

Micro-Level Tips (Ethan Perez)

These small changes accumulate into significantly clearer prose:

• Minimize pronouns: ❌ "This shows..." → ✅ "This result shows..."
• Verbs early: Position verbs near sentence start
• Unfold apostrophes: ❌ "X's Y" → ✅ "The Y of X" (when awkward)
• Delete filler words: "actually," "a bit," "very," "really," "basically," "quite," "essentially"

Full micro-tips with examples: See references/writing-guide.md

Word Choice (Zachary Lipton)

• Be specific: ❌ "performance" → ✅ "accuracy" or "latency" (say what you mean)
• Eliminate hedging: Drop "may" and "can" unless genuinely uncertain
• Avoid incremental vocabulary: ❌ "combine," "modify," "expand" → ✅ "develop," "propose," "introduce"
• Delete intensifiers: ❌ "provides very tight approximation" → ✅ "provides tight approximation"

Precision Over Brevity (Jacob Steinhardt)

• Consistent terminology: Different terms for same concept creates confusion. Pick one and stick with it.
• State assumptions formally: Before theorems, list all assumptions explicitly
• Intuition + rigor: Provide intuitive explanations alongside formal proofs

What Reviewers Actually Read

Understanding reviewer behavior helps prioritize your effort:

Bottom line: If your abstract and intro don't hook reviewers, they may never read your brilliant methods section.

---

Conference Requirements Quick Reference

Universal Requirements:

• Double-blind review (anonymize submissions)
• References don't count toward page limit
• Appendices unlimited but reviewers not required to read
• LaTeX required for all venues

LaTeX Templates: See templates/ directory for all conference templates.

---

Using LaTeX Templates Properly

Workflow 4: Starting a New Paper from Template

Always copy the entire template directory first, then write within it.

Template Setup Checklist:
- [ ] Step 1: Copy entire template directory to new project
- [ ] Step 2: Verify template compiles as-is (before any changes)
- [ ] Step 3: Read the template's example content to understand structure
- [ ] Step 4: Replace example content section by section
- [ ] Step 5: Keep template comments/examples as reference until done
- [ ] Step 6: Clean up template artifacts only at the end

Step 1: Copy the Full Template

# Create your paper directory with the complete template
cp -r templates/neurips2025/ ~/papers/my-new-paper/
cd ~/papers/my-new-paper/

# Verify structure is complete
ls -la
# Should see: main.tex, neurips.sty, Makefile, etc.

⚠️ IMPORTANT: Copy the ENTIRE directory, not just main.tex. Templates include:

• Style files (.sty) - required for compilation
• Bibliography styles (.bst) - required for references
• Example content - useful as reference
• Makefiles - for easy compilation

Step 2: Verify Template Compiles First

Before making ANY changes, compile the template as-is:

# Using latexmk (recommended)
latexmk -pdf main.tex

# Or manual compilation
pdflatex main.tex
bibtex main
pdflatex main.tex
pdflatex main.tex

If the unmodified template doesn't compile, fix that first. Common issues:

• Missing TeX packages → install via tlmgr install <package>
• Wrong TeX distribution → use TeX Live (recommended)

Step 3: Keep Template Content as Reference

Don't immediately delete all example content. Instead:

% KEEP template examples commented out as you write
% This shows you the expected format

% Template example (keep for reference):
% \begin{figure}[t]
%   \centering
%   \includegraphics[width=0.8\linewidth]{example-image}
%   \caption{Template shows caption style}
% \end{figure}

% Your actual figure:
\begin{figure}[t]
  \centering
  \includegraphics[width=0.8\linewidth]{your-figure.pdf}
  \caption{Your caption following the same style.}
\end{figure}

Step 4: Replace Content Section by Section

Work through the paper systematically:

Replacement Order:
1. Title and authors (anonymize for submission)
2. Abstract
3. Introduction
4. Methods
5. Experiments
6. Related Work
7. Conclusion
8. References (your .bib file)
9. Appendix

For each section: 1. Read the template's example content 2. Note any special formatting or macros used 3. Replace with your content following the same patterns 4. Compile frequently to catch errors early

Step 5: Use Template Macros

Templates often define useful macros. Check the preamble for:

% Common template macros to use:
\newcommand{\method}{YourMethodName}  % Consistent method naming
\newcommand{\eg}{e.g.,\xspace}        % Proper abbreviations
\newcommand{\ie}{i.e.,\xspace}
\newcommand{\etal}{\textit{et al.}\xspace}

Step 6: Clean Up Only at the End

Only remove template artifacts when paper is nearly complete:

% BEFORE SUBMISSION - remove these:
% - Commented-out template examples
% - Unused packages
% - Template's example figures/tables
% - Lorem ipsum or placeholder text

% KEEP these:
% - All style files (.sty)
% - Bibliography style (.bst)
% - Required packages from template
% - Any custom macros you're using

Template Pitfalls to Avoid

Quick Template Reference

---

Conference Resubmission & Format Conversion

When a paper is rejected or withdrawn from one venue and resubmitted to another, format conversion is required. This is a common workflow in ML research.

Workflow 3: Converting Between Conference Formats

Format Conversion Checklist:
- [ ] Step 1: Identify source and target template differences
- [ ] Step 2: Create new project with target template
- [ ] Step 3: Copy content sections (not preamble)
- [ ] Step 4: Adjust page limits and content
- [ ] Step 5: Update conference-specific requirements
- [ ] Step 6: Verify compilation and formatting

Step 1: Key Template Differences

Step 2: Content Migration (NOT Template Merge)

Never copy LaTeX preambles between templates. Instead:

# 1. Start fresh with target template
cp -r templates/icml2026/ new_submission/

# 2. Copy ONLY content sections from old paper
# - Abstract text
# - Section content (between \section{} commands)
# - Figures and tables
# - Bibliography entries

# 3. Paste into target template structure

Step 3: Adjusting for Page Limits

When cutting pages (e.g., NeurIPS 9 → AAAI 7):

• Move detailed proofs to appendix
• Condense related work (cite surveys instead of individual papers)
• Combine similar experiments into unified tables
• Use smaller figure sizes with subfigures
• Tighten writing: eliminate redundancy, use active voice

When expanding (e.g., ICML 8 → ICLR 9):

• Add ablation studies reviewers requested
• Expand limitations discussion
• Include additional baselines
• Add qualitative examples

Step 4: Conference-Specific Adjustments

Step 5: Update References

% Remove self-citations that reveal identity (for blind review)
% Update any "under review" citations to published versions
% Add new relevant work published since last submission

Step 6: Addressing Previous Reviews

When resubmitting after rejection:

• Do address reviewer concerns in the new version
• Do add experiments/clarifications reviewers requested
• Don't include a "changes from previous submission" section (blind review)
• Don't reference the previous submission or reviews

Common Conversion Pitfalls:

• ❌ Copying \usepackage commands (causes conflicts)
• ❌ Keeping old conference header/footer commands
• ❌ Forgetting to update \bibliography{} path
• ❌ Missing conference-specific required sections
• ❌ Exceeding page limit after format change

---

Citation Workflow (Hallucination Prevention)

⚠️ CRITICAL: AI-generated citations are a high-risk failure mode. Never write BibTeX from memory.

Canonical authority

Use references/citation-workflow.md as the default authority for citation verification.

The default verification path is: 1. Search programmatically with Semantic Scholar / CrossRef / arXiv / OpenAlex when appropriate. 2. Verify existence in two sources when the claim is important. 3. Retrieve BibTeX programmatically from DOI or a trusted source. 4. Validate the claim against the actual paper content when the citation supports a specific statement. 5. Add the citation only after the metadata and claim are verified.

The golden rule

IF you cannot verify a citation programmatically:
    -> mark it as [CITATION NEEDED] or [PLACEHOLDER - VERIFY]
    -> tell the scientist explicitly
    -> NEVER invent a plausible-sounding reference

Workflow 2: Adding citations

Citation verification:
- [ ] Step 1: Search with Semantic Scholar / CrossRef / arXiv / OpenAlex as appropriate
- [ ] Step 2: Confirm title, authors, year, and venue
- [ ] Step 3: Retrieve BibTeX from DOI, arXiv, or another trusted export path
- [ ] Step 4: Verify that the claim being cited actually appears in the source
- [ ] Step 5: Add verified BibTeX to the bibliography
- [ ] Step 6: If any step fails -> mark as placeholder and report it explicitly

Discovery vs authority

• Programmatic APIs are the canonical verification path.
• Google Scholar may still be used as a manual discovery surface when coverage is weak, but not as the primary authority.
• If Google Scholar finds something that the canonical APIs do not, treat it as a lead that still requires explicit verification.

Summary: citation rules

🚨 NEVER generate BibTeX from memory. Use the programmatic workflow in `references/citation-workflow.md`. 🚨

Complete Citation Workflow Example

Scenario: You need to cite the Transformer paper.

Step 1: Search programmatically
- Semantic Scholar query: "Attention is All You Need Vaswani 2017"
- Result: title, authors, year, and DOI align

Step 2: Verify existence
- CrossRef confirms DOI metadata
- Semantic Scholar record matches the same paper

Step 3: Retrieve BibTeX
- Fetch BibTeX from the DOI / trusted export path

Step 4: Verify the claim
- Read the abstract or paper section that supports the cited statement
- Confirm that the claim being cited is actually present

Step 5: Add to bibliography
- Paste verified BibTeX into the .bib file
- Cite with the verified key

Step 6: If any step fails
- mark the citation as [PLACEHOLDER - VERIFY]
- tell the scientist explicitly what remains unverified

---

Common Issues and Solutions

Issue: Abstract too generic

Delete first sentence if it could be prepended to any ML paper. Start with your specific contribution.

Issue: Introduction exceeds 1.5 pages

Split background into Related Work. Front-load contribution bullets. Methods should start by page 2-3.

Issue: Experiments lack explicit claims

Add sentence before each experiment: "This experiment tests whether [specific claim]..."

Issue: Reviewers find paper hard to follow

• Add explicit signposting: "In this section, we show X"
• Use consistent terminology throughout
• Include figure captions that stand alone

Issue: Missing statistical significance

Always include:

• Error bars (specify: std dev or std error)
• Number of runs
• Statistical tests if comparing methods

---

Reviewer Evaluation Criteria

Reviewers assess papers on four dimensions:

Scoring (NeurIPS 6-point scale):

• 6: Strong Accept - Groundbreaking, flawless
• 5: Accept - Technically solid, high impact
• 4: Borderline Accept - Solid, limited evaluation
• 3: Borderline Reject - Solid but weaknesses outweigh
• 2: Reject - Technical flaws
• 1: Strong Reject - Known results or ethics issues

See references/reviewer-guidelines.md for detailed reviewer instructions.

---

Tables and Figures

If the task is to generate or redesign paper-ready figures/tables themselves, use publication-chart-skill; ml-paper-writing stays responsible for caption quality, placement, storyline, and paper integration.

Tables

Use booktabs LaTeX package for professional tables:

\usepackage{booktabs}
\begin{tabular}{lcc}
\toprule
Method & Accuracy ↑ & Latency ↓ \\
\midrule
Baseline & 85.2 & 45ms \\
\textbf{Ours} & \textbf{92.1} & 38ms \\
\bottomrule
\end{tabular}

Rules:

• Bold best value per metric
• Include direction symbols (↑ higher is better, ↓ lower is better)
• Right-align numerical columns
• Consistent decimal precision

Figures

• Vector graphics (PDF, EPS) for all plots and diagrams
• Raster (PNG 600 DPI) only for photographs
• Use colorblind-safe palettes (Okabe-Ito or Paul Tol)
• Verify grayscale readability (8% of men have color vision deficiency)
• No title inside figure—the caption serves this function
• Self-contained captions—reader should understand without main text

---

References & Resources

Reference Documents (Deep Dives)

LaTeX Templates

Templates in templates/ directory: ICML 2026, ICLR 2026, NeurIPS 2025, ACL/EMNLP, AAAI 2026, COLM 2025.

Compiling to PDF:

• VS Code/Cursor: Install LaTeX Workshop extension + TeX Live → Save to auto-compile
• Command line: latexmk -pdf main.tex or pdflatex + bibtex workflow
• Online: Upload to Overleaf

See templates/README.md for detailed setup instructions.

Key External Sources

Writing Philosophy:

• Neel Nanda: How to Write ML Papers - Narrative, "What/Why/So What"
• Farquhar: How to Write ML Papers - 5-sentence abstract
• Gopen & Swan: Science of Scientific Writing - 7 reader expectation principles
• Lipton: Heuristics for Scientific Writing - Word choice
• Perez: Easy Paper Writing Tips - Micro-level clarity

APIs: Semantic Scholar | CrossRef | arXiv

Venues: NeurIPS | ICML | ICLR | ACL

Conference Paper Checklists

This reference documents the mandatory checklist requirements for major ML/AI conferences. All major venues now require paper checklists—missing them results in desk rejection.

---

Contents

• NeurIPS Paper Checklist
• ICML Paper Checklist
• ICLR Requirements
• ACL Requirements
• Universal Pre-Submission Checklist

---

NeurIPS Paper Checklist

Mandatory Components

All NeurIPS submissions must include a completed paper checklist. Papers lacking this element face automatic desk rejection. The checklist appears after references and supplemental material, outside the page limit.

16 Required Checklist Items

1. Claims Alignment

Authors must verify that abstract and introduction claims match theoretical and experimental results, with clearly stated contributions, assumptions, and limitations.

What to check:

• [ ] Abstract claims match actual results
• [ ] Introduction doesn't overclaim
• [ ] Contributions are specific and falsifiable

2. Limitations Discussion

Papers should include a dedicated "Limitations" section addressing strong assumptions, robustness to violations, scope constraints, and performance-influencing factors.

What to include:

• [ ] Dedicated Limitations section
• [ ] Honest assessment of scope
• [ ] Conditions where method may fail

3. Theory & Proofs

Theoretical contributions require full assumption statements and complete proofs (main paper or appendix with proof sketches for intuition).

What to check:

• [ ] All assumptions stated formally
• [ ] Complete proofs provided (main text or appendix)
• [ ] Proof sketches for intuition in main text

4. Reproducibility

Authors must describe steps ensuring results verification through code release, detailed instructions, model access, or checkpoints appropriate to their contribution type.

What to provide:

• [ ] Clear reproducibility statement
• [ ] Code availability information
• [ ] Model checkpoints if applicable

5. Data & Code Access

Instructions for reproducing main experimental results should be provided (supplemental material or URLs), including exact commands and environment specifications.

What to include:

• [ ] Exact commands to run experiments
• [ ] Environment specifications (requirements.txt, conda env)
• [ ] Data access instructions

6. Experimental Details

Papers must specify training details: data splits, hyperparameters, and selection methods in the main paper or supplementary materials.

What to document:

• [ ] Train/val/test split details
• [ ] All hyperparameters used
• [ ] Hyperparameter selection method

7. Statistical Significance

Results require error bars, confidence intervals, or statistical tests with clearly stated calculation methods and underlying assumptions.

What to include:

• [ ] Error bars or confidence intervals
• [ ] Number of runs/seeds
• [ ] Calculation method (std dev vs std error)

8. Compute Resources

Specifications needed: compute worker types (CPU/GPU), memory, storage, execution time per run, and total project compute requirements.

What to document:

• [ ] GPU type and count
• [ ] Training time per run
• [ ] Total compute used

9. Ethics Code Compliance

Authors confirm adherence to the NeurIPS Code of Ethics, noting any necessary deviations.

What to verify:

• [ ] Read NeurIPS Code of Ethics
• [ ] Confirm compliance
• [ ] Note any deviations with justification

10. Broader Impacts

Discussion of potential negative societal applications, fairness concerns, privacy risks, and possible mitigation strategies when applicable.

What to address:

• [ ] Potential negative applications
• [ ] Fairness considerations
• [ ] Privacy implications
• [ ] Mitigation strategies

11. Safeguards

High-risk models (language models, internet-scraped datasets) require controlled release mechanisms and usage guidelines.

What to consider:

• [ ] Release strategy for sensitive models
• [ ] Usage guidelines if needed
• [ ] Access controls if appropriate

12. License Respect

All existing assets require creator citations, license names, URLs, version numbers, and terms-of-service acknowledgment.

What to document:

• [ ] Dataset licenses cited
• [ ] Code licenses respected
• [ ] Version numbers included

13. Asset Documentation

New releases need structured templates documenting training details, limitations, consent procedures, and licensing information.

For new datasets/models:

• [ ] Datasheet or model card
• [ ] Training data documentation
• [ ] Known limitations

14. Human Subjects

Crowdsourcing studies must include participant instructions, screenshots, compensation details, and comply with minimum wage requirements.

What to include:

• [ ] Task instructions
• [ ] Compensation details
• [ ] Time estimates

15. IRB Approvals

Human subjects research requires documented institutional review board approval or equivalent, with risk descriptions disclosed (maintaining anonymity at submission).

What to verify:

• [ ] IRB approval obtained
• [ ] Risk assessment completed
• [ ] Anonymized at submission

16. LLM Declaration

Usage of large language models as core methodology components requires disclosure; writing/editing use doesn't require declaration.

What to disclose:

• [ ] LLM used as core methodology component
• [ ] How LLM was used
• [ ] (Writing assistance doesn't require disclosure)

Response Format

Authors select "yes," "no," or "N/A" per question, with optional 1-2 sentence justifications.

Important: Reviewers are explicitly instructed not to penalize honest limitation acknowledgment.

---

ICML Paper Checklist

Broader Impact Statement

ICML requires a Broader Impact Statement at the end of the paper, before references. This does NOT count toward the page limit.

Required elements:

• Potential positive impacts
• Potential negative impacts
• Mitigation strategies
• Who may be affected

ICML Specific Requirements

Reproducibility Checklist

• [ ] Data splits clearly specified
• [ ] Hyperparameters listed
• [ ] Search ranges documented
• [ ] Selection method explained
• [ ] Compute resources specified
• [ ] Code availability stated

Statistical Reporting

• [ ] Error bars on all figures
• [ ] Standard deviation vs standard error specified
• [ ] Number of runs stated
• [ ] Significance tests if comparing methods

Anonymization

• [ ] No author names in paper
• [ ] No acknowledgments
• [ ] No grant numbers
• [ ] Prior work cited in third person
• [ ] No identifiable repository URLs

---

ICLR Requirements

LLM Disclosure Policy (New for 2026)

ICLR has a specific LLM disclosure requirement:

"If LLMs played a significant role in research ideation and/or writing to the extent that they could be regarded as a contributor, authors must describe their precise role in a separate appendix section."

When disclosure is required:

• LLM used for significant research ideation
• LLM used for substantial writing
• LLM could be considered a contributor

When disclosure is NOT required:

• Grammar checking
• Minor editing assistance
• Code completion tools

Consequences of non-disclosure:

• Desk rejection
• Potential post-publication issues

ICLR Specific Requirements

Reproducibility Statement (Optional but Recommended)

Add a statement referencing:

• Supporting materials
• Code availability
• Data availability
• Model checkpoints

Ethics Statement (Optional)

Address potential concerns in ≤1 page. Does not count toward page limit.

Reciprocal Reviewing

• Authors on 3+ papers must serve as reviewers for ≥6 papers
• Each submission needs ≥1 author registered to review ≥3 papers

---

ACL Requirements

Limitations Section (Mandatory)

ACL specifically requires a Limitations section:

What to include:

• Strong assumptions made
• Scope limitations
• When method may fail
• Generalization concerns

Important: The Limitations section does NOT count toward the page limit.

ACL Specific Checklist

Responsible NLP

• [ ] Bias considerations addressed
• [ ] Fairness evaluated if applicable
• [ ] Dual-use concerns discussed

Multilingual Considerations

If applicable:

• [ ] Language diversity addressed
• [ ] Non-English languages included
• [ ] Translation quality verified

Human Evaluation

If applicable:

• [ ] Annotator details provided
• [ ] Agreement metrics reported
• [ ] Compensation documented

---

Universal Pre-Submission Checklist

Before Every Submission

Paper Content

• [ ] Abstract ≤ word limit (usually 250-300 words)
• [ ] Main content within page limit
• [ ] References complete and verified
• [ ] Limitations section included
• [ ] All figures/tables have captions
• [ ] Captions are self-contained

Formatting

• [ ] Correct template used (venue + year specific)
• [ ] Margins not modified
• [ ] Font sizes not modified
• [ ] Double-blind requirements met
• [ ] Page numbers (for review) or none (camera-ready)

Technical

• [ ] All claims supported by evidence
• [ ] Error bars included
• [ ] Baselines appropriate
• [ ] Hyperparameters documented
• [ ] Compute resources stated

Reproducibility

• [ ] Code will be available (or justification)
• [ ] Data will be available (or justification)
• [ ] Environment documented
• [ ] Commands to reproduce provided

Ethics

• [ ] Broader impacts considered
• [ ] Limitations honestly stated
• [ ] Licenses respected
• [ ] IRB obtained if needed

Final Checks

• [ ] PDF compiles without errors
• [ ] All figures render correctly
• [ ] All citations resolve
• [ ] Supplementary material organized
• [ ] Conference checklist completed

---

Quick Reference: Page Limits

---

Template Locations

All conference templates are in the templates/ directory:

templates/
├── icml2026/       # ICML 2026 official
├── iclr2026/       # ICLR 2026 official
├── neurips2025/    # NeurIPS 2025
├── acl/            # ACL style files
├── aaai2026/       # AAAI 2026
└── colm2025/       # COLM 2025

Citation Management & Hallucination Prevention

This reference provides a complete workflow for managing citations programmatically, preventing AI-generated citation hallucinations, and maintaining clean bibliographies.

---

Contents

• Why Citation Verification Matters
• Citation APIs Overview
• Verified Citation Workflow
• Python Implementation
• BibTeX Management
• Common Citation Formats
• Troubleshooting

---

Why Citation Verification Matters

The Hallucination Problem

Research has documented significant issues with AI-generated citations:

• ~40% error rate in AI-generated citations (Enago Academy research)
• NeurIPS 2025 found 100+ hallucinated citations slipped through review
• Common errors include:
• Fabricated paper titles with real author names
• Wrong publication venues or years
• Non-existent papers with plausible metadata
• Incorrect DOIs or arXiv IDs

Consequences

• Desk rejection at some venues
• Loss of credibility with reviewers
• Potential retraction if published
• Wasted time chasing non-existent sources

Solution

Never generate citations from memory—always verify programmatically.

---

Citation APIs Overview

Primary APIs

API Selection Guide

Need ML paper search? → Semantic Scholar
Have DOI, need BibTeX? → CrossRef content negotiation
Looking for preprint? → arXiv API
Need open data, bulk access? → OpenAlex

No Official Google Scholar API

Google Scholar has no official API. Scraping violates ToS. Use SerpApi ($75-275/month) only if Semantic Scholar coverage is insufficient.

---

Verified Citation Workflow

5-Step Process

1. SEARCH → Query Semantic Scholar with specific keywords
     ↓
2. VERIFY → Confirm paper exists in 2+ sources
     ↓
3. RETRIEVE → Get BibTeX via DOI content negotiation
     ↓
4. VALIDATE → Confirm the claim appears in source
     ↓
5. ADD → Add verified entry to .bib file

Step 1: Search

Use Semantic Scholar for ML/AI papers:

from semanticscholar import SemanticScholar

sch = SemanticScholar()
results = sch.search_paper("transformer attention mechanism", limit=10)

for paper in results:
    print(f"Title: {paper.title}")
    print(f"Year: {paper.year}")
    print(f"DOI: {paper.externalIds.get('DOI', 'N/A')}")
    print(f"arXiv: {paper.externalIds.get('ArXiv', 'N/A')}")
    print(f"Citation count: {paper.citationCount}")
    print("---")

Step 2: Verify Existence

Confirm paper exists in at least two sources:

import requests

def verify_paper(doi=None, arxiv_id=None, title=None):
    """Verify paper exists in multiple sources."""
    sources_found = []

    # Check Semantic Scholar
    sch = SemanticScholar()
    if doi:
        paper = sch.get_paper(f"DOI:{doi}")
        if paper:
            sources_found.append("Semantic Scholar")

    # Check CrossRef (via DOI)
    if doi:
        resp = requests.get(f"https://api.crossref.org/works/{doi}")
        if resp.status_code == 200:
            sources_found.append("CrossRef")

    # Check arXiv
    if arxiv_id:
        resp = requests.get(
            f"http://export.arxiv.org/api/query?id_list={arxiv_id}"
        )
        if "<entry>" in resp.text:
            sources_found.append("arXiv")

    return len(sources_found) >= 2, sources_found

Step 3: Retrieve BibTeX

Use DOI content negotiation for guaranteed accuracy:

import requests

def doi_to_bibtex(doi: str) -> str:
    """Get verified BibTeX from DOI via CrossRef content negotiation."""
    response = requests.get(
        f"https://doi.org/{doi}",
        headers={"Accept": "application/x-bibtex"},
        allow_redirects=True
    )
    response.raise_for_status()
    return response.text

# Example: "Attention Is All You Need"
bibtex = doi_to_bibtex("10.48550/arXiv.1706.03762")
print(bibtex)

Step 4: Validate Claims

Before citing a paper for a specific claim, verify the claim exists:

def get_paper_abstract(doi):
    """Get abstract to verify claims."""
    sch = SemanticScholar()
    paper = sch.get_paper(f"DOI:{doi}")
    return paper.abstract if paper else None

# Verify claim appears in abstract
abstract = get_paper_abstract("10.48550/arXiv.1706.03762")
claim = "attention mechanism"
if claim.lower() in abstract.lower():
    print("Claim appears in paper")

Step 5: Add to Bibliography

Add verified entry to your .bib file with consistent key format:

def generate_citation_key(bibtex: str) -> str:
    """Generate consistent citation key: author_year_firstword."""
    import re

    # Extract author
    author_match = re.search(r'author\s*=\s*\{([^}]+)\}', bibtex, re.I)
    if author_match:
        first_author = author_match.group(1).split(',')[0].split()[-1]
    else:
        first_author = "unknown"

    # Extract year
    year_match = re.search(r'year\s*=\s*\{?(\d{4})\}?', bibtex, re.I)
    year = year_match.group(1) if year_match else "0000"

    # Extract title first word
    title_match = re.search(r'title\s*=\s*\{([^}]+)\}', bibtex, re.I)
    if title_match:
        first_word = title_match.group(1).split()[0].lower()
        first_word = re.sub(r'[^a-z]', '', first_word)
    else:
        first_word = "paper"

    return f"{first_author.lower()}_{year}_{first_word}"

---

Python Implementation

Complete Citation Manager Class

"""
Citation Manager - Verified citation workflow for ML papers.
"""

import requests
import time
from typing import Optional, List, Dict, Tuple
from dataclasses import dataclass

try:
    from semanticscholar import SemanticScholar
except ImportError:
    print("Install: pip install semanticscholar")
    SemanticScholar = None

@dataclass
class Paper:
    title: str
    authors: List[str]
    year: int
    doi: Optional[str]
    arxiv_id: Optional[str]
    venue: Optional[str]
    citation_count: int
    abstract: Optional[str]

class CitationManager:
    """Manage citations with verification."""

    def __init__(self, api_key: Optional[str] = None):
        self.sch = SemanticScholar(api_key=api_key) if SemanticScholar else None
        self.verified_papers: Dict[str, Paper] = {}

    def search(self, query: str, limit: int = 10) -> List[Paper]:
        """Search for papers using Semantic Scholar."""
        if not self.sch:
            raise RuntimeError("Semantic Scholar not available")

        results = self.sch.search_paper(query, limit=limit)
        papers = []

        for r in results:
            paper = Paper(
                title=r.title,
                authors=[a.name for a in (r.authors or [])],
                year=r.year or 0,
                doi=r.externalIds.get('DOI') if r.externalIds else None,
                arxiv_id=r.externalIds.get('ArXiv') if r.externalIds else None,
                venue=r.venue,
                citation_count=r.citationCount or 0,
                abstract=r.abstract
            )
            papers.append(paper)

        return papers

    def verify(self, paper: Paper) -> Tuple[bool, List[str]]:
        """Verify paper exists in multiple sources."""
        sources = []

        # Already found in Semantic Scholar via search
        sources.append("Semantic Scholar")

        # Check CrossRef if DOI available
        if paper.doi:
            try:
                resp = requests.get(
                    f"https://api.crossref.org/works/{paper.doi}",
                    timeout=10
                )
                if resp.status_code == 200:
                    sources.append("CrossRef")
            except:
                pass

        # Check arXiv if ID available
        if paper.arxiv_id:
            try:
                resp = requests.get(
                    f"http://export.arxiv.org/api/query?id_list={paper.arxiv_id}",
                    timeout=10
                )
                if "<entry>" in resp.text and "<title>" in resp.text:
                    sources.append("arXiv")
            except:
                pass

        return len(sources) >= 2, sources

    def get_bibtex(self, paper: Paper) -> Optional[str]:
        """Get BibTeX for verified paper."""
        if paper.doi:
            try:
                resp = requests.get(
                    f"https://doi.org/{paper.doi}",
                    headers={"Accept": "application/x-bibtex"},
                    timeout=10,
                    allow_redirects=True
                )
                if resp.status_code == 200:
                    return resp.text
            except:
                pass

        # Fallback: generate from paper data
        return self._generate_bibtex(paper)

    def _generate_bibtex(self, paper: Paper) -> str:
        """Generate BibTeX from paper metadata."""
        # Generate citation key
        first_author = paper.authors[0].split()[-1] if paper.authors else "unknown"
        first_word = paper.title.split()[0].lower().replace(',', '').replace(':', '')
        key = f"{first_author.lower()}_{paper.year}_{first_word}"

        # Format authors
        authors = " and ".join(paper.authors) if paper.authors else "Unknown"

        bibtex = f"""@article{{{key},
  title = {{{paper.title}}},
  author = {{{authors}}},
  year = {{{paper.year}}},
  {'doi = {' + paper.doi + '},' if paper.doi else ''}
  {'eprint = {' + paper.arxiv_id + '},' if paper.arxiv_id else ''}
  {'journal = {' + paper.venue + '},' if paper.venue else ''}
}}"""
        return bibtex

    def cite(self, query: str) -> Optional[str]:
        """Full workflow: search, verify, return BibTeX."""
        # Search
        papers = self.search(query, limit=5)
        if not papers:
            return None

        # Take top result
        paper = papers[0]

        # Verify
        verified, sources = self.verify(paper)
        if not verified:
            print(f"Warning: Could only verify in {sources}")

        # Get BibTeX
        bibtex = self.get_bibtex(paper)

        # Cache
        if bibtex:
            self.verified_papers[paper.title] = paper

        return bibtex


# Usage example
if __name__ == "__main__":
    cm = CitationManager()

    # Search and cite
    bibtex = cm.cite("attention is all you need transformer")
    if bibtex:
        print(bibtex)

Quick Functions

def quick_cite(query: str) -> str:
    """One-liner citation."""
    cm = CitationManager()
    return cm.cite(query)

def batch_cite(queries: List[str], output_file: str = "references.bib"):
    """Cite multiple papers and save to file."""
    cm = CitationManager()
    bibtex_entries = []

    for query in queries:
        print(f"Processing: {query}")
        bibtex = cm.cite(query)
        if bibtex:
            bibtex_entries.append(bibtex)
        time.sleep(1)  # Rate limiting

    with open(output_file, 'w') as f:
        f.write("\n\n".join(bibtex_entries))

    print(f"Saved {len(bibtex_entries)} citations to {output_file}")

---

BibTeX Management

BibTeX vs BibLaTeX

Recommendation: Use BibLaTeX with Biber for new papers.

LaTeX Setup

% In preamble
\usepackage[
    backend=biber,
    style=numeric,
    sorting=none
]{biblatex}
\addbibresource{references.bib}

% In document
\cite{vaswani_2017_attention}

% At end
\printbibliography

Citation Commands

\cite{key}      % Numeric: [1]
\citep{key}     % Parenthetical: (Author, 2020)
\citet{key}     % Textual: Author (2020)
\citeauthor{key} % Just author name
\citeyear{key}  % Just year

Consistent Citation Keys

Use format: author_year_firstword

vaswani_2017_attention
devlin_2019_bert
brown_2020_language

---

Common Citation Formats

Conference Paper

@inproceedings{vaswani_2017_attention,
  title = {Attention Is All You Need},
  author = {Vaswani, Ashish and Shazeer, Noam and Parmar, Niki and
            Uszkoreit, Jakob and Jones, Llion and Gomez, Aidan N and
            Kaiser, Lukasz and Polosukhin, Illia},
  booktitle = {Advances in Neural Information Processing Systems},
  volume = {30},
  year = {2017},
  publisher = {Curran Associates, Inc.}
}

Journal Article

@article{hochreiter_1997_long,
  title = {Long Short-Term Memory},
  author = {Hochreiter, Sepp and Schmidhuber, J{\"u}rgen},
  journal = {Neural Computation},
  volume = {9},
  number = {8},
  pages = {1735--1780},
  year = {1997},
  publisher = {MIT Press}
}

arXiv Preprint

@misc{brown_2020_language,
  title = {Language Models are Few-Shot Learners},
  author = {Brown, Tom and Mann, Benjamin and Ryder, Nick and others},
  year = {2020},
  eprint = {2005.14165},
  archiveprefix = {arXiv},
  primaryclass = {cs.CL}
}

---

Troubleshooting

Common Issues

Issue: Semantic Scholar returns no results

• Try more specific keywords
• Check spelling of author names
• Use quotation marks for exact phrases

Issue: DOI doesn't resolve to BibTeX

• DOI may be registered but not linked to CrossRef
• Try arXiv ID instead if available
• Generate BibTeX from metadata manually

Issue: Rate limiting errors

• Add delays between requests (1-3 seconds)
• Use API key if available
• Cache results to avoid repeat queries

Issue: Encoding problems in BibTeX

• Use proper LaTeX escaping: {\"u} for ü
• Ensure file is UTF-8 encoded
• Use BibLaTeX with Biber for better Unicode

Verification Checklist

Before adding a citation:

• [ ] Paper found in at least 2 sources
• [ ] DOI or arXiv ID verified
• [ ] BibTeX retrieved (not generated from memory)
• [ ] Entry type correct (@inproceedings vs @article)
• [ ] Author names complete and correctly formatted
• [ ] Year and venue verified
• [ ] Citation key follows consistent format

---

Additional Resources

APIs:

• Semantic Scholar: https://api.semanticscholar.org/api-docs/
• CrossRef: https://www.crossref.org/documentation/retrieve-metadata/rest-api/
• arXiv: https://info.arxiv.org/help/api/basics.html
• OpenAlex: https://docs.openalex.org/

Python Libraries:

• semanticscholar: https://pypi.org/project/semanticscholar/
• arxiv: https://pypi.org/project/arxiv/
• habanero (CrossRef): https://github.com/sckott/habanero

Verification Tools:

• Citely: https://citely.ai/citation-checker
• ReciteWorks: https://reciteworks.com/

Design Simplification Papers: Less Is More

Source: Kaiming He et al., "Exploring Plain Vision Transformer Backbones for Object Detection" (ViTDet, 2022)

Paper Type: Design simplification / Minimal adaptations paper

Core Pattern: Challenge design assumptions → Minimize changes → Surprising effectiveness → Fair comparison

---

1. Abstract Structure: The "Surprisingly" Framework

Pattern: Conventional Practice → Simple Alternative → Unexpected Results

Template:

Abstract:
1. [Context] Standard practice in [domain] is [conventional design]
2. [Challenge] With [new technology], this faces [challenges]
3. [Common Solution] Most work addresses this by [abandoning philosophy / adding complexity]
4. [Our Direction] We explore [different direction]: [minimal approach]
5. [Surprisingly 1] Surprisingly, we observe: (i) [simple finding 1]
   and (ii) [simple finding 2]
6. [Surprisingly 2] More surprisingly, [stronger claim under conditions]
7. [Implications] This enables [benefit] without [traditional requirement]

ViTDet Abstract Example (annotated):

Modern object detectors consist of hierarchical backbone feature extractors
and detection-specific necks/heads (e.g., FPN, RPN).

With Vision Transformers (ViT) emerging as powerful backbones, their plain,
non-hierarchical nature poses challenges: How to address multi-scale objects?

One solution abandons the plain ViT philosophy, re-introducing hierarchical
designs (e.g., Swin).

We pursue a different direction: plain ViT backbones with minimal adaptations.

Surprisingly, we observe: (i) A simple feature pyramid from a single-scale map
is sufficient (without FPN), and (ii) Window attention without shifting is
sufficient (with a few propagation blocks).

More surprisingly, under some circumstances, our ViTDet can compete with
leading hierarchical detectors like Swin.

With MAE pre-training, ViTDet outperforms hierarchical counterparts,
especially for larger models.

This decouples pre-training from fine-tuning, maintaining independence of
upstream vs downstream tasks.

Key Techniques:

1. "Modern...consist of..." - Establish conventional practice 2. "With...emerging as..." - New technology, new challenge 3. "abandons the...philosophy" - Critique common solutions 4. "We pursue a different direction" - Clear positioning 5. "Surprisingly, we observe: (i)... and (ii)..." - First surprise 6. "More surprisingly..." - Second, deeper surprise 7. "under some circumstances" - Measured claim 8. "sufficient" - Scientific (not "optimal") 9. "without [common practice]" - Negative emphasis

---

2. Introduction: The "Challenge Assumptions" Framework

Pattern: Tradition → New Challenge → Common Compromise → Your Alternative → Philosophy

Structure:

1. [Traditional Practice] Established design in [field]
2. [Evolution] How this emerged historically ("For a long while...")
3. [New Challenge] [New technology] with [different characteristics]
4. [Philosophy Clash] Original [tech] has "'minimalist' pursuit"
   - Questions: "How can we...?" "Is [X] too inefficient?"
5. [Common Solution] One solution: [abandon philosophy] → [revert to old design]
   - Acknowledge: "has shown successful results"
6. [Your Direction] "we pursue a different direction"
   - Motivation: "If successful, enables [benefit]"
7. [Philosophy] "in part follows the [philosophy] of '[concept]'"
8. [Surprising Findings] "Surprisingly, we observe..."
9. [Implications] "More surprisingly..." → Competitive results

ViTDet Introduction Flow:

Traditional Practice (Establish Context)

Modern object detectors in general consist of a backbone feature extractor
that is agnostic to the detection task and a set of necks and heads that
incorporate detection-specific prior knowledge.

Common components in the necks/heads may include Region-of-Interest (RoI)
operations, Region Proposal Networks (RPN) or anchors, Feature Pyramid
Networks (FPN), etc.

Technique:

• "in general consist of" - Standard architecture
• "agnostic to" vs "detection-specific" - Clear division
• "may include" - Examples, not exhaustive

Historical Evolution

For a long while, these backbones have been multi-scale, hierarchical
architectures due to the de facto design of convolutional networks (ConvNet),
which has heavily influenced the neck/head design for detecting objects at
multiple scales (e.g., FPN).

Technique:

• "For a long while" - Historical dimension
• "due to...which has heavily influenced" - Causal chain
• "de facto design" - Established convention

New Technology Challenge

Over the past year, Vision Transformers (ViT) have been established as a
powerful backbone for visual recognition.

Unlike typical ConvNets, the original ViT is a plain, non-hierarchical
architecture that maintains a single-scale feature map throughout.

Its 'minimalist' pursuit is met with challenges when applied to object
detection—e.g., How can we address multi-scale objects in a downstream task
with a plain backbone from upstream pre-training? Is a plain ViT too
inefficient to use with high-resolution detection images?

Technique:

• "Over the past year...have been established as" - Timeframe
• "Unlike typical ConvNets" - Direct contrast
• "plain, non-hierarchical", "single-scale" - Key characteristics
• "'minimalist' pursuit" - Philosophy (in quotes)
• Two questions: Challenge reader to think

Common Solution (Acknowledge then Pivot)

One solution, which abandons this pursuit, is to re-introduce hierarchical
designs into the backbone.

This solution, e.g., Swin Transformers and related works, can inherit the
ConvNet-based detector design and has shown successful results.

Technique:

• "which abandons this pursuit" - Critique (respectful)
• "can inherit" - Acknowledge advantage
• "has shown successful results" - Don't deny effectiveness

Your Different Direction

In this work, we pursue a different direction: we explore object detectors
that use only plain, non-hierarchical backbones.

If this direction is successful, it will enable the use of original ViT
backbones for object detection; this will decouple the pre-training design
from the fine-tuning demands, maintaining the independence of upstream vs.
downstream tasks, as has been the case for ConvNet-based research.

Technique:

• "we pursue a different direction" - Clear positioning
• "If this direction is successful, it will enable..." - Motivation
• "decouple", "independence" - Philosophy keywords
• "as has been the case for..." - Historical precedent

Philosophy Elevation

This direction also in part follows the ViT philosophy of 'fewer inductive
biases' in the pursuit of universal features.

As the non-local self-attention computation can learn translation-equivariant
features, they may also learn scale-equivariant features from certain forms
of supervised or self-supervised pre-training.

Technique:

• "in part follows the...philosophy of" - Theoretical connection
• "fewer inductive biases" - Core concept
• Analogy: translation-equivariant → scale-equivariant
• "may also learn" - Speculation (honest)

Surprising Findings

Surprisingly, we observe: (i) it is sufficient to build a simple feature
pyramid from a single-scale feature map (without the common FPN design) and
(ii) it is sufficient to use window attention (without shifting) aided with
very few cross-window propagation blocks.

Technique:

• "Surprisingly, we observe:" - Marker
• (i) and (ii) - Structured list
• "sufficient to" - Not "optimal", scientific phrasing
• "without the common [X]" - Negative differentiation

Deeper Surprise

More surprisingly, under some circumstances, our plain-backbone detector,
named ViTDet, can compete with the leading hierarchical-backbone detectors
(e.g., Swin, MViT).

With Masked Autoencoder (MAE) pre-training, our plain-backbone detector can
outperform the hierarchical counterparts that are pre-trained on ImageNet-1K/21K
with supervision (Figure 3).

The gains are more prominent for larger model sizes.

Technique:

• "More surprisingly" - Progressive emphasis
• "under some circumstances" - Measured claim
• "named ViTDet" - Brand at results
• Specific comparison: MAE vs ImageNet supervised
• "The gains are more prominent for..." - Pattern observation

---

3. Methods Section: The "Minimal Adaptations" Narrative

Pattern: We Don't Aim to Invent, We Minimize

Structure:

1. [Declaration] We do NOT aim to develop new components
2. [Philosophy] Instead, make minimal adaptations sufficient to overcome challenges
3. [Specific] In particular, [what we actually do]
4. [Abandonment] This abandons [traditional component]
5. [Decoupling] Adaptations only during fine-tuning, do not alter pre-training
6. [Contrast] This is in contrast to [recent methods] that [what they do]
7. [Benefit] Our scenario enables [benefit], without [cost]

ViTDet Methods Narrative:

In our study, we do not aim to develop new components; instead, we make
minimal adaptations that are sufficient to overcome the aforementioned
challenges.

In particular, our detector builds a simple feature pyramid from only the
last feature map of a plain ViT backbone (Figure 1).

This abandons the FPN design and waives the requirement of a hierarchical
backbone.

These adaptations are made only during fine-tuning and do not alter pre-training.

This is in contrast to the recent methods that modify the attention computation
directly with backbone pre-training (e.g., Swin, MViT).

Our scenario enables us to use the original ViT backbone for detection, without
redesigning pre-training architectures.

Techniques:

• "we do not aim to develop new components" - Clear scope
• "minimal adaptations" - Philosophy
• "sufficient to" - Not maximal, necessary
• "This abandons..." - What you give up
• "only during fine-tuning" - Temporal boundary
• "do not alter pre-training" - Upstream independence
• "This is in contrast to" - Competitor positioning
• "enables us to use" - Practical benefit

---

4. Fair Comparison: The "Equal Effort" Declaration

Pattern: Admit Complexity → Claim Effort → Demonstrate Fairness

Structure:

1. [Admit] Modern systems involve [complexity]
2. [Claim] To compare as fairly as possible, we [effort]
3. [Specific 1] Use same [implementation] for all
4. [Specific 2] Different backbones get [appropriate treatment]
5. [Validation] Our results for [competitor] are [better/equal] to original
6. [Implication] Since we reproduce others well, comparisons are fair

ViTDet Fair Comparison Statement:

Modern detection systems involve many implementation details and subtleties.

To focus on comparing backbones under as fair conditions as possible, we
incorporate the Swin and MViTv2 backbones into our implementation.

We use the same implementation of Mask R-CNN and Cascade Mask R-CNN for all
ViT, Swin, and MViTv2 backbones.

We use FPN for the hierarchical backbones of Swin/MViTv2.

We search for optimal hyper-parameters separately for each backbone.

Techniques:

• "involve many implementation details and subtleties" - Admit difficulty
• "under as fair conditions as possible" - Effort disclaimer
• "incorporate...into our implementation" - What we did
• "use the same...for all" - Unified framework
• "search for optimal...separately" - Equal effort

Self-Validation

Our Swin results are better than their counterparts in the original paper;
our MViTv2 results are better than or on par with those reported in the
original paper.

Technique:

• Report self-results → Show competence → Imply fairness

---

5. Results: Multi-Factor Analysis

Pattern: Factors, Trends, Wall-Clock Time

Structure:

1. [Acknowledge Complexity] Comparisons involve [factors]
2. [Identify Trend] Our method presents better [trend behavior]
3. [Qualify] When [condition], our method [advantage]
4. [Expand] Moreover, [second dimension advantage]
5. [Explain] as [reason related to simplicity]

ViTDet Results Narrative:

Figure 3 plots the trade-offs.

The comparisons here involve two factors: the backbone and the pre-training
strategy.

Our plain-backbone detector, combined with MAE pre-training, presents better
scaling behavior.

When the models are large, our method outperforms the hierarchical
counterparts of Swin/MViTv2, including those using IN-21K supervised
pre-training.

Moreover, the plain ViT has a better wall-clock performance (Figure 3 right),
as the simpler blocks are more hardware-friendly.

Techniques:

• "involve two factors" - Analysis depth
• "presents better scaling behavior" - Trend, not just points
• "When the models are large" - Qualify claim
• "Moreover" - Second dimension
• "better wall-clock performance" - Practical metric
• "simpler blocks are more hardware-friendly" - Explain why

---

6. "Surprisingly" Usage: Multi-Level Pattern

Level 1: Basic Surprise (Abstract)

Surprisingly, we observe: (i) [simple sufficient without common practice]
and (ii) [simple sufficient without common practice]

Characteristics:

• Two findings (i) and (ii)
• "sufficient" not "optimal"
• "without [common practice]"
• Structured presentation

Level 2: Competitive Surprise (Introduction)

More surprisingly, under some circumstances, our [method] can compete
with the leading [competitors].

Characteristics:

• "More surprisingly" - Progressive
• "under some circumstances" - Measured
• "compete with" - Not "beat", competitive
• Name competitors specifically

Level 3: Superiority Surprise (Introduction)

With [specific condition], our [method] can outperform the [competitors]
that use [stronger condition].

The gains are more prominent for [specific condition].

Characteristics:

• Specific conditions compared
• "outperform" - Stronger claim here
• Pattern observation: "more prominent for"
• Shows understanding of when/where

---

7. Ablation Study: Incremental + Destructive

Pattern: Baseline → Incremental Additions → Sufficient

Table Design:

Table X: [Component] Ablation
┌──────────────────────────────────────────┐
│ Baseline          | Metric  | Δ         │
├──────────────────────────────────────────┤
│ no [component]    | 47.8    | -         │
│ (a) [common]      | 50.3    | +2.5      │
│ (b) [variant]     | 50.9    | +3.1      │
│ (c) ours: simple  | 51.2    | +3.4 ✓   │
├──────────────────────────────────────────┤
│ Conclusion: Our simple [X] is sufficient  │
└──────────────────────────────────────────┘

ViTDet Table 1 Example:

pyramid design              APbox   APmask
─────────────────────────────────────────
no feature pyramid          47.8    42.5
(a) FPN, 4-stage           50.3    44.9
(b) FPN, last-map          50.9    45.3
(c) simple feature pyramid  51.2    45.5

Techniques:

• Baseline: "no [X]" shows it's needed
• (a), (b), (c): Progressive variations
• Δ标注: (+2.5) - Show incremental gains
• Conclusion text: "our simple pyramid is sufficient"

---

8. "Interestingly" Usage: Pattern + Explanation

Pattern: Observation → Literature Support → Explanation

Structure:

Interestingly, [observation].

This is in line with the observation in [paper] that [their finding].

[Additional explanation or hypothesis].

ViTDet Example:

Interestingly, performing propagation in the last 4 blocks is nearly as
good as even placement.

This is in line with the observation in ViT [14] that ViT has longer
attention distance in later blocks and is more localized in earlier ones.

Techniques:

• "Interestingly" - Marker for unexpected
• Observation: Specific finding
• "in line with the observation in" - Literature support
• Explanation: Why it makes sense

---

9. Minimalism Keywords: Design Simplification Vocabulary

Philosophy Keywords:

• "minimal" - "minimal adaptations"
• "sufficient" - "is sufficient to" (not "optimal")
• "simple" - "simple feature pyramid"
• "plain" - "plain backbone"
• "decouple" - "decouple pre-training from fine-tuning"
• "independence" - "independence of upstream vs downstream"

Direction Keywords:

• "pursue a different direction" - Positioning
• "in contrast to" - Differentiation
• "abandons" - What you give up
• "enables" - What your approach allows

Measured Claim Keywords:

• "under some circumstances" - Not always
• "can compete with" - Competitive, not dominant
• "more prominent for" - When effect is stronger
• "is sufficient" - Necessary, not maximal

Surprise Markers (use in order): 1. "Surprisingly" - First finding 2. "More surprisingly" - Deeper finding 3. "Interestingly" - Pattern observation 4. "Notably" - Important detail 5. "It is worth noting that" - Caveat/clarification

---

10. Common Mistakes in Design Simplification Papers

❌ Don't:

• Claim your method is "optimal" - You're simplifying, not optimizing
• Attack common practices - Acknowledge their value first
• Overgeneralize - "under some circumstances" is honest
• Forget to show fair comparison - Prove you tried hard with baselines
• Hide complexity - Admit what you don't address

✅ Do:

• Use "sufficient" instead of "optimal"
• Say what you DON'T do ("do not aim to develop new components")
• Emphasize minimal changes ("minimal adaptations")
• Report when your method wins and when it doesn't
• Show "surprisingly" findings with proper qualification
• Demonstrate fair comparison effort
• Adapt only where necessary (fine-tuning, not pre-training)

---

11. Revision Checklist for Design Simplification Papers

Before Submission, Verify:

• [ ] Abstract has "Surprisingly, we observe: (i)... and (ii)..."
• [ ] Introduction establishes conventional practice first
• [ ] Common solution is acknowledged ("has shown successful results")
• [ ] "We pursue a different direction" is stated clearly
• [ ] Philosophy is elevated ("fewer inductive biases")
• [ ] "More surprisingly" used for deeper claim
• [ ] Methods section says "we do not aim to develop new components"
• [ ] "minimal adaptations" philosophy stated
• [ ] "only during fine-tuning" boundary specified
• [ ] Fair comparison effort described explicitly
• [ ] Self-validation shown (our reproduction of others is good)
• [ ] Multi-factor analysis in results (scaling, wall-clock)
• [ ] Ablations show incremental progression
• [ ] "sufficient" used, not "optimal"
• [ ] Under what conditions is stated ("under some circumstances")

---

12. Example: Applying This Pattern

Original Idea (Not Design Simplification):

"We propose a new feature pyramid that improves detection AP by 3%."

Design Simplification Version:

"Modern detectors use hierarchical backbones with FPN. With plain ViT emerging as powerful backbones, a common solution re-introduces hierarchy (abandoning the plain philosophy). We pursue a different direction: plain backbones with minimal adaptations. Surprisingly, we observe a simple feature pyramid from a single-scale map is sufficient (without FPN). More surprisingly, with MAE pre-training, ViTDet competes with hierarchical detectors, especially for larger models. This decouples pre-training from fine-tuning, maintaining upstream/downstream independence."

The Design Simplification Frame:

• Conventional: Hierarchy + FPN
• Challenge: Plain ViT is...plain
• Common: Swin (abandons philosophy)
• Ours: Minimal adaptations
• Surprise: Simple is sufficient
• Philosophy: Decoupling, independence

---

Paper Metadata

Title: Exploring Plain Vision Transformer Backbones for Object Detection (ViTDet)

Authors: Yanghao Li, Hanzi Mao, Kaiming He

Venue: ECCV 2022

arXiv: 2203.16527

Key Concepts:

• Plain ViT for detection (no hierarchy needed)
• Simple feature pyramid (no FPN needed)
• Minimal adaptations philosophy
• Decoupling pre-training from fine-tuning
• MAE pre-training synergy

---

Extracted by

Date: 2026-01-26

Source: Analysis of ViTDet paper (21 pages)

Extraction Focus: Design simplification paper writing patterns, "surprisingly" findings reporting, minimal adaptations philosophy, fair comparison strategies

For Integration: ml-paper-writing skill knowledge base

Paper-Miner Writing Memory

This is the active installed writing memory maintained by paper-miner.

It stores reusable academic writing knowledge mined from papers across venues and projects.

Rules

• This is the only maintained paper-miner writing memory.
• paper-miner writes here even when invoked inside a specific project.
• Do not create project-specific paper-miner writing memory.
• Do not split new mined knowledge across multiple maintained category files.
• Keep source attribution explicit and avoid duplicate entries.

Writing patterns mined

<!-- paper-miner adds reusable rhetorical patterns here -->

Structure signals

<!-- paper-miner adds section-flow and organization signals here -->

Reusable phrasing

<!-- paper-miner adds concise reusable phrasing and transition templates here -->

Venue-specific signals

<!-- paper-miner adds venue-facing style and convention signals here -->

How this helps our writing

<!-- paper-miner explains how mined signals can inform future writing decisions here -->

Source index

<!-- one short source entry per analyzed paper -->

Academic Writing Knowledge Base

This knowledge base contains reusable academic writing knowledge mined from papers.

Canonical maintained memory

The canonical paper-miner memory is:

• paper-miner-writing-memory.md

This is the only maintained paper-miner writing memory.

It stores:

• writing patterns mined,
• structure signals,
• reusable phrasing,
• venue-specific signals,
• how those signals help future writing,
• and a source index.

Maintenance rule

paper-miner always writes mined writing knowledge into paper-miner-writing-memory.md.

This memory is:

• global,
• cross-project,
• not project-specific.

If paper-miner is invoked inside a project, it may use project context to understand relevance, but it still writes only to the global memory.

Legacy files

Older files such as:

• structure.md
• writing-techniques.md
• submission-guides.md
• review-response.md

may still exist as historical material, but new paper-miner updates should treat paper-miner-writing-memory.md as the canonical maintained memory.

Usage

Use this knowledge base when:

• drafting papers,
• improving section structure,
• borrowing reusable phrasing patterns,
• preparing rebuttals,
• studying venue-facing writing signals.

Contributing

When paper-miner analyzes a new paper: 1. extract actionable writing knowledge, 2. merge it into paper-miner-writing-memory.md, 3. preserve source attribution, 4. avoid duplicate patterns, 5. keep the memory compact and reusable.

Review Response and Rebuttal Strategies

This file contains effective strategies for responding to reviewer comments and addressing reviewer concerns, extracted from successful ML conference paper rebuttals.

---

General Rebuttal Principles

Core Philosophy

Source: Analysis of successful NeurIPS/ICML rebuttals

Key Principles: 1. Respectful tone: Thank reviewers for their time 2. Direct addressing: Respond point-by-point to each concern 3. Evidence-based: Support claims with data, experiments, or citations 4. Concise communication: Be clear but brief 5. No over-committing: Only promise what can be done

Response Structure

Template:

# Response to Reviewer [Number]

Thank you for this insightful comment. We [address the concern].

[Specific response to concern].

[Additional evidence/experiments if needed].

We have revised the manuscript to clarify this point (see changes marked in blue).

---

Addressing Specific Concerns

Concern: Clarity Issues

Strategy:

• Acknowledge the confusion
• Clarify with revised text
• Add examples if helpful

Template:

# Response to Clarity Concern

We apologize for the confusion. The original text was:

[Original unclear text]

We have revised this to:
"Revised text with clearer explanation"

We also added an example (Figure X) to illustrate this concept.

Real Example:

• Concern: "The algorithm description is unclear."
• Response: "We've rewritten Algorithm 1 with more detailed steps and added pseudocode. We also included a concrete example in Appendix B to illustrate the algorithm's execution."

Concern: Missing Experiments

Strategy:

• Assess whether experiment is feasible
• If yes: add experiment and report results
• If not: explain why experiment is not essential
• Offer alternative evidence if possible

Template:

# Response to Missing Experiment Request

We agree that [experiment] would strengthen the evaluation. We have:
[Option 1: Added experiment and results]
OR
[Option 2: Explained why not essential with alternative evidence]

We believe this addresses the concern while maintaining focus on our core contribution.

Real Example:

• Concern: "Add comparison with Method X on dataset Y."
• Response: "We've added results on dataset Y (Table 3). Our method outperforms Method X by 5%. We also include ablation showing our improvement comes from [feature], not just better optimization."

Concern: Statistical Significance

Strategy:

• Add statistical tests if appropriate
• Report confidence intervals
• Discuss practical significance vs statistical significance
• Note sample size limitations

Template:

# Response to Statistical Significance

We agree statistical testing is important. We have:
- Added paired t-test results showing significance (p<0.01)
- Included 95% confidence intervals in Figure 3
- Reported standard deviations across 5 runs
- Noted that while some differences are not statistically significant due to sample size, they are practically meaningful for [application]

We have updated Section 4.2 with these statistical details.

Concern: Insufficient Baselines

Strategy:

• Add missing baselines if available
• Explain why certain baselines are inappropriate
• Cite reasons for exclusions with references

Template:

# Response to Baseline Concern

We have added comparisons with:
- [Method A]: Added in Table 2
- [Method B]: Excluded because [reason with citation]

For Method B, while it seems related, it [specific reason why not comparable], making direct comparison inappropriate.

Concern: Writing Quality

Strategy:

• Revise problematic text
• Fix grammatical issues
• Improve flow and clarity
• Add signposting

Template:

# Response to Writing Concern

We've revised the writing to address your concerns:
- Restructured Section 3 for better flow
- Fixed typos and grammar
- Added transition sentences between paragraphs
- Clarified technical terminology

The revised manuscript has been proofread and edited for clarity.

Concern: Overclaiming

Strategy:

• Tone down absolute statements
• Add qualifications where appropriate
• Acknowledge limitations more explicitly
• Reframe claims to match evidence

Template:

# Response to Overclaiming Concern

We accept that our original claim was too strong. We have revised the text:

Original: "Our method achieves state-of-the-art on all tasks."
Revised: "Our method achieves state-of-the-art on [specific tasks] and competitive performance on [other tasks]."

We also added a Limitations section acknowledging that our method may not generalize to [condition].

---

Tone and Phrasing Patterns

Opening Statements

Thanking:

• "Thank you for this insightful comment."
• "We appreciate the reviewer's suggestion to..."
• "We thank the reviewer for pointing this out."

Acknowledging Valid Points:

• "The reviewer is right that..."
• "We agree this is a limitation."
• "This is an excellent suggestion."

Addressing Disagreements

Respectful Disagreement:

• "We respectfully disagree with this assessment based on..."
• "While we understand the concern, our results suggest..."
• "We believe our approach is justified because..."

Providing Evidence:

• "Our experimental results (Table 3) show..."
• "As shown in Figure 4, the difference is..."
• "This is supported by prior work [Citation]."

Making Commitments

Full Commitments:

• "We will add this experiment in the revised version."
• "We have added additional ablation studies in Section 5."

Partial Commitments:

• "We have added clarification in the appendix due to space constraints."
• "We've expanded discussion of this point in the revision."

Declining Requests:

• "Unfortunately, due to [constraint], we cannot add this experiment."
• "This would require substantial additional resources beyond our current scope."
• "We believe this is beyond the scope of the current paper but note it as future work."

---

Common Rebuttal Strategies

Strategy: Organized Response

Structure:

# Summary of Changes

We thank the reviewers for their constructive feedback. In this response, we:
- [Major change 1]
- [Major change 2]
- [Improvement 3]

We believe these changes have significantly strengthened the paper.

# Response to Reviewer 1

[Point-by-point responses]

# Response to Reviewer 2

[Point-by-point responses]

Strategy: Evidence-Based Arguments

Template:

# Response to Technical Concern

Our approach is valid because:
1. [Reason 1 with reference/evidence]
2. [Reason 2 with data/figure]
3. [Reason 3 with theoretical justification]

This is supported by [Citation], which demonstrates that [fact].

Strategy: Highlighting Improvements

Template:

# Major Revisions

1. **New Experiments**: Added comparison with [method] on [dataset]
2. **New Analysis**: Included ablation study in Table 4
3. **Clarified Writing**: Rewrote Section 3 for clarity
4. **Added Limitations**: New section 5.2 acknowledging constraints

These additions strengthen our core claims about [contribution].

---

Venue-Specific Considerations

NeurIPS

Emphasis:

• Novelty and conceptual contribution
• Broader impact (lay summary)
• Reproducibility checklist

Rebuttal Focus:

• How work advances understanding
• Significance of contribution
• Ethical considerations

ICML

Emphasis:

• Methodological rigor
• Theoretical contributions
• Broader impact statement

Rebuttal Focus:

• Soundness of methods
• Theoretical guarantees
• Practical implications

ICLR

Emphasis:

• Experimental thoroughness
• Limitations acknowledgment
• LLM usage disclosure

Rebuttal Focus:

• Comprehensive evaluation
• Honest limitation discussion
• Transparency about methods

ACL

Emphasis:

• Linguistic appropriateness
• Ethical considerations
• Clear limitations

Rebuttal Focus:

• Language quality and appropriateness
• Data provenance and ethics
• Practical utility

---

Tips for Successful Rebuttals

Before Writing

1. Understand the concerns: Read carefully, identify key issues 2. Prioritize: Address major concerns first 3. Be realistic: Only promise what can deliver 4. Gather evidence: Collect data, results, citations 5. Coordinate: Discuss with co-authors if applicable

While Writing

1. Be specific: Reference exact sections, figures, tables 2. Be concise: Keep responses focused and brief 3. Be respectful: Thank reviewers, acknowledge good points 4. Be confident: Defend your work appropriately 5. Be honest: Acknowledge limitations, don't overpromise

Common Mistakes to Avoid

• Defensive tone: Don't argue excessively
• Vague responses: Be specific about changes
• Ignoring concerns: Address every point
• Over-promising: Only commit to feasible additions
• Disorganized:
• Poor formatting: Use clear sections and structure
• Rude language: Maintain professional tone

---

Rebuttal Examples

Example 1: Clarity Concern

Reviewer: "The method description in Section 3 is unclear and hard to follow."

Response:

We apologize for the confusion. We have rewritten Section 3.2 to clarify our algorithm:

**Original:** "We process the data using our method and get results."

**Revised:** "Our method consists of three stages: (1) We first normalize the input
features using [technique]. (2) We then apply our core algorithm, which iteratively [process].
(3) Finally, we post-process the outputs using [method]."

We also added Algorithm 1 with detailed steps and included a concrete example in
Appendix A. We believe this revision makes the method reproducible and clear.

Example 2: Missing Baseline

Reviewer: "You should compare with Method X (Smith et al., 2022)."

Response:

Thank you for this suggestion. We have added comparisons with Method X in our
revised manuscript:

**Results in Table 3:** Our method achieves 92% accuracy compared to Method X's
85% on dataset Y. This 7% improvement demonstrates the value of our [key innovation].

**Ablation Study:** We show in Table 4 that our improvement comes specifically from
[feature], not just better optimization.

We chose not to include Method Z because [reason with citation].

Example 3: Overclaiming

Reviewer: "The abstract claims 'state-of-the-art' too broadly."

Response:

We accept this critique. Our original claim was too broad. We have revised the
abstract:

**Original:** "Our method achieves state-of-the-art performance across all tasks."

**Revised:** "Our method achieves state-of-the-art on [specific tasks A and B] (Table 1)
and competitive performance on [other tasks C and D] (Table 2)."

We also added a Limitations section (Section 5) noting that performance may vary
across domains and tasks.

---

Final Checklist

Before submitting rebuttal:

• [ ] All reviewer concerns addressed
• [ ] Responses are clear and specific
• [ ] Tone is respectful and professional
• [ ] Changes are marked in manuscript
• [ ] Evidence provided for claims
• [ ] Feasible commitments made
• [ ] Co-authors agree with responses
• [ ] Proofread for errors
• [ ] Check formatting requirements

---

Notes

• Learn from successful rebuttals: Read well-received papers' reviewer exchanges
• Practice humility: Acknowledge mistakes, show willingness to improve
• Focus on core contribution: Defend your main contribution without overclaiming
• Keep it concise: Reviewers are busy; be respectful of their time

Updates: This file is periodically updated with new strategies and examples from successful rebuttals.

Paper Structure Patterns

This file contains actionable patterns for organizing ML conference papers, extracted from successful publications.

---

Introduction Patterns

Pattern: Contribution Statement Structure

Source: "Attention Is All You Need", NeurIPS (2017) Context: Introducing the main contribution

Pattern: 1. Start with broader context or problem 2. Narrow down to specific limitation 3. Present your approach as solution 4. State clear contribution upfront

Example Template:

[Context/Problem]: Existing approaches struggle with [limitation] due to [reason].

[Our Approach]: We propose [method name], which [key innovation].

[Contribution]: This achieves [result] and enables [capability].

Application: Use this pattern when introducing your main contribution in the first or second paragraph of the introduction.

---

Pattern: Bulleted Contribution List

Source: "BERT: Pre-training of Deep Bidirectional Transformers", NAACL (2019) Context: Summarizing contributions for clarity

Pattern:

• Place near end of Introduction (after Related Work)
• Use 2-4 bullets
• Each bullet: 1-2 lines max (in two-column format)
• Start with strong verbs ("We propose", "We demonstrate", "We show")

Example Template:

Our contributions are three-fold:
- We propose [method], which achieves [result].
- We demonstrate that [technique] improves [metric].
- We show that [approach] enables [new capability].

Application: Use this when you need to clearly delineate multiple contributions for reviewers.

---

Pattern: Related Work Organization

Source: "Attention Is All You Need", NeurIPS (2017) Context: Structuring literature review

Pattern:

• Organize methodologically, not chronologically
• Group papers by approach/assumption
• Contrast your approach with each group
• Use "One line of work uses X whereas we use Y because..."

Example Template:

[Approach Category]: Several approaches use [assumption A] [refs].
[Contrast]: We adopt [assumption B] because it allows [benefit].

[Alternative Category]: Other methods focus on [aspect C] [refs].
[Positioning]: We build on this by adding [our innovation].

Application: Use this to position your work relative to existing literature without paper-by-paper reviews.

---

Methods Section Patterns

Pattern: Algorithm Presentation

Source: "Adam: A Method for Stochastic Optimization", ICLR (2015) Context: Describing algorithms clearly

Pattern: 1. High-level overview first 2. Mathematical formulation 3. Algorithm pseudocode (if complex) 4. Implementation details

Example Template:

[Overview]: We formulate [problem] as optimization. Let [objective] be our goal.

[Method]: Our approach optimizes [objective] using [technique].
Specifically, we [algorithm description].

[Algorithm]: The full procedure is shown in Algorithm 1.

[Implementation]: In practice, we [practical details].

Application: Use this when presenting novel algorithms or optimization methods.

---

Pattern: Component Breakdown

Source: "BERT: Pre-training of Deep Bidirectional Transformers", NAACL (2019) Context: Describing multi-component systems

Pattern:

• Present model architecture first
• Break down into key components
• Explain each component's role
• Show how components interact

Example Template:

[Architecture]: Our model consists of [N components]: [list].

[Component 1]: The [component] module [function].
[Component 2]: The [component] layer [operation].

[Integration]: These components are stacked sequentially, with [connection pattern].

Application: Use this when describing complex architectures with multiple interacting parts.

---

Results Section Patterns

Pattern: Quantitative Opening

Source: "BERT: Pre-training of Deep Bidirectional Transformers", NAACL (2019) Context: Presenting main findings

Pattern:

• Start with strongest quantitative result
• Use exact numbers and metrics
• Include comparison to baselines
• State statistical significance

Example Template:

[Main Result]: Our method achieves [score] on [dataset], improving
over the previous best of [baseline] by [margin] (p<0.001).

[Comparison]: Compared to baselines:
- [Method A]: [score]
- [Method B]: [score]
- Ours: [score]

[Significance]: Results are averaged over N runs; standard deviations shown in parentheses.

Application: Use this to open your Results section with your strongest finding.

---

Pattern: Table Integration

Source: "Attention Is All All You Need", NeurIPS (2017) Context: Presenting results in tables

Pattern:

• Bold best results in each column
• Include direction indicators (↑↓)
• Provide table caption that stands alone
• Reference table in text before presenting

Example Template:

Table 1 shows our method's performance. Our model (bold) outperforms
all baselines across datasets.

[Table content]

As shown in Table 1, we achieve state-of-the-art on [datasets].

Application: Use this when presenting comparative results in table format.

---

Discussion Section Patterns

Pattern: Limitations First

Source: "Attention Is All You Need", NeurIPS (2017) Context: Acknowledging limitations proactively

Pattern:

• State limitations clearly in first paragraph
• Explain why limitations don't undermine core claims
• Distinguish between limitations and future work

Example Template:

[Limitation Statement]: Our approach has [limitation]. Specifically,
[constraint].

[Mitigation]: Despite this, our core findings about [main contribution] remain
valid because [reason].

[Future Work]: Addressing this limitation is an important direction for
future research.

Application: Use this to acknowledge limitations honestly while maintaining paper strength.

---

Pattern: Broader Impact Framing

Source: "Language Models are Few-Shot Learners", GPT-3 Paper (2020) Context: Discussing wider implications

Pattern:

• Start with direct implications
• Expand to related domains
• Consider societal impact (if appropriate)
• End with forward-looking statement

Example Template:

[Direct Impact]: Our findings suggest that [implication for domain].

[Broader Implications]: Beyond [specific domain], this approach could
enable [application in other areas].

[Future Outlook]: As [trend] continues, methods like ours will become
increasingly important for [reason].

Application: Use this when writing the final paragraphs of Discussion or Conclusion.

---

Transition Patterns

Pattern: Section Transitions

Source: "Attention Is All You Need", NeurIPS (2017) Context: Moving between sections

Pattern:

• Introduction → Methods: "We now describe our approach."
• Methods → Results: "We evaluate our method on [tasks]."
• Results → Discussion: "These results suggest that [insight]."

Example Template:

[Transition to Methods]: Having established [motivation], we present
our method.

[Transition to Results]: To validate our approach, we conduct experiments
on [datasets].

[Transition to Discussion]: The experimental results reveal several insights
about [phenomenon], which we discuss next.

Application: Use these to create smooth transitions between major sections.

---

Notes

• Consistency: Maintain consistent terminology throughout the paper
• Flow: Each section should logically lead to the next
• Clarity: Make structure explicit with signposting
• Audience: Write for tired reviewers - make their job easy

何凯明（Kaiming He）的论文结构模式

来源: 分析了何凯明的 19 篇代表性论文

添加时间: {datetime.now().strftime('%Y-%m-%d')}

摘要结构模式

何凯明在摘要中常用的开场模式：

模式 1: 直接陈述贡献

We introduce [method name], a [key feature] framework for [task].
We show that [method] achieves [result] on [dataset].

模式 2: 问题-解决方案

[Problem] is difficult for [task]. We present [solution]
that addresses this by [key mechanism].

示例 (来自 ResNet):

Deeper neural networks are more difficult to train. We present a
residual learning framework to ease the training of networks that
are substantially deeper than those used previously.

引言结构模式

三段式引言: 1. 问题陈述 (2-3段) - 描述挑战和现有方法 2. 方法概述 (1-2段) - 简洁介绍解决方案 3. 主要贡献 (1段) - 列表形式，每条 1-2 行

贡献列表模式:

- 我们提出了 [方法]，解决了 [问题]
- 我们展示了 [方法] 在 [数据集] 上的 [性能提升]
- 我们证明了 [原理] 是有效的

方法部分结构

何凯明的方法部分通常包含：

1. 符号定义 - 清晰定义所有变量和符号 2. 问题形式化 - 数学公式表达 3. 方法描述 - 逐步算法解释 4. 实现细节 - 网络架构、训练设置

常用句式:

• "Let us consider [变量] as [定义]"
• "Formally, we define [公式]"
• "We hypothesize that [假设]"
• "To the extreme, [极端情况]"

实验部分结构

1. 实验设置 - 数据集、评价指标、实现细节 2. 主要结果 - 核心性能对比 3. 消融实验 - 组件分析 4. 可视化分析 - 图表展示

结果描述模式:

• "Table X shows that [结果]"
• "Fig. Y illustrates that [观察]"
• "Our method achieves [指标] on [任务]"
• "This represents a [X]% improvement over baseline"

相关工作部分组织

何凯明倾向于主题式组织而非时间顺序：

好的组织方式:

• "One line of work uses [方法A] [引用], whereas we use [方法B]"
• "[方法A] [引用] assumes [假设], but we show [反驳]"

避免:

• "X et al. introduced [方法]. Y et al. improved [方法]"

Submission Guides and Venue Requirements

This file contains venue-specific submission requirements, formatting guidelines, and checklist items extracted from ML conference and journal publications.

---

NeurIPS Requirements

Format Requirements

Source: NeurIPS 2025 Conference Guidelines

Page Limits:

• Main paper: 9 pages (excluding references)
• References: Unlimited (don't count toward page limit)
• Appendices: Allowed but reviewers not required to read

Required Sections:

• Abstract: 150-250 words
• Introduction: Must clearly state contribution
• Methods: Sufficient for reproduction
• Experiments: Comprehensive evaluation
• Discussion: Interpret results and limitations
• References: Complete citations
• Checklist: Mandatory submission checklist (16 items)
• Lay Summary: Required for accepted papers (1 page, non-technical)

Formatting:

• Double-blind review (anonymize submissions)
• LaTeX template required
• 9pt font, two-column format
• Margins: 1 inch on all sides

Submission Checklist Items: 1. Do the main claims of the paper match the checklist? 2. Have you checked the checklist for missing items? 3. Is the paper anonymized? 4. Are all figures/tables clear and readable? 5. Have you included code and data availability statements? 6. Are all equations properly formatted? 7. Is the abstract within word limit? 8. Are all citations complete and correct? 9. Have you addressed potential ethical concerns? 10. Are experimental settings clearly described? 11. Is statistical significance properly reported? 12. Have you included limitations? 13. Is the broader impact discussed (if required)? 14. Are all figures referenced in text? 15. Is the supplementary material well-organized? 16. Have you proofread for typos and grammar?

---

ICML Requirements

Format Requirements

Source: ICML 2026 Conference Guidelines

Page Limits:

• Main paper: 8 pages
• Camera-ready: +1 page (9 total)
• References: Unlimited (don't count toward page limit)

Required Sections:

• Abstract: Clear summary of contribution
• Introduction: Problem and contribution
• Methods: Complete description
• Experiments: Thorough evaluation
• Broader Impact Statement: Required (after conclusion)
• References: Complete citations

Formatting:

• Double-blind review (anonymize submissions)
• LaTeX template required
• Two-column format
• Margins as per template

Broader Impact Statement:

• Discuss positive and negative societal impacts
• Consider biases, fairness, environmental impact
• 1 page maximum
• Required for all submissions

---

ICLR Requirements

Format Requirements

Source: ICLR 2026 Conference Guidelines

Page Limits:

• Main paper: 9 pages
• Camera-ready: +1 page (10 total)
• References: Unlimited (don't count toward page limit)

Required Sections:

• Abstract: Summary of contribution
• Introduction: Clear problem statement
• Methods: Reproducible description
• Experiments: Comprehensive evaluation
• Limitations Section: MANDATORY
• LLM Disclosure: Required if using LLMs
• References: Complete citations

Formatting:

• Double-blind review (anonymize submissions)
• LaTeX template required
• Two-column format

LLM Disclosure Requirements:

• Describe LLM use in the paper
• Include model details (architecture, training data, compute)
• Acknowledge LLM limitations
• Note any automated text generation

---

ACL Requirements

Format Requirements

Source: ACL 2025 Conference Guidelines

Page Limits:

• Main paper: 8 pages (long papers)
• Short papers: 4 pages
• References: Unlimited (don't count toward page limit)

Required Sections:

• Abstract: 150-200 words
• Introduction: Background and contribution
• Methods: Technical description
• Experiments: Evaluation
• Limitations Section: MANDATORY
• Ethics Statement: Required if applicable
• References: Complete citations

Formatting:

• Double-blind review (anonymize submissions)
• LaTeX template required (ACL style files)
• Two-column format

Ethics Considerations:

• Human subjects research: IRB approval required
• Data privacy: Anonymization and consent
• Environmental impact: Compute resource usage

---

AAAI Requirements

Format Requirements

Source: AAAI 2026 Conference Guidelines

Page Limits:

• Main paper: 7 pages
• Camera-ready: +1 page (8 total)
• References: Unlimited (don't count toward page limit)

Required Sections:

• Abstract: 150-250 words
• Introduction: Problem and contribution
• Methods: Technical description
• Experiments: Evaluation
• References: Complete citations

Formatting:

• Double-blind review (anonymize submissions)
• Strict style file adherence: Must use official template
• Two-column format
• No modifications to style files

Strict Requirements:

• Follow AAAI template exactly
• No custom formatting beyond template
• Font sizes and margins as specified
• Page limits strictly enforced

---

COLM Requirements

Format Requirements

Source: COLM 2025 Conference Guidelines

Page Limits:

• Main paper: 9 pages
• Camera-ready: +1 page (10 total)
• References: Unlimited (don't count toward page limit)

Required Sections:

• Abstract: Summary of contribution
• Introduction: Problem and contribution
• Methods: Technical description
• Experiments: Evaluation
• Focus: Language models specifically
• References: Complete citations

Formatting:

• Double-blind review (anonymize submissions)
• LaTeX template required
• Two-column format

Language Model Focus:

• Papers should address language model challenges
• Method contributions applicable to LM community
• Experimental setup relevant to language tasks

---

Common Submission Requirements

Double-Blind Review

Applies to: NeurIPS, ICML, ICLR, ACL, AAAI, COLM

Requirements:

• Remove author names and affiliations
• Anonymize citations to own work (use [Anonymous, 2024])
• Remove acknowledgments that reveal identity
• Avoid distinctive phrases that identify authors
• Supplementary materials must also be anonymized

Common Mistakes:

• Forgetting to anonymize GitHub links
• Including author names in file paths
• Thanking specific colleagues in acknowledgments
• Citing own work with author names

Code and Data Availability

Increasingly Required:

NeurIPS: Encourages code/data availability statements ICML: Encourages reproducibility ICLR: Recommends code sharing

Best Practices:

• Include code repository link (anonymized if under review)
• Provide data access instructions
• Describe hyperparameters and settings
• Note any proprietary constraints

Supplementary Materials

General Guidelines:

• Appendices allowed but not required reading
• Use for additional experiments, proofs, tables
• Keep main paper self-contained
• Reference supplementary in main text

Formatting:

• Same style as main paper
• Clear section numbering (S1, S2, etc.)
• Include in submission PDF or as separate file

---

Citation Styles

Common Styles in ML

IEEE Style (Numbered):

[1] J. Doe, "Paper title," Conference Name, Year.
[2] A. Smith, "Another paper," Journal Name, vol. 10, pp. 1-15, 2020.

ACM Style (Numbered):

[J. Doe and A. Smith, "Paper title," Conference Name, Year.
[A. Smith and B. Jones, "Another paper," Journal Name, 2020.

Author-Year (APA-like):

Doe (2020) J. Doe. Paper title. Conference Name.
Smith (2019) A. Smith. Another paper. Journal Name.

Reference Management

Best Practices:

• Use consistent style throughout
• Include DOIs when available
• Provide arXiv links for preprints
• Check for broken links
• Verify all citations before submission

---

Checklists and Templates

Pre-Submission Checklist

Content:

• [ ] Novel contribution clearly stated
• [ ] Related work comprehensive
• [ ] Methods reproducible
• [ ] Results support all claims
• [ ] Limitations acknowledged
• [ ] Broader impact addressed (if required)
• [ ] Ethics compliance verified

Formatting:

• [ ] Page limits respected
• [ ] Style file followed exactly
• [ ] References complete and consistent
• [ ] Figures/tables clear and readable
• [ ] Equations numbered and referenced
• [ ] Supplementary material organized

Anonymity:

• [ ] Author names removed
• [ ] Acknowledgements anonymized
• [ ] Self-citations anonymized
• [ ] GitHub links anonymized
• [ ] Identifying information removed

---

Notes

• Always verify: Requirements change between years - always check current conference guidelines
• Plan ahead: Some venues have strict formatting - start early
• Read examples: Look at well-received papers from previous years
• Ask for help: If unsure about a requirement, consult program chairs or experienced colleagues

Updates: This file is regularly updated as new conference requirements become available.

Template

Template and style files for CoLM 2025