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.
npx claudepluginhub jamie-bitflight/claude_skills --plugin python-engineeringThis skill uses the workspace's default tool permissions.
Review the requested Python scope with these priorities.
Generates design tokens/docs from CSS/Tailwind/styled-components codebases, audits visual consistency across 10 dimensions, detects AI slop in UI.
Records polished WebM UI demo videos of web apps using Playwright with cursor overlay, natural pacing, and three-phase scripting. Activates for demo, walkthrough, screen recording, or tutorial requests.
Delivers idiomatic Kotlin patterns for null safety, immutability, sealed classes, coroutines, Flows, extensions, DSL builders, and Gradle DSL. Use when writing, reviewing, refactoring, or designing Kotlin code.
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