# What Is the Function of the RE-REVIEW Stage (Stage 3') in the ARS Pipeline?

> Understand the RE-REVIEW stage (Stage 3') in the ARS pipeline. This crucial verification step ensures author revisions address comments and catch new issues before proceeding.

- Repository: [Edward Cheng-I Wu/academic-research-skills](https://github.com/Imbad0202/academic-research-skills)
- Tags: deep-dive
- Published: 2026-05-13

---

**The RE-REVIEW stage (Stage 3') serves as a verification checkpoint that validates whether author revisions actually address first-round review comments, surfaces any new issues introduced by changes, and requires mandatory human approval before the pipeline continues.**

The **Imbad0202/academic-research-skills** repository implements a rigorous academic paper review pipeline designed to ensure manuscript quality through structured quality gates. Understanding the function of the RE-REVIEW stage (Stage 3') is essential for navigating the revision workflow effectively. This stage operates as the second human gate in the pipeline, specifically examining whether manuscript modifications genuinely resolve previous reviewer concerns without introducing regressions.

## Core Function and Purpose

The RE-REVIEW stage operates as a **verification-review checkpoint** that follows any manuscript revision. Unlike the initial Stage 3 review, this stage specifically examines delta changes to confirm that the author's revisions address comments from the first-round review and identifies any new problems introduced by the modifications.

According to [`docs/ARCHITECTURE.md`](https://github.com/Imbad0202/academic-research-skills/blob/main/docs/ARCHITECTURE.md), Stage 3' represents a **decision-heavy checkpoint** where the user must approve the verification decision—Accept, Minor, or Major—before the pipeline can proceed. This mandatory gate prevents automatic progression and ensures human oversight of revision quality.

### The Three-Agent Verification Team

To maintain focus and efficiency, the RE-REVIEW stage deploys a **trimmed three-agent verification team** rather than the full five-person panel used in Stage 3. As documented in [`academic-paper-reviewer/SKILL.md`](https://github.com/Imbad0202/academic-research-skills/blob/main/academic-paper-reviewer/SKILL.md), only the following agents participate:

- `field_analyst_agent`
- `eic_agent`
- `editorial_synthesizer_agent`

This narrowed configuration eliminates redundancy while preserving the analytical depth required for verification tasks.

## Verification Outputs and Artifacts

The stage produces a structured **Verification Package** containing four key artifacts defined in Schema 11 of the protocol:

1. **Revision-Response Checklist** – Tracks each author claim against review comments
2. **Residual-Issues list** – Documents outstanding problems not resolved by revisions
3. **New editorial decision** – Accept, Minor, or Major verdict based on verification results
4. **R&R Traceability Matrix** – Links each author claim to its verification status

These outputs are saved to [`.claude/pipeline_output/verification_review_report.md`](https://github.com/Imbad0202/academic-research-skills/blob/main/.claude/pipeline_output/verification_review_report.md) upon completion.

## Workflow Constraints and Decision Logic

The RE-REVIEW stage enforces strict boundaries to prevent infinite revision loops and ensure pipeline integrity.

### Hard Limits on Revision Rounds

The pipeline orchestrator, managed by [`academic-pipeline/agents/state_tracker_agent.md`](https://github.com/Imbad0202/academic-research-skills/blob/main/academic-pipeline/agents/state_tracker_agent.md), enforces two critical constraints:

- Only **one RE-REVISE round** (Stage 4') is permitted following RE-REVIEW
- Maximum **two total revision loops** across Stages 4 and 4'

If the verification decision is **Major**, the workflow diverts to a **residual-coaching sub-stage** (Stage 3' → 4') before the final RE-REVISE attempt, as detailed in [`docs/ARCHITECTURE.md`](https://github.com/Imbad0202/academic-research-skills/blob/main/docs/ARCHITECTURE.md).

### Mandatory Integrity Checkpoint

Following RE-REVIEW completion, the pipeline automatically inserts a **mandatory integrity checkpoint** before the Finalize stage. According to [`academic-pipeline/references/integrity_review_protocol.md`](https://github.com/Imbad0202/academic-research-skills/blob/main/academic-pipeline/references/integrity_review_protocol.md), the orchestrator tracks **score-trajectory deltas** to flag any regressions or quality degradation introduced during revisions.

## Triggering the RE-REVIEW Stage

Users invoke the verification process through specific commands that switch the `academic-paper-reviewer` skill into `re-review` mode.

Trigger the verification review after completing revisions:

```bash

# Stage 4: Revise the manuscript

claude "Revise the paper with the following changes:" < revised_draft.txt

# Stage 3': Trigger RE-REVIEW verification

claude "Check revisions"

```

The second command initiates the verification protocol by:

1. Loading the **Revision Roadmap** from Stage 3
2. Executing the three-agent verification team
3. Generating the **Verification Review Report** per [`academic-paper-reviewer/re_review_mode_protocol.md`](https://github.com/Imbad0202/academic-research-skills/blob/main/academic-paper-reviewer/re_review_mode_protocol.md)
4. Pausing for user approval of the decision

Inspect the generated verification report:

```bash
cat .claude/pipeline_output/verification_review_report.md

```

This output contains the checklist, residual issues, and R&R Traceability Matrix required for audit trails.

## Summary

- The RE-REVIEW stage (Stage 3') functions as a **verification checkpoint** that confirms author revisions address first-round review comments.
- Only **three specialized agents** participate, creating a focused verification team distinct from the initial review panel.
- The stage produces four structured artifacts including the **R&R Traceability Matrix** and **Residual-Issues list**.
- **Hard limits** restrict the process to one RE-REVISE round and two total revision loops maximum.
- A **mandatory integrity checkpoint** follows RE-REVIEW to detect score regressions before finalization.

## Frequently Asked Questions

### What is the difference between Stage 3 (Review) and Stage 3' (RE-REVIEW)?

Stage 3 conducts the initial full-panel review of the original manuscript, while Stage 3' performs **verification-specific checks** on revision deltas. RE-REVIEW uses only three agents compared to Stage 3's five-agent panel, and requires explicit human approval of the Accept/Minor/Major decision before continuing.

### How many times can a manuscript go through RE-REVIEW?

The pipeline enforces a **hard limit of one RE-REVISE round** following RE-REVIEW. Across the entire workflow, authors may complete at most **two total revision loops** spanning Stages 4 and 4'. The [`state_tracker_agent.md`](https://github.com/Imbad0202/academic-research-skills/blob/main/state_tracker_agent.md) monitors these counts to prevent infinite cycling.

### What happens if the RE-REVIEW decision is "Major"?

A **Major** decision triggers a residual-coaching sub-stage (Stage 3' → 4') before the final RE-REVISE attempt. This coaching phase helps authors address the residual issues identified in the verification report before consuming their single allowed RE-REVISE round.

### Where are the RE-REVIEW outputs stored?

The **Verification Review Report** is saved to [`.claude/pipeline_output/verification_review_report.md`](https://github.com/Imbad0202/academic-research-skills/blob/main/.claude/pipeline_output/verification_review_report.md). This file contains the Revision-Response Checklist, Residual-Issues list, new editorial decision, and R&R Traceability Matrix as defined in [`re_review_mode_protocol.md`](https://github.com/Imbad0202/academic-research-skills/blob/main/re_review_mode_protocol.md).