Stats
Actions
Tags
From superpowers-plus
Mandatory progressive code review gate that runs before every commit or push, dispatching a multi-phase battery of specialist reviewers on the diff. Skip only when user explicitly declines.
How this skill is triggered — by the user, by Claude, or both
Slash command
/superpowers-plus:progressive-code-review-gateThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
- Before every commit or push of code changes (mandatory, fires automatically)
providing-code-review), language/profanity audit (professional-language-audit)MANDATORY before every commit/push of code changes. Skip only when the human explicitly says to skip review.
Wrong skill? PR-level review of others' work →
providing-code-review. File-protocol review →code-review.
Determine what is being committed or pushed:
# For uncommitted changes (pre-commit):
git diff --staged # staged changes
git diff # unstaged changes
# For unpushed commits (pre-push):
git log --oneline @{u}..HEAD # list unpushed commits
git diff @{u}..HEAD # diff of unpushed commits
If no diff exists in any of these, skip this gate.
First, run the code-review-battery Phase 0 sentinel check:
SENTINEL="$(git rev-parse --show-toplevel 2>/dev/null || echo .)/.code-review-cleared"
cat "$SENTINEL" 2>/dev/null || echo "NO CLEARANCE"
echo "HEAD: $(git rev-parse HEAD 2>/dev/null)"
git diff --quiet && git diff --cached --quiet && echo "WORKTREE_CLEAN" || echo "WORKTREE_DIRTY"
If the sentinel is valid for HEAD AND WORKTREE_CLEAN: battery already ran on this code. Map the existing verdict to gate verdicts (see table below) and skip dispatch.
Otherwise: dispatch battery. Follow the code-review-battery skill procedure (Phase 1–5):
--all or manual request)Map battery output to gate verdicts:
| Battery Severity | Gate Classification | Gate Verdict |
|---|---|---|
| Critical | MUST-FIX | FAIL |
| Important | SHOULD-FIX | FAIL (if ≥2) or PASS_WITH_NITS (if 1) |
| Minor | NIT | PASS_WITH_NITS |
| All clean (✅) | — | PASS |
On FAIL re-review rounds (Round 2+): skip triage, re-dispatch the SAME reviewers from Round 1. On PASS_WITH_NITS re-review: use targeted Step 3a below (scoped files + scoped reviewers).
Fallback (only if parallel sub-agent dispatch is impossible — e.g., platform does not support firing multiple sub-agents simultaneously):
Invoke a single reviewer with the monolithic prompt below. Use whatever
sub-agent mechanism is available (e.g., sub-agent-code-reviewer on Augment,
Task() on Claude Code). Give it a unique name per round (e.g., review-round-1).
The monolithic reviewer MUST receive:
Review the code changes in {repo_path}.
Run `cd {repo_path} && {exact_diff_command}` to see the diff.
Read the full source files for all changed code.
Be harsh and adversarial. Check for:
1. Logic errors, off-by-one, edge cases
2. Missing error handling or silent failures
3. Inconsistency with surrounding code patterns
4. Security issues (injection, secrets, unsafe operations)
5. Stale references (functions/variables that no longer exist)
6. Missing downstream changes (callers, tests, types, docs)
7. Style violations relative to the project's conventions
Classify each issue:
- MUST-FIX: Blocks commit (logic error, security, correctness)
- SHOULD-FIX: Strong recommendation (inconsistency, missing guard)
- NIT: Minor (won't block)
Verdict: PASS, PASS_WITH_NITS, or FAIL
If FAIL: list every MUST-FIX and SHOULD-FIX clearly.
| Verdict | Action |
|---|---|
| PASS | Proceed to commit/push |
| PASS_WITH_NITS | Fix the nits, then go to Step 3a (targeted re-review) |
| FAIL | Fix MUST-FIX and SHOULD-FIX items, then go to Step 2 (full re-review) |
After fixing nits, run a targeted battery round:
-- <fixed-files> appended (see skills/engineering/code-review-battery/skill.md Phase 4 for scoping rules). Each reviewer instruction must include: reviewer prompt + diff + source context (per Phase 2 dispatch requirements).Why targeted, not full: Nit fixes are low-risk by definition. Re-reviewing the entire diff wastes time. But nit fixes can introduce new issues, so the affected reviewer must verify.
pre-commit-gate, order 1)enforce-style-guide, order 2 — runs before this gate so style-induced code changes are covered by this review)providing-code-review)professional-language-audit, order 4)| Wrong | Right |
|---|---|
| Committing without review because "it's a small change" | Every code change gets reviewed |
| Skipping re-review after fixes | Fixes can introduce new issues. Always re-review |
| Running review only when human asks | Review is automatic. Human asks to SKIP, not to START |
| Failure | Symptom | Recovery |
|---|---|---|
| Review loop (5+ rounds) | Each fix introduces new findings | Stop at Round 5. Tell the human. The change may need a different approach |
| Stale diff after fixes | Reviewer sees old diff because changes weren't staged | Re-run git diff or git diff --staged each round — never reuse prior output |
| Fix-induced regression | Round N fix breaks something Round N-1 passed | Reviewer must re-check ALL prior-passing areas, not just the new changes |
| Reviewer scope creep | Flagging pre-existing code not in the diff | Restrict to changed lines and their direct callers. Pre-existing issues are INFO at most |
| Skipping for "small changes" | One-line fix committed without review | Size doesn't determine risk. See Anti-Patterns table above |
Preferred:
use-skill unified-commit-gateloads all 5 gates in one load. Use this skill directly only for deep-dive when the code review gate fails.
pre-commit-gate (1) → enforce-style-guide (2) → progressive-code-review-gate (3) → professional-language-audit (4) → public-repo-ip-audit (5)
npx claudepluginhub bordenet/superpowers-plus --plugin superpowers-plusGuides creation, editing, and verification of skills for AI coding agents using test-driven development with subagent scenarios. Use when authoring or debugging skills.