review2rebuttal

name	review2rebuttal
description	End-to-end academic rebuttal workflow covering Stage1-Stage5: reviewer breakdown, evidence mapping, reply drafting, first-round compilation, follow-up handling, final remarks, and conservative experiment planning from a paper PDF, reviewer comments, and a code repository. Use when the user has reviews and needs a grounded rebuttal workspace rather than a one-shot draft.

Review2Rebuttal

Guide the user through a full rebuttal workflow with on-disk artifacts.

Prefer conservative, grounded outputs over fluent speculation.

Operate in one of two modes:

1. quick mode: review parsing -> issue breakdown -> outline/draft -> first-round compile
2. full mode: complete Stage1-Stage5 workflow with repo grounding, experiment planning, follow-up handling, final remarks, and prompt-driven execution support

Read modes.md before starting.

Quick Start

Collect these inputs before doing substantive drafting:

1. Paper PDF or paper source files.
2. Reviewer comments as pasted text or local files.
3. Venue name, year, and rebuttal deadline.
4. Code repository path, or an explicit statement that no repository is available.

Strongly recommend, but do not require:

1. Supplementary material.
2. Existing rebuttal draft.
3. Notes about reviewer misunderstandings or impossible requests.
4. Compute and time constraints for extra experiments.

If the user has not already organized a workspace, run scripts/scaffold_rebuttal_project.py first. Read workspace-structure.md before creating or validating project files. Read prompt-driven-generation.md before generating final Stage 2, Stage 4, or Stage 5 prose.

Mode Selection

Choose the lightest mode that fits the user request.

Quick Mode

Use when the user mainly wants:

• reviewer comment breakdown
• point-by-point rebuttal drafting
• a compiled first-round rebuttal

Default quick-mode path:

1. scaffold workspace
2. parse reviews
3. build issue index
4. build or update paper/facts.md
5. generate response outlines
6. collect author approvals only if needed
7. generate drafts or Stage 2 prompt packets
8. compile first-round rebuttal

Quick mode does not require:

• repo indexing
• experiment planning
• follow-up artifacts
• final remarks artifacts
• prompt generation queue

Full Mode

Use when the user needs the complete rebuttal operation, including:

• repo-aware evidence mapping
• experiment feasibility planning
• Stage 4 follow-up handling
• Stage 5 final remarks
• prompt-driven execution tracking

Default to full mode only when the user clearly wants end-to-end rigor, multiple rounds, or experiment planning.

Core Principles

1. Keep every important intermediate artifact on disk.
2. Treat reviewer concerns as atomic issues, not as one long free-form conversation.
3. Ground every response in the paper, the repo, or an explicit limitation.
4. Default to conservative experiment planning; do not imply experiments are feasible without evidence.
5. Keep the author in the loop at all decision points that affect scientific claims.
6. If evidence is missing, say so and downgrade confidence instead of inventing support.

Workflow

Step 0: Intake and Scaffold

If there is no rebuttal workspace yet:

1. Create one with scripts/scaffold_rebuttal_project.py <workspace-dir>.
2. Record the paper path, repo path, venue, year, and deadline in rebuttal-config.json.
3. Ensure the generated STRUCTURE.md exists.

Use the scaffolded structure from workspace-structure.md.

Step 1: Paper Grounding

Before parsing reviews, build a concise paper fact sheet.

Create paper/facts.md with:

• problem setup
• key claims
• main method components
• major experiments
• important quantitative results
• acknowledged limitations
• repo entry points likely relevant to reviewer requests

If the PDF is unreadable or the paper cannot be grounded reliably, stop and ask for extracted text or source files.

Step 2: Stage 1 Breakdown

For each reviewer:

1. Parse scores if present.
2. Preserve summary and strengths as faithfully as possible.
3. Split weaknesses, questions, limitations, and suggestions into atomic issues.
4. Assign stable ids and response slots.
5. Write stage artifacts to disk.

Use the schemas in artifact-schema.md. When adapting logic from RebuttalStudio, inspect the original app sources only if the current skill artifacts are insufficient.

Minimum outputs:

• reviews/parsed/<reviewer>.json
• issues/<reviewer>-issues.json
• issues/<reviewer>-issues.md

Step 3: Evidence Mapping

For each atomic issue:

1. Map the issue to paper evidence.
2. Map the issue to code evidence if the repo is available.
3. Identify what is already answered, partially answered, or unsupported.
4. Separate clarification-only issues from experiment-request issues.

Write grounded notes to evidence/.

If the repo is unavailable, mark code-backed feasibility as unknown, not feasible.

