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.