agentleFS
AlexyskoutnevAlexyskoutnev/research-skills/conclusion-writing/SKILL.md

conclusion-writing

Skill2 starsChanged 3 months agoMITView on GitHub

Write or revise a paper's Conclusion using recipes distilled from dissecting top ML researchers' papers. Use when drafting or editing a conclusion, or when applying feedback to it. Applies the three-paragraph envoi shape, the reprise-not-report rule, the flip-the-shortfall move, the refutable-vista close, and mechanical checklists.

The file

We split this skill into the rules it gives an agent

1 rule. About 0 are common, 0 are distinctive, and 1 is very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈0

    Distinctive · estimate

    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. Very specific:

    Follow conclusion-guide.md in this folder, the complete plain-English method.

    line 8

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “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

Conclusion section (master method)

Follow conclusion-guide.md in this folder, the complete plain-English method. This file is the operating summary.

Process

  1. Keep it a terse envoi. One to three dense paragraphs of prose, never a bulleted future-work list. It is a landing, not a second results section. Name the section for its function, or keep a terse "Conclusion" and earn the terseness. Decide the heading before drafting.
  2. Re-name the system at the filled gap. Open with one past-tense thesis sentence re-naming the system and its one mechanism. Open at the now-filled gap and widen to significance, the introduction run backwards.
  3. Reprise both halves of the evidence, zero new numbers. Make the intro's promise concrete by reprising the load-bearing numbers, both the easy half and the hard half. Introduce no new number, table, or figure; every number is a reprise from Experiments.
  4. Recap the mechanism, do not re-report. Name what the system does once; never re-walk the pipeline the Method already assembled or re-list the results table.
  5. Weld one flat scope clause, then flip the shortfall. Carry a single flat limitation clause inside the recap; the full ledger stays in the Limitations subsection. Flip the structural shortfall into the predicted frontier, feature-not-a-bug, the hard half the paper set out to measure, and treat future work as payload, the named direction the paper opens.
  6. Land a refutable vista on the open problem. Close on one sentence that widens from the artifact to the field, a measured, refutable insight that names the open problem the paper opens, not a summary and not hype.

Core rules

  • One to three paragraphs of prose; never a bulleted future-work list; a landing, not a second results section.
  • Open past-tense, re-naming the system and its one mechanism; open at the filled gap and widen out, the intro run backwards.
  • Recap the mechanism once; never re-report the experiments or re-list a table.
  • Reprise the load-bearing numbers to make the promise concrete; introduce no new number, table, or figure.
  • Each limitation is a named assumption welded to a remedy; the full ledger stays in the Limitations subsection; the close carries one flat scope clause.
  • Flip a structural limit, feature-not-a-bug or an honest tradeoff ledger; treat future work as payload, the named frontier the paper opens.
  • The last sentence is a vista, a measured, refutable insight, no hype, no em dashes.
  • Credit neighbors, then contrast on exactly one axis; never bash.
  • Prose axioms: sentences <= ~28 words, subject and verb early, zero "can"/"could", no bare This/These, no em dashes, numbers paired and attached to exact objects.

Reference file

  • conclusion-guide.md: full guide: term translations, the two-move envoi skeleton, three conclusion recipes with fill-in templates (limitations-as- doorways, the terse envoi, the two-move close), mechanical checklists including the "never in a conclusion" list, the assembly order, and a worked example on a toy system.

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.