How the REVIEW Stage in the ARS Pipeline Operates: Architecture, Process, and Modes

The REVIEW stage in the ARS pipeline is a multi-phase peer review simulation driven by the academic-paper-reviewer skill that enforces a Sprint Contract gate before executing parallel agent reviews across six operational modes, culminating in an Editorial Decision Letter.

The Academic Research Skills (ARS) pipeline implements a structured approach to academic manuscript development, with the REVIEW stage serving as the critical first editorial decision point. This stage leverages the academic-paper-reviewer skill (v1.9.0) to simulate multi-perspective peer review through specialized AI agents. According to the Imbad0202/academic-research-skills repository, this stage operates through a rigorous three-phase process with a hard gate mechanism that ensures reviewer commitment before manuscript exposure.

Architecture and Orchestration

The REVIEW stage (Stage 3) represents the first editorial decision point in the pipeline workflow.

The academic-pipeline orchestrator hands the completed manuscript—produced by the WRITE stage—to the reviewer skill. This hand-off is recorded in the pipeline matrix defined in docs/ARCHITECTURE.md (lines 98-104). Before any reviewer accesses the paper, the system enforces a Sprint Contract (Schema 13) through scripts/check_sprint_contract.py, creating a hard gate that guarantees reviewers commit to a scoring plan while the paper remains blind.

The Three-Phase Review Process

The REVIEW stage executes through three distinct phases, each handled by specialized agents:

Phase 0: Field Analysis

The field_analyst_agent analyzes the manuscript to infer discipline, methodology, and target journal. This agent creates a Reviewer Configuration Card containing five reviewer personas that the user can confirm or adjust. This configuration step ensures the subsequent review panel matches the paper's specific academic domain.

Phase 1: Parallel Review

Seven agents execute independently in parallel:

• eic_agent (Editor-in-Chief)
• methodology_reviewer_agent
• domain_reviewer_agent
• perspective_reviewer_agent
• devils_advocate_reviewer_agent
• editorial_synthesizer_agent (read-only)

Each agent produces a structured report using templates stored in academic-paper-reviewer/templates/. The parallel execution ensures diverse perspectives without cross-contamination during the initial review phase.

Phase 2: Synthesis and Decision

The editorial_synthesizer_agent merges the individual reports (five or fewer depending on mode) and applies a three-step mechanical protocol. This phase emits an Editorial Decision Letter classifying the manuscript as Accept, Minor Revision, Major Revision, or Reject, accompanied by a detailed Revision Roadmap.

This decision triggers a decision-heavy checkpoint where the user must confirm the Editorial Decision before the pipeline proceeds to the REVISE stage, as documented in the architecture table (ARCHITECTURE.md, lines 21-28).

Six Operational Modes

The academic-paper-reviewer supports six operational modes that determine which agents execute and what artefacts are produced. The mode is selected automatically from user prompts or forced via CLI flags.

full (default)

• When to use: First-time, pre-submission review
• Agents: All 7 agents (5 reviewers + synthesizer)
• Output: 5 review reports, Editorial Decision, and Revision Roadmap

re-review

• When to use: Stage 3′ verification after author revisions
• Agents: field_analyst_agent, eic_agent, editorial_synthesizer_agent (narrow team)
• Output: Verification package with response checklist and residual-issues list

quick

• When to use: Fast-track sanity check (approximately 15 minutes)
• Agents: field_analyst_agent, eic_agent only
• Output: Concise EIC assessment and key-issue list

methodology-focus

• When to use: Deep check of methods and statistics
• Agents: field_analyst_agent, eic_agent, methodology_reviewer_agent
• Output: Two-reviewer panel (EIC + methodology) with detailed methodology report

guided

• When to use: Interactive Socratic review (author-led)
• Agents: All agents plus Socratic dialogue capability
• Output: Review reports and guided dialogue transcript

calibration

• When to use: One-off accuracy measurement against gold standard papers
• Agents: All 7 agents (run × 5 per gold paper)
• Output: Calibration Report with FNR/FPR metrics and confidence disclosure

Command-Line Usage Examples

Execute the REVIEW stage using the ars-full CLI wrapper with mode-specific flags:

# Run complete pipeline stopping at REVIEW decision checkpoint

ars-full --stop-after review

# Execute REVIEW stage in full mode (first submission)

ars-full --stage review --mode full

# Quick review for rapid assessment

ars-full --stage review --mode quick

# Post-revision verification review

ars-full --stage re-review

# Inspect the Sprint Contract for a full review

cat shared/contracts/reviewer/full.json

Key Implementation Files

File	Purpose
docs/ARCHITECTURE.md	Stage 3 matrix and decision-heavy checkpoint definitions (lines 96-105)
academic-paper-reviewer/SKILL.md	Complete reviewer skill documentation and mode specifications
shared/sprint_contract.schema.json	JSON Schema defining the hard gate requirements
scripts/check_sprint_contract.py	Validator enforcing sprint contract compliance
academic-paper-reviewer/templates/peer_review_report_template.md	Canonical structure for reviewer reports
academic-paper-reviewer/templates/editorial_decision_template.md	Layout for Editorial Decision Letters
commands/ars-full.md	CLI wrapper implementing pipeline orchestration flags

Summary

• The REVIEW stage is Stage 3 of the ARS pipeline, serving as the first editorial decision point using the academic-paper-reviewer skill.
• A Sprint Contract gate enforced by scripts/check_sprint_contract.py ensures blind review commitment before manuscript exposure.
• The three-phase process includes Field Analysis, Parallel Review (7 agents), and Synthesis & Decision.
• Six operational modes (full, re-review, quick, methodology-focus, guided, calibration) adapt the review intensity to submission requirements.
• The stage concludes with an Editorial Decision Letter and Revision Roadmap, requiring user confirmation at a decision-heavy checkpoint before proceeding to revision.

Frequently Asked Questions

What triggers the REVIEW stage to begin in the ARS pipeline?

The REVIEW stage initiates when the academic-pipeline orchestrator completes the hand-off from the WRITE stage, passing the finalized manuscript to the academic-paper-reviewer skill. This transition is recorded in the pipeline matrix within docs/ARCHITECTURE.md, specifically at the Stage 3 entry. The orchestrator only proceeds after verifying that the Sprint Contract has been established via scripts/check_sprint_contract.py.

How does the Sprint Contract gate ensure review integrity?

The Sprint Contract acts as a hard gate requiring reviewers to commit to a scoring plan before accessing the manuscript. Implemented through Schema 13 and enforced by scripts/check_sprint_contract.py, this mechanism ensures the review remains blind and that reviewers cannot adjust their evaluation criteria after seeing the paper. The contract is stored in shared/contracts/reviewer/ and must be validated before Phase 0 execution.

Can I run multiple review modes sequentially on the same manuscript?

Yes. The pipeline supports iterative review cycles. After completing a full review and implementing revisions, you can trigger a re-review (Stage 3′) to verify changes using ars-full --stage re-review. This mode narrows the agent panel to focus specifically on whether revision requests have been adequately addressed, producing a verification package with a traceability matrix.

Where are the reviewer report templates defined?

Each reviewer agent follows a canonical structure defined in academic-paper-reviewer/templates/peer_review_report_template.md. The editorial_synthesizer_agent uses academic-paper-reviewer/templates/editorial_decision_template.md to format the final decision letter. These templates ensure consistency across the five parallel reviews regardless of which operational mode is active.

{
  "mcpServers": {
    "instagit": {
      "command": "npx",
      "args": ["-y", "instagit@latest"]
    }
  }
}