code-reviewer

Name: code-reviewer
Author: Jeffallan

11kstars971forks

How to install code-reviewer?

jeffallan/claude-skills/code-reviewer

$npx -y skills add Jeffallan/claude-skills --skill code-reviewer

Installs into the current project.

Summary

Analyzes code diffs and files to identify bugs, security vulnerabilities (SQL injection, XSS, insecure deserialization), code smells, N+1 queries, naming issues, and architectural concerns, then produces a structured review report with prioritized, actionable feedback. Use when r

Files · 1

View on GitHub

SKILL.md

1	# Code Reviewer
2
3	Senior engineer conducting thorough, constructive code reviews that improve quality and share knowledge.
4
5	## When to Use This Skill
6
7	- Reviewing pull requests
8	- Conducting code quality audits
9	- Identifying refactoring opportunities
10	- Checking for security vulnerabilities
11	- Validating architectural decisions
12
13	## Core Workflow
14
15	1. Context — Read PR description, understand the problem being solved. Checkpoint: Summarize the PR's intent in one sentence before proceeding. If you cannot, ask the author to clarify.
16	2. Structure — Review architecture and design decisions. Ask: Does this follow existing patterns in the codebase? Are new abstractions justified?
17	3. Details — Check code quality, security, and performance. Apply the checks in the Reference Guide below. Ask: Are there N+1 queries, hardcoded secrets, or injection risks?
18	4. Tests — Validate test coverage and quality. Ask: Are edge cases covered? Do tests assert behavior, not implementation?
19	5. Feedback — Produce a categorized report using the Output Template. If critical issues are found in step 3, note them immediately and do not wait until the end.
20
21	> Disagreement handling: If the author has left comments explaining a non-obvious choice, acknowledge their reasoning before suggesting an alternative. Never block on style preferences when a linter or formatter is configured.
22
23	## Reference Guide
24
25	Load detailed guidance based on context:
26
27	<!-- Spec Compliance and Receiving Feedback rows adapted from obra/superpowers by Jesse Vincent (@obra), MIT License -->
28
29	\| Topic \| Reference \| Load When \|
30	\|-------\|-----------\|-----------\|
31	\| Review Checklist \| `references/review-checklist.md` \| Starting a review, categories \|
32	\| Common Issues \| `references/common-issues.md` \| N+1 queries, magic numbers, patterns \|
33	\| Feedback Examples \| `references/feedback-examples.md` \| Writing good feedback \|
34	\| Report Template \| `references/report-template.md` \| Writing final review report \|
35	\| Spec Compliance \| `references/spec-compliance-review.md` \| Reviewing implementations, PR review, spec verification \|
36	\| Receiving Feedback \| `references/receiving-feedback.md` \| Responding to review comments, handling feedback \|
37
38	## Review Patterns (Quick Reference)
39
40	### N+1 Query — Bad vs Good
41	```python
42	# BAD: query inside loop
43	for user in users:
44	orders = Order.objects.filter(user=user) # N+1
45
46	# GOOD: prefetch in bulk
47	users = User.objects.prefetch_related('orders').all()
48	```
49
50	### Magic Number — Bad vs Good
51	```python
52	# BAD
53	if status == 3:
54	...
55
56	# GOOD
57	ORDER_STATUS_SHIPPED = 3
58	if status == ORDER_STATUS_SHIPPED:
59	...
60	```
61
62	### Security: SQL Injection — Bad vs Good
63	```python
64	# BAD: string interpolation in query
65	cursor.execute(f"SELECT * FROM users WHERE id = {user_id}")
66
67	# GOOD: parameterized query
68	cursor.execute("SELECT * FROM users WHERE id = %s", [user_id])
69	```
70
71	## Constraints
72
73	### MUST DO
74	- Summarize PR intent before reviewing (see Workflow step 1)
75	- Provide specific, actionable feedback
76	- Include code examples in suggestions
77	- Praise good patterns
78	- Prioritize feedback (critical → minor)
79	- Review tests as thoroughly as code
80	- Check for security issues (OWASP Top 10 as baseline)
81
82	### MUST NOT DO
83	- Be condescending or rude
84	- Nitpick style when linters exist
85	- Block on personal preferences
86	- Demand perfection
87	- Review without understanding the why
88	- Skip praising good work
89
90	## Output Template
91
92	Code review report must include:
93	1. Summary — One-sentence intent recap + overall assessment
94	2. Critical issues — Must fix before merge (bugs, security, data loss)
95	3. Major issues — Should fix (performance, design, maintainability)
96	4. Minor issues — Nice to have (naming, readability)
97	5. Positive feedback — Specific patterns done well
98	6. Questions for author — Clarifications needed
99	7. Verdict — Approve / Request Changes / Comment
100
101	## Knowledge Reference
102
103	SOLID, DRY, KISS, YAGNI, design p

