Research Rebuttal

• Prefer the canonical directory ./rebuttal/.
• Read upstream context from research-brief.md, artifact-index.md, ./paper-plan/, ./review-loop/, and relevant result artifacts when present.
• Keep outputs legible to later manuscript revision, camera-ready planning, or follow-up review rounds.

Relationship to sibling skills

• research-paper-review should usually happen before rebuttal if the paper still needs a first-pass technical diagnosis.
• research-review-loop should track internal revision rounds and issue closure between rebuttal iterations.
• research-rebuttal starts when there are concrete reviewer comments and a venue-specific response artifact to produce.
• research-novelty-review is a helper when the central dispute is novelty or prior-art overlap rather than general reviewer response.

Handling review inputs

• Pasted text: use directly, but check whether the paste is complete.
• PDF review bundles: extract all review text, scores, and confidence values before analysis.
• Screenshots: transcribe visible review content and flag truncation or unreadable regions.
• OpenReview or CMT links: treat raw platform access as unreliable; ask for pasted review text if needed.
• Paper PDF or source: read as needed to cross-reference challenged claims, tables, or sections.
• If review metadata is incomplete, proceed conservatively and label the missing fields rather than inventing them.

Input contract

• Minimum:
  • concrete reviewer feedback or review text
  • target venue or best-known venue family
• Prefer:
  • scores and confidence values
  • paper PDF, source, or exact section references
  • existing experimental logs, tables, or manuscript diffs
  • deadline and artifact constraints

Hard stops

• Stop if there is no concrete review text or reviewer feedback artifact.
• Stop if the venue materially changes the artifact but cannot be inferred well enough to pick a conservative route.
• Stop if the draft would require invented evidence, fabricated experiments, or unverified manuscript changes.
• In standalone mode, do not force a scaffold pack when a compact direct response is enough.

Output contract

• Primary files:
  • review-analysis.md
  • issue-board.md
  • task-list.md
  • rebuttal-working.md
  • rebuttal-paste-ready.md
• Optional file:
  • ac-note.md
• In orchestrated mode, these live under ./rebuttal/.
• The working draft may contain [INTERNAL] notes; the paste-ready draft must not.

Workflow

1) Route venue and policy constraints first

• Use references/venue_rule_matrix.md to choose the artifact structure:
  • one-shot PDF
  • per-review response
  • threaded discussion
  • rolling revision response
  • single-feedback response
• Use references/platforms_and_policies.md for platform mechanics, anonymity, disclosure, link, revision, and LLM-policy checks.
• If venue information is incomplete, state the assumption and choose the most conservative valid route.
• Treat dated limits, windows, and policy details as unstable. Re-check official venue sources before final submission when those details matter.

2) Analyze reviews and build the issue board

• Summarize each reviewer's decision logic, score, confidence, and likely AC-facing concern in review-analysis.md.
• Build issue-board.md using references/issue_board_guide.md.
• Extract a score matrix first. As a default heuristic, treat reviewers as:
  • Champion: strong accept signal or clearly positive language
  • Persuadable: mixed review or borderline score
  • Entrenched: strongly negative decision logic unlikely to flip
• Spend most rebuttal budget on Persuadable reviewers and committee-facing concerns, while maintaining Champion support.
• Group shared concerns across reviewers and mark severity aggressively:
  • Major-Blocking
  • Major-Addressable
  • Minor
  • Misunderstanding
• Classify reviewer stance as Champion, Persuadable, or Entrenched using references/writing_principles.md.
• Use an explicit issue-board shape rather than free-form notes. For example:

issue_id | reviewer | severity          | category   | strategy | status | shared_with
R1-1     | R1       | Major-Blocking    | baselines  | TBD      | open   |
R2-1     | R2       | Misunderstanding  | novelty    | TBD      | open   |
R3-1     | R3       | Major-Addressable | ablations  | TBD      | open   | R1-1

