ML Literature Review / Related Work Skill

1. Groups prior work into coherent thematic threads relevant to your contribution
2. Synthesizes findings and limitations within each thread (not paper-by-paper summaries)
3. Exposes the gap that your paper fills

The gap is the star of the show. Every sentence should serve it.

Step-by-Step Process

Step 0: Gather Inputs from the User

Before writing anything, collect the following. Ask the user directly if they haven't provided these:

• Paper title and one-sentence contribution: What does this paper do that is new?
• Key claims / main results: What specifically does the method achieve?
• 2–5 closest prior works: The papers most similar to this one (the user should know these)
• Broader related areas: e.g., "self-supervised learning," "graph neural networks," "efficient transformers"
• Target venue (if known): Conference page limits matter — NeurIPS/ICML typically allow 1–2 pages of related work; workshop papers much less.
• Any uploaded draft or notes: If the user provides an existing draft, review it before writing.

Step 1: Identify the Thematic Threads

Organize the landscape of prior work into 2–5 thematic groups (not individual papers). Each group should represent a line of attack on the problem that is relevant to the current paper.

Example thematic threads for a paper on efficient fine-tuning of LLMs:

• Parameter-efficient fine-tuning (LoRA, adapters, prefix tuning)
• Knowledge distillation approaches
• Pruning and quantization for deployment
• Prompt-based and in-context learning methods

Each thread becomes a paragraph or short subsection.

Step 2: Draft Each Thread Using the GAP Pattern

For each thematic group, write a paragraph following this pattern:

[WHAT EXISTS]  →  [WHAT'S LIMITED]  →  [HOW THIS PAPER DIFFERS]

Concretely:

1. Establish the thread (1–2 sentences): What has been done in this area? Synthesize, don't enumerate. Write about findings, not finders.
2. Surface the limitation (1–2 sentences): What do these approaches fail to address? Be specific — not "little is known" but rather "these methods assume access to labeled target-domain data, which is unavailable in X setting."
3. Bridge to your work (1 sentence, optional per thread): How does your approach sidestep or address this limitation? This can be implicit if the gap speaks for itself.

Step 3: Write the Closing Bridge Paragraph

End the related work section with a short paragraph (2–4 sentences) that:

• Synthesizes the overall gap across all threads
• States how your paper's contribution is distinct from and advances beyond the prior work
• Avoids vague claims like "our method is better" — instead be precise: "Unlike X which requires Y, our approach achieves Z without this constraint."

Step 4: Self-Edit Using the Conciseness Checklist

Before delivering the final draft, apply these checks (drawn from Hotaling's 10 rules and Schimel):

• No "Smith found" sentences: Citations should be at the end of clauses, not the subject. Write "Attention mechanisms improve sequence modeling (Vaswani et al., 2017)" NOT "Vaswani et al. (2017) proposed the Transformer." Exception: when highlighting a debate or attributing a specific disputed claim.
• No data dumps: Every cited paper must serve a purpose in the narrative. If removing a citation doesn't weaken the argument, remove it.
• No filler phrases: Cut "It is worth noting that," "In recent years," "A large body of work has studied," "It is well known that." Just state the fact.
• Active voice preferred: "Recent methods reduce latency by X%" not "Latency has been reduced by recent methods by X%."
• No redundancy: If you said it in the introduction, don't repeat it here verbatim.
• Short words over long: "use" not "utilize," "show" not "demonstrate," "method" not "methodology."
• Each paragraph has one job: If a paragraph covers two threads, split it.
• Gap is explicit: A reader should be able to underline the gap sentence in every paragraph. If they can't, rewrite.
• Generous but not exhaustive citations: Cite the 2–3 closest works per thread. You don't need to cite every paper ever written. Be generous to give proper credit, but don't pad.

ML-Specific Conventions

Citation Density and Style

ML papers typically use numeric citations [1] or author-year (Author et al., 2024). Follow the user's venue style. In ML, it's common and acceptable to cite 15–30 papers in related work, but each citation should earn its place.

Common Thematic Groupings in ML Papers

When the user isn't sure how to organize, suggest groupings from this non-exhaustive list:

• Architecture families: Transformers, CNNs, GNNs, state-space models, diffusion models
• Training paradigms: supervised, self-supervised, semi-supervised, reinforcement learning, RLHF
• Efficiency techniques: pruning, quantization, distillation, parameter-efficient methods
• Task-specific prior art: whatever the specific application domain is (e.g., medical imaging, code generation, robotics)
• Theoretical foundations: relevant theory, convergence results, generalization bounds
• Evaluation and benchmarks: prior benchmarks, metrics, or evaluation protocols the paper builds on

Positioning Table (Optional)

For papers with many close comparators, suggest a small comparison table summarizing key properties (e.g., "requires labels?", "handles distribution shift?", "inference cost"). This is common in top-venue ML papers and can replace several paragraphs of prose.

What NOT to Do

These are the most common failure modes. Avoid them:

1. The chronological survey: "In 2017, Vaswani et al. proposed... In 2018, Devlin et al. introduced... In 2019..." This is a data dump, not an argument. Organize by theme, not by year.

2. The "little is known" cop-out: Schimel warns that claiming "little is known about X" is almost always false and unconvincing. Instead, describe specifically what has been done and what specific limitation remains.

3. The exhaustive catalog: Cochrane: "Literature reviews have gotten way out of hand. It is not necessary to cite every single paper in the literature." Focus on the 2–3 closest papers per thread.

4. The unconnected list: "Method A does X. Method B does Y. Method C does Z." Without synthesis, this is useless. Instead: "Several methods address X by doing Y (A; B; C), but all assume Z, which limits their applicability to..."

5. Selling your solution before the problem: Schimel: "To sell us a solution, first sell us a problem." Don't start with how great your method is. Build the gap first, then let your contribution emerge as the natural response.

6. Being mean to prior work: Cochrane: "Be generous in your citations. You do not have to say that everyone else did it all wrong for your approach and improvements to be interesting." State limitations factually. The prior work was valuable—your contribution builds on it.

Output Format

When delivering the related work section to the user, provide:

1. The drafted section in LaTeX or Markdown (match user's preference or infer from context)
2. Placeholder citations in the format \cite{author2024keyword} or (Author et al., 2024) — the user will fill in exact keys
3. Inline comments (as LaTeX % comments or Markdown <!-- -->) flagging:
   • Places where the user should verify a factual claim
   • Suggestions for additional citations the user might want to add
   • Any sentence where Claude is uncertain about the accuracy of a technical claim

Always remind the user: Claude cannot guarantee the accuracy of specific technical claims about cited papers. The user must verify all factual claims and citation details against the actual papers.

Tone and Style Targets

• Voice: Third-person academic, active voice preferred
• Sentence length: Vary, but average 15–25 words. No sentence over 40 words.
• Paragraph length: 4–8 sentences per paragraph, each paragraph focused on one thread
• Overall length: Scale to venue — typically 0.75–2 pages for a conference paper, potentially longer for a journal
• Register: Precise and technical but not pompous. "Use" not "utilize." "Show" not "demonstrate." Avoid "novel" and "state-of-the-art" — let the results speak.

Example: Before and After

Before (weak — data dump, no gap):

Vaswani et al. (2017) introduced the Transformer architecture. Devlin et al. (2019)
proposed BERT for pre-training. Radford et al. (2019) developed GPT-2. Brown et al.
(2020) scaled this to GPT-3. Recently, Touvron et al. (2023) released LLaMA. Wei et al.
(2022) showed that chain-of-thought prompting improves reasoning.

After (strong — synthesized, gap-focused):

Large language models have advanced rapidly through scaling pre-trained Transformers,
progressing from masked language modeling to autoregressive generation at increasingly
large parameter counts (Devlin et al., 2019; Brown et al., 2020; Touvron et al., 2023).
While scaling improves general capability, these models remain brittle on multi-step
reasoning tasks, often producing plausible but logically inconsistent outputs. Prompting
strategies such as chain-of-thought (Wei et al., 2022) partially mitigate this, but
require careful prompt engineering and degrade on out-of-distribution problem types.
Our approach instead addresses reasoning robustness at the architectural level,
eliminating the need for task-specific prompts.

Reference

For deeper guidance on the principles underlying this skill, consult references/writing_principles.md.