agentleFS
sidiangongyuansidiangongyuan/codex-skills-library/skills/paper-writing/SKILL.md

paper-writing

Skill11 starsChanged 4 months agoMITView on GitHub

Draft or restructure research-paper sections, refine local prose, and audit manuscript-wide consistency. Use for evidence-grounded academic writing and revision, not independent acceptance-risk review or official rebuttal management.

36 other projects use a version of this.

Adopted by

Most recently taken up by

Used with

Projects with it also use ml-training-recipe, replication and 10 more.

Other files people use alongside this one.

Files found in the same public projects as a version of this one, more often than they turn up anywhere else. Each project counts once, large collections count for less, and this file's own repository is left out.
  • getcompanion-aiSkill

    ml-training-recipe

    Find implementable ML training recipes from papers, datasets, docs, and code. Use when the user wants to fine-tune, train, reproduce, or choose a practical ML method, dataset, hyperparameter setup, or benchmark recipe.

    Also in 3 projects that use this

  • getcompanion-aiSkill

    replication

    Plan a replication of a paper, claim, or benchmark, and execute only after an explicit environment choice. Use when the user asks to replicate results, reproduce an experiment, verify a claim empirically, or build a replication package.

    Also in 3 projects that use this

  • brainbytes-devSkill

    alpha-research

    Also in 3 projects that use this

  • JaimeParkerSkill

    paper-code-audit

    Perform three-way cross-validation of a research paper by comparing the original paper text (via Zotero), official code implementation (via Git), and personal Obsidian notes. Use this skill whenever the user wants to "audit a paper", "verify paper claims against code", "cross-check notes with implementation", "triangulate paper + code + notes", "find discrepancies between paper and code", or mentions wanting a deep, structured comparison of a paper's claims against its implementation and their own notes. Also trigger when the user asks to "analyze this paper thoroughly" with code available, or when they want to systematically reconcile what the paper says, what the code does, and what their notes claim.

    Also in 3 projects that use this

  • JimLiuSkill

    pdf-explore

    Use this skill when the user has attached a PDF, paper, report, or other document and the answer needs content from more than one place in it: summarize the methods or any other section, compare sections, find where a topic is discussed, read a value or label off a figure or chart, or find/list/extract every instance of something across the whole document (datasets, benchmarks, citations, figures, table rows, accession numbers — including appendices). Skip it only for a single lookup of 1–4 pages quoted in your very next response — `read_file(pages=[...])` attaches pages as images that are dropped from context after one turn, so multi-section answers end up re-reading the same ranges repeatedly. Parses the PDF once in the Python kernel: `pdf_pages` (pages as persistent text), `pdf_outline` (TOC), `pdf_scan` (rank pages by relevance), `pdf_map`/`pdf_extract` (per-page summary / structured fields via parallel haiku calls). For PDF creation/manipulation, use reportlab/pypdf directly.

    Also in 4 projects that use this

  • Yusong-EnceladusSkill

    research-review

    Get a deep critical review of research from GPT via Codex MCP. Use when user says "review my research", "help me review", "get external review", or wants critical feedback on research ideas, papers, or experimental results.

    Also in 6 projects that use this

  • +1 more from getcompanion-ai

The file

We split this skill into the rules it gives an agent

8 rules. 0 are common, 7 are distinctive, and 1 is very specific to this project.

  • 0

    Common

    Most of the 26 edited versions we read keep these.

  • 7

    Distinctive

    This author's own choices. Worth a look.

  • 1

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Local refinement: read the target and its immediate context, then use prose.md.

    line 16
  2. Distinctive:

    Whole-manuscript consistency: read consistency.md and trace claims and terminology across the main text, visuals, and supplement.

    line 20
  3. Distinctive:

    Use a section guide only where a concrete structural issue needs repair.

    line 22
  4. Distinctive:

    Keep this working map compact.

    line 39
  5. Very specific:

    When uncertain citations or factual claims affect the requested edit, verify them with primary sources.

    line 71
  6. Distinctive:

    Keep a condition in prose when omitting it would change the interpretation of fairness, applicability, or the central claim.

    line 91
  7. Distinctive:

    Prefer direct declarative language to defensive framing such as “we acknowledge,” “it should be noted,” or a pre-emptive concession.

    line 95
  8. Distinctive:

    Check that the changed text answers its intended reader question, follows from the preceding passage, and matches the evidence.

    line 112

“Common” is measured: kept by at least 6 in 10 of the 26 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Paper Writing

Make the paper's purpose, contribution, use, and evidence easy to follow. Adapt the writing to the actual paper rather than fitting it to a method-paper template.

