mcpField
P
paper-writing

paper-writing

github.com/fcakyonDocuments438157 installsUpdated 3w ago
Repository

About paper-writing

A methodology skill for researchers drafting or revising academic papers. It guides evidence-based writing, consistent notation, section structure, and figure refinement.

Key features

  1. 01Evidence-linked claims
  2. 02Section-specific writing guidance
  3. 03Notation consistency checks
  4. 04Figure revision and verification
  5. 05LaTeX-ready output guidance

Use cases

  1. 01Drafting or revising paper sections
  2. 02Checking claims against code and results
  3. 03Maintaining notation across a paper
  4. 04Refining and verifying figures

Install

Copy the command and run it in a terminal.

$npx skills add https://github.com/fcakyon/phd-skills --skill paper-writing

After installing, type/paper-writingin Claude Code to confirm it loaded.

Details

From the project README

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 comparisons

Comments

Markdown supported