SuperAPI AI Directory

camera-ready-finalizer

Writing & research

View repository

Updated 10-15 07:42

About this skill

Camera-Ready Finalizer

Finalize an accepted paper so the submitted camera-ready version is consistent, de-anonymized, claim-safe, and ready to hand off to code release or artifact evaluation.

Use this skill when:

  • a paper has been accepted and the user needs the camera-ready version
  • author-response or discussion promises must be checked against the final PDF
  • anonymized submission text must become final author-facing text
  • acknowledgements, author metadata, code links, project pages, or funding statements must be added
  • final figures, tables, captions, appendix, supplement, and references must be synchronized
  • new rebuttal experiments or reviewer-requested edits must be integrated cleanly
  • the paper needs a final claim/evidence/citation/code-release consistency pass before upload
  • camera-ready or publisher-visible source must be cleaned of agent-private files, internal result docs, plotting scripts, raw CSVs, reviewer/rebuttal scratch, and private paths

Do not use this skill for pre-submission readiness. Use submit-paper before initial submission. Use rebuttal-strategist while reviews are still active. Use release-code for the public code repository after paper-facing obligations are clear.

Pair this skill with:

  • rebuttal-strategist to recover reviewer issues, response promises, and promised revisions
  • paper-evidence-board to close final claim/evidence/provenance/risk/action/handoff links
  • figure-results-review to recheck final figures, captions, and tables after edits
  • citation-audit for final BibTeX, citation, label, and metadata correctness
  • citation-coverage-audit when accepted-paper edits reveal missing related work
  • conference-writing-adapter for final wording of accepted reviewer criticism or limitations
  • submit-paper for final format and compile checks
  • release-code and artifact-evaluation-prep for public code and artifact handoff
  • add-git-tag when marking the accepted/camera-ready milestone
  • research-project-memory when final paper status should persist across sessions

Skill Directory Layout

<installed-skill-dir>/
├── SKILL.md
└── references/
    ├── claim-evidence-final-lock.md
    ├── de-anonymization.md
    ├── final-submission-audit.md
    ├── memory-writeback.md
    ├── rebuttal-promise-audit.md
    ├── release-handoff.md
    ├── report-template.md
    └── supplement-consistency.md

Progressive Loading

  • Always read references/rebuttal-promise-audit.md, references/de-anonymization.md, references/claim-evidence-final-lock.md, and references/final-submission-audit.md.
  • Read references/supplement-consistency.md when appendix, supplement, checklist, or extra material exists.
  • Read references/release-handoff.md when code, project page, artifact, data, checkpoints, or reproduction links are involved.
  • Read references/report-template.md before writing the final report.
  • Read references/memory-writeback.md when the project has memory/, component .agent/ folders, or the user asks for persistent memory.
  • If venue-specific camera-ready rules matter, verify current official venue instructions before making hard claims about page limits, required sections, licenses, checklists, or upload fields.

Core Principles

  • Camera-ready is a consistency and obligation closeout, not a new paper rewrite.
  • Every rebuttal promise should be either fulfilled, explicitly superseded, or documented as not applicable.
  • De-anonymization must be complete but should not introduce new claims or unsupported links.
  • Final claims must match final evidence, figures, tables, supplement, and code.
  • New post-acceptance edits should reduce risk, not reopen novelty or evaluation disputes.
  • The main paper, appendix, supplement, metadata, and code links must tell the same story.
  • The final output should leave a clear handoff to release, artifact evaluation, tagging, and archival memory.
  • Do not record local TeX availability as durable paper state. Use the project/worktree compile backend (local, Overleaf-GitHub, CI, or unknown) to decide where final compile evidence comes from.
  • Prefer a dedicated paper worktree under paper-worktrees/ for camera-ready finalization when the main paper branch must preserve the submitted or arXiv state.
  • Treat final camera-ready source as camera-ready-public or publisher-artifact unless the user explicitly says the source package remains private.

Step 1 - Recover Acceptance Context

Collect:

  • paper directory and main LaTeX file
  • whether the final version lives in paper/ or a paper-worktrees/ camera-ready worktree
  • target venue and camera-ready deadline
  • acceptance email, meta-review, reviews, discussion, and author responses
  • rebuttal promise list, if available
  • current accepted draft and current camera-ready draft
  • final figures, tables, supplement, appendix, checklist, and bibliography
  • author list, affiliations, acknowledgements, funding, project/code/data links
  • code release or artifact expectations
  • project memory IDs such as CLM-###, EVD-###, RSK-###, ACT-###, REV-###, or PROM-###

If no promise list exists, create one from reviews, rebuttal, and discussion before editing the paper.

Step 2 - Audit Rebuttal Promises

Read references/rebuttal-promise-audit.md.

Build a promise ledger:

  • reviewer/source
  • promise or implied commitment
  • required paper change
  • current status
  • location in final draft
  • evidence or artifact link
  • risk if omitted

