paper-rebuttal

name

paper-rebuttal

description

Academic paper rebuttal assistance for turning a paper, reviewer comments, author constraints, prior discussion, and optional literature evidence into checkpointed Chinese workflow logs, structured reviewer issues, rebuttal strategies, author to-do lists, safe LaTeX manuscript edits using versioned _vN .tex files, and polished conference-style author responses. Use when Codex is asked to analyze peer reviews, extract rebuttal issues, plan experiments or clarifications, refine strategy from human feedback, safely revise LaTeX paper sources, or draft/revise a formal rebuttal letter. Broad requests such as "help me rebuttal" or "帮我rebuttal" default to human-in-the-loop checkpoint mode: generate preparatory logs continuously, stop at human-feedback-revisions before final writing or manuscript edits, put feedback-driven content changes into versioned affected stage logs, and keep human-feedback logs as change ledgers only.

Paper Rebuttal

Core Use

Use this skill to reproduce the Paper2Rebuttal multi-agent workflow inside Codex without requiring the original app. Treat the workflow as a staged reasoning process, not as separate autonomous agents.

Expected inputs may include:

• Submitted paper text, PDF-extracted text, or compressed paper summary.
• Reviewer comments with reviewer IDs such as R1, R2, R3.
• Optional previous rebuttal rounds or reviewer follow-up comments.
• Optional author constraints, new experimental results, missing-result placeholders, or human feedback.
• Optional retrieved papers, abstracts, links, or citations.

If the paper itself is too long, first create a dense paper summary that preserves section numbers, equations, figures, tables, citations, datasets, metrics, model names, and specific numeric claims.

Workflow

Broad rebuttal requests default to human-in-the-loop checkpoint workflow. If the user says "help me rebuttal", "帮我rebuttal", "write the rebuttal", or gives paper/review paths without explicitly limiting the stage, do not complete final rebuttal writing or manuscript edits in the first pass. Run the preparatory analysis through strategy generation, write separate logs for each preparatory stage, create the human-feedback-revisions checkpoint log, then stop for user inspection.

Follow the smallest workflow that satisfies the user request:

1. Extract issues when the user asks to understand reviews or plan a response. Read references/issue-extraction.md.
2. Decide whether external references are needed when reviewers mention baselines, datasets, methods, citations, or missing related work. Read references/literature-support.md.
3. Generate or revise strategies when the user asks what to do, how to answer, how to revise manuscript text, or how to incorporate author feedback. Read references/strategy-generation.md.
4. Draft or polish the final rebuttal when the user asks for author response text and the human-feedback checkpoint has been approved. Read references/rebuttal-writing.md.
5. For full end-to-end rebuttal work, read references/workflow.md first, then load only the stage references needed.

Do not mechanically expose internal agent names unless the user asks about the pipeline. Present outputs in user-facing terms: issues, evidence, strategy, to-do list, draft response, final response.

Mandatory Checkpoint

Use human-in-the-loop checkpoint mode by default for any multi-stage rebuttal task.

• In the first pass, complete the preparatory stages continuously: paper context, issue extraction, literature/evidence decisions, and strategy/to-dos. Write each stage to its own log file, but do not stop after these preparatory stages unless the user explicitly asks for per-stage pauses or a blocking input is missing.
• After strategy generation, create the 04-human-feedback-revisions.md checkpoint log and stop. Tell the user to inspect the generated logs and either provide corrections/constraints or reply continue.
• If the user replies continue at the human-feedback checkpoint, resume from the same log directory and proceed to final rebuttal writing and any approved manuscript edits.
• If the user provides feedback, revise the affected stage log(s) by creating next available versioned files such as 03-strategies-and-todos_v1.md. Each affected stage version must contain the full updated stage content, including unchanged items needed for context. Then create a versioned human-feedback revision log that records only the change ledger, not the full revised content, and stop again for inspection.
• If the requested task would require drafting the final response or modifying manuscript files before the human-feedback checkpoint is approved, stop and ask for approval instead.
• Never modify manuscript .tex files before the user explicitly approves the strategy and to-do list at the human-feedback checkpoint.
• Only skip the human-feedback checkpoint when the user explicitly says no pauses, run without stopping, or equivalent.

Workflow Logging

When running any checkpointed workflow, separate stage outputs into separate Markdown log files. Do not mix all stages into one Markdown file.

