---
description: Review the current diff with six specialized agents and synthesize one ranked report.
argument-hint: "[base ref, e.g. main — defaults to HEAD]"
allowed-tools: Bash(git diff:*), Bash(git status:*), Bash(git merge-base:*), Task, Read, Grep
---

You are running `/ultrareview`: a six-agent code review of the current change.

## 1. Capture the diff

The base ref is `$ARGUMENTS` (if empty, use `HEAD`). Get the change under review:

- Working-tree + staged diff vs the base:
  !`git diff ${ARGUMENTS:-HEAD}`
- For context, the list of changed files and status:
  !`git status --short`

If the diff is empty, stop and tell the user there is nothing to review.

## 2. Dispatch the six reviewers

Launch all six review subagents **in parallel** (one Task call each, in a
single batch), passing each the diff captured above and the changed-file
list. Each reviewer looks for exactly one class of problem and returns its
findings — do not let them stray outside their lane:

1. `security`    — injection, secrets, auth gaps, SSRF, path traversal, unsafe deserialization.
2. `performance` — N+1 queries, work inside loops, unbounded allocations, sync I/O on hot paths.
3. `tests`       — coverage gaps for new/changed behavior, missing edge and error cases.
4. `types`       — types that fail to enforce invariants; illegal states left representable.
5. `comments`    — comments drifted from code, stale TODOs, comments that lie.
6. `simplify`    — dead code, duplication, needless complexity, reuse opportunities.

If a reviewer needs to see more than the diff (surrounding lines, a callee's
signature), it may Read the touched files. Reviewers should judge only what
this diff changes, not the whole repo.

## 3. Synthesize ONE report

Collect all six results and write a single report. Structure it exactly like this:

```
# /ultrareview — <N> files, <base> → working tree

## Top issues (ranked)
1. [SEVERITY] <one line> — <file:line> (<which reviewer>)
2. ...
(Highest severity first. If there are none, say "No blocking issues found.")

## Security
<that reviewer's findings, or "No findings.">

## Performance
<...>

## Tests
<...>

## Types
<...>

## Comments
<...>

## Simplify
<...>
```

Rules for the synthesis:
- Keep all six section headings, in that order, even when a section is empty.
- Each finding: **severity** (BLOCKER / HIGH / MEDIUM / LOW), `file:line`, the
  offending line quoted, and a one-line suggested fix.
- De-duplicate: if two reviewers flag the same line, keep it once under the
  most relevant section and note the overlap.
- The "Top issues" list is your judgment call across all six — surface the
  things that should block a merge first. No preamble before the report.
