From superpowers-plus
Dispatches code-review-battery before presenting code changes to humans for review. Checks git sentinel and worktree for prior clearance to skip redundant runs.
npx claudepluginhub bordenet/superpowers-plus --plugin superpowers-plusThis skill uses the workspace's default tool permissions.
> **Wrong skill?** Pre-commit/push → `unified-commit-gate`. Reviewing someone else's PR → `providing-code-review`. Implementing feedback you received → `receiving-code-review`. Inter-agent file handoff → `inter-agent-review-protocol`.
Mandates invoking relevant skills via tools before any response in coding sessions. Covers access, priorities, and adaptations for Claude Code, Copilot CLI, Gemini CLI.
Share bugs, ideas, or general feedback.
Wrong skill? Pre-commit/push →
unified-commit-gate. Reviewing someone else's PR →providing-code-review. Implementing feedback you received →receiving-code-review. Inter-agent file handoff →inter-agent-review-protocol.
Dispatch code-review-battery to catch issues before they cascade. The battery dispatches 5 specialist reviewers in parallel — each focused on a distinct set of review dimensions — producing deeper analysis than any single-pass review.
Core principle: Review early, review often.
Apply this protocol whenever you are about to show a human your work — PR links, summaries, "here's what I built," "please review my changes." Run this check before writing that message.
Step 1 — Read the sentinel, HEAD SHA, and worktree state:
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 || echo 'unknown')"
git diff --quiet && git diff --cached --quiet && echo "WORKTREE_CLEAN" || echo "WORKTREE_DIRTY"
Step 2 — Decide:
| Result | Action |
|---|---|
NO CLEARANCE | STOP. Run code-review-battery first. Do not write the review request. |
| Sentinel SHA ≠ HEAD SHA | STOP. Changes were made after last review. Re-run code-review-battery. |
Sentinel valid for HEAD but WORKTREE_DIRTY | STOP. Staged/unstaged changes exist that battery didn't review. Commit or stash, then re-run battery. |
v1|SHA|PASS|... or PASS_WITH_NITS, SHA matches HEAD, AND WORKTREE_CLEAN | Proceed — include the clearance line in your message (see Step 3) |
| Anything else | STOP. Sentinel is malformed. Delete .code-review-cleared, re-run battery. |
Step 3 — Include the clearance in your human-facing message:
Every message that presents work to the human for review MUST open with the clearance line:
🔍 Review cleared: PASS | SHA: abc12345 | 2026-04-02T21:29Z
This is not optional decoration. It lets the human verify at a glance that battery ran on exactly the code being reviewed. If you cannot produce this line, you have not run battery on HEAD. Run it now.
The INTENT TO PRESENT is the trigger — not the words you use.
The moment you are forming a response to the human that describes code you wrote — that is the trigger. Before the words exist. Not after you say "done". Before you start writing the sentence.
This applies unconditionally. No threshold for simplicity. No exception for small fixes. No exception for "the user will just look at the diff themselves." Every response. Every time.
| Internal state (INTENT) | Required gate |
|---|---|
| Forming a response that describes code changes | Battery must have PASSED |
| About to commit or push | Battery must have PASSED; sentinel must exist |
| About to share an MR/PR link | Sentinel must exist for HEAD |
| About to write a completion summary | Battery must have PASSED |
| ANY moment of transitioning from "working" to "reporting" | This IS the trigger. There is no hesitation threshold. |
If battery already ran and sentinel exists for HEAD: Evidence confirmed. Do not re-dispatch. Note the clearance and proceed.
If battery has not run: Run it now, before writing a single word of the response.
The autonomous review is not the human's job to request. You must do it yourself, every time, before the response is formed.
Why this rule exists: See the 2026-04-02b incident in verification-before-completion Incident History. The gate failed because the implementation→reporting transition was not recognized as a trigger despite an explicit incident log entry from earlier the same session. The fix: trigger on INTENT, not on output language.
Always (hard gates):
Also valuable:
BASE_SHA=$(git merge-base HEAD main) # or origin/dev, origin/main
HEAD_SHA=$(git rev-parse HEAD)
git diff $BASE_SHA..$HEAD_SHA # the diff to review
Follow the code-review-battery procedure:
sub-agent-code-reviewer| Severity | Action |
|---|---|
| Critical | Fix immediately. Re-dispatch battery. |
| Important | Fix before proceeding. Re-dispatch if >1 fixed. |
| Minor | Fix now or document for follow-up. |
| Reviewer wrong | Push back with technical reasoning and evidence. |
Only proceed to presenting work as "ready" when battery verdict is PASS or PASS_WITH_NITS (with nits fixed).
| Workflow | When to Review |
|---|---|
| Subagent-driven development | After EACH task — catch issues before they compound |
| Feature development | After implementation, before presenting options |
| Ad-hoc development | Before merge or when stuck |
| Finishing a branch | Step 0 of finishing-a-development-branch dispatches code-review-battery directly |
| Wrong | Right |
|---|---|
| Skipping review because "it's simple" | Complexity doesn't determine risk |
| Ignoring Critical findings | Critical = broken if shipped |
| Proceeding with unfixed Important findings | Fix first, then re-dispatch |
| Arguing with valid technical feedback | Push back only with evidence |
| Presenting work as "ready" then reviewing | Review first, present second |