/ds-rebuttal

name: ds-rebuttal
description: Use when a quest already has a paper, draft, or review package and the task is to map reviewer feedback into experiments, manuscript deltas, and a durable rebuttal / revision response.
skill_role: companion
license: MIT
metadata:
  author: ResearAI/DeepScientist
  version: "1.0.0"

Rebuttal

Use this skill when the quest is in review, revision, or rebuttal mode.

This is not the same as ordinary `write`. The task is no longer “draft the paper from evidence”. The task is “respond to concrete reviewer pressure with the smallest honest set of experiments, text changes, claim adjustments, and response artifacts”.

Interaction discipline

• Follow the shared interaction contract injected by the system prompt.
• For ordinary active work, prefer a concise progress update once work has crossed roughly 6 tool calls with a human-meaningful delta, and do not drift beyond roughly 12 tool calls or about 8 minutes without a user-visible update.
• Message templates are references only. Adapt to the actual context and vary wording so updates feel natural and non-robotic.
• If a threaded user reply arrives, interpret it relative to the latest rebuttal progress update before assuming the task changed completely.
• When the rebuttal plan, the main supplementary-evidence package, or the final response bundle becomes durable, send one richer `artifact.interact(kind='milestone', reply_mode='threaded', ...)` update that says what reviewer concerns are now addressed, what still remains open, and what happens next.
• Hard execution rule: if this stage needs terminal work such as manuscript builds, scripted checks, Git inspection, or reviewer-linked experiment launches, every such command must go through `bash_exec`.

Purpose

`rebuttal` is an auxiliary orchestration skill for review-driven work.

It should convert reviewer material into a durable response workflow:

1. parse and normalize the review package 2. split comments into stable atomic items and classify what they actually require 3. decide which concerns need literature/positioning analysis, which need experiments, which need text, and which require claim downgrades 4. route supplementary runs to `analysis-campaign` only after the analysis step says they are truly needed 5. route manuscript edits to `write` 6. assemble the response letter and revision ledger

Default rebuttal stance: analysis before execution. Do not jump from “reviewer asked for more evidence” straight to experiments. Do not invent rebuttal-only special tools or side workflows. Stay inside the normal DeepScientist surface: `memory`, `artifact`, `bash_exec`, plus ordinary stage/companion skills. First decide whether the issue is actually:

• a wording / clarity gap
• a literature / novelty / positioning gap
• an evidence-presentation gap
• a missing baseline or comparator
• a genuinely new experiment gap

Use when

• `startup_contract.custom_profile = revision_rebuttal`
• the quest already has:
• reviewer comments
• a meta-review
• a revision request
• a decision letter
• a list of required extra experiments for a submitted paper
• the user says:
• “补实验并写 rebuttal”
• “根据 review 修改论文”
• “先整理 reviewer comments 再决定实验”

Do not use when

• the paper does not yet exist and the task is ordinary paper drafting
• there are no concrete review materials
• the work is actually a fresh ideation or baseline quest

Non-negotiable rules

• Do not invent experiment results, response claims, or manuscript changes that have not been made.
• Do not promise “we will add” unless the work is truly planned and the response format explicitly allows future-work statements.
• Do not silently ignore hard reviewer concerns because they are inconvenient.
• Do not answer a reviewer with rhetoric when the issue actually requires evidence.
• Do not run supplementary experiments without first mapping them to named reviewer concerns.
• Do not keep the original claim scope if the new evidence no longer supports it.
• If a reviewer request cannot be fully satisfied, say so clearly and explain the honest limitation.
• If `startup_contract.baseline_execution_policy` is present, honor it:
• `must_reproduce_or_verify`
• verify or recover the rebuttal-critical baseline/comparator before reviewer-linked follow-up work
• `reuse_existing_only`
• trust the current baseline/results unless you find concrete inconsistency, corruption, or missing-evidence problems
• `skip_unless_blocking`
• do not spend time rerunning baselines unless a named reviewer item truly depends on a missing comparator
• If `startup_contract.manuscript_edit_mode = latex_required`, treat the provided LaTeX tree or `paper/latex/` as the preferred writing surface when manuscript revision is needed.
• If LaTeX source is unavailable while `latex_required` is requested, do not pretend the manuscript was edited; produce LaTeX-ready replacement text and an explicit blocker note instead.
• Accept review inputs from URLs, local file paths, local directories, or current-turn attachments; do not assume the review packet must already be neatly structured.

Primary inputs

Use, in roughly this order:

• the current paper or draft
• the selected outline if one exists
• review comments, meta-review, or editor letter
• current-turn attachments and user-provided local paths / directories / URLs for the manuscript or review packet
• the six-field `evaluation_summary` blocks from recent main experiments and analysis slices
• recent main and analysis experiment results
• prior decision and writing memory
• existing figures, tables, and claim-evidence maps

If the current paper/result state is still unclear, open `intake-audit` first before continuing the rebuttal workflow. Before launching any new supplementary experiment, read those structured `evaluation_summary` blocks first so the rebuttal plan starts from the already-recorded evidence state rather than from raw narrative memory. If the