ICLR Workflow
Use this as the project-management skill for an ICLR submission. Always replace dates with the
current cycle's official deadlines and work backwards from OpenReview cutoffs.
ICLR is a conference, not a journal: it has no standing editor-in-chief and no article-processing
charge. The rotating leadership is the per-edition General Chair, Senior Program Chair, and Program
Chairs (2026 General Chair: Carl Vondrick; Senior PC: Bharath Hariharan; PCs: Raffel, Pinto, Yang,
Faust, verified 2026-06-22), and the cost model is registration fees, not APCs — proceedings are
open-access on OpenReview. Conference organizers rotate yearly, so re-check the current CFP and
committees page rather than carrying a name forward.
Milestones
- Fit decision: confirm the paper has a learning-representation contribution and a credible ICLR
audience.
- Evidence lock: freeze the main claim, core baselines, ablations, and reproducibility path.
- Abstract deadline: submit a real abstract and verify author list, conflicts, subject areas, and
OpenReview profiles.
- Paper deadline: upload anonymized PDF, supplement, code/data package, disclosures, and required
fields.
- Review release: triage reviewer concerns and assign owners for evidence, wording, and revision.
- Discussion: respond, upload allowed revisions, maintain a concise changelog, and escalate only
through official channels.
- Decision: archive reviews, meta-review, author discussion, and final submitted version.
- Acceptance: complete camera-ready, poster, slides, video, project page, public artifacts, and
registration.
Operating rules
- Maintain one source-of-truth checklist for OpenReview fields and file names.
- Run an anonymity audit after every PDF, supplement, code, or demo change.
- Keep a "reviewer can verify this in five minutes" path for each major claim.
- Do not add new experiments during discussion unless they clarify an already submitted claim and
current rules allow the revision.
Phase ownership and risk
ICLR's timeline differs from venues with a short rebuttal: the public discussion phase is long, and
revisions you upload remain visible. Plan for an extended, public exchange, not a one-shot rebuttal.
| Phase |
Owner focus |
ICLR-specific risk |
| Abstract deadline |
Profiles, conflicts, real abstract |
Placeholder abstract or incomplete profile |
| Paper deadline |
Anonymized PDF, supplement, disclosures |
Identity leak in code or links |
| Review release |
Triage, assign evidence owners |
Reacting to every score instead of the AC's concern |
| Discussion |
Replies, allowed revisions, changelog |
Promising runs the cycle's rules disallow |
| Camera-ready |
De-anonymize, fulfill promises |
Final PDF drifts from the meta-review |
Worked vignette
A two-person team plans backward from the OpenReview paper deadline for an interpretability paper.
They lock the main claim and core ablation early, reserve the final days for an anonymity audit of
the PDF and code ZIP, and pre-assign discussion roles: one owns evidence replies, one owns wording
and the changelog. When reviews land they already have a "verify in five minutes" probe script, so
the public thread stays concrete.
Reviewer-pushback patterns to schedule around
- "We need a new experiment fast." Pre-build a probe or ablation harness so small results are cheap.
- "Anonymity slipped after an edit." Re-run the audit after every PDF, supplement, or code change.
- "Deadline confusion." Treat the current cycle's OpenReview dates as the single source of truth.
Output format
[Current stage] idea / experiments / writing / submission / discussion / accepted
[Next deadline] <official date and source, or unknown>
[Critical path] <three tasks that determine readiness>
[Anonymity checkpoint] pass / needs audit
[Owner map] <task -> person or role>
Source: brycewang-stanford/Awesome-Journal-Skills → ICLR-Skills/skills/iclr-workflow/SKILL.md
1---2name: iclr-workflow3description: Use when planning an ICLR project timeline from topic selection through OpenReview submission, discussion, revision, decision, camera-ready, poster, video, and public artifact release. Use when sequencing milestones against the current cycle's OpenReview deadlines, budgeting time for the long public discussion phase, or assigning owners for anonymity audits and reviewer-verifiable evidence paths.4---5
6
7# ICLR Workflow
8
9Use this as the project-management skill for an ICLR submission. Always replace dates with the
10current cycle's official deadlines and work backwards from OpenReview cutoffs.
11
12ICLR is a conference, not a journal: it has no standing editor-in-chief and no article-processing
13charge. The rotating leadership is the per-edition General Chair, Senior Program Chair, and Program
14Chairs (2026 General Chair: Carl Vondrick; Senior PC: Bharath Hariharan; PCs: Raffel, Pinto, Yang,
15Faust, verified 2026-06-22), and the cost model is registration fees, not APCs — proceedings are
16open-access on OpenReview. Conference organizers rotate yearly, so re-check the current CFP and
17committees page rather than carrying a name forward.
18
19## Milestones
20
21- Fit decision: confirm the paper has a learning-representation contribution and a credible ICLR
22 audience.
23- Evidence lock: freeze the main claim, core baselines, ablations, and reproducibility path.
24- Abstract deadline: submit a real abstract and verify author list, conflicts, subject areas, and
25 OpenReview profiles.
26- Paper deadline: upload anonymized PDF, supplement, code/data package, disclosures, and required
27 fields.
28- Review release: triage reviewer concerns and assign owners for evidence, wording, and revision.
29- Discussion: respond, upload allowed revisions, maintain a concise changelog, and escalate only
30 through official channels.
31- Decision: archive reviews, meta-review, author discussion, and final submitted version.
32- Acceptance: complete camera-ready, poster, slides, video, project page, public artifacts, and
33 registration.
34
35## Operating rules
36
37- Maintain one source-of-truth checklist for OpenReview fields and file names.
38- Run an anonymity audit after every PDF, supplement, code, or demo change.
39- Keep a "reviewer can verify this in five minutes" path for each major claim.
40- Do not add new experiments during discussion unless they clarify an already submitted claim and
41 current rules allow the revision.
42
43## Phase ownership and risk
44
45ICLR's timeline differs from venues with a short rebuttal: the public discussion phase is long, and
46revisions you upload remain visible. Plan for an extended, public exchange, not a one-shot rebuttal.
47
48| Phase | Owner focus | ICLR-specific risk |
49| --- | --- | --- |
50| Abstract deadline | Profiles, conflicts, real abstract | Placeholder abstract or incomplete profile |
51| Paper deadline | Anonymized PDF, supplement, disclosures | Identity leak in code or links |
52| Review release | Triage, assign evidence owners | Reacting to every score instead of the AC's concern |
53| Discussion | Replies, allowed revisions, changelog | Promising runs the cycle's rules disallow |
54| Camera-ready | De-anonymize, fulfill promises | Final PDF drifts from the meta-review |
55
56## Worked vignette
57
58A two-person team plans backward from the OpenReview paper deadline for an interpretability paper.
59They lock the main claim and core ablation early, reserve the final days for an anonymity audit of
60the PDF and code ZIP, and pre-assign discussion roles: one owns evidence replies, one owns wording
61and the changelog. When reviews land they already have a "verify in five minutes" probe script, so
62the public thread stays concrete.
63
64## Reviewer-pushback patterns to schedule around
65
66- "We need a new experiment fast." Pre-build a probe or ablation harness so small results are cheap.
67- "Anonymity slipped after an edit." Re-run the audit after every PDF, supplement, or code change.
68- "Deadline confusion." Treat the current cycle's OpenReview dates as the single source of truth.
69
70## Output format
71
72```text
73[Current stage] idea / experiments / writing / submission / discussion / accepted
74[Next deadline] <official date and source, or unknown>
75[Critical path] <three tasks that determine readiness>
76[Anonymity checkpoint] pass / needs audit
77[Owner map] <task -> person or role>
78```
79
80---
81
82**Source:** [`brycewang-stanford/Awesome-Journal-Skills`](https://github.com/brycewang-stanford/Awesome-Journal-Skills) → `ICLR-Skills/skills/iclr-workflow/SKILL.md`
thedixitjain