arbiter

name	arbiter
description	Use when receiving code review feedback, before implementing any suggestion — requires technical verification and reasoned evaluation, not performative agreement or blind implementation
type	process

Code Review Reception

Overview

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."

---

The Response Pattern

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

---

Forbidden Responses

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 verification

Instead:

• Restate the technical requirement in your own words
• Ask a specific clarifying question
• Push back with technical reasoning when the suggestion is wrong
• Just start working — actions are louder than acknowledgments

---

Handling Unclear Feedback

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."

---

Source-Specific Handling

From the user (your human partner)

• Trusted — implement after understanding
• Still ask if scope is unclear
• No performative agreement
• Skip straight to action or a technical acknowledgment

From External Reviewers

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

---

YAGNI Check

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."

---

Implementation Order

For multi-item feedback, always in this sequence:

1. Clarify anything unclear first
2. Blocking issues (breaks functionality, security)
3. Simple fixes (typos, imports, formatting)
4. Complex fixes (refactoring, logic changes)
5. Test each fix individually
6. Verify no regressions

---

When to Push Back

Push back when a suggestion:

• Would break existing functionality
• Lacks full codebase context
• Violates YAGNI (adds unused features)
• Is technically incorrect for this stack
• Conflicts with the user's architectural decisions
• Ignores legitimate legacy or compatibility reasons

How to push back:

• Technical reasoning, not defensiveness
• Ask specific verifying questions
• Reference working tests or code
• Involve the user if architectural

Signal word if uncomfortable pushing back directly: "Strange things are afoot at the Circle K"

---

Acknowledging Correct Feedback

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.

---

Common Mistakes

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

---

Real Examples

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?"

---

Red Flags

Never:

• Implement suggestions before verifying them
• Express performative agreement or gratitude
• Implement one reviewer's suggestion that conflicts with the user's architecture without discussing it
• Skip the clarification step when items are ambiguous

Always:

• Verify before implementing
• Push back with technical reasoning when the suggestion is wrong
• Clarify ALL unclear items before implementing ANY
• Test each fix individually

---

Integration

Mirror of:

• tribunal — dispatches the reviewer; ARBITER handles the reception

Pairs with:

• sentinel — re-run verification after implementing review feedback before claiming done
• forge — if a review reveals missing tests, FORGE writes them first