rebuttal skill

Workflow 4: Rebuttal

Prepare and maintain a grounded, venue-compliant rebuttal for: $ARGUMENTS

Scope

This skill is optimized for:

• text-only rebuttal under strict character/word limits (e.g. ICML single-document)
• per-reviewer thread responses where each reviewer renders independently (e.g. OpenReview-style)
• multiple reviewers with shared and reviewer-specific concerns
• follow-up rounds after the initial rebuttal
• safe drafting with no fabrication, no overpromise, and full issue coverage

This skill does not:

• run new experiments automatically
• generate new theorem claims automatically
• edit or upload a revised PDF
• submit to OpenReview / CMT / HotCRP

If the user already has new results, derivations, or approved commitments, the skill can incorporate them as user-confirmed evidence.

Lifecycle Position

Workflow 1:   idea-discovery
Workflow 1.5: experiment-bridge
Workflow 2:   auto-review-loop (pre-submission)
Workflow 3:   paper-writing
Workflow 4:   rebuttal (post-submission external reviews)

Constants

• VENUE = ICML — Default venue. Override if needed.
• RESPONSEMODE = TEXTONLY — v1 default.
• REVIEWERMODEL = gpt-6-astra** — Default model for the Codex backend. Used for internal stress-testing. Manual backend uses a model the user chooses — it must be a recognized model from a different family (OpenAI, Anthropic, Google, DeepSeek, Moonshot/Kimi, Qwen).
• REVIEWERBACKEND = codex** — Default: Codex MCP (xhigh). Override with — reviewer: oracle-pro for Oracle MCP, or — reviewer: manual for Manual Review MCP. If manual-review MCP is unavailable, stop and print the install command; do not fall back to Codex. See shared-references/reviewer-routing.md.
• MAXINTERNALDRAFTROUNDS = 2** — draft → lint → revise.
• VENUEMODE = singledocument — singledocument for one shared author response, or perreviewer_thread when each reviewer thread renders independently. Confirm the venue/interface before drafting if unclear. Affects Phase 4/7 output shape.
• STRESSTESTROUNDSBASE = 1 — One external reviewer critique round on the full response set. Add focused rounds for reviewerpriority: pivotal responses, terminating when the reviewer returns no new substantive issues. Hard cap at 5.
• MAXFOLLOWUPROUNDS = 3 — per reviewer thread.
• AUTOEXPERIMENT = false** — When true, automatically invoke /experiment-bridge to run supplementary experiments when the strategy plan identifies reviewer concerns that require new empirical evidence. When false (default), pause and present the evidence gap to the user for manual handling.
• QUICKMODE = false — When true, only run Phase 0-3 (parse reviews, atomize concerns, build strategy). Outputs ISSUEBOARD.md + STRATEGY_PLAN.md and stops — no drafting, no stress test. Useful for quickly understanding what reviewers want before deciding how to respond.
• REBUTTALDIR = rebuttal/**
• RENDERHTML = true — When true (default), auto-render rebuttal/REBUTTALDRAFTrich.md (the detailed reviewer-facing draft) to HTML after Phase 6 / Phase 8 finalization. Uses full Codex review gate (final pre-submission deliverable — reviewer-facing content, render fidelity matters). The plain-text PASTEREADY.txt is NOT rendered (it's character-counted plain text by design). Set false to skip, or pass — render html: false.

Override: /rebuttal "paper/" — venue: NeurIPS, character limit: 5000

Reviewer Calling Convention

When calling the reviewer for stress-testing, branch on REVIEWER_BACKEND:

If REVIEWERBACKEND = codex: Use mcpcodexcodex for new review threads. Use mcpcodex__codex-reply for follow-up rounds (reuse threadId).

If REVIEWERBACKEND = manual: Use mcpmanualreviewreview for new review threads with: prompt: [exact same prompt that would go to Codex] config: {"modelreasoningeffort": "xhigh", "executormodel": "", "requirereviewermodel": true} Save the returned threadId. Use mcpmanualreviewreviewreply for follow-up rounds with: threadId: [saved manual-review threadId] prompt: [follow-up prompt] config: {"modelreasoningeffort": "xhigh", "executormodel": "", "requirereviewermodel": true}

Prompt fidelity: the manual prompt must be exactly the same text that Codex would receive. Review tracing applies equally to both backends.

Required Inputs

1. Paper source — PDF, LaTeX directory, or narrative summary
2. Raw reviews — pasted text, markdown, or PDF with reviewer IDs
3. Venue rules — venue name, character/word limit, text-only or revised PDF allowed, rendering mode (one shared response or independent reviewer threads)
4. Current stage — initial rebuttal or follow-up round

If venue rules, limit, or rendering mode are missing, stop and ask before drafting.

Safety Model

Three hard gates — if any fails, do NOT finalize:

1. Provenance gate — every factual statement maps to: paper, review, userconfirmedresult, userconfirmedderivation, or future_work. No source = blocked.
2. Commitment gate — every promise maps to: alreadydone, approvedforrebuttal, or futurework_only. Not approved = blocked.
3. Coverage gate — every reviewer concern ends in: answered, deferredintentionally, or needsuser_input. No issue disappears.

Workflow

Phase 0: Resume or Initialize

1. If rebuttal/REBUTTAL_STATE.md exists → resume from recorded phase
2. Otherwise → create rebuttal/, initialize all output documents
3. Load paper, reviews, venue rules, any user-confirmed evidence

Phase 1: Validate Inputs and Normalize Reviews

1. Validate venue rules are explicit
2. Normalize all reviewer text into rebuttal/REVIEWS_RAW.md (verbatim)
3. Record metadata in rebuttal/REBUTTAL_STATE.md
4. If ambiguous, pause and ask

Phase 2: Atomize and Classify Reviewer Concerns

Create rebuttal/ISSUE_BOARD.md.

For each atomic concern:

• issue_id (e.g., R1-C2)
• reviewer, round, raw_anchor (short quote)
• issuetype: assumptions / theoremrigor / novelty / empiricalsupport / baselinecomparison / complexity / practical_significance / clarity / reproducibility / other
• severity: critical / major / minor
• reviewer_stance: positive / swing / negative / unknown
• reviewer_priority: standard / pivotal
• pivotal — a reviewer whose response is likely to affect the decision if addressed well: low or borderline rating, addressable concerns, and enough confidence/influence to matter. Phase 3 allocates extra drafting and stress-test budget here.
• responsemode: directclarification / groundedevidence / nearestworkdelta / assumptionhierarchy / narrowconcession / futureworkboundary / structuraldistinction
• structural_distinction — for "your method reduces to X / is just generic Y / is subsumed by Z" attacks. Pattern: agree on the local reduction; show the structural feature your parameterization preserves that X/Y/Z does not capture, backed by a concrete mechanism (theorem dependency, derivation step, or empirical consequence). Never use rhetorically without the supporting mechanism.
• status: open / answered / deferred / needsuserinput

Phase 3: Build Strategy Plan

Create rebuttal/STRATEGY_PLAN.md.

A verdict-bearing manual response MUST begin with Reviewer-Model: — pass the model THIS session is actually running as in executormodel. Missing, unknown, or same-family identity cannot acquit; emit REVIEWUNAVAILABLE rather than guessing. If the executor model cannot be named, manual review's cross-family claim is unprovable — say so in the report instead of asserting it.

1. Identify 2-4 global themes resolving shared concerns
2. Choose response mode per issue
3. Build character budget (10-15% opener, 75-80% per-reviewer, 5-10% closing) — applies in singledocument mode; in perreviewer_thread mode, set per-thread word/char targets instead
4. Identify pivotal reviewer(s) — reviewers whose vote or confidence shift would most affect the decision, especially when concerns are addressable rather than ideological. Mark them reviewerpriority: pivotal in ISSUEBOARD.md. There may be more than one. Allocate disproportionate drafting + stress-test budget here.
5. Identify blocked claims (ungrounded or unapproved)
6. If unresolved blockers → pause and present to user

QUICKMODE exit: If QUICKMODE = true, stop here. Present ISSUEBOARD.md + STRATEGYPLAN.md to the user and summarize: how many issues per reviewer, shared vs unique concerns, recommended priorities, and evidence gaps. The user can then decide to continue with full rebuttal (/rebuttal — quick mode: false) or write manually.

Phase 3.5: Evidence Sprint (when AUTO_EXPERIMENT = true)

Skip entirely if AUTOEXPERIMENT is false — instead, pause and present the evidence gaps to the user.**

If the strategy plan identifies issues that require new empirical evidence (tagged responsemode: groundedevidence with evidencesource: needsexperiment):

1. Generate a mini experiment plan from the reviewer concerns:

• What to run (ablation, baseline comparison, scale-up, condition check)
• Success criterion (what result would satisfy the reviewer)
• Estimated GPU-hours

1. Invoke /experiment-bridge with the mini plan:

/experiment-bridge "rebuttal/REBUTTAL_EXPERIMENT_PLAN.md"

1. Wait for results, then update ISSUE_BOARD.md:

• Tag completed experiments as userconfirmedresult
• Update evidence source for relevant issue cards

1. If experiments fail or are inconclusive:

• Switch response mode to narrowconcession or futurework_boundary
• Do NOT fabricate positive results

1. Save experiment results to rebuttal/REBUTTAL_EXPERIMENTS.md for provenance tracking.

Time guard: If estimated GPU-hours exceed rebuttal deadline, skip and flag for manual handling.

Phase 4: Draft Initial Rebuttal

Create the draft artifact(s) per VENUE_MODE:

• singledocument mode → one rebuttal/REBUTTALDRAFT_v1.md
• perreviewerthread mode → one rebuttal/Reviewerresponse.md per reviewer (no top-level REBUTTALDRAFT_v1.md)

Structure depends on VENUEMODE:**

• singledocument — one REBUTTALDRAFT_v1.md:

1. Short opener — thank reviewers + 2-4 global resolutions
2. Per-reviewer numbered responses — answer → evidence → implication
3. Short closing — resolved / remaining / acceptance case

• perreviewerthread — one self-contained Reviewer__response.md per reviewer:

1. Brief acknowledgment of that reviewer's main thrust
2. Numbered W#/Q# responses (answer → evidence → implication)
3. Optional shared experimental-setup paragraph (see "Reusable setup block" below)

• Each file must be readable standalone. No "see Reviewer X's response" references. No global opener.