1k tokens
context cost
the whole folder, loaded on every use
1
files
instructions only
0
copies elsewhere
how many repositories repackaged it
356
stars on the repo
on the repository, not the skill itself
Install
one command, takes just this skill from the repository
npx skills add https://github.com/fcakyon/phd-skills --skill paper-writing
Copy
The instruction itself
17 sections, as written by the author
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
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)$)
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
Copy
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
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