This step is optional in quick mode and expected in full mode.

Step 4: Experiment Planning

When reviewer issues imply new empirical work:

1. Inspect the repository for likely training, evaluation, config, data, and baseline entry points.
2. Classify each request as ready_now, moderate_effort, high_risk, not_realistic, or unknown.
3. Write a conservative plan with expected files to touch, risks, and likely outputs.
4. Present the estimate to the author and let the author decide whether to run anything.

Do not execute experiments by default in this skill. Read experiment-planning.md when planning or downgrading feasibility.

This step belongs to full mode.

Minimum outputs:

• experiments/requests.md
• experiments/feasibility.md
• experiments/proposed-plan.md

Step 5: Stage 2 Reply Drafting

For each issue:

1. Draft an outline first.
2. Require the author to confirm or revise the outline if the issue is high risk, scientific, defend, or experiment-dependent.
3. Build a Stage 2 prompt packet for high-quality generation once approval is recorded.
4. Use deterministic draft scaffolds only as fallback or temporary placeholders.
5. Keep claims bounded by known evidence.

Minimum outputs:

• responses/outlines/<issue_id>.md
• responses/drafts/<issue_id>.md
• responses/prompts/<issue_id>-prompt.md

Step 6: Stage 3 First-Round Compilation

Compile issue-level responses into:

1. per-reviewer files
2. one merged first-round file

If venue limits are tight:

1. compress low-priority text first
2. keep coverage before polish
3. never silently drop an issue

Minimum outputs:

• responses/compiled/<reviewer>-first-round.md
• responses/compiled/all-first-round.md

Step 7: Stage 4 Follow-Up

If discussion continues:

1. Condense the prior discussion for each reviewer.
2. Preserve prior commitments and numbers.
3. Build a follow-up prompt packet from condensed context + question + experiment decisions.
4. Draft concise follow-up responses from that prompt packet.
5. Check for contradictions with earlier rounds.

Minimum outputs:

• followups/<reviewer>-context.md
• followups/<reviewer>-roundN.md
• followups/prompts/<reviewer>-roundN-prompt.md

This step belongs to full mode.

Step 8: Stage 5 Final Remarks and QA

At the end:

1. Synthesize reviewer concerns and resolutions.
2. Build a final Stage 5 prompt packet from reviewer summaries, compiled rebuttal, follow-up artifacts, and experiment decisions.
3. Draft final remarks from that prompt packet.
4. Run a QA pass for unsupported claims, contradictory numbers, fabricated citations, and missed issues.
5. Refresh PROMPT_GENERATION_QUEUE.md so pending prompt-driven tasks remain explicit.
6. After generating prose from any Stage 2, Stage 4, or Stage 5 prompt packet, write it back with scripts/apply_prompt_packet.py rather than manually guessing the target path.

Minimum outputs:

• final/final-remarks.md
• final/qa-report.md
• final/prompts/final-remarks-prompt.md
• final/reviewer-summaries.md
• PROMPT_GENERATION_QUEUE.md

This step belongs to full mode.

Required Review Gates

Require explicit author confirmation before:

1. any claim that depends on a new experiment
2. any promise to add analysis, benchmarks, or implementation changes
3. any response that contradicts or narrows a paper claim
4. final compilation submission text
5. any Stage 2 prompt packet for an issue flagged in responses/outline-review.md

If the user wants speed over rigor, still preserve the warnings in the relevant artifact files.

Output Rules

1. Preserve stage artifacts on disk even if you also summarize them in chat.
2. Use stable ids for issues and responses.
3. Prefer Markdown or JSON for artifacts.
4. Keep a canonical structure document in the workspace root.
5. Distinguish clearly between:
   • paper-backed claims
   • code-backed feasibility
   • reviewer requests
   • author decisions

Hard Constraints

1. Do not fabricate experiments, numbers, citations, baselines, or repo capabilities.
2. Do not claim an experiment is easy unless the repo inspection actually supports that claim.
3. Do not write final polished prose before grounding the paper and parsing the reviews.
4. Do not silently resolve ambiguity; record it.
5. Do not collapse Stage 1-Stage 5 into one monolithic draft unless the user explicitly asks.

References

Read references only when needed:

• modes.md: quick mode vs full mode selection and boundaries
• workspace-structure.md: project layout and required files
• artifact-schema.md: canonical artifact schemas for all stages
• experiment-planning.md: conservative experiment planning rules and feasibility categories
• script-usage.md: recommended commands for the helper scripts
• prompt-driven-generation.md: when and how to use the higher-quality Stage 2/4/5 prompt packets