---
name: amp-review
description: Review code using Amp's review command. Use when explicitly asked to do an "amp-review" or amp review.
---

# Amp Code Review

Start an Amp review by running the `amp review` CLI with the right target. This works from Amp or any other agent harness with shell access.

## Scope terms

- **Uncommitted changes** = staged + unstaged + untracked local file changes — everything `git status` would list as not yet committed. Never silently drop untracked files from a default local review; they are part of the work surface.
- **Mainline** = the branch a feature branch diverges from; resolved in the order below.

## Target Selection

First determine the target from the user's request and git state.

Priority order:

1. **Specific commit/range only when explicitly requested**
   - If the user gives a commit SHA, tag, ref, or range, review exactly that commit/range.
   - Do not reinterpret a commit request as worktree or PR review.

2. **Specific worktree scope only when explicitly requested**
   - If the user asks for uncommitted, staged, unstaged, worktree, or local-only changes, review only that requested scope.
   - Do not add committed branch changes just because the current branch is not `main` or `master`.

3. **Feature/special branch default: review uncommitted changes plus branch changes vs merge base**
   - If current branch is not `main` or `master`, treat it as a PR/branch review.
   - Include both:
     - committed branch changes since merge base with mainline
     - uncommitted local changes (per Scope terms — includes untracked)
   - Separate findings by committed branch changes vs uncommitted changes when useful.

4. **Mainline branch default: review uncommitted changes only**
   - If current branch is `main` or `master`, review uncommitted local changes (per Scope terms — includes untracked).

5. **Ambiguous or no clear target: ask**
   - If there is no relevant diff, detached HEAD without a specified commit/range, no clear mainline, or multiple plausible targets, ask the user which target to review.

## Discovery Commands

Run these first unless the user gave an explicit commit/range:

```bash
git status --short --branch
git branch --show-current
git symbolic-ref --quiet refs/remotes/origin/HEAD || true
git remote show origin || true
```

Find mainline in this order:

1. user-specified base
2. `origin/HEAD`
3. `origin/main`, `origin/master`
4. local `main`, local `master`

Do not switch branches. Fetch only if needed for a reliable merge base; ask before fetch when network side effects are undesirable.

## Run Amp Review

Use `amp review [diff_description...]` as the review engine. The `diff_description` can be a git command, commit range, single commit/ref, natural language description, or empty for uncommitted changes.

Useful options:

- `--instructions <text>` / `-i <text>`: add review focus.
- `--files <files...>` / `-f <files...>`: focus specific files or directories.
- `--thinking high`: use for larger or riskier reviews.
- `--json`: structured output when another agent needs to parse results.

Command selection:

- **Explicit commit/range**: `amp review "<commit-or-range>" --thinking high`
- **Explicit uncommitted/worktree scope**: `amp review "uncommitted changes" --thinking high`
- **Feature/special branch default**: after detecting mainline, run `amp review "<mainline>...HEAD plus uncommitted changes" --thinking high`
- **Mainline branch default**: `amp review --thinking high`

Add instructions unless the user supplied more specific review focus:

```bash
amp review "<target>" --thinking high --instructions "Focus on correctness bugs, regressions, security, data loss, API/contract drift, performance, and missing tests that could hide bugs. Return only actionable findings with file/line evidence and concrete failure modes. If no blocking issues, say so and list residual risk."
```

If `amp review` is unavailable or fails before starting, report the exact error and stop. Do not perform a manual fallback review unless the user explicitly asks for one.

## Output

Lead with findings, not summary.

Use this shape:

```text
Ref: <branch/range/worktree scope>
Base: <mainline/merge-base or N/A>
Mode: <commit | branch+uncommitted | uncommitted>

Findings:
- <severity> <file:line> — <bug/failure mode>. <why it happens>. <smallest fix>.

No blocking issues found. Checked: <strongest proof>. Residual risk: <test gaps/large unreviewed surface>.
```

Severity levels: `blocker` (must fix before merge), `major` (real bug, fix soon), `minor` (worth fixing), `nit` (style/clarity). Use `blocker` only for changes that could break behavior, lose data, or introduce security holes — reserve it so it stays meaningful.

Rules:

- No edits during review unless the user explicitly asks for fixes.
- Do not approve, merge, push, or comment on hosted PRs unless asked.
- Do not invent line numbers; read files or diffs for evidence.
- If unsure, say what evidence is missing instead of weakening into vague suggestions.