Stats
Actions
Tags
Evaluates code review feedback by verifying suggestions against the codebase, clarifying ambiguities, pushing back technically when wrong, before any implementation. Use when receiving reviews.
How this skill is triggered — by the user, by Claude, or both
Slash command
/claude-code-superpowers:arbiterThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
**ARBITER** — *An arbiter is an independent judge who evaluates claims on their technical merits, not on who made them.*
ARBITER — An arbiter is an independent judge who evaluates claims on their technical merits, not on who made them. When invoked: evaluates every piece of review feedback against the actual codebase before implementing — verifies correctness, pushes back with technical reasoning when wrong, and never performs agreement it hasn't earned.
Core principle: Verify before implementing. Ask before assuming. Technical correctness over social comfort.
Announce at start: "Running ARBITER to evaluate this review feedback."
WHEN receiving code review feedback:
1. READ — complete feedback without reacting
2. CLARIFY — if anything is unclear, stop and ask before implementing anything
3. VERIFY — check each suggestion against codebase reality
4. EVALUATE — technically sound for THIS codebase and context?
5. RESPOND — technical acknowledgment or reasoned pushback
6. IMPLEMENT — one item at a time, test each
Never say:
"You're absolutely right!" — explicit violation"Great point!" / "Excellent feedback!" — performative"Thanks for catching that!" / any gratitude expression — actions speak instead"Let me implement that now" — before verificationInstead:
IF any item is unclear:
STOP — do not implement anything yet
ASK for clarification on ALL unclear items
WHY: Items may be related. Partial understanding = wrong implementation.
Example:
Reviewer: "Fix 1–6"
You understand 1, 2, 3, 6. Unclear on 4, 5.
❌ WRONG: Implement 1,2,3,6 now, ask about 4,5 later
✅ RIGHT: "I understand items 1,2,3,6. Need clarification on 4 and 5 before proceeding."
Before implementing any suggestion from an external reviewer:
CHECK:
1. Technically correct for THIS codebase?
2. Would it break existing functionality?
3. Is there a reason the current impl exists?
4. Does it work on all target platforms/versions?
5. Does the reviewer have full context?
IF suggestion seems wrong → push back with technical reasoning
IF you can't easily verify → "I can't verify this without [X]. Should I [investigate/ask/proceed]?"
IF it conflicts with the user's prior decisions → stop and discuss with the user first
IF reviewer suggests "implementing properly" or adding a feature:
grep codebase for actual usage
IF unused: "This isn't called anywhere. Remove it (YAGNI)?"
IF used: Then implement properly
The user's rule: "You and the reviewer both report to me. If we don't need this feature, don't add it."
For multi-item feedback, always in this sequence:
Push back when a suggestion:
How to push back:
Signal word if uncomfortable pushing back directly: "Strange things are afoot at the Circle K"
When feedback IS correct:
✅ "Fixed. [Brief description of what changed]"
✅ "Good catch — [specific issue]. Fixed in [location]."
✅ [Just fix it and show in the diff]
❌ "You're absolutely right!"
❌ "Great point!"
❌ "Thanks for [anything]"
No thanks. No praise. Just the fix. The code itself shows you heard the feedback.
If you were wrong after pushing back:
✅ "You were right — checked [X] and it does [Y]. Fixing now."
✅ "Verified and you're correct. My initial understanding was wrong because [reason]. Fixing."
❌ Long apology
❌ Defending why you pushed back
❌ Over-explaining
State the correction factually and move on.
| Mistake | Fix |
|---|---|
| Performative agreement | State the technical requirement or just act |
| Blind implementation | Verify against codebase first |
| Batch without testing | One item at a time, test each |
| Assuming reviewer is right | Check whether it breaks things |
| Avoiding pushback | Technical correctness > social comfort |
| Partial implementation when unclear | Clarify all items first |
| Can't verify, proceed anyway | State the limitation, ask for direction |
Performative agreement (wrong):
Reviewer: "Remove legacy code"
❌ "You're absolutely right! Let me remove that..."
Technical verification (right):
Reviewer: "Remove legacy code"
✅ "Checking... build target is 10.15+, this API needs 13+.
Need legacy for backward compat. Current impl has wrong bundle ID —
fix it, or drop pre-13 support?"
YAGNI (right):
Reviewer: "Implement proper metrics tracking with database, date filters, CSV export"
✅ "Grepped codebase — nothing calls this endpoint. Remove it (YAGNI)?
Or is there usage I'm missing?"
Never:
Always:
Mirror of:
tribunal — dispatches the reviewer; ARBITER handles the receptionPairs with:
sentinel — re-run verification after implementing review feedback before claiming doneforge — if a review reveals missing tests, FORGE writes them firstnpx claudepluginhub gadaalabs/claude-code-on-steroidsGuides technical processing of code review feedback: read, understand, verify, evaluate, and respond before implementing, especially unclear or questionable suggestions.
Enforces verification-first code review: evaluate suggestions rigorously before implementing, push back when feedback is incorrect or lacks context.
Evaluates code review feedback before implementing. Verifies technical correctness, asks for clarification on unclear items, and pushes back with reasoned arguments when suggestions are wrong.