paper-write git:20261030.3dd54cfA

Immutable. This exact content never changes and is served at /api/v1/blob/a5de738454dabba5.

---
name: paper-write
description: Write, structure, or revise academic paper sections, keep notation consistent, refine figures and tables, and set up or fix the LaTeX build (TeX distribution, biber vs bibtex, venue templates, compilation). Use when the user says "write the abstract", "structure the methods", "improve this section", "notation consistency", "figure refinement", "paper structure", "setup latex", "biber vs bibtex", "latex compilation error", "install latex packages", "venue template", or "texlive setup".
---

# Paper Write: academic paper writing and LaTeX setup

For LaTeX environment setup, biber vs bibtex, venue templates and compilation, follow [references/latex.md](references/latex.md).

## Core Principles

1. **Precision over elegance.** Every claim traces to code, data or a cited source.
2. **Conciseness.** Remove words that don't add information.

## Writing Process

1. **Read first.** Always read the existing section before writing.
2. **Identify the claim.** What is this paragraph trying to say?
3. **Find the evidence.** Where in code/results does this come from?
4. **Write the text.** State claim, present evidence, interpret.
5. **Verify.** Re-read against source to catch any drift, then compile with the project pipeline from [references/latex.md](references/latex.md) Step 5 and fix any error before the next edit.

## Section-Specific Guidance

### Abstract

- Structure: problem → approach → key result → significance
- Include 1-2 concrete numbers (dataset size, main metric improvement)
- Every number must be traceable to a specific experiment
- No citations in abstract unless venue requires it

### Introduction

- Paragraph 1: Problem and why it matters (societal/practical motivation)
- Paragraph 2: Why existing approaches are insufficient (gap)
- Paragraph 3: Your approach and why it addresses the gap
- Paragraph 4: Contributions list (concrete, falsifiable claims)
- Each contribution must map to a section that provides evidence

### Related Work

- Organize by theme/approach, not chronologically
- For each group: what they do, what's missing, how your work differs
- Be fair: acknowledge strengths of prior work, don't strawman
- End each paragraph with how your work addresses the limitation

### Methods

- Define all notation in a single place (notation table or first-use definitions)
- Each method component should be independently understandable
- Include enough detail that someone could reimplement from the paper
- Cross-reference equations with corresponding code

### Experiments

- Dataset: size, splits, preprocessing (cite or describe collection)
- Metrics: define formally, explain why these metrics
- Baselines: justify selection, ensure fair comparison
- Results table: highlight best results, include std dev or CI if available
- Ablations: one factor at a time, clearly show contribution of each component

### Conclusion

- Summarize contributions (not the entire paper)
- State limitations honestly
- Future work: specific and feasible, not vague

## Notation Consistency Protocol

Define once, use identically everywhere. When writing or editing any section:

1. Read existing notation definitions in the paper
2. Use EXACTLY the same symbols. Do not introduce synonyms.
3. If a new symbol is needed, check it doesn't clash with existing ones
4. Maintain a notation table if the paper has one

Common pitfalls:

- Using both $x$ and $\mathbf{x}$ for the same concept
- Defining $N$ as dataset size in methods but using $n$ in experiments
- Inconsistent subscript conventions (e.g., $f_i$ vs $f(i)$)

## Figure Refinement Methodology

### 1. Specification Capture

Before generating or modifying any figure:

- What data does it show? (exact source file/variable)
- What message should the reader take away?
- What are the hard constraints? (font size ≥ 8pt, column width, color scheme)
- What aspects of the current version are correct and must be preserved?

### 2. Constraint Preservation

Across multiple rounds of revision, track constraints explicitly:

```
Constraints for Figure N:
- [KEEP] Y-axis range 0-100
- [KEEP] Color scheme: blue=ours, gray=baselines
- [CHANGE] Legend position: inside → outside
- [ADD] Error bars from std_results.json
```

### 3. Variant Generation

When exploring design alternatives:

- Generate 2-3 variants side by side when feasible
- Each variant changes ONE visual aspect
- Let the user compare and choose, don't pick for them

### 4. Visual Verification

After generating any figure, ALWAYS:

- Open the rendered image and look at it
- Check data values, colors and axis ranges against the spec and constraint list above
- Verify labels, legends, and annotations are correct
- Confirm the takeaway message is clear from a glance

## Output Format

When writing paper text:

- Provide LaTeX-ready output that matches the paper's existing style
- Include comments for any claim that needs verification: `% TODO: verify this number`
- Flag any notation inconsistencies found during writing
- Suggest specific improvements with before/after comparisons