skills/writing-papers/SKILL.md
# SKILL: Writing Papers > How to write a paper that people actually read — with singular focus, a story that lands, self-contained figures, and a conclusion that does not waste its moment. > Based on Carlini (2026) — "How to win a best paper award." --- ## When to use this skill Use this skill when transitioning from the execution phase to drafting. Also use it when reviewing a draft in progress. For full end-to-end pipeline runs (topic to export), use `paper-pipeline` instead — this skill i
npx skillsauth add moralespanitz/research-loop skills/writing-papersInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
How to write a paper that people actually read — with singular focus, a story that lands, self-contained figures, and a conclusion that does not waste its moment. Based on Carlini (2026) — "How to win a best paper award."
Use this skill when transitioning from the execution phase to drafting. Also use it when reviewing a draft in progress. For full end-to-end pipeline runs (topic to export), use paper-pipeline instead — this skill is for standalone drafting when you already have results.
Invoke with: /writing-papers or @scribe: apply writing skill
This skill provides standalone paper drafting capability. For the full 14-phase
pipeline (topic → literature → experiment → draft → review → export), load the
paper-pipeline skill instead:
| Scenario | Skill to Use |
|----------|-------------|
| You have experiment results and need a paper | writing-papers (this skill) |
| You have a topic and want a full pipeline run | paper-pipeline |
| You need publication-quality figures | figure-agent (then embed results here) |
| You need to handle reviewer feedback after submission | review-prep |
| You need a structured literature review | literature-review |
This skill composes with paper-pipeline at Phase 11 (Paper Draft) — the
guidance here applies to the draft phase of the pipeline.
When drafting or formatting for submission, use these guidelines:
A research paper communicates exactly one idea.
Write this idea in one sentence before you write anything else. Put it at the top of your draft document. Every section, paragraph, figure, and sentence you write must connect to it. If a sentence does not serve this idea, cut it.
If you cannot express your idea in one sentence, your paper is trying to do too many things. Fix the paper, not the sentence.
Pick a specific person as your target reader. Write for them, not for a generic "research community."
A useful default: the six-months-younger version of yourself. What would that person need to hear to be motivated to read this paper? What background do they have? What misconceptions do they bring?
The background section exists to expand who "the reader" can be. After the background, you can assume the reader knows everything you wrote there. Write the background accordingly — not as a block of citations to appease reviewers, but as the minimal set of concepts your ideal reader needs to follow your argument.
Before writing, state explicitly:
The abstract has two jobs: (1) convey the entirety of the paper in a few sentences, and (2) convince the right reader to keep reading.
A reliable structure:
| Sentence | Content | |----------|---------| | 1 | The topic/field you are working in | | 2 | The specific problem you are solving | | 3 | Your method or key insight | | 4 | Your results, or what sentence 3 did not cover | | 5 | Why this matters |
Alternative structure for broad topics or narrow audiences:
Rules for the abstract:
The introduction is the beginning of a story. Its job is to move the reader from where they currently are — their existing beliefs — to the frame of mind where your contribution makes sense.
Structure:
How much story you need depends on how accepted the premise is:
| Situation | Approach | |-----------|----------| | Well-studied problem, clear contribution | One paragraph is enough. "We solve unsolved problem X." | | Moderately known problem | Brief reminder, then contribution | | Underexplored area | Extended setup — you must convince the reader the problem matters before they will care about your solution | | Heretical claim | Do not state the conclusion upfront. Lay evidence first. Let the reader arrive at the conclusion themselves. |
The introduction has at most two pages. Readers have short attention spans. Do not write a novel before getting to the point.
Most readers skim before they commit to reading. The skimming path is: title → abstract → figures. Your figures must work on this path.
Rules:
A typical figure arc for an experimental paper:
The conclusion is not the abstract in the past tense. It is not a summary.
The conclusion is a moment of reflection. The reader has just spent an hour in the technical details of your paper. They have surfaced. Your job is to tell them clearly what they should take away from the experience.
Structure:
A test: if your conclusion could be replaced by "our method achieves X% on Y" and nothing would be lost, your conclusion is not doing its job. The "so what" must be more than the result — it must be the meaning of the result.
Write your best-case conclusion before running any experiments (per the idea-selection skill). When writing the actual paper, this becomes your target. Hold yourself to it.
You do not need to be a great writer. You need to be clear enough that the reader can follow your argument without getting distracted by the prose.
Practical rules:
The reader will forgive occasional typos. They will not forgive an argument they cannot follow.
The title must be accurate. It need not be clever. It should let the right readers identify that this paper is for them.
If you are struggling to write a title, it is often a sign the paper is trying to do more than one thing. Fix the paper, then title it.
testing
Plan and execute a structured replication workflow for a paper, claim, or benchmark with environment selection and integrity checks.
testing
End-to-end paper generation pipeline ported from AutoResearchClaw (Aiming Lab). 14 phases covering topic initiation through export/publish, with human- in-the-loop gates and quality gating at each handoff. Use this when the user wants a full paper pipeline run — topic to submission-ready manuscript. Delegates to researcher/reviewer/writer/verifier subagents for stage execution and to autonomous-iteration for experiment optimization loops.
testing
Run a structured literature review on a topic using parallel search, evidence tables with quality scoring, and primary-source synthesis.
development
Publication-quality figure generation for research papers. Decision agent selects figure type (code plot vs architecture diagram). Generates Matplotlib/Seaborn code for quantitative figures with iterative improvement loop. Style-matches conference templates (NeurIPS, ICML, ICLR). Use when the paper-pipeline reaches the figure generation phase, or when a user requests figures for an existing draft.