메뉴
Use when receiving PR review feedback or code review comments. Enforces verification-first response to review feedback with anti-sycophancy classification and constructive disagreement protocol.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
Use when orchestrating parallel Claude Code instances across tmux panes with git worktree isolation — managing multiple concurrent development tasks visually
Use when production incident occurs, alerts fire, service degradation detected, or on-call escalation needed - guides systematic organizational response before technical fixes
Use when conducting manual PR reviews - provides structured checklist covering security, performance, maintainability, and code quality dimensions with anti-sycophancy principles
Run local CI checks and ship changes — create branch, commit, push, and PR. Optionally link to a GitHub issue. Use when changes are ready to ship.
Use when encountering any bug, test failure, or unexpected behavior, before proposing fixes
Architecture guide using Next.js App Router's Parallel Routes for Widget-Slot pattern. Separates static layouts from dynamic widgets to achieve separation of concerns, fault isolation, and plug-and-play development.
| name | receiving-code-review |
| description | Use when receiving PR review feedback or code review comments. Enforces verification-first response to review feedback with anti-sycophancy classification and constructive disagreement protocol. |
| allowed-tools | Read, Grep, Glob, Bash(gh:*, git:*) |
| argument-hint | ["pr-url-or-number"] |
Blind agreement with review feedback is as harmful as ignoring it. Implementing unverified suggestions introduces bugs, degrades architecture, and teaches reviewers that superficial comments get results.
Core principle: Treat every review comment as a hypothesis to be tested, not an instruction to be followed. Evidence determines your response, not authority or politeness.
Violating the letter of this process is violating the spirit of receiving code review.
VERIFY BEFORE IMPLEMENTING — AGREEMENT WITHOUT EVIDENCE IS SYCOPHANCY
Always use for:
Lighter process acceptable for:
Do NOT use for:
brainstorming or writing-plans skills)pr-review skill instead)| Classification | Criteria | Verification Required | Action |
|---|---|---|---|
| Must-Fix | Bug, crash, security vulnerability, data loss | YES — reproduce the issue | Fix immediately after verification |
| Evaluate | Alternative approach, refactoring, performance | YES — compare approaches | Implement if better, discuss if not |
| Preference | Style, naming, formatting, subjective taste | NO — check project conventions | Accept if convention-aligned, discuss if not |
| Verification Result | Classification | Action |
|---|---|---|
| Issue reproduced | Must-Fix | Fix and cite the reproduction |
| Issue NOT reproduced | Must-Fix | Reply with evidence, ask for scenario |
| Alternative is better | Evaluate | Adopt with acknowledgment |
| Alternative is equivalent or worse | Evaluate | Decline with evidence and tradeoff analysis |
| Matches project convention | Preference | Accept silently |
| Contradicts project convention | Preference | Cite convention, keep current approach |
Goal: Categorize every review comment before acting on any of them.
Process:
Classification decision tree:
Is the reviewer claiming a bug, crash, security issue, or data loss?
├── YES → Must-Fix
└── NO → Is the reviewer suggesting an alternative approach or refactoring?
├── YES → Evaluate
└── NO → Preference
Watch for misclassification:
| Looks Like | Actually Is | How to Tell |
|---|---|---|
| Must-Fix ("this will crash") | Evaluate (edge case that can't happen in context) | Check call sites and input constraints |
| Preference ("rename this") | Must-Fix (name collision causes shadowing bug) | Check scope for conflicts |
| Evaluate ("use pattern X") | Preference (both patterns are equivalent here) | Compare actual tradeoffs in this context |
Done when: Every comment has a classification tag. If unsure, classify UP (Preference → Evaluate, Evaluate → Must-Fix).
Goal: Build evidence for each Must-Fix and Evaluate item before acting.
| Feedback Type | Verification Method | Evidence |
|---|---|---|
| "This will crash/fail on X" | Write a test with input X, run it | Test result (pass/fail) |
| "N+1 query / performance issue" | Add logging, hit the endpoint, measure | Query count, timing data |
| "This violates SRP / SOLID" | Evaluate against project conventions and codebase patterns | Convention references, pattern grep results |
| "Use pattern X instead" | Compare both approaches against existing codebase patterns | grep for pattern usage, tradeoff list |
| "Missing error handling" | Trace call path, check if error can actually reach this code | Call chain analysis |
| "Race condition possible" | Analyze concurrent access paths | Sequence diagram or test |
| "Style: rename this variable" | Skip verification — this is Preference | Check project conventions only |
For each Must-Fix / Evaluate item:
.ai-rules/ or project style guideDone when: Every Must-Fix and Evaluate item has a verification result: reproduced, not reproduced, or tradeoff analyzed.
Guard against over-verification: Preference items do NOT need verification. If you catch yourself writing a test for a variable rename, stop — you are stalling.
Goal: Act on each item based on classification AND verification evidence.
Must-Fix — Verified:
Confirmed. Reproduced with [test/scenario]. Fixed in [commit]. Added regression test.
Must-Fix — Cannot Reproduce:
Attempted to reproduce with [specific steps]. Test passes with [input]. Could you share the exact scenario you're seeing? Here's what I tested: [evidence].
Evaluate — Adopted:
Good point. Adopted [approach] because [evidence it's better in this context]. [Brief tradeoff acknowledged].
Evaluate — Declined:
Considered this. Staying with current approach because [concrete evidence]. The tradeoff: [their approach advantage] vs [current approach advantage]. In this context, [reason current wins].
Evaluate — Partial Agreement:
You're right about [the problem]. However, [proposed solution] would [issue]. Instead, I [alternative fix] which addresses the concern while [preserving X].
Preference — Accepted:
Updated.
Preference — Convention Conflict:
Project convention uses [X pattern] per [rule reference]. Keeping for consistency. Happy to discuss changing the convention project-wide if you'd like.
| Reviewer | Tone | Example |
|---|---|---|
| Peer | Direct and evidence-based | "Tested this — passes with null input. What scenario triggers the crash?" |
| Senior / Tech Lead | Respectful but still evidence-based | "Great catch on [valid point]. For [other point], I verified with [test] and it passes — could you clarify the scenario?" |
| External Contributor | Welcoming but factual | "Thanks for the review! I checked [claim] and found [evidence]. Here's my reasoning: [explanation]." |
Key principle: Deference is not compliance. You can respect someone's expertise while still requiring evidence for their claims.
Done when: Every comment has a response: implemented (with commit reference), declined (with evidence), or discussed (with question).
Goal: Close the feedback loop cleanly.
Checklist:
Summary comment template:
Changes made:
- [Must-Fix] Fixed [issue] — added regression test (commit abc123)
- [Evaluate] Adopted [suggestion] for [reason] (commit def456)
- [Preference] Updated [items] (commit ghi789)
Discussed (no change):
- [item]: [brief reason with evidence link]
Ready for re-review.
When you believe the reviewer is wrong, follow this escalation:
Bad: "I disagree with this suggestion."
Good: "I tested with [input] and it passes. The null case can't reach
this code path because [caller] validates at line 42. Here's the test: [link]."
Bad: "My approach is better."
Good: "Your approach has [advantage]. Mine has [advantage]. In this context,
[mine/yours] fits better because [specific reason]."
Bad: "No, I won't change this."
Good: "Instead of [their suggestion], what about [alternative] which
addresses your concern about [X] while preserving [Y]?"
If you cannot reach agreement after evidence exchange:
| Don't Say | Why It's Harmful |
|---|---|
| "Great catch! Fixing now." (without verifying) | You don't know if it's actually a catch |
| "You're absolutely right, I should have caught that." | You're performing contrition, not engineering |
| "Sounds good, will update." (without reading code) | Agreeing to changes you haven't evaluated |
| "Thanks for the thorough review!" (as the only response) | Politeness is not a substitute for engagement |
| "I'll fix all of these." (batch-agreeing) | Each comment needs individual evaluation |
| Anti-Pattern | What Happens | Instead |
|---|---|---|
| Apologetic capitulation | "You're right, sorry" → implement unverified change | Verify first, then respond with evidence |
| Scope creep acceptance | "While you're at it, also refactor X" → silent addition | Acknowledge, create separate issue/PR |
| Authority-driven compliance | Senior said it → must be right → implement blindly | Seniors deserve evidence-based responses too |
| Fix-then-justify | Implement first, rationalize after | Evaluate BEFORE implementing |
| Cherry-picking easy wins | Fix trivial items, ignore hard critical feedback | Process Must-Fix items FIRST |
| Silent disagreement | Disagree privately, implement anyway | State your concern on the review thread |
| Over-verification stalling | "I need to verify" as excuse to avoid valid feedback | Preference items don't need verification |
| Conflating preference with defect | Treating style feedback as a bug fix | Classify correctly, respond accordingly |
| Performative agreement | Agreeing enthusiastically to avoid conflict | Evidence determines response, not comfort |
These thoughts mean you are about to violate the Iron Law:
| Thought | Reality |
|---|---|
| "I'll just fix it, it's faster" | Faster than what? You haven't verified it's broken. |
| "The reviewer is senior, they must be right" | Seniority is not evidence. Verify. |
| "It's just a small change, no need to verify" | Small unverified changes compound into big problems. |
| "I don't want to seem argumentative" | Evidence-based responses are not arguments. |
| "They clearly know more about this" | They might. Verify and find out. |
| "I'll verify later after implementing" | That's fix-then-justify. Evaluate BEFORE implementing. |
| "All their other comments were valid, so this one must be too" | Each comment stands on its own evidence. |
| "Pushing back will delay the PR" | Implementing wrong changes delays it more. |
| Rationalization | Counter |
|---|---|
| "Verifying takes too long" | Implementing a wrong fix takes longer. Reverting takes even longer. |
| "I trust this reviewer" | Trust is not a verification method. Even trusted reviewers make mistakes. |
| "It's not worth the discussion" | If it's not worth discussing, it's not worth implementing either. |
| "The reviewer will be annoyed if I push back" | Professional reviewers respect evidence-based responses. |
| "I already know they're right" | Then verification will be quick. Do it anyway. |
| "This is just bikeshedding" | If so, classify as Preference and handle accordingly. |
When multiple reviewers give contradictory feedback:
When feedback lacks specifics ("this feels wrong", "not clean enough"):
When the reviewer suggests changing code required by the framework:
Apply higher scrutiny to suggestions that weaken tests:
pr-review — For conducting reviews (the giving side of this skill)systematic-debugging — For investigating issues found during verificationtest-driven-development — For writing verification tests in Phase 2writing-plans — For re-planning when architectural review feedback requires redesign