rebuttal-response-skills ยท diff
git:20260727.63e3eb3 to git:20260727.2a35619
216 added, 163 removed. Audit A to A.
---
name: rebuttal-response-skills
- description: Use when drafting, revising, compressing, planning, or stress-testing rebuttals and author responses in PDF or OpenReview Markdown. Requires exact review text, preserves reviewer order, and grounds each answer in verified paper or experiment evidence.
+ description: Use when planning, drafting, revising, compressing, or auditing conference rebuttals and author responses in OpenReview Markdown or PDF. Supports exact reviewer mapping, evidence and experiment integration, guided risk decisions, venue-format validation, and blind reviewer/AC audits.
license: MIT
---
# Rebuttal Response Skills
- ## Core Goal
+ ## Goal
- Write a direct, reviewer-specific author response that is easy to verify and
- hard to misread. Keep evidence discipline strict internally. Do not turn that
- discipline into a visible stream of disclaimers, limitations, or defensive
- scope statements.
+ Produce reviewer-specific responses that are direct, easy to verify, and
+ strictly grounded in the submitted paper or approved rebuttal evidence. Keep
+ internal risk control rigorous without turning the visible response into a
+ stream of disclaimers.
- ## Required Inputs
+ ## Choose the Workflow
- Do not draft from a paraphrase of the review.
+ Use the **full workflow** for a complete rebuttal, multiple reviewers, new
+ evidence or experiments, a meta-review, or a final acceptance audit. Maintain
+ four internal artifact classes in the task's rebuttal directory:
- 1. Obtain the exact review text, including all available questions, weaknesses,
- scores, confidence ratings, and score-raising conditions. A supplied file or
- attachment containing the full text counts. If the user provides only a
- summary, ask only for the complete review first. Do not send a long intake
- checklist. After receiving it, discover local artifacts before asking for
- anything else.
- 2. Read the submitted paper and supplement, preferably the submitted PDF as the
- reviewer saw it. Use newer source files only to locate content or when the
- user explicitly identifies them as the submission.
- 3. Determine the official response format: shared or per-reviewer, PDF or
- portal text, page or character limit, anonymity rules, Markdown/LaTeX
- support, and whether links or attachments are allowed. Verify current
- official venue instructions when the venue is known and the rules were not
- supplied.
- 4. Collect only evidence that can be traced to the submission, appendix, code,
- accepted result artifacts, verified literature, or an explicit
- user-confirmed value.
+ 1. Exact review archive, such as `reviews.md`.
+ 2. Concern/evidence map with a shared decision ledger, such as
+ `concern_map.md`.
+ 3. One response per reviewer.
+ 4. Final audit record, such as `rebuttal_audit.md`.
- ## Select the Output Mode
+ Use the **lightweight workflow** for a bounded sentence rewrite, one isolated
+ question, or minor formatting. Edit inline and create no files unless the user
+ asks. Preserve the original technical meaning and claim strength by default.
+ The supplied sentence is sufficient for a pure prose edit; ask for context only
+ when clarity would require changing a factual claim, number, quotation, or
+ scope statement.
- Ask the user when the mode is genuinely ambiguous. Official venue rules
- override all defaults.
+ Read [references/response-patterns.md](references/response-patterns.md) when
+ drafting a full response, integrating experiments, resolving a risk marker,
+ running a blind audit, or performing final format verification.
- ### OpenReview Markdown
+ ## Establish Sources of Truth
- - Use one response per reviewer when the platform provides separate threads.
- - Include reviewer ID, score, and confidence in the title when they are
- available, useful, and allowed by the platform.
- - Count the complete visible response, including headings, tables, spaces, and
- Markdown, under the platform's stated rule.
- - Use GFM tables for dense numerical comparisons and supported LaTeX
- delimiters for formulas.
- - Check table alignment, paired math delimiters, headings, bold text, and links
- before submission.
+ 1. Treat the complete review text supplied by the user as the review source of
+ truth. If the user later supplies a revised version, use it and record the
+ replacement. Check the platform only when text is incomplete, versions
+ conflict, or the user asks. Do not draft a full response from a review
+ summary; request the exact weaknesses, questions, score, and confidence.
+ 2. Read the submitted paper and supplement as the reviewer saw them. Prefer the
+ submitted PDF for claims and values; use source files to locate content only
+ when their submitted status is verified.
+ 3. For rebuttal-only work, treat the submission as immutable evidence. Record
+ its hash or version before work and verify it is unchanged at the end. Edit
+ it only under a separate explicit request.
+ 4. Determine the official response mode, per-response or shared limit,
+ anonymity rules, Markdown/LaTeX support, and link or attachment policy.
+ Verify current official instructions when the venue is known and the user
+ has not supplied them.
- ### PDF Author Response
+ ## Map Every Concern
- - Use the official template and exact page limit. One page is common, not
- universal.
- - Preserve reviewer order within the shared document while allocating more
- space to decision-critical concerns.
- - Compile the final source, render every page, and inspect page count, font
- size, overflow, clipping, table readability, and references.
- - Do not solve overflow by making the response unreasonably small or dense.
+ Read each review sentence by sentence before drafting. For every substantive
+ point, record:
- ## Map the Review Before Drafting
+ - exact original sentence and source section;
+ - premise and actual concern;
+ - explicit request or score-shifting condition;
+ - submitted and rebuttal evidence, with exact source locations;
+ - evidence gap and proposed response mode;
+ - one coverage status: `fully answered`, `partially answered`,
+ `untested boundary`, or `pending evidence`.
- Read the review sentence by sentence. For each substantive point, record its
- reviewer, source section, original position, premise, explicit request,
- available evidence, and proposed answer.
+ Keep a separate map per reviewer and a shared decision ledger for
+ user-confirmed values, prohibited wording, excluded experiments, cross-reviewer
+ terminology, and stop decisions.
- - Preserve the visible order of the review. Meta-review priorities may change
- emphasis, but not the question sequence.
- - Match labels to the source: `Q1` for Questions and `W1` for standalone
- Weaknesses. Use `S1` only when a factual premise in Strengths needs explicit
- correction and cannot be handled cleanly in the opening or a related
- question. Do not replace source-matched labels with generic labels such as
- `C1`.
- - If a weakness and a question ask the same thing, answer once under the
- explicit question at its original position. Keep the duplicate mapping
- internal.
- - If two explicit questions overlap but contain distinct requests, keep both
- headings. Answer the shared part once, then use the later heading only for
- the remaining request.
- - Treat a declarative score-raising condition in the Questions section as the
- next `Q` item.
- - Keep a separate concern map for each reviewer. Reuse a shared experiment only
- when it directly answers both reviewers; do not import one reviewer's
- requested baselines, limitations, or side issues into another response.
- - Ensure every substantive point is answered, intentionally combined with a
- duplicate, or held for one necessary user decision.
+ - Preserve the review's visible order unless the user explicitly requests a
+ different order. A meta-review may change emphasis, not sequence.
+ - Match labels to the source. Use `W1`, `Q1`, and similar labels rather than
+ generic `C1` labels.
+ - Prefer the reviewer's complete decisive sentence or sentences as the
+ heading. Shorten only for precision or a binding format limit.
+ - Never place a paraphrase or stitched fragment inside quotation marks.
+ - Merge true duplicates internally. Preserve separate headings when overlapping
+ questions contain distinct requests.
+ - Every substantive point must be answered, explicitly combined with a
+ duplicate, marked as an untested boundary, or held for one necessary user
+ decision.
- ## Draft Each Response
+ ## Build the Response
- Assume the reviewer may not remember the paper in detail. Start with at most
- two or three short sentences that restore only the method concept needed to
- understand the answers.
+ Start each reviewer response with at most two short sentences that state the
+ answer order. Restore method context only when the answer would otherwise be
+ hard to understand; do not mechanically re-explain the paper.
- For each issue:
+ For every issue:
- 1. Use a short heading that faithfully restates the concern.
- 2. Give the direct answer in the first sentence.
- 3. Provide the minimum explanation, evidence, formula, or experiment needed.
- 4. End with the concrete implication for that concern.
+ 1. Give the direct answer in the first sentence.
+ 2. Explain only the mechanism, definition, or setup needed for that issue.
+ 3. Present evidence before interpretation.
+ 4. State the narrow implication supported by that evidence.
+ 5. Add a concrete camera-ready clarification only when the submitted wording
+ actually needs correction.
Writing rules:
- - Prefer short declarative sentences and familiar technical words.
- - Write in the authors' voice for the reviewer, not as notes to the user.
- - Match the reviewer's tone. Use a cooperative tone for exploratory questions
- and a calm, factual, AC-readable tone for skeptical or low-score reviews.
- - Do not criticize the reviewer or speculate about their expertise.
- - Avoid repeated gratitude, long question restatements, generic transition
- sentences, and AI-sounding summaries.
- - Use compact tables when prose would force the reviewer to track many values.
- Define the protocol, comparison point, unit, and direction. Bold the best
- relevant result. Do not add redundant gain rows when the best values are
- already clear.
- - Report mixed or negative results honestly, then explain their narrow
- implication without hiding them or turning them into a broader claim.
+ - Prefer short declarative sentences and terminology already used in the
+ submission. Introduce a new term only when necessary and define it once.
+ - If the review relies on an incorrect or incomplete premise, correct it
+ politely with submitted evidence, then answer the underlying concern.
+ - Stay within that reviewer's explicit concerns. Shared evidence may be reused,
+ but do not import another reviewer's limitations, baselines, or side issues.
+ - Acknowledge an especially useful or decision-critical question once when it
+ improves the exchange. Avoid routine praise and repeated gratitude.
+ - Use a closing contribution synthesis only for a low-score review or when it
+ is needed to change the overall assessment.
+ - Never promise an experiment, release, revision, capability, or positive
+ future result merely to make the response sound complete.
- ## Stay on the Asked Question
+ ## Present Experiments and Numbers
- - Do not volunteer unrelated limitations, missing modalities, extra tasks,
- baselines, experiments, or deployment gaps.
- - Do not habitually write "we only claim", "we do not claim", or long scope
- boundaries. Use a boundary only when it corrects a material misreading,
- separates measured evidence from an estimate, or prevents an actual
- overclaim.
- - Do not repeat a limitation already acknowledged by the reviewer unless it is
- part of the question being answered.
- - For a request that is infeasible during rebuttal, first answer the technical
- point with current evidence or reasoning. Explain the missing protocol or
- resource in one concise sentence. Add a future-work commitment only after the
- user approves it.
- - Never promise a new experiment, dataset, release, revision, or result merely
- to make the response sound complete.
+ - State a shared dataset, model pair, and setup once near the beginning. Mark
+ local exceptions beside the relevant table.
+ - Use a normal Markdown table when the reviewer must compare several conditions
+ or metrics. Use prose for only one or two values.
+ - Define every rebuttal-specific condition, schedule, statistic, and
+ nonstandard metric at first use. For a derived metric, give its calculation,
+ unit, and whether higher or lower is better. Do not re-define standard paper
+ metrics unnecessarily.
+ - Keep shared values and definitions identical across reviewers. Crop a shared
+ table to reviewer-relevant rows or columns when useful.
+ - Do not present pending runs, placeholders, expected trends, or partial
+ outputs as results.
- ## Evidence Discipline
+ ## Enforce Evidence Discipline
- Maintain an internal claim-to-source map even when it is not shown to the
- reviewer.
+ - Use submitted PDF/LaTeX values for submitted claims. Use matched controls from
+ the same protocol for a new rebuttal experiment.
+ - If a reproduction materially conflicts with the submission, stop and ask the
+ user. Pause the affected claim, table, and every dependent response; continue
+ only work that does not depend on the conflict. Do not silently choose,
+ average, or substitute values. Treat a conflict as material when it could
+ change a reviewer-facing conclusion, comparison ordering, or claim boundary.
+ - Before proposing a new experiment, inspect the main paper, appendix, and
+ supplement. When reusing submitted evidence, cite its exact location and
+ summarize the observation relevant to the concern; do not write only
+ "see Appendix."
+ - A logically matched proxy is acceptable. Define what it measures once and do
+ not describe it as direct evidence for an unmeasured quantity.
+ - Separate measured results, analytical derivations, architectural reasoning,
+ dataset facts, and future directions.
+ - Use `$research-evidence` when an answer depends on external literature,
+ dataset facts, novelty positioning, or citation authenticity. Never invent a
+ citation.
- - Separate submitted evidence, new rebuttal evidence, analytical derivations,
- dataset statistics, architectural reasoning, and future work.
- - Trace every number to the submitted PDF, a table/CSV/log, or an explicit
- user-confirmed final value. Record user-confirmed values as such internally.
- - Do not present pending runs, placeholders, expected trends, or partial
- outputs as results.
- - State formulas and analytical estimates with their assumptions. Do not call
- them measured latency, accuracy, scalability, or network behavior.
- - Use `$research-evidence` when a response depends on external literature,
- dataset facts, novelty positioning, or citation authenticity. Do not invent
- citations. Follow venue rules on links and normal citations.
- - Add a new experiment only when it directly answers the review, fits the
- rebuttal window, uses an interpretable protocol, and does not create a new
- paper contribution.
+ For capability or deployment questions, distinguish:
- ## Resolve High-Impact Decisions
+ 1. what the method design permits;
+ 2. what the submitted implementation supports;
+ 3. what the experiments evaluate.
- Use `$grill-me` behavior for ambiguous reviewer requests, experiment choices,
- conflicting evidence, response-scope tradeoffs, or future commitments.
+ Use the paper description first. Inspect code or configuration when the paper
+ cannot answer an explicitly implementation-specific question or the user asks.
+ Do not turn an architectural extension into an implemented or evaluated claim.
- - Inspect the paper, review, code, logs, and official rules before asking.
- - Ask one high-impact question at a time and provide a recommended answer.
- - Use a reasonable documented default for non-critical choices.
- - Do not make this skill dependent on Plan Mode.
+ ## Control New Evidence and Risks
- ## Independent Reviewer and AC Audit
+ Before starting any new experiment, give the user the minimal design, the
+ review concern it answers, the comparison and controls, and the outcome
+ criteria. Run it only after explicit approval.
- For a high-stakes final response, use independent subagents when available.
+ Retain every predeclared condition in the internal evidence record. Do not
+ silently remove a mixed or negative condition. Mark high-impact uncertainty as:
- 1. Give each reviewer agent only the exact review, submitted paper, applicable
- venue rules, and that reviewer's response.
- 2. Do not provide the intended answer, prior critique, or suspected weakness.
- 3. Ask the agent to identify missed or reordered concerns, evasive answers,
- unsupported claims, unclear concepts, contradictions, and format violations.
- 4. Give an AC agent the meta-review, all reviews, and all responses only after
- the reviewer-specific audits.
- 5. Revise substantive problems. Do not expand the rebuttal for minor stylistic
- preferences.
+ `[REVIEW NEEDED | Ideal: ... | Observed: ... | Decision: ...]`
- If subagents are unavailable, apply the same audit yourself.
+ Use this marker for material numeric conflicts, mixed or negative results,
+ proxy limitations, or a proposed claim/commitment needing approval. Explain
+ each marker to the user one at a time and remove it only after explicit
+ confirmation. A submission candidate must contain no marker, placeholder, or
+ pending result. The user decides the reviewer-facing presentation, but a
+ reviewer-requested result, a promised condition, or evidence material to a
+ visible claim cannot be omitted merely because it is negative. Report it or
+ narrow the claim so the response remains complete and non-misleading.
- ## Final Three-Pass Check
+ If the user says to stop an experiment or stop discussing a protocol dispute,
+ stop immediately. Do not continue the run, internal investigation, or
+ questioning. Do not add the stopped technical sub-issue to the visible response
+ unless the user later requests it. This does not authorize silently dropping an
+ explicit reviewer concern: answer that concern with approved existing evidence
+ or one concise untested-boundary statement. If the user explicitly directs its
+ omission, record that decision in the ledger.
- 1. **Coverage and order**: every concern is mapped once, headings match the
- review, duplicates are merged, and reviewer-specific issues remain isolated.
- 2. **Evidence and logic**: every number and factual claim has provenance;
- comparisons are fair; estimates are labeled; no unapproved commitment,
- contradiction, or logical gap remains.
- 3. **Language and rendering**: sentences are direct and natural; repetition is
- removed; Markdown/LaTeX or the compiled PDF renders correctly; the exact
- character or page limit is satisfied with margin.
+ For an untested or infeasible request, answer what current evidence or
+ reasoning supports, state the untested part once, and propose a future direction
+ only after user approval. Do not guarantee implementation or a favorable
+ outcome.
- For a follow-up reviewer comment, write only the needed delta response. Do not
- restart the full rebuttal unless the new comment changes the response strategy.
+ ## Handle Meta-Review
- ## Technical Rebuttal Defaults
+ When a meta-review exists, extract its decision-critical or score-shifting
+ conditions and map each one to the relevant reviewer response and final AC
+ audit. Add a condition to a reviewer response only when it directly overlaps
+ that reviewer's concern. If a meta-only condition has no response entry and no
+ such overlap, keep it as an internal AC item rather than forcing it into an
+ unrelated response. Do not change the default reviewer order. Draft a
+ standalone meta response only when the platform provides an appropriate entry.
- - Separate communication payload from compute latency and measured network
- latency.
- - Separate architecture-level scaling from measured multi-agent accuracy,
- runtime, congestion, or dataset coverage.
- - Keep native and unified-protocol baselines clearly labeled.
- - Use mechanism, control, and ablation evidence to explain why a method works;
- do not assign a full gain to one component when several factors change.
- - Treat dataset counts and protocol audits as context, not performance evidence.
+ ## Run a Blind Reviewer and AC Audit
+
+ For a high-stakes final response, use fresh subagents when available. If fresh
+ agents are unavailable, run separate paper-only and response-aware self-audit
+ passes using the same input isolation, and state internally that independence
+ was not achieved.
+
+ 1. **Paper-only phase:** Give each reviewer agent only the submitted paper,
+ supplement, venue scoring scale, and public rules. Ask for an independent
+ review, score, confidence, and major concerns. Lock this output.
+ 2. **Response phase:** Then give the same agent the corresponding exact official
+ review and response. Ask which concerns are answered, whether the score
+ changes, and whether a response defect remains.
+ 3. **AC phase:** After reviewer audits, give a fresh AC agent the submitted
+ materials, meta-review when present, official reviews, responses, and audit
+ outcomes.
+
+ Never expose the concern map, decision ledger, author strategy, target score,
+ suspected weakness, or intended conclusion to blind agents.
+
+ Classify audit findings as:
+
+ - `Response defect`: missed concern, evasion, unsupported claim,
+ contradiction, misleading evidence, or format violation.
+ - `Unresolved paper limitation`: a real limitation the response cannot remove.
+ - `Optional strengthening`: a non-blocking improvement.
+
+ Only a `Response defect` blocks by default. Each reviewer agent must report its
+ before/after score, per-concern coverage, and final `ACCEPTABLE` or blocking
+ defect. The final candidate passes only when every reviewer audit and the AC
+ audit reports `ACCEPTABLE` with no blocking response defect. Do not expand the
+ rebuttal for unrelated new concerns unless they expose a fatal factual error,
+ integrity risk, or direct contradiction.
+
+ ## Final Verification
+
+ Use a fresh format-verifier agent plus deterministic checks. If no fresh agent
+ is available, run a separate verifier pass using only the final candidate and
+ official rules. Follow the platform's official counting method; require the
+ candidate to remain below a character limit and within a page limit.
+
+ 1. **Coverage:** all mapped concerns retain correct order and labels; no
+ reviewer-specific issue has leaked into another response.
+ 2. **Evidence:** every number and factual claim has provenance; comparisons are
+ fair; no unapproved commitment or unresolved high-impact decision remains.
+ 3. **Rendering:** enforce the official character or page limit; check Markdown
+ tables, LaTeX delimiters, headings, anonymity, machine paths, allowed links,
+ and PDF compile/render quality when applicable.
+ 4. **Cleanliness:** search for `REVIEW NEEDED`, `TODO`, `pending`, placeholders,
+ and internal artifact paths. Resolve every hit before submission.
+ 5. **Immutability:** verify the submitted paper and supplement version or hash
+ is unchanged.
+
+ For a follow-up reviewer comment, answer only the new delta unless it changes
+ the overall strategy.