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. Use when user says "rebuttal", "reply to reviewers", "ICML rebuttal", "OpenReview response", or wants to answer exter

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 Constants VENUE = ICML — Default venue. Override if needed. RESPONSE MODE = TEXT ONLY — v1 default. REVIEWER MODEL = 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). REVIEWER BACKEND = 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 . MAX INTERNAL DRAFT ROUNDS = 2 — draft → lint → revise. VENUE MODE = single document — single document for one shared author response, or per reviewer thread when each reviewer thread renders independently. Confirm the venue/interface before drafting if unclear. Affects Phase 4/7 output shape. STRESS TEST ROUNDS BASE = 1 — One external reviewer critique round on the full response set. Add focused rounds for reviewer priority: pivotal responses, terminating when the reviewer returns no new substantive issues. Hard cap at 5. MAX FOLLOWUP ROUNDS = 3 — per reviewer thread. AUTO EXPERIMENT = 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. QUICK MODE = false — When true , only run Phase 0 3 (parse reviews, atomize concerns, build strategy). Outputs ISSUE BOARD.md + STRATEGY PLAN.md and stops — no drafting, no stress test. Useful for quickly understanding what reviewers want before deciding how to respond. REBUTTAL DIR = rebuttal/ RENDER HTML = true — When true (default), auto render rebuttal/REBUTTAL DRAFT rich.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 PASTE READY.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 REVIEWER BACKEND = codex : Use mcp codex codex for new review threads. Use mcp codex codex reply for follow up rounds (reuse threadId). If REVIEWER BACKEND = manual : Use mcp manual review review for new review threads with: prompt: [exact same prompt that would go to Codex] config: {"model reasoning effort": "xhigh", "executor model": "<actual executor model ", "require reviewer model": true} Save the returned threadId . Use mcp manual review review reply for follow up rounds with: threadId: [saved manual review threadId] prompt: [follow up prompt] config: {"model reasoning effort": "xhigh", "executor model": "<actual executor model ", "require reviewer model": 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 , user confirmed result , user confirmed derivation , or future work . No source = blocked. 2. Commitment gate — every promise maps to: already done , approved for rebuttal , or future work only . Not approved = blocked. 3. Coverage gate — every reviewer concern ends in: answered , deferred intentionally , or needs user 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) issue type : assumptions / theorem rigor / novelty / empirical support / baseline comparison / 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. response mode : direct clarification / grounded evidence / nearest work delta / assumption hierarchy / narrow concession / future work boundary / structural distinction 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 / needs user input Phase 3: Build Strategy Plan Create rebuttal/STRATEGY PLAN.md . 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 single document mode; in per reviewer 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 reviewer priority: pivotal in ISSUE BOARD.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 A verdict bearing manual response MUST begin with Reviewer Model: <exact model id — pass the model THIS session is actually running as in executor model . Missing, unknown, or same family identity cannot acquit; emit REVIEW UNAVAILABLE 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. QUICK MODE exit : If QUICK MODE = true , stop here. Present ISSUE BOARD.md + STRATEGY PLAN.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 AUTO EXPERIMENT is false — instead, pause and present the evidence gaps to the user. If the strategy plan identifies issues that require new empirical evidence (tagged response mode: grounded evidence with evidence source: needs experiment ): 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 2. Invoke /experiment bridge with the mini plan: 3. Wait for results, then update ISSUE BOARD.md : Tag completed experiments as user confirmed result Update evidence source for relevant issue cards 4. If experiments fail or are inconclusive: Switch response mode to narrow concession or future work boundary Do NOT fabricate positive results 5. 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 : single document mode → one rebuttal/REBUTTAL DRAFT v1.md per reviewer thread mode → one rebuttal/Reviewer <ID response.md per reviewer (no top level REBUTTAL DRAFT v1.md ) Structure depends on VENUE MODE : single document — one REBUTTAL DRAFT 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 per reviewer thread — one self contained Reviewer <ID 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. Default reply pattern per issue: Sentence 1: direct answer Sentence 2 4: grounded evidence Last sentence: implication for the paper Reusable setup block (per reviewer thread mode). If multiple reviewer thread responses need the same experimental setup or metric definitions, write a canonical SETUP METRICS BLOCK.md . Reuse it consistently in each reviewer file that needs it. Target ≤ 150 words; expand only with genuinely reviewer specific additions inline. Change once update everywhere prevents drift across threads. Heuristics from successful rebuttals (content): Evidence assertion Global narrative first, per reviewer detail second (single document mode only) Concrete numbers for counter intuitive points Name closest prior work + exact delta for novelty disputes Concede narrowly when reviewer is right For theory: separate core vs technical assumptions Answer friendly reviewers too Reviewer defensive moves: Minimum sufficient evidence per concern. Usually one numerical anchor: the metric that maps directly to that reviewer's specific ask. Cut metrics other reviewers care about — bloat dilutes the answer. Pre registered calibration phrasing. When a threshold or hold out was fixed before generated samples were inspected, say so explicitly with a phrase like "set on hold o