메뉴
Use when receiving code review feedback, before implementing any suggestion — requires technical verification and reasoned evaluation, not performative agreement or blind implementation
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
Store and retrieve patterns from past work using semantic search; adds self-learning capability to Superpowers
Use when facing 2+ independent tasks that can be worked on without shared state or sequential dependencies
Select optimal subagent topology (hierarchical, mesh, ring, star) based on task structure; adds Ruflo-style swarm intelligence to Superpowers
Structured first-pass exploration of an unfamiliar codebase — what to read, in what order, what to map, what traps to find. Use when entering any new or inherited project before writing code.
Select optimal AI model by task complexity — route to cheap/fast models for simple tasks, capable models for complex reasoning
Use when starting any conversation - establishes how to find and use skills, requiring Skill tool invocation before ANY response including clarifying questions
| 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 |
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 first