review-structure

# Structural-Maintainability Review Use this skill for an unusually strict review focused on implementation quality, maintainability, abstraction quality, and codebase health. Above all, this skill should push the reviewer to be **ambitious** about code structure. Do not merely identify local cleanup opportunities. Actively search for "code judo" moves: restructurings that preserve behavior while making the implementation dramatically simpler, smaller, more direct, and more elegant. The structural lens is **repo-wide**: read any file in the codebase as needed (Read/Grep/Bash) to judge whether canonical helpers already exist, whether file-size budgets are honored, and whether the change makes the codebase easier or harder to live with. ## Hard gates (sequence) Advance only when each **pass condition** is objectively satisfied (artifact path, tool output, or labeled capture — not "I checked it mentally"): | Gate | Pass condition | |------|----------------| | **G1 — Changed-file list** | `git diff --name-only` (or equivalent) returns a non-empty list *or* you exit with an explicit "no changed files" message; the list is recorded before any review step begins. | | **G2 — Full file reads** | Every file in scope has been opened with `Read`; for each file you record the path and line count (e.g. `src/foo.ts — 342 lines`). Do **not** proceed to findings until all reads are logged. | | **G3 — Canonical-helper and 1k-line claims verified** | Any finding that asserts "no canonical...