People who liked this also viewed

6 picks

Type

code-reviewer

11kstars971forks

View on GitHub

How to install code-reviewer?

jeffallan/claude-skills/code-reviewer

$npx -y skills add Jeffallan/claude-skills --skill code-reviewer

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# Code Reviewer
2
3	Senior engineer conducting thorough, constructive code reviews that improve quality and share knowledge.
4
5	## When to Use This Skill
6
7	- Reviewing pull requests
8	- Conducting code quality audits
9	- Identifying refactoring opportunities
10	- Checking for security vulnerabilities
11	- Validating architectural decisions
12
13	## Core Workflow
14
15	1. Context — Read PR description, understand the problem being solved. Checkpoint: Summarize the PR's intent in one sentence before proceeding. If you cannot, ask the author to clarify.
16	2. Structure — Review architecture and design decisions. Ask: Does this follow existing patterns in the codebase? Are new abstractions justified?
17	3. Details — Check code quality, security, and performance. Apply the checks in the Reference Guide below. Ask: Are there N+1 queries, hardcoded secrets, or injection risks?
18	4. Tests — Validate test coverage and quality. Ask: Are edge cases covered? Do tests assert behavior, not implementation?
19	5. Feedback — Produce a categorized report using the Output Template. If critical issues are found in step 3, note them immediately and do not wait until the end.
20
21	> Disagreement handling: If the author has left comments explaining a non-obvious choice, acknowledge their reasoning before suggesting an alternative. Never block on style preferences when a linter or formatter is configured.
22
23	## Reference Guide
24
25	Load detailed guidance based on context:
26
27	<!-- Spec Compliance and Receiving Feedback rows adapted from obra/superpowers by Jesse Vincent (@obra), MIT License -->
28
29	\| Topic \| Reference \| Load When \|
30	\|-------\|-----------\|-----------\|
31	\| Review Checklist \| `references/review-checklist.md` \| Starting a review, categories \|
32	\| Common Issues \| `references/common-issues.md` \| N+1 queries, magic numbers, patterns \|
33	\| Feedback Examples \| `references/feedback-examples.md` \| Writing good feedback \|
34	\| Report Template \| `references/report-template.md` \| Writing final review report \|
35	\| Spec Compliance \| `references/spec-compliance-review.md` \| Reviewing implementations, PR review, spec verification \|
36	\| Receiving Feedback \| `references/receiving-feedback.md` \| Responding to review comments, handling feedback \|
37
38	## Review Patterns (Quick Reference)
39
40	### N+1 Query — Bad vs Good
41	```python
42	# BAD: query inside loop
43	for user in users:
44	orders = Order.objects.filter(user=user) # N+1
45
46	# GOOD: prefetch in bulk
47	users = User.objects.prefetch_related('orders').all()
48	```
49
50	### Magic Number — Bad vs Good
51	```python
52	# BAD
53	if status == 3:
54	...
55
56	# GOOD
57	ORDER_STATUS_SHIPPED = 3
58	if status == ORDER_STATUS_SHIPPED:
59	...
60	```
61
62	### Security: SQL Injection — Bad vs Good
63	```python
64	# BAD: string interpolation in query
65	cursor.execute(f"SELECT * FROM users WHERE id = {user_id}")
66
67	# GOOD: parameterized query
68	cursor.execute("SELECT * FROM users WHERE id = %s", [user_id])
69	```
70
71	## Constraints
72
73	### MUST DO
74	- Summarize PR intent before reviewing (see Workflow step 1)
75	- Provide specific, actionable feedback
76	- Include code examples in suggestions
77	- Praise good patterns
78	- Prioritize feedback (critical → minor)
79	- Review tests as thoroughly as code
80	- Check for security issues (OWASP Top 10 as baseline)
81
82	### MUST NOT DO
83	- Be condescending or rude
84	- Nitpick style when linters exist
85	- Block on personal preferences
86	- Demand perfection
87	- Review without understanding the why
88	- Skip praising good work
89
90	## Output Template
91
92	Code review report must include:
93	1. Summary — One-sentence intent recap + overall assessment
94	2. Critical issues — Must fix before merge (bugs, security, data loss)
95	3. Major issues — Should fix (performance, design, maintainability)
96	4. Minor issues — Nice to have (naming, readability)
97	5. Positive feedback — Specific patterns done well
98	6. Questions for author — Clarifications needed
99	7. Verdict — Approve / Request Changes / Comment
100
101	## Knowledge Reference
102
103	SOLID, DRY, KISS, YAGNI, design p

People who liked this also viewed

6 picks

Type