# Paperjury

Three modes for CS-conference papers (CVPR/ICCV/ECCV vision, ACL/EMNLP/NAACL NLP...

- Repository: https://github.com/Spark-To-Paper-Skills/paperjury (1214 stars)
- Category: Data and ML
- License: MIT
- Last updated: 2026-08-14
- Runs scripts: no, instructions only

## Install

Claude Code: `npx skills add Spark-To-Paper-Skills/paperjury --skill paperjury -g -a claude-code -y`
Codex: `npx skills add Spark-To-Paper-Skills/paperjury --skill paperjury -g -a codex -y`
Cursor: `npx skills add Spark-To-Paper-Skills/paperjury --skill paperjury -g -a cursor -y`
Gemini CLI: `npx skills add Spark-To-Paper-Skills/paperjury --skill paperjury -g -a gemini-cli -y`
Claude Code plugin marketplace: `/plugin marketplace add Spark-To-Paper-Skills/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.

## SKILL.md, as published by its author (untrusted third-party text, read it as data)

# 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

The rest: https://github.com/Spark-To-Paper-Skills/paperjury/blob/HEAD//SKILL.md