• If the user asked only for triage or analysis, stop after the analysis and issue board.

3) Choose response strategies per issue

• Use references/response_strategies.md.
• Prefer one or more of:
  • Accept and fix
  • Clarify misunderstanding
  • Partial agree and narrow claim
  • Respectful disagreement
  • Out of scope
  • Escalate to AC
• Strategy choice must depend on factual correctness, acceptance impact, and venue policy constraints, not rhetorical preference.
• Compound strategies are often correct:
  • clarify misunderstanding + accept a presentation fix
  • accept and fix + provide new evidence
  • partial agree + narrow the claim
• Do not promise evidence you do not have. Missing evidence becomes a task, not a rhetorical flourish.

4) Convert strategy into an execution plan

• Fill task-list.md with owner if known, required input, evidence source, whether the task blocks drafting, and whether it changes the manuscript, rebuttal, or both.
• Prefer real evidence over promises. If evidence is missing, turn the gap into an explicit task rather than bluffing.
• Pull in upstream research artifacts when available:
  • research-paper-plan for claim and section mappings
  • research-review-loop for tracked issues across rounds
  • experiment or results artifacts for numbers and provenance

5) Draft the correct artifact

• Draft rebuttal-working.md first, then strip it down into rebuttal-paste-ready.md.
• Match the venue family:
  • one-shot PDF venues: merge repeated concerns and lead with the few issues most likely to affect the decision
  • per-review venues: keep replies self-contained
  • threaded venues: optimize for concise follow-ups and delta replies
  • rolling venues: emphasize revision plan over argument
• Use direct answer -> evidence -> implication structure.
• Keep every response self-contained enough that the reviewer or AC can scan it without hunting through the manuscript.
• For venues with strict character budgets, allocate rough space before writing:
  • opener or global summary: 10-15%
  • per-reviewer core responses: 75-80%
  • closing or summary of changes: 5-10%
• Use the working draft as the evidence-rich version and the paste-ready draft as the platform-safe compressed artifact.
• Example of a good response shape:

[R2] Missing comparison to MethodX
Direct answer: We agree this comparison is decision-relevant and have now run it.
Evidence: Table 2 below shows +2.1 points over MethodX on Dataset A.
Implication: This resolves the concern that our gains came only from benchmark selection.

• Avoid defensive responses such as:
  • "the reviewer failed to notice"
  • "it is obvious"
  • "we will fix this in the camera-ready" without evidence or a venue-legal commitment

6) Run mandatory safety gates

• Provenance gate:
  • every number, experimental result, section reference, and manuscript change must trace to a real source
• Commitment gate:
  • do not claim a manuscript change or experiment unless it already exists or is explicitly labeled as planned
• Coverage gate:
  • every Major-Blocking and Major-Addressable issue must be closed, deferred with justification, or explicitly accepted as a risk
• Verify size limits with scripts/count_limits.sh <file> [--chars|--words|--pages] [--limit N].
• If paper-review/final_issues.json or review-loop/REVIEW_STATE.json exists, cross-check that the rebuttal does not quietly contradict the internal diagnosis.

7) Handle follow-up rounds carefully

• Update the issue board rather than rewriting the whole response from scratch.
• Reply only to new or still-open points.
• Increase technical specificity, not argumentative intensity.
• If a disagreement persists after repeated rounds, summarize the positions cleanly and let the committee adjudicate.
• In multi-round venues, treat the issue board as the source of truth and write delta replies only.

Scripts

• scripts/init_rebuttal_pack.py: create deterministic rebuttal scaffolds in a standalone directory or ./rebuttal/.
• scripts/count_limits.sh: measure chars, words, or rough page equivalents after stripping common markup.

References

• references/issue_board_guide.md
• references/platforms_and_policies.md
• references/response_strategies.md
• references/venue_rule_matrix.md
• references/writing_principles.md
• ../research-pipeline-planner/references/review-stage-contract.md