Statuses:

  • fulfilled
  • partially-fulfilled
  • superseded
  • not-applicable
  • missing
  • needs-author-decision

Do not silently drop a promise because it is inconvenient. If a promise cannot be fulfilled, mark the risk and draft a conservative note or limitation if needed.

Step 3 - De-Anonymize and Restore Final Metadata

Read references/de-anonymization.md.

Check:

  • author names, order, affiliations, emails, and footnotes
  • acknowledgements, funding, compute grants, institutional resources
  • code, data, project page, model, and appendix links
  • self-citations and anonymized references
  • removed anonymity placeholders
  • PDF metadata and artifact metadata where applicable
  • license, copyright, and publisher-specific final metadata if required

Do not invent funding, affiliation, or author-order details. Ask the user if a required personal/institutional detail is missing.

Step 4 - Lock Claims Against Final Evidence

Read references/claim-evidence-final-lock.md.

For each main claim:

  • final paper location
  • supporting figure/table/theorem/experiment/citation
  • final status: supported, narrowed, moved-to-appendix, limitation, or cut
  • whether new rebuttal experiments changed the claim
  • whether captions and result prose match final numbers
  • whether supplement and code agree with the paper

If a claim is unsupported, either narrow it, move it to limitations/future work, or cut it.

Step 5 - Check Supplement and Appendix Consistency

Read references/supplement-consistency.md when relevant.

Check:

  • main paper references to appendix/supplement resolve
  • appendix numbering, figure/table labels, and cross-references are correct
  • supplement claims do not contradict the main paper
  • extra experiments are summarized consistently
  • reviewer-requested details are easy to find
  • checklists, ethics, limitations, broader impacts, and reproducibility sections match final venue requirements

Step 6 - Run Final Submission Audit

Read references/final-submission-audit.md.

Check:

  • venue camera-ready instructions and upload requirements
  • page limits and final formatting
  • compile status and final PDF sanity
  • bibliography and metadata
  • labels, references, figures, tables, algorithms, equations, and appendices
  • stale TODOs, comments, draft macros, anonymization text, or hidden placeholders
  • public or publisher-visible source hygiene: no internal figure/table descriptions, reviewer notes, private paths, or draft-only comments in .tex files
  • public or publisher-visible tree hygiene: no .agent/, AGENTS.md, CLAUDE.md, raw CSVs, internal result docs, plotting scripts, notebooks, provenance ledgers, reviewer/rebuttal scratch, or private paths in the source package
  • final title, abstract, author metadata, and PDF filename
  • final link reachability if links are included

Use citation-audit and submit-paper for detailed checks when needed.

If the compile backend is local, detect the compiler at runtime before compiling. If the backend is Overleaf-GitHub, confirm the GitHub remote, push the camera-ready source when requested, and ask the user to compile in Overleaf. If the backend is CI, use CI logs and artifacts. Use remote logs or screenshots to drive any final LaTeX fixes.

Step 7 - Prepare Release and Artifact Handoff

Read references/release-handoff.md when relevant.

Produce handoff items for:

  • release-code: repository visibility, README, license, citation file, tag, model/data links, reproduction commands
  • artifact-evaluation-prep: install instructions, expected runtime, minimal demo, hardware, checkpoints, data, troubleshooting
  • add-git-tag: accepted/camera-ready milestone summary
  • project memory closeout

Keep paper finalization separate from code release, but make obligations explicit.

Step 8 - Write the Camera-Ready Report

Read references/report-template.md.

If saving to a project and no path is given, use:

docs/submission/camera_ready_audit_YYYY-MM-DD_<venue>.md

The report must include:

  • readiness decision
  • blocking issues
  • promise ledger
  • de-anonymization status
  • final claim/evidence lock
  • supplement/appendix consistency
  • final submission audit
  • release/artifact handoff
  • memory update section

Step 9 - Write Back to Project Memory

Read references/memory-writeback.md when memory exists.

Update:

  • memory/decision-log.md: acceptance and camera-ready decisions
  • memory/claim-board.md: final claim status
  • memory/evidence-board.md: final paper-ready evidence and artifact links
  • memory/risk-board.md: any residual accepted risks
  • memory/action-board.md: final blockers, release tasks, artifact tasks, and tag tasks
  • memory/source-visibility-board.md: final source visibility tier, cleanup gate, public-clean audit status, and remaining source-package blockers
  • paper/.agent/: camera-ready status, final metadata, final PDF path, final upload notes
  • rebuttal/.agent/: promise fulfillment status and accepted outcome

Final Sanity Check

Before finalizing:

  • all rebuttal promises are accounted for
  • author metadata and acknowledgements are complete
  • no anonymity placeholders remain
  • final claims match final evidence
  • figures/tables/captions/supplement/code links are consistent
  • final references and labels are clean or routed to citation-audit
  • final format is clean or routed to submit-paper
  • final source visibility is clean or routed to submit-paper / source cleanup
  • code/artifact/release obligations are routed
  • project memory records the accepted/camera-ready state