Placement: Was the change made in the right place architecturally? Does it fit naturally into the existing structure?
Simplicity over cleverness: Prefer simple, explicit code over clever, implicit solutions. If something requires a comment to explain why it's written that way, it's probably too clever.
DRY: Did the change introduce redundant duplication? Is there existing code that already handles this or could be reused?
YAGNI: Was anything added that isn't needed right now? Remove speculative abstractions, unused parameters, and premature generalization.
Idiomatic code: Does the code follow conventions of the language, framework, and ecosystem? It should look like it belongs in the codebase.
DX and UX: Is the change pleasant to use from both a developer and end-user perspective? Are APIs intuitive? Are error messages helpful?
Consistency: Does the change follow the patterns already established in the project? A consistent codebase is more important than a locally "better" approach.
Maintainability: Will this be easy to understand and modify six months from now by someone unfamiliar with the change?
Robustness: Is the code brittle or potentially buggy? Look for edge cases, race conditions, or assumptions that could break.

Process

$ARGUMENTS

self-review