receiving-code-review

Name: receiving-code-review
Author: obra

byobra· 95 skills

Installs

152k

Stars

261k

Forks

23k

How to install receiving-code-review?

obra/superpowers/receiving-code-review

$npx -y skills add obra/superpowers --skill receiving-code-review

Installs into the current project.

›Prefer a prompt? Paste this to your agent

Use this skill

Run `npx skills use "https://github.com/obra/superpowers" --skill "obra/superpowers/receiving-code-review"` and follow the generated skill instructions now. Read its complete output, redirecting it to a temporary file first if necessary. Resolve relative paths from the supporting-files directory it provides.

Use the whole pack

Use the skills in "https://github.com/obra/superpowers" that are relevant to the current task. Run `npx skills add "https://github.com/obra/superpowers"` and select the relevant skills, then follow their instructions.

Files · 1

View on GitHub

SKILL.md

1	# Code Review Reception
2
3	## Overview
4
5	Code review requires technical evaluation, not emotional performance.
6
7	Core principle: Verify before implementing. Ask before assuming. Technical correctness over social comfort.
8
9	## The Response Pattern
10
11	```
12	WHEN receiving code review feedback:
13
14	1. READ: Complete feedback without reacting
15	2. UNDERSTAND: Restate requirement in own words (or ask)
16	3. VERIFY: Check against codebase reality
17	4. EVALUATE: Technically sound for THIS codebase?
18	5. RESPOND: Technical acknowledgment or reasoned pushback
19	6. IMPLEMENT: One item at a time, test each
20	```
21
22	## Forbidden Responses
23
24	NEVER:
25	- "You're absolutely right!" (explicit instruction-file violation)
26	- "Great point!" / "Excellent feedback!" (performative)
27	- "Let me implement that now" (before verification)
28
29	INSTEAD:
30	- Restate the technical requirement
31	- Ask clarifying questions
32	- Push back with technical reasoning if wrong
33	- Just start working (actions > words)
34
35	## Handling Unclear Feedback
36
37	```
38	IF any item is unclear:
39	STOP - do not implement anything yet
40	ASK for clarification on unclear items
41
42	WHY: Items may be related. Partial understanding = wrong implementation.
43	```
44
45	Example:
46	```
47	your human partner: "Fix 1-6"
48	You understand 1,2,3,6. Unclear on 4,5.
49
50	❌ WRONG: Implement 1,2,3,6 now, ask about 4,5 later
51	✅ RIGHT: "I understand items 1,2,3,6. Need clarification on 4 and 5 before proceeding."
52	```
53
54	## Source-Specific Handling
55
56	### From your human partner
57	- Trusted - implement after understanding
58	- Still ask if scope unclear
59	- No performative agreement
60	- Skip to action or technical acknowledgment
61
62	### From External Reviewers
63	```
64	BEFORE implementing:
65	1. Check: Technically correct for THIS codebase?
66	2. Check: Breaks existing functionality?
67	3. Check: Reason for current implementation?
68	4. Check: Works on all platforms/versions?
69	5. Check: Does reviewer understand full context?
70
71	IF suggestion seems wrong:
72	Push back with technical reasoning
73
74	IF can't easily verify:
75	Say so: "I can't verify this without [X]. Should I [investigate/ask/proceed]?"
76
77	IF conflicts with your human partner's prior decisions:
78	Stop and discuss with your human partner first
79	```
80
81	your human partner's rule: "External feedback - be skeptical, but check carefully"
82
83	## YAGNI Check for "Professional" Features
84
85	```
86	IF reviewer suggests "implementing properly":
87	grep codebase for actual usage
88
89	IF unused: "This endpoint isn't called. Remove it (YAGNI)?"
90	IF used: Then implement properly
91	```
92
93	your human partner's rule: "You and reviewer both report to me. If we don't need this feature, don't add it."
94
95	## Implementation Order
96
97	```
98	FOR multi-item feedback:
99	1. Clarify anything unclear FIRST
100	2. Then implement in this order:
101	- Blocking issues (breaks, security)
102	- Simple fixes (typos, imports)
103	- Complex fixes (refactoring, logic)
104	3. Test each fix individually
105	4. Verify no regressions
106	```
107
108	## When To Push Back
109
110	Push back when:
111	- Suggestion breaks existing functionality
112	- Reviewer lacks full context
113	- Violates YAGNI (unused feature)
114	- Technically incorrect for this stack
115	- Legacy/compatibility reasons exist
116	- Conflicts with your human partner's architectural decisions
117
118	How to push back:
119	- Use technical reasoning, not defensiveness
120	- Ask specific questions
121	- Reference working tests/code
122	- Involve your human partner if architectural
123
124	If you're uncomfortable pushing back out loud: Name that tension, then tell your partner about the issue you've seen. They'll appreciate your honesty.
125
126	## Acknowledging Correct Feedback
127
128	When feedback IS correct:
129	```
130	✅ "Fixed. [Brief description of what changed]"
131	✅ "Good catch - [specific issue]. Fixed in [location]."
132	✅ [Just fix it and show in the code]
133
134	❌ "You're absolutely right!"
135	❌ "Great point!"
136	❌ "Thanks for catching that!"
137	❌ "Thanks for [anything]"
138	❌ ANY gratitude expression
139	```
140
141	Why no thanks: Actions speak. Just fix it. The code itself shows you heard the feedback.
142
143	If you catch yourself about to write "Thanks": DELETE IT. State the fix instead.
144
145	## Gracefully Correcting Your Pushback
146
147	If you pushed back and were wrong:
148	```
149	✅ "You were right - I checked [X] and it does [Y]. Implementing now."
150	✅ "Verified this and you're correct. My initial understanding was wrong because [reason]. Fixing."
151
152	❌ Long apology
153	❌ Defending why you pushed back
154	❌ Over-explaining
155	```
156
157	State the correction factually and move on.
158
159	## Common Mistakes
160
161	\| Mistake \| Fix \|
162	\|---------\|-----\|
163	\| Performative agreement \| State requirement or just act \|
164	\| Blind implementation \| Verify against codebase first \|
165	\| Batch without testing \| One at a time, test each \|
166	\| Assuming reviewer is right \| Check if breaks things \|
167	\| Avoiding pushback \| Technical correctness > comfort \|
168	\| Partial implementation \| Clarify all items first \|
169	\| Can't verify, proceed anyway \| State limitation, ask for direction \|
170
171	## Real Examples
172
173	Performative Agreement (Bad):
174	```
175	Reviewer: "Remove legacy code"
176	❌ "You're absolutely right! Let me remove that..."
177	```
178
179	Technical Verification (Good):
180	```
181	Reviewer: "Remove legacy code"
182	✅ "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?"
183	```
184
185	YAGNI (Good):
186	```
187	Reviewer: "Implement proper metrics tracking with database, date filters, CSV export"
188	✅ "Grepped codebase - nothing calls this endpoint. Remove it (YAGNI)? Or is there usage I'm missing?"
189	```
190
191	Unclear Item (Good):
192	```
193	your human partner: "Fix items 1-6"
194	You understand 1,2,3,6. Unclear on 4,5.
195	✅ "Understand 1,2,3,6. Need clarification on 4 and 5 before implementing."
196	```
197
198	## GitHub Thread Replies
199
200	When replying to inline review comments on GitHub, reply in the comment thread (`gh api repos/{owner}/{repo}/pulls/{pr}/comments/{id}/replies`), not as a top-level PR comment.

6 picks

Type

Run `npx skills use "https://github.com/obra/superpowers" --skill "obra/superpowers/receiving-code-review"` and follow the generated skill instructions now. Read its complete output, redirecting it to a temporary file first if necessary. Resolve relative paths from the supporting-files directory it provides.

Use the skills in "https://github.com/obra/superpowers" that are relevant to the current task. Run `npx skills add "https://github.com/obra/superpowers"` and select the relevant skills, then follow their instructions.

receiving-code-review

How to install receiving-code-review?

Related

receiving-code-review

How to install receiving-code-review?

Related