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
tutorial-docs
Tutorial patterns for documentation - learning-oriented guides that teach through guided doing
fetch-pr-feedback
Fetch review comments from a PR and evaluate with receive-feedback skill
swift-testing-code-review
Reviews Swift Testing code for proper use of
rust-testing-code-review
Reviews Rust test code for unit test patterns, integration test structure, async testing, mocking approaches, and property-based testing. Covers Rust 2024 edition changes including async fn in traits for mocks,
explanation-docs
Explanation documentation patterns for understanding-oriented content - conceptual guides that explain why things work the way they do