review-python
Comprehensive Python/FastAPI backend code review with optional parallel agents
Install via CLI (Recommended)
clawhub install openclaw/skills/skills/anderskev/review-pythonBackend Code Review
Hard gates (sequence)
Advance only when each pass condition is objectively satisfied (prevents linter-owned false positives and ungrounded findings):
| Gate | Pass condition |
|---|---|
| G1 — Diff scope | Step 1 command has been run; the changed .py paths are enumerated in writing (list may be empty — if empty, state that explicitly and do not invent Python findings). |
| G2 — Linters before manual style/type | For ruff and mypy: either no project config exists for that tool, or it was run on the changed files and you captured pass/fail (exit code or clear tool output). Do not add manual style or type findings for rules those tools already enforce when configured. |
| G3 — Protocol and base skills | beagle-python:review-verification-protocol, beagle-python:python-code-review, and beagle-python:fastapi-code-review are loaded before Step 6 substantive review. |
| G4 — Evidence per issue | Step 7 checks are satisfied for each reported issue before it appears in the final list (re-read source, search references for “unused”, confirm framework handling for “missing”, verify syntax against current docs). |
| G5 — Output contract | Findings use sequential numbering, every issue has FILE:LINE, and the Verdict follows Step 8 (Critical/Major only block; Minor/Informational do not). |
Arguments
--parallel: Spawn specialized subagents per technology area- Path: Target directory (default: current working directory)
Step 1: Identify Changed Files
Pass (G1): Capture the command output (or equivalent) as your authoritative changed-.py set before Steps 2–3.
git diff --name-only $(git merge-base HEAD main)..HEAD | grep -E '\.py$'
Step 2: Verify Linter Status
CRITICAL: Run project linters BEFORE flagging any style or type issues. Pass (G2): You may only proceed to Step 3 after each configured linter has been run on the changed files or you have recorded why it was skipped (missing config).
# Check if ruff config exists and run it
if [ -f "pyproject.toml" ] || [ -f "ruff.toml" ]; then
ruff check <changed_files>
fi
# Check if mypy config exists and run it
if [ -f "pyproject.toml" ] || [ -f "mypy.ini" ]; then
mypy <changed_files>
fi
Rules:
- If a linter passes for a specific rule (e.g., line length), DO NOT flag that issue manually
- Linter configuration is authoritative for style rules
- Only flag issues that linters cannot detect (semantic issues, architectural problems)
Why: Analysis of 24 review outcomes showed 4 false positives (17%) where reviewers flagged line-length violations that ruff check confirmed don't exist. The linter's configuration reflects intentional project decisions.
Step 3: Detect Technologies
# Detect Pydantic-AI
grep -r "pydantic_ai\|@agent\.tool\|RunContext" --include="*.py" -l | head -3
Metadata
Not sure this is the right skill?
Describe what you want to build — we'll match you to the best skill from 16,000+ options.
Find the right skillPaste this into your clawhub.json to enable this plugin.
{
"plugins": {
"official-anderskev-review-python": {
"enabled": true,
"auto_update": true
}
}
}Related Skills
explanation-docs
Explanation documentation patterns for understanding-oriented content - conceptual guides that explain why things work the way they do
tutorial-docs
Tutorial patterns for documentation - learning-oriented guides that teach through guided doing
pytest-code-review
Reviews pytest test code for async patterns, fixtures, parametrize, and mocking. Use when reviewing test_*.py files, checking async test functions, fixture usage, or mock patterns.
reference-docs
Reference documentation patterns for API and symbol documentation. Use when writing reference docs, API docs, parameter tables, or technical specifications. Triggers on reference docs, API reference, function reference, parameters table, symbol documentation.
serde-code-review
Reviews serde serialization code for derive patterns, enum representations, custom implementations, and common serialization bugs. Use when reviewing Rust code that uses serde, serde_json, toml, or any serde-based serialization format. Covers attribute macros, field renaming, and format-specific pitfalls.