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 paper discovery/evaluation criteria.
Instalar com Codex ou Claude Copie este prompt, cole no Codex, Claude ou outro assistente e deixe que ele revise a página da skill e instale para você.
Um comando direto ignora o prompt de revisão. Verifique a origem antes de executá-lo.
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 paper discovery/evaluation criteria.
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:
lock the operating mode from references/OPERATING-MODES.md,
understand the repo or draft context,
use references/citation-workflow.md as the canonical citation authority,
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:
Understand the project by exploring the repo, results, and existing documentation
Deliver a complete first draft when confident about the contribution
Search literature using web search and APIs to find relevant citations
Refine through feedback cycles when the scientist provides input
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 citation
Search API → verify → fetch BibTeX
Write BibTeX from memory
Uncertain about a paper
Mark as [CITATION NEEDED]
Guess the reference
Can't find exact paper
Note: "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"
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.
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:
Check the claim ledger gate for contribution and result claims
Write the full first draft end-to-end only for supported claims
Mark unsupported or speculative claims explicitly
Present the complete draft for feedback
Iterate based on scientist's response
If genuinely uncertain about framing or major claims:
Draft what you can confidently
Flag specific uncertainties: "I framed X as the main contribution—let me know if you'd prefer to emphasize Y instead"
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:
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:
Section
Purpose
Writing patterns mined
Reusable rhetorical and claim-evidence patterns
Structure signals
Section flow, paragraph progression, and paper organization signals
Reusable phrasing
Transition phrases, framing templates, and concise wording
Venue-specific signals
Visible venue-facing style and convention cues
How this helps our writing
Practical guidance for future drafts, reports, and rebuttals
Source index
Source 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
↓
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:
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 Level
Action
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):
Section
Draft Autonomously
Flag With Draft
Abstract
Yes
"Framed contribution as X—adjust if needed"
Introduction
Yes
"Emphasized problem Y—correct if wrong"
Methods
Yes
"Included details A, B, C—add missing pieces"
Experiments
Yes
"Highlighted results 1, 2, 3—reorder if needed"
Related Work
Yes
"Cited papers X, Y, Z—add any I missed"
Only block for input when:
Target venue is unclear (affects page limits, framing)
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."
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:
Source
Key Contribution
Link
Neel Nanda (Google DeepMind)
The Narrative Principle, What/Why/So What framework
Why? Most reviewers form judgments before reaching your methods. Readers encounter your paper as: title → abstract → introduction → figures → maybe the rest.
These principles are based on how readers actually process prose. Violating them forces readers to spend cognitive effort on structure rather than content.
Principle
Rule
Example
Subject-verb proximity
Keep subject and verb close
❌ "The model, which was trained on..., achieves" → ✅ "The model achieves... after training on..."
Stress position
Place emphasis at sentence ends
❌ "Accuracy improves by 15% when using attention" → ✅ "When using attention, accuracy improves by 15%"
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:
Paper Section
% Reviewers Who Read
Implication
Abstract
100%
Must be perfect
Introduction
90%+ (skimmed)
Front-load contribution
Figures
Examined before methods
Figure 1 is critical
Methods
Only if interested
Don't bury the lede
Appendix
Rarely
Put only supplementary details
Bottom line: If your abstract and intro don't hook reviewers, they may never read your brilliant methods section.
Conference Requirements Quick Reference
Conference
Page Limit
Extra for Camera-Ready
Key Requirement
NeurIPS 2025
9 pages
+0
Mandatory checklist, lay summary for accepted
ICML 2026
8 pages
+1
Broader Impact Statement required
ICLR 2026
9 pages
+1
LLM disclosure required, reciprocal reviewing
ACL 2025
8 pages (long)
varies
Limitations section mandatory
AAAI 2026
7 pages
+1
Strict style file adherence
COLM 2025
9 pages
+1
Focus on language models
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 templatecp -r templates/neurips2025/ ~/papers/my-new-paper/
cd ~/papers/my-new-paper/
# Verify structure is completels -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:
Read the template's example content
Note any special formatting or macros used
Replace with your content following the same patterns
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
Pitfall
Problem
Solution
Copying only main.tex
Missing .sty, won't compile
Copy entire directory
Modifying .sty files
Breaks conference formatting
Never edit style files
Adding random packages
Conflicts, breaks template
Only add if necessary
Deleting template content too early
Lose formatting reference
Keep as comments until done
Not compiling frequently
Errors accumulate
Compile after each section
Quick Template Reference
Conference
Main File
Key Style File
Notes
NeurIPS 2025
main.tex
neurips.sty
Has Makefile
ICML 2026
example_paper.tex
icml2026.sty
Includes algorithm packages
ICLR 2026
iclr2026_conference.tex
iclr2026_conference.sty
Has math_commands.tex
ACL
acl_latex.tex
acl.sty
Strict formatting
AAAI 2026
aaai2026-unified-template.tex
aaai2026.sty
Very strict compliance
COLM 2025
colm2025_conference.tex
colm2025_conference.sty
Similar to ICLR
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.
Paper checklist (appendix), lay summary if accepted
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:
Search programmatically with Semantic Scholar / CrossRef / arXiv / OpenAlex when appropriate.
Verify existence in two sources when the claim is important.
Retrieve BibTeX programmatically from DOI or a trusted source.
Validate the claim against the actual paper content when the citation supports a specific statement.
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.
Verified paper exists but the claim was not checked
⚠️ Use only for general attribution, not for precise technical claims
Discovery surface suggests a paper but metadata is still weak
⚠️ Keep as lead, not as final citation
Cannot verify programmatically
❌ Mark [CITATION NEEDED], inform the scientist
🚨 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:
Criterion
What Reviewers Look For
Quality
Technical soundness, well-supported claims
Clarity
Clear writing, reproducible by experts
Significance
Community impact, advances understanding
Originality
New insights (doesn't require new method)
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
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:
