---
name: peer-review
description: Simulate a tough but constructive peer review of an AI research artifact. Use when the user asks for a review, critique, feedback on a paper or draft, or wants to identify weaknesses before submission.
---

# Peer Review

Simulate a rigorous AI-research peer review with likely objections, severity scoring, and a concrete revision plan. Output a structured review artifact in `outputs/`.

Derive a slug from the artifact name (lowercase, hyphens, ≤5 words).

## Subagent mapping

See `../_platform-mapping.md`. Use `researcher` to gather evidence on the artifact; a second `reviewer`-style subagent (or the lead agent with a reviewer prompt) writes the actual review.

## Workflow

### 1. Plan

Briefly outline:

- What will be reviewed (paper PDF, cited draft, code repo, or all of the above)
- Review criteria — novelty, empirical rigor, baselines, reproducibility, clarity, related-work coverage
- Verification-specific checks for claims, figures, and reported metrics

Summarize to the user in 2–3 sentences, continue immediately unless they asked for plan review.

### 2. Gather evidence (for non-trivial artifacts)

Dispatch a `researcher` subagent to:

- Read the paper / draft
- Inspect the code repo (via `alpha-research` `alpha code` or equivalent)
- Cross-check cited work for misrepresentation
- Look at any linked experimental artifacts (logs, tables, commit history)

Output: `<slug>-research.md` on disk.

For small/simple artifacts where a full research pass is overkill, the lead agent reads directly and skips this step.

### 3. Write the review

Either dispatch a `reviewer` subagent with `<slug>-research.md` as input, or write the review yourself.

Required structure for `outputs/<slug>-review.md`:

```markdown
# Review: <title>

**Artifact:** <link or path>
**Reviewer:** <lead agent / subagent>
**Date:** YYYY-MM-DD

## Summary (one paragraph)
<what the artifact claims and what it actually delivers>

## Strengths
- bulleted, concrete, with section references

## Objections (severity-scored)

### FATAL
- <issue> — why it breaks the paper's core claim, what would need to change

### MAJOR
- <issue> — substantive flaw that should be addressed before submission

### MINOR
- <issue> — would improve the paper but isn't blocking

## Reproducibility check
- Are baselines reported with seeds / runs / variance? <y/n + evidence>
- Is the code available and runnable? <y/n + evidence>
- Are datasets cited and accessible? <y/n + evidence>

## Related-work coverage
- Work the paper engages with adequately
- Work the paper ignores or misrepresents (name specific references)

## Revision plan
A numbered list of concrete edits, in priority order, that would address the FATAL + MAJOR objections.

## Sources
- <every external reference touched during the review>
```

### 4. Second pass (only if FATALs were fixed)

If the first review found FATALs and the author fixes them, run one verification-style pass before final delivery. This pass checks that the fix actually addresses the original objection — no "we updated the introduction" cop-outs for a methodology flaw.

### 5. Deliver

Save exactly one review artifact to `outputs/<slug>-review.md`. End with a `Sources` section with direct URLs for every inspected external source.

## What a peer review is NOT

- Not a summary. The review assumes the reader has read the artifact.
- Not a rewrite suggestion. Flag problems; don't draft the fix.
- Not a hit piece. Every objection should be actionable and specific.
