rebuttal
Rebuttal: Response to Reviewers
Overview
Turns reviewer comments into an auditable, fabrication-free response package for a CS / systems / ML paper. The pipeline atomizes every comment into an ISSUE_BOARD, maps each to a fixed action label, drafts replies in strict R-A-C form, and runs three hard gates before anything finalizes. It reads the existing manuscript and verification report so every claimed change points at a real location.
This skill does NOT run experiments, edit the manuscript prose, generate new theorem claims, or submit to OpenReview / CMT / HotCRP. It drafts the response text only. New results, derivations, or approved commitments enter as user-confirmed evidence; the skill never invents them.
Core principle: Evidence before claims, always. Every factual sentence in the response must trace to a source. A sentence with no source is blocked, not softened.
Iron law: No STATUS: final flip on the response without all three gates passing in .writing/reviews/REBUTTAL_STATE.md.
Relation to the claim-first hook. During drafting, a PreToolUse hook (see superpower-writing:main Claim-First Protocol) blocks prose writes that lack a backed claim. The rebuttal Provenance gate is the same discipline pointed at the response letter. Where the hook asks "does this manuscript paragraph have a backed claim?", the gate asks "does this response sentence have a source?". Same answer when neither has one: blocked.
AUTHOR_INPUT_NEEDED is the [NEEDS-EVIDENCE] of rebuttals. In drafting, [NEEDS-EVIDENCE] marks a claim whose support is not yet on disk. In a rebuttal, AUTHOR_INPUT_NEEDED marks a response whose facts the author has not yet supplied. Both are visible placeholders that block finalization, never silent gaps. Both surface to the user; neither is fabricated away.
Verdicts are advisory. The gates surface blockers to the user. They never auto-reject a comment, auto-mutate state, or paste a response anywhere. The user decides what to send.