/paperjury

name: paperjury
description: Three modes for CS-conference papers (CVPR/ICCV/ECCV vision, ACL/EMNLP/NAACL NLP, ICLR/NeurIPS/ICML/AAAI ML). DIRECT-EDIT mode (common): the user describes a change in Chinese or English and the manuscript (LaTeX or Markdown) is edited directly through a CS-venue writing toolkit with author sign-off (use for 改这段 / 把中文想法写成 latex / polish / de-AI / translate / compress a passage). REVIEW mode (occasional, pre-submission): harden the paper through an adversarial courtroom review engine (N holistic domain reviewers / contestability routing / two-sided trial / three-way verdict / clerk-converged multi-round loop) with consensus-gated, author-signed revisions (use for review / critique / 审稿 / 评审 / mock-review). AUTO mode (unattended, opt-in via /goal): run the review-revise loop toward a verifiable goal, applying safe fixes under a drift-bounded policy and queueing risky ones. Resolves all inputs at runtime, no hardcoded paths. Not a from-scratch drafter (use ml-paper-writing) and not an official-venue rebuttal.
version: 1.2.1
author: Yiran Wang
license: MIT
tags: [Academic Writing, Peer Review, Adversarial Review, CVPR, ICCV, ECCV, ACL, EMNLP, NAACL, ICLR, NeurIPS, ICML, AAAI, Workflow, LaTeX]

PaperJury (CS-conference paper review and editing)

PaperJury edits and hardens any CS-conference paper. It runs in three modes. In **direct-edit mode** (the common case) the user describes a change in Chinese or English and the LaTeX is edited directly through a CS-venue writing toolkit, with author sign-off. In **review mode** (occasional, pre-submission) it exposes the manuscript to a harsh, multi-perspective courtroom review engine that adjudicates each issue (N holistic domain reviewers -> contestability routing -> two-sided trial -> three-way verdict, with a polish track and a clerk-converged multi-round loop), gates every change behind consensus, and tracks issues in a durable ledger. In **auto mode** (unattended, opt-in via `/goal`) it runs that same engine toward a verifiable goal, applying safe fixes under a drift-bounded policy and queueing the risky ones for one human pass on return. All modes share the same writing toolkit, hard rules, ledger, and author sign-off (auto via up-front policy sign-off plus the queue, see hard rule 1).

This skill is **fully generic**. It ships no hardcoded paths, no project files, and no embedded paper. Everything specific to a given paper (where the manuscript is, the venue, who signs off, the house style) is resolved at runtime or supplied by a config the *project* owns. The skill itself is the backbone; any concrete paper is just an instantiation of it.

Scope: CS conferences only. Three venue families, each with its own style profile:

• **Vision**: CVPR, ICCV, ECCV, WACV
• **NLP**: ACL, EMNLP, NAACL, COLING
• **ML**: ICLR, NeurIPS, ICML, AAAI, COLM

When to use / when not

Three modes, one skill. Pick by what the user is asking for:

• **Direct-edit mode (the common case).** The user describes a change in Chinese

(or English) and wants the LaTeX edited directly: "把这段改成...", "polish this paragraph", "把我对 intro 的想法写成 LaTeX", "tighten this". No review panel; go straight to drafting the patch through the writing toolkit, with author sign-off.

• **Review mode (occasional, pre-submission).** The user wants the paper critiqued

or hardened: review / critique / 审稿 / 评审 / mock-review, or iterating a draft to clear reviewer-raised issues. This runs the courtroom review engine (`references/review-engine-v3.md`).

• **Auto mode (unattended).** The user opts in via `/goal` (or config `mode: auto`)

to run the review-revise loop AFK toward a verifiable goal. Establish the spine up front (the one human step), then the engine applies safe fixes under the bounded-aggressive policy and queues the rest. The drafter input passes the significance floor (`node scripts/ledger.js floor`: valid-fixable majors only) and the ledger view is initialized collapsed (`--display collapse`: minors fold into a Minor digest, majors stay itemized). See `references/auto-mode.md`. Never self-detect auto; it is explicit only.

Do NOT use for: writing a paper from scratch (use `ml-paper-writing`), figure or diagram generation (use `academic-plotting`), or an official-venue rebuttal (this is a pre-submission self-hardening loop, no score gate).

Soft update reminder: at the start of each PaperJury invocation, before choosing the mode or editing a manuscript, run `node scripts/check-update.js` from the skill root unless `PAPERJURY_DISABLE_UPDATE_CHECK=1` is set. If it reports an available update, show the notice once and continue. If the check is skipped, silent, or cannot reach GitHub, continue without mentioning it; update checks are never allowed to block review or editing.

The three primitives

This paradigm is expressed as **Skill + Workflow + Memory**. Each carries one concern; together they replace the heavy per-round file-and-flag machinery a hand-rolled version accumulates.

1. **Skill (this folder) = entry point + methodology.** The protocol, the reviewer panel, the contestability routing, the writing toolkit, the human gates. Detail in `references/review-engine-v3.md`, `references/reviewer-personas.md`, `references/writing-toolkit.md`. 2. **Workflow = fan-out engine.** The semantic, no-human-in-the-middle steps run as Workflows (parallelism + schema-validated output by construction). The simple panel is `workflows/review-panel.workflow.js`; the v3 courtroom engine is `assign-reviewers` -> `reading-check` -> `coverage-auditor` -> `merge` -> {`trial` (+ escalate) || `polish`} -> `recall-audit` -> `drafter` -> {`edit-audit` | `meaning-audit`} -> `clerk`. The DETERMINISTIC guards run orchestrator-side via Bash between workflow calls (the Workflow sandbox has no fs): `scripts/` holds `decompose`, `extract-docx`, `ledger`, `journal`, `apply-patch`, `anchor-diff`, `cross-ref`, `spine`, `rekey`,