Layered Python Code Reviewer
Overview
Provide a reusable code review workflow and checklist that applies across Python projects, especially ones that aim for layered architecture and dependency inversion. Produce actionable, concrete review comments (not vague style opinions).
Review Workflow
Identify the change scope
- Summarize touched modules and layers (example layers:
domain/, service/, dataset/, adapters/, infra/).
- Identify which changes are: (a) core policy/logic, (b) boundary I/O, (c) data shaping, (d) test-only.
Apply hard blockers first
- Dependency direction (DIP): low-level modules must not import high-level policy/service types.
- Public interfaces: avoid leaking raw
dict across layers; use TypedDict, dataclasses, or Pydantic models.
- Config correctness: validate invariants on load (range continuity, required keys, value bounds).
- Type/lint hygiene: fix
None handling, unused variables, and any Any propagation caused by missing types.
Apply design-quality checks
- Composition root: wiring (ENV/config/I/O/client construction) stays at the boundary (
create()/entrypoint).
- Separation of concerns: “build payload/message” vs “send request”, “decide” vs “orchestrate”.
- Test seams: time/randomness/I/O are injectable; core logic is deterministic.
Write review output
- Group comments by:
Architecture, DIP/DI, Typing, Config, Error handling, Tests, Naming/Docs.
- For each issue: state impact + preferred pattern + minimal change suggestion.
References
Load and apply:
references/principles.md for a project-agnostic checklist and comment templates.references/review-themes.md for common “review-driven refactor” patterns (kept generic on purpose).
Optional Automation
If your project uses clear “layer folders” under a package root, run:
python scripts/check_layered_imports.py --root <package_root_dir> --package-name <top_level_package>
Use flags to match your project layout:
--layers domain,service,adapters,infra--forbid domain:service,adapters,infra--forbid adapters:service
1---2name: prnd-layered-python-code-reviewer3description: Review Python code changes with a focus on layered architecture boundaries, DI/DIP, configuration validation, typing quality (mypy/flake8 readiness), naming/docstring accuracy, and testability. Use when asked to “code review”, “PR review”, or “리뷰해줘” to prevent repeat feedback on architecture regressions and low-signal changes.4---56# Layered Python Code Reviewer78## Overview910Provide a reusable code review workflow and checklist that applies across Python projects, especially ones that aim for layered architecture and dependency inversion. Produce actionable, concrete review comments (not vague style opinions).1112## Review Workflow13141. Identify the change scope15 - Summarize touched modules and layers (example layers: `domain/`, `service/`, `dataset/`, `adapters/`, `infra/`).16 - Identify which changes are: (a) core policy/logic, (b) boundary I/O, (c) data shaping, (d) test-only.17182. Apply hard blockers first19 - **Dependency direction (DIP)**: low-level modules must not import high-level policy/service types.20 - **Public interfaces**: avoid leaking raw `dict` across layers; use `TypedDict`, dataclasses, or Pydantic models.21 - **Config correctness**: validate invariants on load (range continuity, required keys, value bounds).22 - **Type/lint hygiene**: fix `None` handling, unused variables, and any `Any` propagation caused by missing types.23243. Apply design-quality checks25 - **Composition root**: wiring (ENV/config/I/O/client construction) stays at the boundary (`create()`/entrypoint).26 - **Separation of concerns**: “build payload/message” vs “send request”, “decide” vs “orchestrate”.27 - **Test seams**: time/randomness/I/O are injectable; core logic is deterministic.28294. Write review output30 - Group comments by: `Architecture`, `DIP/DI`, `Typing`, `Config`, `Error handling`, `Tests`, `Naming/Docs`.31 - For each issue: state impact + preferred pattern + minimal change suggestion.3233## References3435Load and apply:36- `references/principles.md` for a project-agnostic checklist and comment templates.37- `references/review-themes.md` for common “review-driven refactor” patterns (kept generic on purpose).3839## Optional Automation4041If your project uses clear “layer folders” under a package root, run:4243`python scripts/check_layered_imports.py --root <package_root_dir> --package-name <top_level_package>`4445Use flags to match your project layout:46- `--layers domain,service,adapters,infra`47- `--forbid domain:service,adapters,infra`48- `--forbid adapters:service`49
diegosouzapw