fredrikaverpil Self-Review
Review the change end-to-end. Read every file touched in full, not just the diff — the surrounding code is what says whether the change belongs. Report everything you find and fix what matters; don't self-censor to only the severe findings.
Review criteria
Beyond the obvious ones, weigh these — they are the ones most often missed:
- Placement: was the change made in the right place architecturally, or merely somewhere that works?
- Simplicity over cleverness: if something needs a comment to explain why it's written that way, it's probably too clever.
- Consistency: a codebase consistent with itself beats a change that is locally "better" but idiosyncratic.
- DX and UX: are APIs intuitive and error messages helpful, from both the developer's and the end user's side?
- Testability: look for clear seams, injectable dependencies, and logic separated from side effects. Hard-to-test code is a design smell — flag it rather than leaving it untested.
- Robustness: edge cases, race conditions, and assumptions that hold today but only by accident.
Laziness ladder
The ponytail plugin applies this ladder while code is being written. Apply it here in reverse, to what was written: for each piece of code the change added, check it climbed no higher than necessary.
- Does this need to exist? — if not, remove it (YAGNI).
- Already in this codebase? — reuse it, don't rewrite.
- Standard library does it? — use it.
- Native platform feature? — use it.
- Already-installed dependency? — use it.
- One line? — one line.
- Only then: the minimum that works.
Flag anything that skipped a lower rung — a new dependency where the stdlib or a native feature would do, a reimplementation of something the codebase already has, or an abstraction with a single caller.
The ladder never touches safety: trust-boundary and input validation, security, data-loss and error handling, and accessibility are out of scope for trimming.
$ARGUMENTS