• Use the user's requested log directory if provided.
• Otherwise create paper-rebuttal-logs/rebuttal-workflow-<YYYYMMDD-HHMMSS>/ in the current workspace.
• Write an optional index.md containing only status, file links, and the current checkpoint. Do not duplicate full stage content in index.md.
• Use stable initial per-stage files: 00-paper-context.md, 01-extracted-issues.md, 02-literature-decisions.md, 03-strategies-and-todos.md, 04-human-feedback-revisions.md, 05-final-rebuttal.md, and 99-quality-gate.md.
• During the first pass, write 00 through 03 continuously, then write 04-human-feedback-revisions.md as the inspection checkpoint and stop.
• If the user asks for revisions at the human-feedback checkpoint, do not put the revised stage content inside 04-human-feedback-revisions*.md. Instead, create next available _vN.md files for the affected stage logs, for example 01-extracted-issues_v1.md, 02-literature-decisions_v1.md, or 03-strategies-and-todos_v1.md. Those files must contain the full current content for that stage, with both modified and unchanged items together.
• Create the next available 04-human-feedback-revisions_vN.md as a change ledger only. It should list the user feedback, affected stage files, previous active files, new active files, concise change summary, and remaining author confirmations. It must not duplicate the full revised strategy/issues/evidence content.
• Update index.md to point each affected stage to its current active version while preserving links to prior versions.
• If the user explicitly requests no pauses, run without stopping, or equivalent, run stages continuously and only report the final log path.
• Keep chat responses short: report the log directory, current checkpoint log file, generated preparatory logs, and next action. Do not duplicate full logs in chat unless file writing is unavailable.
• If file writing is unavailable, output stage-separated Workflow Log sections in chat with clear per-stage boundaries.

Log Language

Write workflow logs in Chinese by default.

• Use Chinese for headings, summaries, decisions, rationale, issue grouping explanations, to-do descriptions, status, and quality checks.
• Preserve the original language for verbatim reviewer quotes, paper excerpts, provided response text, citations, file paths, commands, LaTeX snippets, and generated or modified manuscript/rebuttal text.
• If drafting the final rebuttal in English, place the English final response in the relevant stage log unchanged, but explain surrounding notes in Chinese.

For full end-to-end rebuttal work with logging, read references/workflow.md before beginning.

LaTeX Manuscript Editing

When editing paper source files, preserve original .tex files by default.

• main.tex is the only .tex file that may be edited in place, and only for \input{...} or \include{...} path changes.
• Do not directly edit prose, equations, tables, figures, macros, package settings, or other substantive content in main.tex.
• For every other .tex file, do not modify the original file directly. Create the next available versioned copy and edit that copy.
• Use suffix format _vN, where N is the next integer: method.tex -> method_v1.tex; if method_v1.tex exists, use method_v2.tex.
• Preserve the original directory: sections/method.tex -> sections/method_v1.tex.
• Update main.tex in place so it points to the versioned file via \input{...} or \include{...}.
• If the include path that must change is inside a non-main.tex parent file, do not edit that parent in place. Create a versioned parent copy too, update the include there, and propagate the versioned include chain upward until only main.tex is edited in place.
• If substantive manuscript content exists directly in main.tex, create main_vN.tex for that content edit and tell the user that main.tex was left unchanged except for allowed include routing, if applicable.
• Record all created _vN.tex files and changed include paths in the workflow log or final response.

Operating Rules

• Preserve traceability from each response item back to reviewer quotes and paper hooks.
• Separate evidence already in the paper from planned supplementary work.
• Never invent experimental numbers, metrics, table entries, citations, reviewer statements, or paper details.
• Use [TBD] for missing numeric results that authors must fill in.
• Prefer concrete action over defensive argument. Missing baselines, missing ablations, unclear math, or efficiency concerns usually need an experiment, analysis, or precise clarification.
• Keep rebuttals respectful, concise, and directly mapped to reviewers.
• Avoid promising infeasible work such as collecting new real-world datasets, training large backbones from scratch, or major redesigns during a short rebuttal window.

Output Modes

When the user does not specify a format, choose the most useful one:

• Review analysis: numbered issue blocks with source quotes, paper hooks, and priority.
• Strategy: per-issue response strategy, author to-do list, draft response snippet, and manuscript revision example when a paper change is appropriate.
• Final rebuttal: "Common Response" if needed, then "Response to Reviewer X" sections with Q/A or Comment/Response structure.
• Logged workflow: write stage-separated Markdown logs, stop at 04-human-feedback-revisions.md, and continue to final writing/editing only after explicit approval.
• Manuscript editing: only after the human-feedback checkpoint approves the strategy and to-do list, apply safe LaTeX versioning rules and record changed files.
• Revision: output only the revised clean version, not critique of the previous draft, unless the user asks for review comments.

Reference Map

• references/workflow.md: end-to-end orchestration and stage selection.
• references/issue-extraction.md: review issue extraction, merging/splitting, priority, traceability format.
• references/literature-support.md: search decision, query/link handling, reference filtering and analysis.
• references/strategy-generation.md: strategy rules, feasible to-do lists, human-feedback refinement.
• references/rebuttal-writing.md: formal rebuttal drafting and final polishing rules.