phase-review
Adaptive multi-agent phase verification for Claude Code. Auto-scales 2 → 7 fresh subagents (S/M/L) so a one-line bug-fix doesn't burn the same tokens as a database migration.
A typical "review what you wrote" prompt asks the same agent that just wrote the code to grade itself. It won't. It's primed to defend its own assumptions. phase-review spawns fresh subagents for every reviewer role, zones them strictly (one role = one agent), and adapts the depth to the size of the change.
Why this exists
After implementing a phase of work, three things consistently went wrong with naïve self-review:
- The author-agent is psychologically uncritical. It "knows what it meant" and skips invariants.
- One reviewer doing many roles (security + quality + architecture in one prompt) goes shallow on all of them.
- Bug-fixes ran the same heavy pipeline as architecture changes → token spend wildly out of proportion to risk.
phase-review fixes all three:
- Every reviewer is a fresh subagent (no session history, no defensive bias).
- Strict role zoning — one reviewer never carries two hats.
- Adaptive S/M/L sizing — 2 agents for a typo fix, 7 for an auth refactor. Auto-detected from diff stats and a sensitive-area heuristic; user can override.
Built on top of the Superpowers methodology with multi-agent zoning + adaptive sizing on top.
How it works
Step 0 Context preparation (current session)
Step 0.5 Size detection (S / M / L) (current session)
Step 1 Declarations Gate ┐ parallel
├─ 1A reviewer — Spec compliance + assumption check │
└─ 1B system-architect — Architecture invariants (M/L) ┘
Step 2 Risk Profiles ┐ parallel
├─ 2A code-analyzer — Code quality │
├─ 2B security-auditor — Security (S only on bump; M/L: always)
└─ 2C perf-analyzer — Forward look (M/L) ┘
Step 2.5 Adversarial Skeptic (sequential)
analyst — tags every finding as REAL or PARANOIA
Step 3 Apply REAL fixes in priority order (current session)
Step 3.5 Regression Sweep (sequential, fresh eyes on the fix-diff)
Step 4 Final report with verdict
Sizing rules
| Size | When | Pipeline |
|---|
| S | <4 files AND <100 lines AND no sensitive area | 2 agents (Spec + Quality) |
| M | 4–15 files OR contains sensitive area | 4–5 agents (+ Architecture, Security, optional Skeptic) |
| L | >15 files OR ≥3 modules OR DB migration | 7 agents (full pipeline) |
Sensitive-bump
If the diff touches auth, PII, payments, e-signatures, file upload, or raw SQL, size is automatically bumped to at least M. S is not allowed for these areas. No exceptions.
Install
Option 1 — Plugin (recommended)
# In Claude Code
/plugin marketplace add tripinfinite-gif/claude-skill-phase-review
/plugin install phase-review@tripinfinite
Then use /phase-review directly.
Option 2 — Manual clone
git clone https://github.com/tripinfinite-gif/claude-skill-phase-review.git
cp -r claude-skill-phase-review/skills/phase-review ~/.claude/skills/
cp claude-skill-phase-review/commands/phase-review.md ~/.claude/commands/
Restart Claude Code. The skill is now available everywhere.
Usage
Auto-detect size and current phase
/phase-review
The orchestrator inspects git diff --name-only HEAD~1, the current session context, and any sensitive-area hits, then picks S / M / L and explains why.
Force a size
/phase-review --size L
/phase-review --size M Phase 6a — driver consent upload
/phase-review --size S
Describe the phase explicitly
/phase-review Just refactored the OCR fallback path — verify nothing regressed
Real-world examples
These are actual outcomes from production use on a Russian permit-issuance platform and a SaaS compliance scanner:
Jeffallan
nyldn
xu-xiang