review-python-file

name	review-python-file
description	Perform a comprehensive review of a single Python file — invoke when reviewing one file in depth; use review-changes for a multi-file changeset. Covers design, correctness, DRY, security, type safety, pydocs, imports, logging, and test coverage

Review like a senior engineer. Every finding must answer three questions in concrete terms: what is wrong, what is better, why the change is worth its cost. All topics are fair game — correctness, security, design, duplication, clarity, naming, structure, tests. Be conscious of suggestions that do not serve a purpose.

Perform a comprehensive review of the specified Python file as it currently exists.

1. Design: Is the code well-structured and consistent with the project? Apply the ref-python-coding-practices and ref-mcp-module-organization skills as relevant.
2. Correctness: Does the code do what it claims? Look for logic errors, incorrect assumptions, and edge cases.
3. Simplification and DRY: Can the code be simplified? Flag duplicated logic that should be shared, unnecessary abstraction, and over-engineering.
4. Code smells: Flag anything that makes a senior engineer pause and ask "why is it like that?" — long functions, deep nesting, magic numbers, complex conditions, oddly-shaped APIs (boolean-mode flags, stringly-typed parameters where a Literal or Enum belongs, long parameter lists), strange call syntax, dead or commented-out code, mixed abstraction levels within one function, mutable default arguments, broad except clauses, side effects in property getters or __init__, argument mutation, speculative generality, primitive obsession, feature envy, re-implementations of stdlib or library functionality, misleading names, inconsistent return types, sentinel returns where an exception belongs — This list is illustrative, not exhaustive; trust your judgment. Apply the general style rules in .