Structural Review

Opinionated structural and maintainability review rubric. Report-only — this skill produces findings; it does not mutate files or open PRs.

Core Principle

Every structural finding must answer: "What exactly should the author delete, collapse, or rename — and which specific file/line is the canonical landing zone?" Vague nits ("this could be cleaner") are noise. High-conviction, actionable findings only.

This rubric is explicitly complementary to /code-review. Do not re-flag correctness bugs or CLAUDE.md rule violations already covered there. Own the orthogonal structural/maintainability/devex dimensions.

Primary Review Questions

Ask these first, before scanning for individual issues:

1. Does this PR make the codebase smaller or larger? If larger: is each new abstraction earning its keep, or is it complexity added on faith?
2. Where is the decision logic? Is it in the canonical layer (server action, domain service, hook) or scattered across render trees and event handlers?
3. Can a reader understand this module in isolation? Or does understanding it require tracking state/logic across 4+ files?
4. Is every new type structurally placed? Or are bare unknown, and as X casts hiding future breakage, and are interfaces inlined where they should be in *.types.ts?
5. Does the PR leave the stack cleaner than it found it? Tailwind v3 debris, npm invocations, raw HTML in a shadcn project, middleware.ts in a Next.js 16 app — these are regressions, not style notes.