code-review-excellence

Name: code-review-excellence
Author: wshobson

25kinstalls4.1kforks

How to install code-review-excellence?

wshobson/agents/code-review-excellence

$npx -y skills add wshobson/agents --skill code-review-excellence

Installs into the current project.

Summary

Master effective code review practices to provide constructive feedback, catch bugs early, and foster knowledge sharing while maintaining team morale. Use when reviewing pull requests, establishing review standards, or mentoring developers.

Files · 1

View on GitHub

SKILL.md

1	# Code Review Excellence
2
3	Transform code reviews from gatekeeping to knowledge sharing through constructive feedback, systematic analysis, and collaborative improvement.
4
5	## When to Use This Skill
6
7	- Reviewing pull requests and code changes
8	- Establishing code review standards for teams
9	- Mentoring junior developers through reviews
10	- Conducting architecture reviews
11	- Creating review checklists and guidelines
12	- Improving team collaboration
13	- Reducing code review cycle time
14	- Maintaining code quality standards
15
16	## Core Principles
17
18	### 1. The Review Mindset
19
20	Goals of Code Review:
21
22	- Catch bugs and edge cases
23	- Ensure code maintainability
24	- Share knowledge across team
25	- Enforce coding standards
26	- Improve design and architecture
27	- Build team culture
28
29	Not the Goals:
30
31	- Show off knowledge
32	- Nitpick formatting (use linters)
33	- Block progress unnecessarily
34	- Rewrite to your preference
35
36	### 2. Effective Feedback
37
38	Good Feedback is:
39
40	- Specific and actionable
41	- Educational, not judgmental
42	- Focused on the code, not the person
43	- Balanced (praise good work too)
44	- Prioritized (critical vs nice-to-have)
45
46	```markdown
47	❌ Bad: "This is wrong."
48	✅ Good: "This could cause a race condition when multiple users
49	access simultaneously. Consider using a mutex here."
50
51	❌ Bad: "Why didn't you use X pattern?"
52	✅ Good: "Have you considered the Repository pattern? It would
53	make this easier to test. Here's an example: [link]"
54
55	❌ Bad: "Rename this variable."
56	✅ Good: "[nit] Consider `userCount` instead of `uc` for
57	clarity. Not blocking if you prefer to keep it."
58	```
59
60	### 3. Review Scope
61
62	What to Review:
63
64	- Logic correctness and edge cases
65	- Security vulnerabilities
66	- Performance implications
67	- Test coverage and quality
68	- Error handling
69	- Documentation and comments
70	- API design and naming
71	- Architectural fit
72
73	What Not to Review Manually:
74
75	- Code formatting (use Prettier, Black, etc.)
76	- Import organization
77	- Linting violations
78	- Simple typos
79
80	## Review Process
81
82	### Phase 1: Context Gathering (2-3 minutes)
83
84	```markdown
85	Before diving into code, understand:
86
87	1. Read PR description and linked issue
88	2. Check PR size (>400 lines? Ask to split)
89	3. Review CI/CD status (tests passing?)
90	4. Understand the business requirement
91	5. Note any relevant architectural decisions
92	```
93
94	### Phase 2: High-Level Review (5-10 minutes)
95
96	```markdown
97	1. Architecture & Design
98	- Does the solution fit the problem?
99	- Are there simpler approaches?
100	- Is it consistent with existing patterns?
101	- Will it scale?
102
103	2. File Organization
104	- Are new files in the right places?
105	- Is code grouped logically?
106	- Are there duplicate files?
107
108	3. Testing Strategy
109	- Are there tests?
110	- Do tests cover edge cases?
111	- Are tests readable?
112	```
113
114	### Phase 3: Line-by-Line Review (10-20 minutes)
115
116	```markdown
117	For each file:
118
119	1. Logic & Correctness
120	- Edge cases handled?
121	- Off-by-one errors?
122	- Null/undefined checks?
123	- Race conditions?
124
125	2. Security
126	- Input validation?
127	- SQL injection risks?
128	- XSS vulnerabilities?
129	- Sensitive data exposure?
130
131	3. Performance
132	- N+1 queries?
133	- Unnecessary loops?
134	- Memory leaks?
135	- Blocking operations?
136
137	4. Maintainability
138	- Clear variable names?
139	- Functions doing one thing?
140	- Complex code commented?
141	- Magic numbers extracted?
142	```
143
144	### Phase 4: Summary & Decision (2-3 minutes)
145
146	```markdown
147	1. Summarize key concerns
148	2. Highlight what you liked
149	3. Make clear decision:
150	- ✅ Approve
151	- 💬 Comment (minor suggestions)
152	- 🔄 Request Changes (must address)
153	4. Offer to pair if complex
154	```
155
156	## Review Techniques
157
158	### Technique 1: The Checklist Method
159
160	```markdown
161	## Security Checklist
162
163	- [ ] User input validated and sanitized
164	- [ ] SQL queries use parameterization
165	- [ ] Authentication/authorization checked
166	- [ ] Secrets not hardcoded
167	- [ ] Error messages don't leak info
168
169	## Performance Checklist
170
171	- [ ] No N+1 queries
172	- [ ] Database queries indexed
173	- [ ] Large lists paginated
174	- [ ] Expensive operations cached
175	- [ ] No blocking I/O in hot paths
176
177	## Testing Checklist
178
179	- [ ] Happy path tested
180	- [ ] Edge cases covered
181	- [ ] Error cases tested
182	- [ ] Test names are descriptive
183	- [ ] Tests are deterministic
184	```
185
186	### Technique 2: The Question Approach
187
188	Instead of stating problems, ask questions to encourage thinking:
189
190	```markdown
191	❌ "This will fail if the list is empty."
192	✅ "What happens if `items` is an empty array?"
193
194	❌ "You need error handling here."
195	✅ "How should this behave if the API call fails?"
196
197	❌ "This is inefficient."
198	✅ "I see this loops through all users. Have we considered
199	the performance impact with 100k users?"
200	```
201
202	### Technique 3: Suggest, Don't Command
203
204	````markdown
205	## Use Collabora

