skills/review-prep/SKILL.md
# SKILL: Review Preparation > What to do after the paper is written: surviving rejection, positioning for awards, and persisting without losing the thread. > Based on Carlini (2026) — "How to win a best paper award." --- ## When to use this skill Use this skill when a paper is complete and being prepared for submission, when a rejection arrives, and when evaluating whether a rejected paper is worth resubmitting or should be killed. Invoke with: `/review-prep` or `@reviewer: prepare for subm
npx skillsauth add moralespanitz/research-loop skills/review-prepInstall 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.
What to do after the paper is written: surviving rejection, positioning for awards, and persisting without losing the thread. Based on Carlini (2026) — "How to win a best paper award."
Use this skill when a paper is complete and being prepared for submission, when a rejection arrives, and when evaluating whether a rejected paper is worth resubmitting or should be killed.
Invoke with: /review-prep or @reviewer: prepare for submission
A best paper award is one sample from a distribution. You do not control the sampling process. What you control is the distribution.
The factors outside your control:
Focus on what you can control: the quality, clarity, and timing of the work. Everything else is luck, and luck is not a lever.
Before submitting, assess timing on two axes:
Too early:
Too late:
The sweet spot: You are 6–18 months ahead of where the community will arrive. The problem is real enough that reviewers can see it, but not so worked-over that your contribution is marginal.
Before submitting, list every objection a skeptical reviewer might raise. For each objection, answer:
| Objection | Have you addressed it in the paper? | Should you? | |-----------|-------------------------------------|-------------| | "This problem isn't important" | The introduction must answer this | Yes, always | | "This setup is unrealistic" | The experimental design section | Yes, if the objection is valid | | "Why not just do X instead?" | Related work or discussion | Yes, if X is obvious | | "The results don't generalize" | Ablations and scope section | Yes, if true | | "The evaluation metric is wrong" | Metric justification | Yes, this kills papers |
If there is a valid objection you have not addressed, either run the experiment that answers it, or address it explicitly in the paper with a honest discussion of the limitation.
Do not paper over valid objections. Reviewers notice.
Most papers that eventually receive recognition were rejected at least once first.
The pattern:
The revision between rejection and acceptance is often the most important work on the paper. Use rejection feedback as a diagnostic: if reviewers are confused about X, your explanation of X is not good enough. Fix it.
When to keep revising and resubmitting:
When to kill the paper after rejection:
Log the decision in knowledge_graph.md with status rejected-killed or rejected-revising and the reasoning.
Before submitting, run the Reviewer agent (@reviewer) or manually check:
Methodology:
Claims:
Reproducibility:
The causal annotation test: For every experiment that did not work in the way expected, is there a causal explanation in the paper? "We tried X and it did not work" is not a causal annotation. "We tried X; it did not work because Y, which implies Z" is.
Awards are sometimes given for reasons beyond pure technical quality:
If your paper has done any of these things, make it obvious. Do not hide this in the conclusion. The introduction should signal clearly what the paper is changing, not just what it is adding.
The papers most likely to receive recognition are those that:
You control (1) and (2). Maximize them.
Accept that:
When a rejection arrives:
Do not write angry rebuttals. Do not submit a paper you know is not ready. Do not internalize rejection as a judgment of the idea — it is often a judgment of the timing or the framing.
@reviewer) has audited methodology and claimstesting
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.