rebuttal

name	rebuttal
description	Workflow 4: Submission rebuttal pipeline. Parses external reviews, enforces coverage and grounding, drafts a safe text-only rebuttal under venue limits, and manages follow-up rounds.
argument-hint	["paper-dir-or-review-bundle"]
allowed-tools	Bash(*), Read, Write, Edit, Grep, Glob, Agent, Skill, mcp__codex__codex, mcp__codex__codex-reply

Workflow 4: Rebuttal

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

Scope

This skill is optimized for:

• IEEE Transactions revision response (default) — point-by-point response letter + revised manuscript
• ICML/NeurIPS-style text-only rebuttal (when venue is set to conference)
• multiple reviewers (IEEE Trans typically has 3-5 reviewers + Associate Editor)
• follow-up rounds (Major Revision → 2nd round review)
• safe drafting with no fabrication, no overpromise, and full issue coverage

This skill does not:

• run new experiments/simulations automatically unless AUTO_EXPERIMENT = true
• generate new theorem claims automatically
• submit to ScholarOne / Editorial Manager

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

• DECISION_MODEL = Opus — Use for response strategy, concessions, and final wording approval.

• EXECUTION_MODEL = Sonnet — Use for issue extraction, evidence lookup, and first-draft response assembly.

• VENUE = IEEE_TRANS — Default venue. Options: IEEE_TAC, IEEE_TSMC, IEEE_TCYB, IEEE_TIE, IEEE_TNNLS, IEEE_TCSI, IEEE_ACCESS, ICML, NeurIPS, ICLR

• RESPONSE_MODE = POINT_BY_POINT — IEEE Trans default: detailed point-by-point response letter. TEXT_ONLY for conferences.

• REVIEWER_MODEL = gpt-5.4 — Used via a secondary Codex agent for internal stress-testing

• MAX_INTERNAL_DRAFT_ROUNDS = 2

• MAX_STRESS_TEST_ROUNDS = 1

• MAX_FOLLOWUP_ROUNDS = 3 — IEEE Trans typically allows 1-2 revision rounds

• AUTO_EXPERIMENT = false — When true, invoke /experiment-bridge for reviewer concerns that require new simulations

• QUICK_MODE = false — When true, only run Phase 0-3 and stop after strategy

• REBUTTAL_DIR = rebuttal/

• HIGHLIGHT_CHANGES = true — IEEE Trans convention: use blue/red text to highlight changes in revised manuscript

Override: /rebuttal "paper/" — venue: IEEE_TAC

Project Automation Policy

Before acting, resolve automation defaults in this precedence order:

1. Inline command arguments
2. PROJECT_AUTOMATION.md in the project root
3. CLAUDE.md in the project root
4. The constants in this skill

For Trans revisions, treat AUTO_PROCEED=false as the safe default. Never finalize the response letter without a final user review.

IEEE Trans Revision Response Format

The standard IEEE Trans response letter format:

Dear Editor and Reviewers,

We sincerely thank the Editor and all reviewers for the constructive comments
and suggestions that have helped us improve the quality of this manuscript.
We have carefully addressed all the comments point by point. The main changes
are highlighted in blue in the revised manuscript.

---
## Response to Reviewer 1

