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.
In this repository29 other files it gives its agents.
- AGENTS.mdAGENTS.md
- CLAUDE.mdCLAUDE.md
- abstract-craftSkill
- anonymize-checkSkill
- artifact-packSkill
- baseline-pinSkill
- bench-protocolSkill
- bib-verifySkill
- camera-readySkill
- eprint-searchSkill
- experiments-writingSkill
- falsifySkill
- figure-harvestSkill
- idea-mining-loopSkill
- lean-bridgeSkill
- lit-matrixSkill
- log-to-evidenceSkill
- mock-reviewSkill
- paper-figuresSkill
- param-estimationSkill
- phase-gateSkill
- polish-writingSkill
- reading-notesSkill
- rebuttalSkill
- related-work-writingSkill
- sage-checkSkill
- technique-overviewSkill
- textbook-indexSkill
- venue-calibrationSkill
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
- Very specific: line 60
Write CLAIMS.md rows for each contribution.
- Distinctive: line 64
After each section, run the section's checklist (end of each file).
≈ “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.
Files
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)
- 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. - Write falsifiable claims first, then try to break them. Each contribution is
first written as one sentence in
CLAIMS.md; thefalsifierandreviewer-simagents attack it before the prose is polished. - Form is fixed, wording is new. Reuse the skeleton and the moves, never the sentences of a previous paper.
- 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.
- Late edits are only necessary and verifiable ones. In the last 24 hours before a deadline, fix errors only; no stylistic rewrites.
Section files
| file | section |
sections/00_overall_structure.md | skeleton, page budget, layout hard rules, notation freeze |
sections/01_title.md | title patterns and anti-patterns |
sections/02_abstract.md | three-part paradigm (state of the art → technique → results/artifact) |
sections/03_introduction.md | funnel → pipeline → objective equation → open question |
sections/04_contributions.md | lead-in + ordered bullets; wording rules |
sections/05_technique_overview.md | recall routes → reduce to questions → insights answer them |
sections/06_related_work.md | organise by axis not by time; comparison table; bridge paragraph |
sections/07_preliminaries.md | compact notation table, only what is reused |
sections/08_main_construction.md | statement → construction → cost/selection rule |
sections/09_security_correctness.md | security claim, attack checklist, correctness/noise |
sections/10_experiments.md | nine-part evaluation section; number discipline |
sections/11_conclusion.md | two-to-three sentence conclusion |
sections/12_appendix.md | appendix organisation; "not load-bearing" rule |
examples/toy_abstracts.md | good/bad abstracts for three toy papers |
examples/toy_intro_and_contributions.md | toy intro funnel + contribution list, good vs bad |
examples/toy_overview_and_related.md | toy 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)
- Freeze notation and the framework's one-word name (
00_overall_structure.md). - Write
CLAIMS.mdrows for each contribution; get falsifier verdicts. - 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.)
- After each section, run the section's checklist (end of each file).
- Hand to
reviewer-sim; iterate; hand tosubmission-rebuttal.
Related skills
- abstract-craft, technique-overview, related-work-writing, experiments-writing, venue-calibration, polish-writing
- LaTeX skeleton:
templates/paper/.
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
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.