People who liked this also viewed

6 picks

Type

code-review-excellence

25kinstalls4.1kforks

View on GitHub

How to install code-review-excellence?

wshobson/agents/code-review-excellence

$npx -y skills add wshobson/agents --skill code-review-excellence

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# Code Review Excellence
2
3	Transform code reviews from gatekeeping to knowledge sharing through constructive feedback, systematic analysis, and collaborative improvement.
4
5	## When to Use This Skill
6
7	- Reviewing pull requests and code changes
8	- Establishing code review standards for teams
9	- Mentoring junior developers through reviews
10	- Conducting architecture reviews
11	- Creating review checklists and guidelines
12	- Improving team collaboration
13	- Reducing code review cycle time
14	- Maintaining code quality standards
15
16	## Core Principles
17
18	### 1. The Review Mindset
19
20	Goals of Code Review:
21
22	- Catch bugs and edge cases
23	- Ensure code maintainability
24	- Share knowledge across team
25	- Enforce coding standards
26	- Improve design and architecture
27	- Build team culture
28
29	Not the Goals:
30
31	- Show off knowledge
32	- Nitpick formatting (use linters)
33	- Block progress unnecessarily
34	- Rewrite to your preference
35
36	### 2. Effective Feedback
37
38	Good Feedback is:
39
40	- Specific and actionable
41	- Educational, not judgmental
42	- Focused on the code, not the person
43	- Balanced (praise good work too)
44	- Prioritized (critical vs nice-to-have)
45
46	```markdown
47	❌ Bad: "This is wrong."
48	✅ Good: "This could cause a race condition when multiple users
49	access simultaneously. Consider using a mutex here."
50
51	❌ Bad: "Why didn't you use X pattern?"
52	✅ Good: "Have you considered the Repository pattern? It would
53	make this easier to test. Here's an example: [link]"
54
55	❌ Bad: "Rename this variable."
56	✅ Good: "[nit] Consider `userCount` instead of `uc` for
57	clarity. Not blocking if you prefer to keep it."
58	```
59
60	### 3. Review Scope
61
62	What to Review:
63
64	- Logic correctness and edge cases
65	- Security vulnerabilities
66	- Performance implications
67	- Test coverage and quality
68	- Error handling
69	- Documentation and comments
70	- API design and naming
71	- Architectural fit
72
73	What Not to Review Manually:
74
75	- Code formatting (use Prettier, Black, etc.)
76	- Import organization
77	- Linting violations
78	- Simple typos
79
80	## Review Process
81
82	### Phase 1: Context Gathering (2-3 minutes)
83
84	```markdown
85	Before diving into code, understand:
86
87	1. Read PR description and linked issue
88	2. Check PR size (>400 lines? Ask to split)
89	3. Review CI/CD status (tests passing?)
90	4. Understand the business requirement
91	5. Note any relevant architectural decisions
92	```
93
94	### Phase 2: High-Level Review (5-10 minutes)
95
96	```markdown
97	1. Architecture & Design
98	- Does the solution fit the problem?
99	- Are there simpler approaches?
100	- Is it consistent with existing patterns?
101	- Will it scale?
102
103	2. File Organization
104	- Are new files in the right places?
105	- Is code grouped logically?
106	- Are there duplicate files?
107
108	3. Testing Strategy
109	- Are there tests?
110	- Do tests cover edge cases?
111	- Are tests readable?
112	```
113
114	### Phase 3: Line-by-Line Review (10-20 minutes)
115
116	```markdown
117	For each file:
118
119	1. Logic & Correctness
120	- Edge cases handled?
121	- Off-by-one errors?
122	- Null/undefined checks?
123	- Race conditions?
124
125	2. Security
126	- Input validation?
127	- SQL injection risks?
128	- XSS vulnerabilities?
129	- Sensitive data exposure?
130
131	3. Performance
132	- N+1 queries?
133	- Unnecessary loops?
134	- Memory leaks?
135	- Blocking operations?
136
137	4. Maintainability
138	- Clear variable names?
139	- Functions doing one thing?
140	- Complex code commented?
141	- Magic numbers extracted?
142	```
143
144	### Phase 4: Summary & Decision (2-3 minutes)
145
146	```markdown
147	1. Summarize key concerns
148	2. Highlight what you liked
149	3. Make clear decision:
150	- ✅ Approve
151	- 💬 Comment (minor suggestions)
152	- 🔄 Request Changes (must address)
153	4. Offer to pair if complex
154	```
155
156	## Review Techniques
157
158	### Technique 1: The Checklist Method
159
160	```markdown
161	## Security Checklist
162
163	- [ ] User input validated and sanitized
164	- [ ] SQL queries use parameterization
165	- [ ] Authentication/authorization checked
166	- [ ] Secrets not hardcoded
167	- [ ] Error messages don't leak info
168
169	## Performance Checklist
170
171	- [ ] No N+1 queries
172	- [ ] Database queries indexed
173	- [ ] Large lists paginated
174	- [ ] Expensive operations cached
175	- [ ] No blocking I/O in hot paths
176
177	## Testing Checklist
178
179	- [ ] Happy path tested
180	- [ ] Edge cases covered
181	- [ ] Error cases tested
182	- [ ] Test names are descriptive
183	- [ ] Tests are deterministic
184	```
185
186	### Technique 2: The Question Approach
187
188	Instead of stating problems, ask questions to encourage thinking:
189
190	```markdown
191	❌ "This will fail if the list is empty."
192	✅ "What happens if `items` is an empty array?"
193
194	❌ "You need error handling here."
195	✅ "How should this behave if the API call fails?"
196
197	❌ "This is inefficient."
198	✅ "I see this loops through all users. Have we considered
199	the performance impact with 100k users?"
200	```
201
202	### Technique 3: Suggest, Don't Command
203
204	````markdown
205	## Use Collabora

People who liked this also viewed

6 picks

Type