**Comment 1.1:** [quote reviewer's exact words]

**Response:** [detailed response with specific changes]
[If text was changed: "We have revised the manuscript accordingly. Please see
Section X, page Y, lines Z1-Z2 (highlighted in blue)."]

**Comment 1.2:** ...

---
## Response to Reviewer 2
...

---
## Response to Associate Editor
...

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
4. Current stage — initial rebuttal or follow-up round

If venue rules or limit 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 a known source
2. Commitment gate — every promise maps to already-done / approved-for-rebuttal / future-work-only
3. Coverage gate — every reviewer concern ends in answered / deferred intentionally / needs user input

Workflow

Before stress-testing the rebuttal, read ../shared-references/agent-role-charter.md and apply the Rebuttal Editor role. Also read ../shared-references/model-routing-policy.md.

Routing:

• Sonnet assembles the issue board, traces evidence, and drafts point-by-point responses
• gpt-5.4 stress-tests for factual and tone risk
• Opus decides final concessions, final phrasing, and final submission readiness

Phase 0: Resume or Initialize

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

Phase 1: Validate Inputs and Normalize Reviews

1. Validate that 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.

Reviewer-specific issue extraction can run in parallel as long as each reviewer owns a disjoint slice of the board.

For each atomic concern, record:

• issue_id
• reviewer, round, raw_anchor
• issue_type
• severity
• reviewer_stance
• response_mode
• status

Phase 3: Build Strategy Plan

Create rebuttal/STRATEGY_PLAN.md.

1. Identify 2-4 global themes resolving shared concerns
2. Choose a response mode per issue
3. Build the character budget
4. Identify blocked claims
5. If unresolved blockers exist, pause and present them to the user

QUICK_MODE exit: if QUICK_MODE = true, stop here and present ISSUE_BOARD.md + STRATEGY_PLAN.md.

Phase 3.5: Evidence Sprint (when AUTO_EXPERIMENT = true)

Skip entirely if AUTO_EXPERIMENT is false.

If the strategy plan identifies issues that require new empirical evidence:

1. Generate a mini experiment plan from the reviewer concerns
2. Invoke /experiment-bridge "rebuttal/REBUTTAL_EXPERIMENT_PLAN.md"
3. Wait for results, then update ISSUE_BOARD.md
4. If experiments fail or are inconclusive, switch to narrow_concession or future_work_boundary
5. Save experiment results to rebuttal/REBUTTAL_EXPERIMENTS.md

Phase 4: Draft Initial Rebuttal

Create rebuttal/REBUTTAL_DRAFT_v1.md.

Use Sonnet for the first-draft assembly, then return to Opus only after the safety and stress-test passes reveal what actually needs high-stakes judgment.

Structure:

1. Short opener
2. Per-reviewer numbered responses
3. Short closing

Also generate rebuttal/PASTE_READY.txt with exact character count.

Phase 5: Safety Validation

Run all lints:

1. Coverage
2. Provenance
3. Commitment
4. Tone
5. Consistency
6. Limit

Phase 6: Stress Test

spawn_agent:
  model: gpt-5.4
  reasoning_effort: xhigh
  message: |
    You are a seasoned associate editor / senior reviewer for scientific journals.
    Stress-test this rebuttal draft:
    [raw reviews + issue board + draft + venue rules]

    1. Unanswered or weakly answered concerns?
    2. Unsupported factual statements?
    3. Risky or unapproved promises?
    4. Tone problems?
    5. Paragraph most likely to backfire with a meta-reviewer?
    6. Minimal grounded fixes only. Do not invent evidence.
    7. Any sentence whose tone sounds defensive, sales-like, or AI-generated?

    Verdict: safe to submit / needs revision

Save the full response to rebuttal/MCP_STRESS_TEST.md. If a hard safety blocker remains, revise before finalizing.

Phase 7: Finalize — Two Versions

Produce:

1. rebuttal/PASTE_READY.txt — strict version, ready to paste
2. rebuttal/REBUTTAL_DRAFT_rich.md — extended version with optional sections marked
3. Update rebuttal/REBUTTAL_STATE.md
4. Present the remaining risks and any lines needing manual approval

Phase 8: Follow-Up Rounds

When new reviewer comments arrive:

1. Append them to rebuttal/FOLLOWUP_LOG.md
2. Link to existing issues or create new ones
3. Draft the delta reply only
4. Re-run safety lints
5. If continuity helps, reuse the same reviewer agent via send_input
6. Escalate technically, not rhetorically

Key Rules

• Never fabricate evidence, numbers, derivations, citations, or links
• Never overpromise. Only promise what the user explicitly approved.
• Every reviewer concern must be tracked and accounted for
• Preserve raw records
• Shared concerns go in the opener; reviewer-specific details go in the per-reviewer sections
• Answer friendly reviewers too
• Respect the hard character limit