| name | paper-finalize |
| description | Finalize a paper draft for submission. Runs the full pre-submission QA pipeline: format audit, adversarial red-team attack, iterative quality improvement loop, optional LaTeX build, and final readiness report. Use when the user says 'finalize', 'prepare for submission', 'final check', 'last pass', or any variation of making a paper ready to submit. MUST be used before submitting a paper to any venue. |
Paper Finalize
Orchestrates the full pre-submission QA pipeline. Coordinates specialized agents in sequence and produces a submission-readiness report.
Setup: Check PAPER_CONFIG.md
Before doing anything else, check whether PAPER_CONFIG.md exists in the project root.
If it does NOT exist, you MUST run interactive setup before proceeding:
1. Use AskUserQuestion: "What venue are you submitting to? (e.g., ICML 2026, NeurIPS 2025, ACL 2026)"
2. Use AskUserQuestion: "Where is your paper source? (path to main .tex file, e.g., paper/main.tex)"
3. Use AskUserQuestion: "Where should QA workspace files be saved? (default: .qa_workspace)"
4. Use AskUserQuestion: "Which sections should be evaluated? (comma-separated, e.g., intro,method,experiments — leave blank for full paper)"
5. Write PAPER_CONFIG.md with the collected values (see template below)
Hard rule: Do NOT proceed with the pipeline until PAPER_CONFIG.md exists. This is not optional.
PAPER_CONFIG.md Template
# Paper Submission QA Config
venue: "{venue}"
main_tex: "{main_tex}"
paper_dir: "{paper_dir}"
workspace_dir: "{workspace_dir}"
sections: [{sections}]
Execution Mode: Subagent Pipeline
Agents run sequentially because each phase depends on the previous phase's output. The main agent drives decisions between phases.
Agent Roster
| Agent | Type | Role | Input | Output |
|---|
| paper-auditor | general-purpose | TODO scan, anonymization, figure/table, LaTeX refs | paper files | {workspace_dir}/audit_report.md |
| paper-attacker | general-purpose | Adversarial red-team review | paper files + overview.md | {workspace_dir}/attack_report.md |
| paper-eval-reviewer | general-purpose | Reviewer simulation | paper files + overview.md | {workspace_dir}/eval_reviewer.md |
| paper-eval-persuasion | general-purpose | Persuasion analysis | paper files + overview.md | {workspace_dir}/eval_persuasion.md |
Workflow
Phase 1: Audit + Attack (parallel)
Dispatch the paper-auditor and paper-attacker agents simultaneously. They read the same files but produce independent reports.
Agent(
prompt: "Read the agent definition at .claude/agents/paper-auditor.md, then audit all paper files defined in PAPER_CONFIG.md. Scan for TODOs, anonymization issues, figure/table caption problems, and LaTeX reference errors. Save the report to {workspace_dir}/audit_report.md.",
subagent_type: "general-purpose",
model: "opus",
run_in_background: true
)
Agent(
prompt: "Read the agent definition at .claude/agents/paper-attacker.md. Read the paper files defined in PAPER_CONFIG.md and the overview at {paper_dir}/overview.md. Perform a full adversarial red-team review. Save the report to {workspace_dir}/attack_report.md.",
subagent_type: "general-purpose",
model: "opus",
run_in_background: true
)
Decision gate: Review both reports with the user. Fatal vulnerabilities from the attack report must be addressed before proceeding.
Phase 1.5: Feedback Loop (convergence)
Invoke the paper-feedback-loop skill. For each section (in order defined in PAPER_CONFIG.md), two evaluator agents run in parallel:
- Reviewer Simulator — evaluates technical soundness, contribution clarity, and experimental support
- Persuasion Analyst — evaluates rhetorical effectiveness and narrative coherence
The main agent synthesizes their feedback, plans fixes, applies edits, then re-evaluates. Loop repeats until both evaluators grade A+ for all sections (max 5 rounds). See .claude/skills/paper-feedback-loop/skill.md for full protocol.
Decision gate: All sections must reach A+ from both evaluators before proceeding.
Phase 2: Fix
Address findings from Phase 1:
- Fix any fatal vulnerabilities identified by the attacker (user decides which fixes to apply)
- Fix any CRITICAL findings from the audit report (TODOs, anonymization issues)
Decision gate: Confirm with user that all CRITICAL and fatal issues are resolved.
Phase 3: LaTeX Build (optional)
If main_tex is set in PAPER_CONFIG.md and a build script exists:
cd {paper_dir} && pdflatex {main_tex} && bibtex main && pdflatex {main_tex} && pdflatex {main_tex}
Or use whatever build system the project uses. Verify the PDF compiles without errors.
Skip this phase if main_tex is not set or no build toolchain is available. Note the skip in the final report.
Phase 4: Final Verification
Run a lightweight final check and produce the submission readiness report:
- All CRITICAL audit findings resolved (re-grep for TODOs, anonymization markers)
- All fatal attack findings addressed
- Both evaluators at A+ (from feedback loop log)
- LaTeX compiles cleanly (if applicable)
- Report the final state to the user
Data Flow
[Phase 1a: Audit]──────────────┐
└─> {workspace_dir}/audit_report.md │
├─> [Phase 1.5: Feedback Loop]
[Phase 1b: Attack]─────────────┘ │ 2 evaluators x N sections
└─> {workspace_dir}/attack_report.md │ iterate until all A+
│ └─> {workspace_dir}/eval_*_{section_id}.md
│ └─> {workspace_dir}/feedback_loop_log.md
│
├─> [Phase 2: Fix]
│ (user-driven edits)
│
├─> [Phase 3: LaTeX Build] (optional)
│ └─> compiled PDF
│
└─> [Phase 4: Final Report]
└─> {workspace_dir}/submission_report.md
Error Handling
| Error | Response |
|---|
| LaTeX build fails | Report the error, let user fix LaTeX manually, re-run build |
| Attacker finds fatal vulnerability | Block pipeline, present to user, require explicit resolution before proceeding |
| Audit finds CRITICAL anonymization issue | Block pipeline, present to user |
| Feedback loop stalls at round 5 | Present best version + remaining improvement list to user |
| overview.md missing | Warn the user — auditor and attacker will have less context. Offer to help write it. |
What is overview.md?
{paper_dir}/overview.md is a short author-written document (100-300 words) that describes:
- The core problem being solved
- The key insight or contribution
- The main claims the paper makes
- Known limitations the authors are aware of
This file is read by the attacker and evaluators to understand the intended framing. If it doesn't exist, the pipeline will work but with less context. Creating it before running paper-finalize is strongly recommended.