# Awesome Rebuttal > Install a local rebuttal workspace for academic papers with structured intake, reviewer analysis, and strategy planning to produce venue-compliant author responses. - Skill: `xiongqi123123/awesome-rebuttal` (Agent Skill, multi-file: 6 files) - Install (CLI): `npx skillmds add xiongqi123123/awesome-rebuttal` - Raw SKILL.md: https://api.skillmd.com/api/skills/xiongqi123123/awesome-rebuttal/raw - Safety review: CAUTION (external: skill-scanner PASS, skillspector PASS) - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Research & Search, AI & ML, Docs & Writing, Academic Writing, Summarization, Technical Writing - Tags: Academic Paper, Latex, Openreview, Peer Review, Rebuttal, Reviewer Analysis, Strategy Planning, Venue Rules - Author: xiongqi123123 (https://skillmd.com/u/xiongqi123123) - Updated: 2026-08-22 - Page: https://skillmd.com/skills/xiongqi123123/awesome-rebuttal --- # Awesome Rebuttal Use this skill as a **global-installable, project-level rebuttal workspace assistant**. The installed skill provides reusable procedures and assets; each actual paper/rebuttal workspace gets its own `.awesome-rebuttal/` state folder for memory, snapshots, template state, and logs. Start by understanding the workspace, then collect evidence, persist memory, analyze strategy, and only then draft response text. ## Operating contract 1. Inspect the current workspace before content analysis. 2. Create or use a project-local `.awesome-rebuttal/` state folder; never store runtime memory in the installed skill folder. 3. If the workspace is empty, organize or recommend `Code/`, `Paper/`, `Reference/`, and `Temp/`. 4. If the workspace already contains files, infer the author's organization and adapt non-destructively. 5. Ask how progress should be preserved: `manual_git`, `auto_git`, or `markdown_snapshot_only`. 6. Run the intake gate before analysis. Missing required inputs block drafting. 7. Treat venue rules as user-provided or AI-searched + user-confirmed; never rely on stale built-in venue rules. 8. Keep every factual claim grounded in `paper`, `code`, `review`, `venue_rules`, `user`, or explicit `inference`. 9. Never invent experiments, numbers, citations, reviewer positions, or venue permissions. ## Language policy - Interaction language: follow the user's language by default for questions, analysis reports, progress updates, and explanations. - Submission language: final rebuttal artifacts must be written in English unless the user explicitly requests another submission language and the venue permits it. - Memory: record this choice in `project_memory.language_policy` and mirror any venue-specific exception in `venue_rules.language_policy`. - Drafting rule: `11_response_writer.md`, `12_template_designer.md`, and `13_ac_summary_writer.md` may discuss plans in the user's language, but author-response text, reviewer replies, AC summaries, OpenReview comments, and PDF rebuttal prose default to English. - Terminology: preserve exact technical terms, metric names, method names, dataset names, and reviewer wording from the paper/reviews; translate only surrounding explanatory prose when needed. - If the user provides Chinese strategy notes, convert them into professional English rebuttal prose rather than literal translation. ## Shared questionnaire protocol Whenever the skill hits missing, ambiguous, or confirmation-dependent information, first summarize what the user already provided and what the workspace evidence shows. Then ask a focused questionnaire instead of guessing. Read `references/core/user_questionnaire_protocol.md` for the reusable questionnaire pattern. Use it especially in workspace bootstrap and intake, and reuse it later for venue-rule confirmation, experiment feasibility, versioning mode, or any strategy decision that materially changes the output. Prefer structured choices when possible: - single-choice for mutually exclusive paths - multi-select for available inputs or constraints - short text for pasted rules, reviews, paths, or URLs - confirmation for inferred workspace maps or AI-found venue rules Ask only for the smallest missing decision set needed for the next safe step. ## Canonical response modes Use these exact `response_mode` values across all memory files and capability handoffs: - `openreview_per_reviewer` — one reply/comment per reviewer thread. - `unified_limited` — one limited unified response where concerns are merged. - `pdf_one_page` — one-page PDF/LaTeX rebuttal. - `global_comment` — one global platform comment/text box. - `hybrid` — global summary plus per-reviewer replies. - `openreview_markdown_latex` — OpenReview-style Markdown comment with lightweight LaTeX math. - `unknown` — not confirmed yet. Do not introduce aliases such as `per_reviewer`, `global`, `global_text`, `one_page_pdf`, or `markdown_latex_hybrid` in new memory. If user wording uses those terms, normalize to the canonical value and record the original wording in notes if useful. ## Venue rules schema contract Use `references/memory-schemas/venue_rules.schema.json` as the global rule-memory contract. Venue rules are runtime evidence, not built-in knowledge. Every `venue_rules.json` should separate: - `status` and `source`: missing/user-provided/AI-found-pending-confirmation plus URL/path/retrieval notes. - `response`: canonical `mode`, platform, limits, per-reviewer/global/interactive/AC-summary permissions. - `formatting`: official template, PDF/LaTeX/Markdown support, figures/tables/appendix, and page-layout constraints. - `content_permissions`: new experiments/results, links, supplements, code links, references, revision commitments. - `anonymity`: anonymous requirement, self-citation, acknowledgements, and identity-risk notes. - `confirmation`: user confirmation timestamp, pending questions, and conflicts. - `language_policy`: interaction language follows user; final submission-facing prose defaults to English. If rules are AI-searched, keep `status: ai_found_pending_confirmation` until the user confirms them. Unknown fields stay `unknown`; do not infer permissions silently. ## Required workflow Follow this order unless the user asks for a narrower capability: 1. **Workspace bootstrap** — read `references/capabilities/00_workspace_bootstrap.md`; create/use `.awesome-rebuttal/`, detect LaTeX environment, and if decisions are missing use `references/core/user_questionnaire_protocol.md`. 2. **Intake gate** — read `references/capabilities/01_intake_gate.md`; parse user-provided context first, then ask a questionnaire for blockers. 3. **Template management** — read `17_rebuttal_template_manager.md` after intake when response format requires a `pdf_one_page` template, `openreview_per_reviewer` Markdown scaffolds, `global_comment` Markdown, or `openreview_markdown_latex` comments. 4. **Information collection** — read `references/capabilities/02_information_collection.md`. 5. **Paper/code memory** — read `03_paper_memory_builder.md` and/or `04_code_memory_builder.md` when paper or code context is present. 6. **Review indexing** — read `05_review_normalizer.md`; preserve raw reviews, build raw anchors, issue item index, and common issue index without strategic analysis. 7. **Review concern analysis** — read `06_situation_analyzer.md`; interpret indexed concerns semantically without priority ranking. 8. **Review-driven experiment planning** — read `10_experiment_triage.md`; generate numbered `EXP-*` experiment candidates from reviewer concerns and persist `experiment_memory.json` before final strategy planning. 9. **Priority and situation analysis** — read `07_concern_atomizer.md`; rank concern importance, classify rebuttal posture, build reviewer priority map, link P0/P1 evidence gaps to numbered experiments, and identify AC-facing decision facts. 10. **Strategy planning** — read `08_strategy_planner.md`; combine priority analysis, experiment memory, paper/code evidence, venue constraints, and user decisions. Use a questionnaire for strategy/experiment trade-offs before locking the plan. 11. **Snapshots/versioning** — read `09_snapshot_maker.md` and `16_rebuttal_versioning.md` at each durable checkpoint. 12. **Writing** — read `11_response_writer.md`, `13_ac_summary_writer.md`, and `12_template_designer.md` only after strategy is evidence-backed and user-approved; 12 selects `pdf_one_page`, `openreview_per_reviewer`, `global_comment`, `hybrid`, or `openreview_markdown_latex` layout. 13. **Rehearsal** — read `18_rebuttal_rehearsal.md` once a draft exists; simulate reviewer/AC personas reading paper-vs-rebuttal in isolation, then route hardening back to 11/13. Advisory only; it never approves submission. 14. **Safety gate** — read `14_safety_rule_checker.md` before any final or paste-ready text/PDF/comment. 15. **Discussion rounds** — read `19_discussion_round_handler.md` after the first rebuttal is submitted; ingest reviewer/AC follow-up replies, track score/engagement per round, draft delta-only follow-ups (reusing the 18 answer bank), and route each through 14 before posting. 16. **Overleaf sync** — read `15_overleaf_leaflink_sync.md` only when the paper is on Overleaf/cn.overleaf or the user asks about cloud/local synchronization. Read only the capability files needed for the current request. ## Core outputs A complete strategy-first run should produce: - Intake completeness report - workspace-local `.awesome-rebuttal/memory/*.json` for project, paper, code, reviews, experiments, strategy, responses, templates, AC summaries, safety, versioning, and optional Overleaf sync - Reviewer stance map - Atomic concern ledger - Common concern clusters - Response strategy matrix - Numbered review-driven experiment memory and triage (`EXP-*`) - Format-aware response blueprint and evidence-aligned response draft - Coverage map from reviewer concerns to response units - Rehearsal findings from simulated reviewer/AC personas, with a prioritized hardening list and an anticipated follow-up answer bank - Multi-round discussion state: reviewer engagement/score tracker, per-thread decisions, and delta-only follow-up drafts gated by safety - Optional AC summary decision, fact ledger, and draft when rules allow - Rule/safety checklist and `safety_memory.json` final gate - Rebuttal template report and active template copy when template-based response is needed - Canonical `.awesome-rebuttal/snapshots/snapshot_memory.json` plus generated user Markdown snapshot, or git checkpoint according to the selected versioning mode ## Project-local state folder For each actual rebuttal workspace, create or use: ```text .awesome-rebuttal/ ├── memory/ # project/paper/code/review/experiment/strategy/response/template/rehearsal/discussion/safety/versioning memory ├── drafts/ # response blueprints, drafts, and coverage maps ├── snapshots/ # JSON and markdown reload snapshots ├── templates/ # active rebuttal templates copied/adapted for this project ├── logs/ # rule-search, compile, and validation logs └── cache/ # disposable skill cache; safe to regenerate ``` The installed/global skill folder contains reusable instructions and assets only. Runtime memory, snapshots, fetched templates, and logs belong in the current workspace's `.awesome-rebuttal/` folder. ## Workspace convention Recommended runtime workspace: ```text / ├── Code/ # code, scripts, configs, reproduced outputs ├── Paper/ # paper PDF/LaTeX; Overleaf sync target if used ├── Reference/ # reviews, venue rules, reference papers, notes └── Temp/ # temporary extraction, scratch drafts, search/cache outputs ``` Do not force this layout on an existing organized workspace. Map existing paths and record them in project memory. ## Progress preservation modes Ask the user to choose one: - `manual_git`: suggest checkpoint boundaries and commit messages; do not commit unless explicitly asked. - `auto_git`: create local milestone commits only; no push, history rewrite, or destructive git operations without explicit instruction. - `markdown_snapshot_only`: maintain `.awesome-rebuttal/snapshots/snapshot_memory.json` as the canonical reload entry and render `.awesome-rebuttal/snapshots/REBUTTAL_SNAPSHOT.md` or `.awesome-rebuttal/snapshots/PROJECT_SNAPSHOT.md` as the user-readable progress summary. ## LaTeX environment policy During workspace bootstrap, detect whether a local LaTeX toolchain is available (`latexmk`, `pdflatex`, `xelatex`, `lualatex`, `bibtex`/`biber`, `kpsewhich`, or `tectonic`). If no compiler is available and a PDF rebuttal is needed, ask the user to choose a setup path for their platform: MacTeX/BasicTeX on macOS, TeX Live on Linux, MiKTeX/TeX Live on Windows, Tectonic, Overleaf-only compilation, or skip local compilation for now. ## Overleaf / LeafLink policy LeafLink is not an advertisement. It is a conditional helper for authors whose paper is on cloud Overleaf. - Ask whether the paper is on Overleaf/cn.overleaf. - If yes, offer LeafLink as an optional way to sync the project into `Paper/`: https://github.com/xiongqi123123/LeafLink - If no, stay silent and use local paper files. - Never include LeafLink text in final rebuttal, reviewer replies, AC summaries, or conference-submission-facing text. ## Safety gates Block finalization if any of these fail: 1. **Provenance gate** — every factual statement has a source. 2. **Commitment gate** — every promise is already done, explicitly approved, or framed as future work. 3. **Coverage gate** — every reviewer concern is answered, intentionally deferred, or marked `needs_user_input`. 4. **Venue-rule gate** — format/links/supplementary claims are allowed by confirmed rules. 5. **Tone gate** — no reviewer attacks, defensiveness, flattery manipulation, or unprofessional phrasing.