메뉴
Use when receiving code review feedback -- before implementing suggestions, especially when feedback seems unclear
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
Use when reviewing a spec or task graph for completeness before implementation
Use when the user needs to interact with websites, including navigating pages, filling forms, clicking buttons, taking screenshots, extracting data, testing web apps, logging in, or automating browser actions
Use when the user needs to interact with websites, including navigating pages, filling forms, clicking buttons, taking screenshots, extracting data, testing web apps, logging in, or automating browser actions
Use when decomposing a spec, design, or feature description into a task dependency graph with self-evaluating acceptance criteria
Use when doing creative product, feature, component, functionality, or behavior design work
Use when infrastructure or features are built but before declaring done -- verifies work is wired into the system and actively used
| name | receiving-code-review |
| description | Use when receiving code review feedback -- before implementing suggestions, especially when feedback seems unclear |
Code review requires technical evaluation, not emotional performance.
Core principle: Verify before implementing. Ask before assuming. Technical correctness over social comfort.
WHEN receiving code review feedback:
1. READ: Complete feedback without reacting
2. UNDERSTAND: Restate requirement in own words (or ask)
3. VERIFY: Check against codebase reality
4. EVALUATE: Technically sound for THIS codebase?
5. RESPOND: Technical acknowledgment or reasoned pushback
6. IMPLEMENT: One item at a time, test each
NEVER:
INSTEAD:
If ANY item is unclear: STOP. Do not implement anything yet. Ask for clarification on unclear items.
Items may be related. Partial understanding = wrong implementation.
If reviewer suggests "implementing properly":
For multi-item feedback:
Push back when:
How: Use technical reasoning, not defensiveness. Reference working tests/code.
✅ "Fixed. [Brief description of what changed]"
✅ "Good catch - [specific issue]. Fixed in [location]."
✅ [Just fix it and show in the code]
❌ "You're absolutely right!"
❌ "Thanks for catching that!"
❌ ANY gratitude expression
Actions speak. Just fix it.
| Mistake | Fix |
|---|---|
| Performative agreement | State requirement or just act |
| Blind implementation | Verify against codebase first |
| Batch without testing | One at a time, test each |
| Assuming reviewer is right | Check if breaks things |
| Avoiding pushback | Technical correctness > comfort |