ML Paper Writing for Top AI Conferences

SkillAI & models

Gives your agent an ml paper writing skill for drafting conference papers, doing literature reviews, and verifying citations.

Available today. Use it from your connected AI after setup.

Add ahel to your AI once: Claude, ChatGPT, Cursor, Claude Code or Codex. Then ask it to use this.

Then ask your AI: use the ML Paper Writing for Top AI Conferences skill

About this skill

Write publication-ready ML/AI papers for NeurIPS, ICML, ICLR, ACL, AAAI, COLM. Use when drafting papers from research repos, conducting literature reviews, finding related work, verifying citations, or preparing camera-ready submissions. Includes LaTeX templates, citation verification workflows, and

What this skill tells your AI

The instructions your AI receives, as published by galaxy-dawn/claude-scholar in skills/ml-paper-writing/SKILL.md and read by ahel’s review.

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.

Action✅ Correct❌ Wrong
Adding a citationSearch API → verify → fetch BibTeXWrite BibTeX from memory
Uncertain about a paperMark as [CITATION NEEDED]Guess the reference
Can't find exact paperNote: "placeholder - verify"Invent similar-sounding paper

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:

DimensionWeightEvaluation Focus
Innovation30%Novelty and originality
Method Completeness25%Clarity and reproducibility
Experimental Thoroughness25%Validation depth
Writing Quality10%Presentation clarity
Relevance & Impact10%Domain importance

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 shares the active installed writing memory maintained by paper-miner with the Nature writing, polishing, response, and other academic writing skills:

  • 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:

SectionPurpose
Writing patterns minedReusable rhetorical and claim-evidence patterns
Structure signalsSection flow, paragraph progression, and paper organization signals
Reusable phrasingTransition phrases, framing templates, and concise wording
Venue-specific signalsVisible venue-facing style and convention cues
How this helps our writingPractical guidance for future drafts, reports, and rebuttals
Source indexSource attribution for mined papers

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
↓
Relevant academic writing skills reuse 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. repo-local evidence and experiment artifacts
  2. references/knowledge/paper-miner-writing-memory.md, when relevant entries exist
  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.

Confidence LevelAction
High (clear repo, obvious contribution)Write full draft, deliver, iterate on feedback
Medium (some ambiguity)Write draft with flagged uncertainties, continue
Low (major unknowns)Ask 1-2 targeted questions, then draft

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

SectionDraft AutonomouslyFlag With Draft
AbstractYes"Framed contribution as X—adjust if needed"
IntroductionYes"Emphasized problem Y—correct if wrong"
MethodsYes"Included details A, B, C—add missing pieces"
ExperimentsYes"Highlighted results 1, 2, 3—reorder if needed"
Related WorkYes"Cited papers X, Y, Z—add any I missed"

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):

PillarDescriptionExample
The What1-3 specific novel claims within cohesive theme"We prove that X achieves Y under condition Z"
The WhyRigorous empirical evidence supporting claimsStrong baselines, experiments distinguishing hypotheses
The So WhatWhy readers should careConnection to recognized community problems

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:

SourceKey ContributionLink
Neel Nanda (Google DeepMind)The Narrative Principle, What/Why/So What frameworkHow to Write ML Papers
Sebastian Farquhar (DeepMind)5-sentence abstract formulaHow to Write ML Papers
Gopen & Swan7 principles of reader expectationsScience of Scientific Writing
Zachary LiptonWord choice, eliminating hedgingHeuristics for Scientific Writing
Jacob Steinhardt (UC Berkeley)Precision, consistent terminologyWriting Tips
Ethan Perez (Anthropic)Micro-level clarity tipsEasy Paper Writing Tips
Andrej KarpathySingle contribution focusVarious lectures

For deeper dives into any of these, see:

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.

PrincipleRuleExample
Subject-verb proximityKeep subject and verb close❌ "The model, which was trained on..., achieves" → ✅ "The model achieves... after training on..."
Stress positionPlace emphasis at sentence ends❌ "Accuracy improves by 15% when using attention" → ✅ "When using attention, accuracy improves by 15%"
Topic positionPut context first, new info after✅ "Given these constraints, we propose..."
Old before newFamiliar info → unfamiliar infoLink backward, then introduce new
One unit, one functionEach paragraph makes one pointSplit multi-point paragraphs
Action in verbUse verbs, not nominalizations❌ "We performed an analysis" → ✅ "We analyzed"
Context before newSet stage before presentingExplain before showing equation

Shortened here. Read the whole file on GitHub.

Signals

GitHub stars
6k
Forks
443
Last commit
Sep 2026

ahel review

  • K1binfo
    installs-packages (in references/citation-workflow.md)
  • K1binfo
    installs-packages (in references/sources.md)
  • K1binfo
    installs-packages (in templates/README.md)

Automated review, not a security audit. Ruleset v1+k2.

Advanced
Item type
skill
Key
ml-paper-writing-galaxy-dawn
Source
github.com/galaxy-dawn/claude-scholar