review
Review
Run all review dimensions against the current branch and produce one unified review. Approve when a change improves overall code health, even if it isn't perfect.
Scope
Review only what changed on the current branch against main, but read enough surrounding code and docs to understand conventions and boundaries.
Do not duplicate the same issue across categories.
Change sizing
Before reviewing, check the diff size:
- ~100 lines: good, reviewable in one pass.
- ~300 lines: acceptable if one logical change.
- ~1000 lines: too large — ask the author to split before reviewing.
Refactoring mixed with feature work is two changes. Flag it.
More from cniska/skills
tdd
Drive implementation with red-green-refactor. Use when building features or fixing bugs test-first.
12plan
Design a feature or behavior change through dialogue. Use when asked to plan, scope, design, or break down work before coding.
10explore
Explore a task or design through systematic questions until reaching shared understanding. Use before implementing complex or ambiguous work.
10issue
Create a GitHub issue from a short description. Use when filing a bug, feature request, or task.
10pr
Create a pull request with review and verify. Use when the branch is ready to merge.
10debug
Debug systematically with structured triage. Use when tests fail, builds break, or runtime behavior doesn't match expectations.
8