Choose the scope before the workflow

  • Section writing: draft or restructure the requested sections. Read their relevant guides below and identify the paper's main contribution before editing.
  • Local refinement: read the target and its immediate context, then use prose.md. Preserve the settled story and verify affected links only. A caption correction does not require a new literature survey, contribution interview, full manuscript rewrite, or experiment run.
  • Whole-manuscript consistency: read consistency.md and trace claims and terminology across the main text, visuals, and supplement. Use a section guide only where a concrete structural issue needs repair.

An assessment request authorizes diagnosis, not file changes. An explicit revision request authorizes scoped edits and their normal verification. Missing experiments are evidence gaps, not permission to launch jobs. Ask only when a decision changes the scientific claim, scope, resources, or an external action; inspect existing records first. Do not reopen settled choices without a concrete contradiction.

Establish the argument

For structural work, identify from the draft and evidence:

  • the reader's question and the paper's primary contribution;
  • what the resource, method, or analysis enables, and how it is actually used;
  • which evidence supports each principal claim, and what remains untested;
  • the role of reference implementations, auxiliary supervision, and controls.

Keep this working map compact; it need not become a new document. For a benchmark paper, lead with the resource and what its use demonstrates, not a compulsory model invention. For a method paper, connect the problem to the tested design. For a system paper, connect requirements and interfaces to end-to-end evidence. For an analysis paper, connect the question and measurement to the finding. Hybrid papers may combine roles without forcing every component into an equal contribution. Do not invent a new name or mechanism to create a narrative turn.

Read only the relevant guidance

  • Abstract or Introduction: front-matter.md.
  • Dataset/benchmark design and its use: benchmark.md.
  • Related Work and positioning: related-work.md.
  • Method, formulation, and implementation exposition: method.md.
  • Experiments, tables, and result captions: experiments.md.
  • Conclusion, limitations, and supplement: closing-material.md.
  • Sentence-level clarity and transitions: prose.md.
  • Cross-section verification and rendered checks: consistency.md.

Evidence and scope boundaries

Preserve verified results and references. Do not fabricate support, silently change evaluation populations, or turn pending cells into findings. Narrow unsupported claims or identify the missing evidence. Fluent phrasing cannot repair a false premise. A complete system's gain does not isolate a component's causal effect.

Focus is not concealment: secondary observations need not interrupt every headline, but conditions that change the validity of a comparison must remain clear where the claim is interpreted. Primary metrics, auxiliary tasks, statistical analyses, page budgets, and punctuation preferences are project or venue decisions, not universal rules. Do not automatically require or forbid additional experiments.

When uncertain citations or factual claims affect the requested edit, verify them with primary sources; use research-evidence if available. Reuse still-applicable verification rather than restarting a full search. Borrow an exemplar's rhetorical function only after reading the relevant passage, not its unverified scientific claims or alleged venue authority.

Separate the manuscript-ready replacement from the explanation to the author. An evidence gap may need an editorial note without becoming a disclaimer inside every revised sentence. Do not insert pending-run status into finished result prose.

Result prose and tone

  • Lead result paragraphs, abstracts, and conclusions with the supported main finding, contribution, or scientific implication. Let the paragraph land on that result rather than on a secondary cost that the reader can already inspect in a complete table.
  • Let a table carry secondary metrics and tradeoffs when it gives the metric, unit, direction or interpretation, comparison scope, and necessary conditions clearly. A short table pointer is enough; do not repeat a visible value merely to make the prose sound balanced.
  • Keep a condition in prose when omitting it would change the interpretation of fairness, applicability, or the central claim. State it once in the setup, caption, result discussion, or limitations section where it matters, instead of attaching it as a defensive final clause to every positive result.
  • Prefer direct declarative language to defensive framing such as “we acknowledge,” “it should be noted,” or a pre-emptive concession. “But,” “however,” and “although” remain available when they express a real logical dependency; do not use them to manufacture a negative ending after a supported finding.
  • For example, replace “Our method improves AP, but uses more memory” with “Our method improves AP under the matched setting (Table X).” If memory changes deployment feasibility or comparison validity, state that condition plainly where the reader needs it rather than hiding it or repeating it as a rhetorical concession.
  • The same rule applies to Chinese prose: replace “性能更好,但显存更高” with “在评测设置下,该方法取得更高性能(表 X)” when the table already reports memory. State the memory boundary separately when it changes the deployment claim or comparison validity.

Finish and hand off

Check that the changed text answers its intended reader question, follows from the preceding passage, and matches the evidence. Validate affected references and rendering in proportion to the edit. Stop when the requested criteria are met; leave already clear and accurate passages alone. Report substantive changes, remaining evidence gaps, and checks actually performed, not invented readiness.

Independent acceptance-risk assessment belongs to paper-review-panel; official review responses to rebuttal-response-skills; new experiment design to experiment-planner. Use those skills only when the task needs them. For actual figure/table design or layout work, use paper-visual-craft, with paper-framework-figure-studio-pro for framework planning. Caption wording alone does not require redesigning a figure. None of these optional handoffs is a mandatory writing pipeline.

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.