awesome-rebuttal

name

awesome-rebuttal

description

Global-installable, project-level academic rebuttal strategy skill for AI/ML/CV/NLP/Robotics papers. Use when authors need a workspace-local .awesome-rebuttal state folder, paper/code/review/venue-rule intake, JSON memory, snapshots, LaTeX/template handling for one-page rebuttals, reviewer stance analysis, strategy planning, experiment triage, safe author response drafting, or AC summaries under confirmed venue rules.

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, , and only after strategy is evidence-backed and user-approved; 12 selects , , , , or layout.

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:

.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:

<rebuttal-workspace>/
├── 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.