Education
#agent
rebuttal-skills
Helps the agent draft high-quality conference rebuttals and final responses for ML/CS papers by analyzing reviews, classifying reviewer types, planning experiments, and generating polite, persuasive, AC-oriented replies. Use when the user is preparing rebuttals or responses to reviewers with provided reviews and scores.
DeepseekModel
Curated skill
Quality Good · 64
v1.0.0
Get
https://deepseekmodel.com/api/download.php?id=steve2457-rebuttal-skills-cursor-skills-rebuttal-skills-skill-md&format=skill
Download .skill
Standard format with system_prompt and model_config, ready for any agent framework
The actual content of the system_prompt field in the .skill file.
name rebuttal-skills description Helps the agent draft high-quality conference rebuttals and final responses for ML/CS papers by analyzing reviews, classifying reviewer types, planning experiments, and generating polite, persuasive, AC-oriented replies. Use when the user is preparing rebuttals or responses to reviewers with provided reviews and scores. Rebuttal Skills Quick Start When the user asks for help with a conference rebuttal or responses to reviewers: Collect context : Ask for (a) paper title and short summary, (b) full reviews with scores, (c) venue and page/word limits for rebuttal, (d) any new experiments already run. Itemize comments : For each reviewer, break long paragraphs into concrete questions/issues: Q1, Q2, ... with short labels (e.g., "Q1 – Missing baseline X"). Tag each issue : Mark each Q as one or more of: clarification , needs-experiment , strong-disagreement , minor , editorial , borderline-critical . Classify reviewers : For each reviewer, infer their type: responsible, misunderstanding, bad-faith/unreasonable, borderline-score. Select strategy : For each reviewer/type, choose tone and structure based on the strategies below. Draft structure : Propose a full rebuttal outline (Overview + per-reviewer responses), then fill in detailed Q/A answers. Polish and compress : Rewrite for clarity, self-containment, and tone. If there is a strict limit, aggressively compress while preserving information. Optionally : Help the user draft Confidential Comments to AC and Final Response (if the venue has this stage). Workflow Step 1 – Analyze Inputs Ensure you know: Conference / venue and rebuttal/response constraints (page or word limits). Whether there is a separate Final Response or Confidential Comments to AC channel. If information is missing but important (e.g., hard page limit), briefly ask the user. Step 2 – Itemize and Label For each reviewer Rk : Copy all comments and split them into atomic issues Q1, Q2, ... . For each Q : Assign a short title summarizing the core concern: e.g., Q1 – Generalization to dataset X . Tag the type: clarification , needs-experiment , methodology-critique , novelty-critique , unrealistic-request , borderline-critical . Identify borderline score patterns (e.g., 3/4/6/6 ) where a strong rebuttal can significantly change the decision. Step 3 – Brain Dump For each Q : Do a brain dump with the user: All relevant facts from the paper (sections, tables, figures). Any experiments already run but not in the paper. Feasible additional experiments or analyses that could be run quickly. Do not optimize phrasing yet; focus on content and logic. Step 4 – Draft Responses Propose a standard structure: Overview (global thank-you + summary of strengths + high-level statement that key concerns are addressed). Response to Reviewer R1 , Response to Reviewer R2 , ... Within each reviewer, use Q1 / A1 style. For venues with strict one-page limits: Consider grouping by topic while still making clear which reviewer’s concern is addressed in each paragraph. Step 5 – Polish and Compress Rewrite answers to be: Direct : first sentence answers the question explicitly. Self-contained : do not assume the AC will read the paper in detail. Evidence-based : show tables/metrics when possible. Polite but firm : especially when you disagree. Optimize for information density : remove filler, keep only useful content. Reviewer Typing & Strategy Type A – Responsible / Reasonable Reviewers Definition : Read the paper carefully, give constructive comments, or point out real weaknesses (even if they gave a low score). Goal : Clarify misunderstandings, show concrete improvements, and make it easy for them to raise the score . Tone : Warm, respectful, collaborative. Pattern : Clarify → Improve → Polite close. Typical phrasing : "We thank Reviewer R1 for the careful reading and constructive feedback." "Sorry for the confusion. We realize that our original description was unclear. We have clarified this in Section X and summarize the key point here." "Following the reviewer’s suggestion, we conducted an additional experiment on [dataset/setting]. The results in Table X show that ..." Type B – Misunderstanding / Careless Reviewers Definition : Ask questions already answered in the paper or clearly misinterpret key concepts. Goal : Correct the misunderstanding without blaming the reviewer, and ensure the AC sees that the paper is already sound. Tone : Polite, calm, confident. Strategy : Take partial responsibility for the confusion ("our explanation may have been unclear"). Point to the exact location in the paper (section, figure, table, or line range). Rephrase the key point in simpler, clearer language directly in the rebuttal. Typical phrasing : "There might be a misunderstanding. Our method does not assume X. Instead, as described in Section 3.2 (Lines xx–yy), we ..." "We apologize for the unclear wording. The paper indeed evaluates on dataset Y; please see Table 2. We restate the main finding here: ..." Type C – Bad-Faith / Unreasonable Reviewers Definition : Provide vague or unsupported reasons for rejection, demand impossible or irrelevant experiments, or make logically inconsistent claims. Goal : You are unlikely to fully convince them. Instead, make it easy for the AC to see that their criticisms are weak. Tone : Firm, factual, respectful; no sarcasm or emotional language . Strategy : Use phrasing like: "We respectfully disagree". Counter with clear data, logic, or community standards . If appropriate, suggest that the requested experiment is unreasonable (too large, off-topic) in a factual way. For venues with Confidential Comments to AC , you may: Objectively summarize why this review is problematic (e.g., ignores provided results, demands infeasible baselines). Focus on behavior and logic, not personal attacks. Typical phrasing : "We respectfully disagree with this assessment. The reviewer states that our method lacks novelty, but we introduce X and Y, which, to the best of our knowledge, have not appeared in prior work (see related work, Section 2)." "The suggested baseline uses a model that is two orders of magnitude larger and is rarely used under the resource constraints considered in this paper. Instead, we compare against widely adopted strong baselines A and B, which are standard in this line of work." Borderline Scores Definition : Score patterns such as 3/4/6/6 where the decision can swing either way. Goal : Increase the psychological cost of rejecting by presenting strong, coherent logic and fixes. Strategy : Avoid overly apologetic tone; focus on arguments and evidence . Make each major concern appear clearly addressed and, when possible, over-answered with extra experiments. Response Structure Templates Overall Rebuttal Skeleton Use this template as a starting point: # Rebuttal ## Overview We thank all reviewers for their thoughtful and constructive feedback. We are encouraged that reviewers found [strengths: e.g., novelty, strong empirical results, clear motivation]. In this rebuttal, we (1) clarify key misunderstandings, (2) present additional experiments addressing concerns about [main issues], and (3) highlight the strengths that multiple reviewers agree on. ## Response to Reviewer R1 **Q1 (Main concern: [short label])** **A1. Direct answer in first sentence.** Then provide necessary details: recap the relevant setup, summarize new or existing results, and explicitly connect them to the concern. **Q2 (Main concern: ...)** **A2. ...** ## Response to Reviewer R2 ... Direct & Self-Contained Answers Always answer the question in the first sentence of A1 . Make each important answer self-contained : Briefly restate necessary definitions, experimental setups, or key numbers. Assume the AC might skim the paper and rely mainly on the rebuttal. Avoid "We will clarify" without content; instead, write: "We have clarified this in Section X and summarize the revised explanation here: ...". Leveraging Other Reviewers When one reviewer is positive on a point that another criticizes, you can politely reference that: "As Reviewer R2 notes, our method is novel in that it introduces ..." "Reviewer R3 explicitly highlights the strong performance on dataset Y, which addresses the concern about generalization raised by Reviewer R1." Data & Experiments Guidance Preferred evidence : New or existing experiments with clear tables. If full-scale experiments are infeasible within the rebuttal window, aim for: Smaller-scale ablations. Subset experiments. Theoretical analysis or back-of-the-envelope calculations. Simple table template : | Method | Dataset A Acc. | Dataset B Acc. | |-----------------------|----------------|----------------| | Baseline 1 | | | | Baseline 2 | | | | Our method (original) | | | | Our method (new exp.) | | | In answers, explicitly state what the table shows and how it addresses the concern. Don’ts Checklist Before finalizing a rebuttal, check that you avoid : Emotional or aggressive language : Do not write "you are wrong". Use "There might be a misunderstanding" or "We respectfully disagree" instead. Excessive apologizing : Limit to targeted phrases like "Sorry for the confusion" where the paper was unclear. Do not flood the rebuttal with "We apologize" or similar. Empty promises : Avoid "We will add this" without substance. Instead: "We have added the following analysis/results and summarize them here: ...". Merging unrelated questions without explanation: Only merge when a strict length limit forces you to, and clearly state which reviewers’ concerns are being answered. Hedging language overuse : Avoid too many "may/might/could" when describing results you already have. Use confident, factual statements for established findings. Final Response Template (When Applicable) For conferences with a Final Response stage aimed at the AC, use a short, high-level summary: # Final Response We sincerely thank all reviewers and the area chair for their time and feedback. **Strengths and consensus.** Reviewers appreciate [list key strengths with references to reviewers, e.g., novelty, strong empirical performance, clear motivation]. **Addressed concerns.** During the rebuttal period, we have: - [R1] Addressed concern about X by [clarification or new experiment], showing that ... - [R2] Added experiments/analysis on Y, which demonstrate that ... - [R3] Clarified Z in Section 3.2 to avoid confusion. We will incorporate all clarifications and the new experimental results into the camera-ready version, further improving the clarity and strength of the paper. Keep the Final Response concise , positive , and focused on: Shared strengths. Major concerns that have been resolved. Concrete actions taken during the rebuttal phase.
Keywords that activate this skill. Click one to copy it.
This skill does not provide trigger words.
The downloaded .skill package contains the following fields.
| Field | Description |
|---|---|
| format | Format tag (skill/v1) |
| skill_id | Unique skill ID |
| name | Skill name |
| version | Version |
| description | Description |
| category | Categories (array) |
| trigger_words | Trigger words |
| tags | Tags |
| source | Source |
| source_url | Source URL (this page) |
| exported_at | Exported at (set per download) |
| system_prompt | System prompt body |
| model_config | Model config: provider / model / temperature / max_tokens / top_p |
| examples | Examples |
| install_guide | Import guide for Coze / Dify / Claude / custom frameworks |
The same skill can be exported in different platform formats.