agentleFS
acprkacprk/crypto-research-agents/skills/paper-playbook/SKILL.md

paper-playbook

Skill15 starsChanged 10 days agoMITView on GitHub

Use when drafting or restructuring a cryptography paper (IACR LNCS / IACR journal / security-conference format). Gives the overall skeleton, page budget, and the rhetorical moves of every section from title to appendix, with good/bad toy examples.

The file

We split this skill into the rules it gives an agent

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

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈1

    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:

    Write CLAIMS.md rows for each contribution.

    line 60
  2. Distinctive:

    After each section, run the section's checklist (end of each file).

    line 64

≈ “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

Paper Playbook — structure and rhetorical moves for crypto papers

The playbook fixes the form of a paper; the content is always rewritten for the new paper. Templates here are structures, not wording to copy.

Five principles (read first)

  1. Every number has one source. Abstract, intro, body, tables and appendix quote the same value from the same row of EVIDENCE.md. No number enters the paper without an EVIDENCE row (SPEC §3). Numbers are generated or grep-checked, never retyped from memory.
  2. Write falsifiable claims first, then try to break them. Each contribution is first written as one sentence in CLAIMS.md; the falsifier and reviewer-sim agents attack it before the prose is polished.
  3. Form is fixed, wording is new. Reuse the skeleton and the moves, never the sentences of a previous paper.
  4. The body carries the weight; the appendix only supplements. Reviewers are not obliged to read appendices. No claim in the body may depend solely on an appendix.
  5. Late edits are only necessary and verifiable ones. In the last 24 hours before a deadline, fix errors only; no stylistic rewrites.

Section files

filesection
sections/00_overall_structure.mdskeleton, page budget, layout hard rules, notation freeze
sections/01_title.mdtitle patterns and anti-patterns
sections/02_abstract.mdthree-part paradigm (state of the art → technique → results/artifact)
sections/03_introduction.mdfunnel → pipeline → objective equation → open question
sections/04_contributions.mdlead-in + ordered bullets; wording rules
sections/05_technique_overview.mdrecall routes → reduce to questions → insights answer them
sections/06_related_work.mdorganise by axis not by time; comparison table; bridge paragraph
sections/07_preliminaries.mdcompact notation table, only what is reused
sections/08_main_construction.mdstatement → construction → cost/selection rule
sections/09_security_correctness.mdsecurity claim, attack checklist, correctness/noise
sections/10_experiments.mdnine-part evaluation section; number discipline
sections/11_conclusion.mdtwo-to-three sentence conclusion
sections/12_appendix.mdappendix organisation; "not load-bearing" rule
examples/toy_abstracts.mdgood/bad abstracts for three toy papers
examples/toy_intro_and_contributions.mdtoy intro funnel + contribution list, good vs bad
examples/toy_overview_and_related.mdtoy technique overview and related-work table

Toy papers used throughout (all numbers are invented and illustrative):

  • T1 (FHE): "faster programmable bootstrapping (PBS) via LUT packing" — pack several small lookup tables into one test polynomial.
  • T2 (symmetric): "a new 6-round differential distinguisher for a toy SPN" found by SAT-based trail search.
  • T3 (protocols): "PSI with lower communication" via a toy OPRF + cuckoo-hash variant.

Workflow (used by the writer agent)

  1. Freeze notation and the framework's one-word name (00_overall_structure.md).
  2. Write CLAIMS.md rows for each contribution; get falsifier verdicts.
  3. Draft in this order: contributions → technique overview → main construction → experiments → related work → introduction → abstract → title → conclusion. (The abstract is written last because it summarises the other sections.)
  4. After each section, run the section's checklist (end of each file).
  5. Hand to reviewer-sim; iterate; hand to submission-rebuttal.

Related skills

  • abstract-craft, technique-overview, related-work-writing, experiments-writing, venue-calibration, polish-writing
  • LaTeX skeleton: templates/paper/.

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.