From python-engineering
Reviews Python code for type safety, error handling, security vulnerabilities, performance issues, and modern patterns. Use for code reviews, PRs, or quality assessments.
How this skill is triggered — by the user, by Claude, or both
Slash command
/python-engineering:reviewThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
Review the requested Python scope with these priorities.
Review the requested Python scope with these priorities.
Scope: $ARGUMENTS
Check for:
Any without justification — no Any outside boundary modulesList, Dict, Optional, Union)Severity: High (type errors cause runtime failures)
# Bad - missing types
def process(data):
return data.get("value")
# Good - complete types
def process(data: dict[str, int]) -> int | None:
return data.get("value")
Check for:
except: or except Exception:add_note()Severity: High (silent failures cause data corruption)
# Bad - swallowed exception
try:
result = risky_call()
except Exception:
pass # Silent failure
# Good - specific handling with context
try:
result = risky_call()
except ConnectionError as e:
e.add_note(f"Failed connecting to {host}")
raise
Check for:
subprocess.run(..., shell=True) with user inputeval() or exec() with external inputSeverity: Critical (security vulnerabilities)
# Bad - SQL injection risk
query = f"SELECT * FROM users WHERE id = {user_id}"
# Good - parameterized query
query = "SELECT * FROM users WHERE id = ?"
cursor.execute(query, (user_id,))
Check for:
in list vs in set)__slots__ for data classes with many instancesSeverity: Medium (degraded performance)
# Bad - O(n) lookup on each iteration
valid_codes = [200, 201, 204]
for code in codes:
if code in valid_codes: # O(n) each time
process(code)
# Good - O(1) lookup
VALID_CODES = {200, 201, 204}
for code in codes:
if code in VALID_CODES: # O(1) each time
process(code)
Check for:
unittest.mock in pytest tests (use pytest-mock instead)Severity: Low (technical debt)
# Bad - legacy pattern
from typing import Optional
result = expensive_call()
if result:
process(result)
# Good - modern pattern
if result := expensive_call():
process(result)
Check for:
__all__ in public modulesSeverity: Medium (maintainability)
Check for:
parse_*, validate_*)Severity: High (correctness)
# Bad - raw dict passed into typed core
def handle_request(payload: dict) -> None:
user = create_user(payload["name"], payload["email"])
# Good - validated at boundary
def handle_request(payload: dict) -> None:
user_input = UserInput.model_validate(payload) # validates at boundary
user = create_user(user_input.name, user_input.email)
Check for:
unittest.mock instead of pytest-mockSeverity: Medium (test quality)
Check for:
Severity: Low (maintainability)
TYPE SAFETY
- [ ] All functions have complete type hints
- [ ] No Any outside boundary modules
- [ ] No legacy typing imports (List, Dict, Optional, Union)
- [ ] TypeVar/Protocol used appropriately
ERROR HANDLING
- [ ] No bare except clauses
- [ ] No swallowed exceptions
- [ ] Exceptions have context (add_note or from)
- [ ] Specific exception types used
SECURITY
- [ ] No SQL injection vulnerabilities
- [ ] No command injection (shell=True with user input)
- [ ] No hardcoded secrets
- [ ] Input validation present at boundaries
PERFORMANCE
- [ ] Sets used for membership testing
- [ ] No string concatenation in loops
- [ ] Appropriate caching used
- [ ] Async patterns correct
MODERN PATTERNS
- [ ] Builtin generics used (list, dict, not List, Dict)
- [ ] Walrus operator where beneficial
- [ ] Match-case for dispatch
- [ ] pytest-mock instead of unittest.mock
DESIGN
- [ ] Functions under 50 lines
- [ ] No deep nesting (>3 levels)
- [ ] No circular imports
- [ ] __all__ defined in public modules
- [ ] SOLID principles followed
BOUNDARY
- [ ] Raw data validated before crossing into typed core
- [ ] Boundary modules use approved naming (parse_*, validate_*, etc.)
- [ ] Typed return values from boundary code
TESTING
- [ ] Tests exist for changed code
- [ ] Edge cases covered
- [ ] pytest-mock (not unittest.mock)
- [ ] Behavioral test names
DOCUMENTATION
- [ ] Public functions have docstrings
- [ ] Docstrings match signatures
- [ ] Complex logic commented
For each finding:
[SEVERITY] [Category]: Brief Description
Location: file.py:123 in function_name
Issue: Detailed explanation
Fix: Suggested fix with code
Impact: Why this matters (security, performance, reliability)
End with:
## Review Summary
Files Reviewed: N
Total Findings: N
| Severity | Count |
|----------|-------|
| Critical | X |
| High | X |
| Medium | X |
| Low | X |
Recommendation: APPROVE / REQUEST CHANGES / BLOCK
npx claudepluginhub jamie-bitflight/claude_skills --plugin python-engineeringReviews Python code for type safety, error handling, security vulnerabilities, and performance issues. Reports findings by severity/location with fix examples.
Reviews Python code for type safety, async patterns, error handling, and common mistakes. Use when reviewing .py files, checking type hints, async/await usage, or exception handling.
Reviews Python code enforcing type hints, Pythonic patterns, naming clarity, imports, testing practices, and maintainability. Strict on existing code modifications.