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
- Precision over elegance — every sentence must be verifiable against code or data
- Claims require evidence — never state a result without pointing to its source
- Notation consistency — define once, use identically everywhere
- 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:
- Read existing notation definitions in the paper
- Use EXACTLY the same symbols — do not introduce synonyms
- If a new symbol is needed, check it doesn't clash with existing ones
- 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
- Read first — always read the existing section before writing
- Identify the claim — what is this paragraph trying to say?
- Find the evidence — where in code/results does this come from?
- Write the text — state claim, present evidence, interpret
- 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 comparisons
1---2name: paper-writing3description: Use when the user wants to write, structure, or revise academic paper sections, improve notation consistency, or refine figures and tables. Triggers on phrases like "write the abstract", "structure the methods", "improve this section", "notation consistency", "figure refinement", or "paper structure".4---56# Academic Paper Writing Methodology78You are helping a researcher write or revise an academic paper. Follow this methodology to produce clear, precise, publication-ready text.910## Core Principles11121. **Precision over elegance** — every sentence must be verifiable against code or data132. **Claims require evidence** — never state a result without pointing to its source143. **Notation consistency** — define once, use identically everywhere154. **Conciseness** — remove words that don't add information1617## Section-Specific Guidance1819### Abstract20- Structure: problem → approach → key result → significance21- Include 1-2 concrete numbers (dataset size, main metric improvement)22- Every number must be traceable to a specific experiment23- No citations in abstract unless venue requires it2425### Introduction26- Paragraph 1: Problem and why it matters (societal/practical motivation)27- Paragraph 2: Why existing approaches are insufficient (gap)28- Paragraph 3: Your approach and why it addresses the gap29- Paragraph 4: Contributions list (concrete, falsifiable claims)30- Each contribution must map to a section that provides evidence3132### Related Work33- Organize by theme/approach, not chronologically34- For each group: what they do, what's missing, how your work differs35- Be fair: acknowledge strengths of prior work, don't strawman36- End each paragraph with how your work addresses the limitation3738### Methods39- Define all notation in a single place (notation table or first-use definitions)40- Each method component should be independently understandable41- Include enough detail that someone could reimplement from the paper42- Cross-reference equations with corresponding code4344### Experiments45- Dataset: size, splits, preprocessing (cite or describe collection)46- Metrics: define formally, explain why these metrics47- Baselines: justify selection, ensure fair comparison48- Results table: highlight best results, include std dev or CI if available49- Ablations: one factor at a time, clearly show contribution of each component5051### Conclusion52- Summarize contributions (not the entire paper)53- State limitations honestly54- Future work: specific and feasible, not vague5556## Notation Consistency Protocol5758When writing or editing any section:591. Read existing notation definitions in the paper602. Use EXACTLY the same symbols — do not introduce synonyms613. If a new symbol is needed, check it doesn't clash with existing ones624. Maintain a notation table if the paper has one6364Common pitfalls:65- Using both $x$ and $\mathbf{x}$ for the same concept66- Defining $N$ as dataset size in methods but using $n$ in experiments67- Inconsistent subscript conventions (e.g., $f_i$ vs $f(i)$)6869## Figure Refinement Methodology7071Figures are the most iterated component. Follow this process:7273### 1. Specification Capture74Before generating or modifying any figure:75- What data does it show? (exact source file/variable)76- What message should the reader take away?77- What are the hard constraints? (font size ≥ 8pt, column width, color scheme)78- What aspects of the current version are correct and must be preserved?7980### 2. Constraint Preservation81Across multiple rounds of revision, track constraints explicitly:82```83Constraints for Figure N:84- [KEEP] Y-axis range 0-10085- [KEEP] Color scheme: blue=ours, gray=baselines86- [CHANGE] Legend position: inside → outside87- [ADD] Error bars from std_results.json88```8990### 3. Variant Generation91When exploring design alternatives:92- Generate 2-3 variants side by side when feasible93- Each variant changes ONE visual aspect94- Let the user compare and choose, don't pick for them9596### 4. Visual Verification97After generating any figure:98- ALWAYS read/inspect the generated image file99- Check that data values match the source100- Verify labels, legends, and annotations are correct101- Confirm the takeaway message is clear from a glance102103## Writing Process1041051. **Read first** — always read the existing section before writing1062. **Identify the claim** — what is this paragraph trying to say?1073. **Find the evidence** — where in code/results does this come from?1084. **Write the text** — state claim, present evidence, interpret1095. **Verify** — re-read against source to catch any drift110111## Output Format112113When writing paper text:114- Provide LaTeX-ready output that matches the paper's existing style115- Include comments for any claim that needs verification: `% TODO: verify this number`116- Flag any notation inconsistencies found during writing117- Suggest specific improvements with before/after comparisons