git clone --depth 1 https://github.com/fcakyon/phd-skills /tmp/paper-writing && cp -r /tmp/paper-writing/plugin/skills/paper-writing ~/.claude/skills/paper-writingSKILL.md
# Academic Paper Writing Methodology
You are helping a researcher write or revise an academic paper. Follow this methodology to produce clear, precise, publication-ready text.
## Core Principles
1. **Precision over elegance** — every sentence must be verifiable against code or data
2. **Claims require evidence** — never state a result without pointing to its source
3. **Notation consistency** — define once, use identically everywhere
4. **Conciseness** — remove words that don't add information
## 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
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
Figures are the most iterated component. Follow this process:
### 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 read/inspect the generated image file
- Check that data values match the source
- Verify labels, legends, and annotations are correct
- Confirm the takeaway message is clear from a glance
## 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
## 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 comparisonsSame-epoch comparison of training runs across wandb, neptune, tensorboard, or mlflow. Aligns runs at the student's current step (never current-vs-final-of-baseline) and separates proxy metrics from downstream targets. Use when the user asks to compare runs, check if a run is improving, track lag against a baseline, rank experiments, or evaluate run-vs-run performance.
>
Evidence-before-action diagnosis of failing ML experiments. Probes the system before guessing causes, process list, dmesg, GPU stats, log scrollback, checkpoint state, then states a hypothesis as a hypothesis and runs a smoke before claiming a root cause. Use when the user asks why a run is failing, diverging, OOMing, hanging, slow, producing weird metrics, has crashed, or asks to debug, diagnose, troubleshoot, or investigate a training issue.
>
>
Pre-flight checklist for long-running ML training jobs covering config diff, run naming, path verification, monitoring setup, and restart-cleanup. Use when the user asks to launch, kick off, start, restart, or kill a training run, or mentions launching a multi-hour or multi-day GPU job (python train, accelerate launch, torchrun, deepspeed, sbatch, tmux training).
>
>