Py Review

Python Review Router

Use this skill first for Python code review. Orient on context, then load only the focused skills that match the changed code.

Before Reviewing: Orient

1. Check Python version from pyproject.toml, setup.cfg, tox.ini, CI, or README.

   • If >=3.10: load all relevant core skills, but apply each rule only when its Python/tool caveat matches.
   • If 3.8-3.9: skip syntax rules requiring >=3.10.
   • If unknown: assume minimum 3.10, but phrase version-sensitive findings conservatively.

2. Classify project maturity.

   • Active/greenfield: full rule set is appropriate.
   • Mature legacy/maintenance-only: prioritize CRITICAL and HIGH findings.
   • Automation/scripts: prioritize safety, correctness, resource handling, and clear errors.

3. Check toolchain.

   • If the project uses pyright, do not recommend mypy-specific config.
   • If the project uses ruff, defer style/import findings to its configuration.
   • If no tool is configured, make tool suggestions low-severity unless the issue is correctness-related.

4. Read the exact changed files before flagging issues.

   • For an uncommitted review, inspect git status --short, the unstaged diff, the staged diff (git diff --cached), and every relevant untracked file. Plain git diff omits untracked files.
   • Before treating a failed command as a code finding, separate repository behavior from reviewer-environment limits such as sandbox permissions, unavailable network access, or an unwritable temporary directory. Compare existing tests and configured CI when the failure may be environmental.
   • Cite file and line for every finding.
   • Do not issue generic findings without local evidence.
   • A rule match is a signal, not a verdict.

Routing

Portability Note

The "Load" column tells you which focused skill's rules to apply for each change type. How you access those rules depends on your agent runtime:

• Dynamic loading: If your agent supports activating skills mid-session, make the named skill discoverable and activate it when the routing table signals its scope.
• Static checklist: Read the focused skill's SKILL.md file directly from the skills directory and apply its rules as a review checklist.

Both approaches produce the same review outcome. The routing table is the decision tree; the focused skill provides the rule set.

Review Output

Lead with bugs and behavioral risks. Keep style-only findings behind correctness findings. For legacy code, prefer actionable high-impact issues over broad modernization advice.

Review Budget

Default to one discovery pass and one post-fix verification pass.

• The discovery pass identifies concrete findings from the complete changed surface.
• The verification pass checks the applied fixes and looks for regressions introduced by those fixes.
• Continue beyond those two passes only when verification exposes a new, concrete behavioral risk. Do not repeat an unchanged review merely to seek more confidence.
• Record commands that could not run because of reviewer-environment limits; do not spend another review pass retrying the same unavailable capability.

Sensitive Evidence Safety

If changed code or tool output reveals a suspected credential, token, private key, secret-bearing URL, or other sensitive value, do not quote or reproduce the value. Report only its existence and location. Treat filename and pattern checks as heuristic evidence, not proof that a repository is secret-free.

If the exposure appears credible, make it the first finding, stop lower-priority review, and recommend revocation or rotation. Never place sensitive values in reports, generated examples, or commit subjects or bodies.