Critically review your recent changes and fix any issues you find. Choose one of the two paths below, based on the size of the change. When in doubt, delegate - the cost is low and the unbiased read is the point.
Option A: Review it yourself (small or simple changes)
For a single file, or one focused fix or feature: Re-read what you changed with a sceptical eye - correctness, completeness, regressions, over-engineering, unwarranted verbosity.
Then fix what you find directly.
Option B: Delegate to the reviewer (larger changes)
For changes spanning multiple files, features, or fixes: Delegate to the critical-reviewer subagent(s) for a fresh, unbiased read, then act on what they report.
- A fresh reviewer catches what you've talked yourself into, and keeps the review reasoning out of your context.
- The reviewer is read-only and returns prioritised findings (each with a severity and a
file:line location); you triage by severity and apply the fixes.
When you delegate:
- If the change is large or complex. Consider calling the sub-agent with the fable model (if it's available) as it's the most powerful AI model.
- Provide a high signal brief. The agent operates outside of this conversation's context. Give it: the list of changed files (names only, e.g.
git diff --name-only), the task you were originally asked to do and what was in / out of scope, and anything intentional that looks wrong but isn't.
- Parallelise only on independent slices. Spawn one reviewer per group of changes that don't interact (by subsystem, layer, or requirement), and give each an explicit boundary - the files or area it owns - so they don't overlap. When slices share an interface or contract, brief at least one reviewer on both sides, or use a single reviewer - a fresh reviewer that sees only one side can't catch the interaction. Don't split for its own sake.
- Stay fresh by default. A fresh reviewer gives the unbiased read that makes self-review worth doing. Fork only if the review genuinely needs this conversation's nuance; never fork it for the adversarial read, since a fork inherits this agent's bias and defeats the point.
- Write the brief in terse notes. Keywords and bullets, not full prose; the reviewer is a capable model, not an audience.
After each reviewer agent has finished and returned it's findings (unless there is a good reason to wait for all findings, or instructed otherwise):
- Action the (valid) findings.
- Fix what's real. Apply the fixes for genuine findings, then verify (build, tests, lint). Push back on findings that are wrong rather than changing correct code to satisfy them.
- If you make large amounts of changes, loop back and run another review cycle (maximum loops: 3).
$ARGUMENTS
1---2name: self-review3description: Use to critically self-review your changes, or when you want to delegate the review to a sub-agent.4---5
6Critically review your recent changes and fix any issues you find. Choose one of the two paths below, based on the size of the change. When in doubt, delegate - the cost is low and the unbiased read is the point.
7
8## Option A: Review it yourself (small or simple changes)
9
10For a single file, or one focused fix or feature: Re-read what you changed with a sceptical eye - correctness, completeness, regressions, over-engineering, unwarranted verbosity.
11
12Then fix what you find directly.
13
14## Option B: Delegate to the reviewer (larger changes)
15
16For changes spanning multiple files, features, or fixes: Delegate to the `critical-reviewer` subagent(s) for a fresh, unbiased read, then act on what they report.
17
18- A fresh reviewer catches what you've talked yourself into, and keeps the review reasoning out of your context.
19- The reviewer is read-only and returns prioritised findings (each with a severity and a `file:line` location); you triage by severity and apply the fixes.
20
21When you delegate:
22
23- **If the change is large or complex.** Consider calling the sub-agent with the fable model (if it's available) as it's the most powerful AI model.
24- **Provide a high signal brief.** The agent operates outside of this conversation's context. Give it: the list of changed files (names only, e.g. `git diff --name-only`), the task you were originally asked to do and what was in / out of scope, and anything intentional that looks wrong but isn't.
25- **Parallelise only on independent slices.** Spawn one reviewer per group of changes that don't interact (by subsystem, layer, or requirement), and give each an explicit boundary - the files or area it owns - so they don't overlap. When slices share an interface or contract, brief at least one reviewer on both sides, or use a single reviewer - a fresh reviewer that sees only one side can't catch the interaction. Don't split for its own sake.
26- **Stay fresh by default.** A fresh reviewer gives the unbiased read that makes self-review worth doing. Fork only if the review genuinely needs this conversation's nuance; never fork it for the adversarial read, since a fork inherits this agent's bias and defeats the point.
27- **Write the brief in terse notes.** Keywords and bullets, not full prose; the reviewer is a capable model, not an audience.
28
29After each reviewer agent has finished and returned it's findings (unless there is a good reason to wait for all findings, or instructed otherwise):
30
311. Action the (valid) findings.
32 - **Fix what's real.** Apply the fixes for genuine findings, then verify (build, tests, lint). Push back on findings that are wrong rather than changing correct code to satisfy them.
332. If you make large amounts of changes, loop back and run another review cycle (maximum loops: 3).
34
35---
36
37`$ARGUMENTS`
sammcj