// Systematic code review workflows with bundled utilities for analyzing code quality, detecting patterns, and providing structured feedback. Use this skill when reviewing pull requests or conducting code audits.
| name | code-review-helper |
| description | Systematic code review workflows with bundled utilities for analyzing code quality, detecting patterns, and providing structured feedback. Use this skill when reviewing pull requests or conducting code audits. |
Systematic code review workflows with utilities for thorough, consistent reviews.
This skill provides structured workflows and utilities for conducting high-quality code reviews. It emphasizes:
Before reviewing, understand the change:
# View PR metadata
gh pr view <pr-number> --repo <owner/repo>
# Check file changes
gh pr diff <pr-number> --repo <owner/repo>
# Review CI status
gh pr checks <pr-number> --repo <owner/repo>
Review across these dimensions:
Correctness
Clarity
Testing
Documentation
Performance
Security
Use bundled utilities to detect common issues:
# Import review helpers
from review_helpers import (
check_naming_conventions,
detect_code_smells,
analyze_complexity,
find_duplicate_code,
check_test_coverage
)
# Analyze code
naming_issues = check_naming_conventions("path/to/file.py")
smells = detect_code_smells("path/to/file.py")
complexity = analyze_complexity("path/to/file.py")
duplicates = find_duplicate_code("src/")
coverage = check_test_coverage("tests/", "src/")
# Report findings
for issue in naming_issues + smells:
print(f"⚠️ {issue}")
Provide feedback in this format:
## Summary
[Brief overview of the PR and general assessment]
## Strengths
- [Positive aspect 1]
- [Positive aspect 2]
## Issues Found
### Critical
- [ ] **[File:Line]**: [Description]
- Why: [Explanation]
- Fix: [Suggestion]
### Important
- [ ] **[File:Line]**: [Description]
- Why: [Explanation]
- Fix: [Suggestion]
### Minor
- [ ] **[File:Line]**: [Description]
- Why: [Explanation]
- Fix: [Suggestion]
## Suggestions
- [Non-blocking improvement 1]
- [Non-blocking improvement 2]
## Questions
- [Clarification needed 1]
- [Clarification needed 2]
## Overall Assessment
[Approve / Request Changes / Comment]
Provides automated analysis functions:
check_naming_conventions(filepath)
detect_code_smells(filepath)
analyze_complexity(filepath)
find_duplicate_code(directory)
check_test_coverage(test_dir, source_dir)
When reviewing authentication, authorization, or data handling:
**Security Checklist**:
- [ ] Input validation present
- [ ] SQL injection prevention
- [ ] XSS prevention (if web)
- [ ] Secrets not hardcoded
- [ ] Sensitive data encrypted
- [ ] Access control enforced
- [ ] Audit logging included
When reviewing loops, database queries, or large data operations:
**Performance Checklist**:
- [ ] N+1 queries avoided
- [ ] Appropriate indexes used
- [ ] Caching considered
- [ ] Bulk operations used where possible
- [ ] Memory usage reasonable
- [ ] Algorithmic complexity acceptable
When reviewing public API modifications:
**API Checklist**:
- [ ] Backward compatibility maintained or migration path provided
- [ ] Documentation updated
- [ ] Examples provided
- [ ] Error handling clear
- [ ] Type hints complete
- [ ] Deprecation warnings added if needed
Focus on improvement, not criticism:
# Unhelpful
This code is terrible.
# Helpful
This function is hard to test due to tight coupling. Consider using dependency injection to improve testability.
Explain why something matters:
# Incomplete
This variable name is bad.
# Complete
The variable name 'x' is unclear. Consider 'customer_count' which better expresses the domain concept and improves readability.
When requesting changes, show how:
# Vague
This needs to be refactored.
# Specific
Consider extracting this logic into a separate function for better testability and reuse.
Distinguish between blocking and non-blocking feedback:
**Blocking**: Security vulnerability in password handling (line 42)
**Important**: Missing input validation (line 67)
**Nice-to-have**: Consider extracting helper function (line 123)
**Question**: Why use X instead of Y here? (line 89)
# Check for common issues
rg "TODO|FIXME|XXX" --type py src/
grep -r "import \*" src/
find src/ -name "*.py" -exec wc -l {} + | sort -rn | head -10
<<<<<<< ORIGINAL
def process_data(data):
result = []
for item in data:
result.append(transform(item))
return result
=======
def process_data(data):
"""Process data items with transformation.
Args:
data: Iterable of items to process
Returns:
List of transformed items
"""
return [transform(item) for item in data]
>>>>>>> UPDATED
# Find patterns
sg --pattern 'except: $$$' --lang python src/
sg --pattern 'print($MSG)' --lang python src/
sg --pattern 'def $FUNC($ARGS): pass' --lang python src/
Complete review workflow:
#!/usr/bin/env python3
"""Automated code review workflow."""
from review_helpers import (
check_naming_conventions,
detect_code_smells,
analyze_complexity,
find_duplicate_code
)
def review_pr(pr_number: int, repo: str):
"""Conduct automated review of PR."""
# Get changed files
files = get_pr_files(pr_number, repo)
# Analyze each file
all_issues = []
for filepath in files:
if filepath.endswith('.py'):
issues = []
issues.extend(check_naming_conventions(filepath))
issues.extend(detect_code_smells(filepath))
complexity = analyze_complexity(filepath)
if complexity > 10:
issues.append(f"High complexity: {complexity}")
all_issues.extend([(filepath, issue) for issue in issues])
# Check for duplicates across files
duplicates = find_duplicate_code("src/")
# Generate review comment
comment = format_review_comment(all_issues, duplicates)
# Post review
post_pr_review(pr_number, repo, comment)
if __name__ == "__main__":
review_pr(123, "owner/repo")