Review code across five quality dimensions before merge

This skill runs multi-dimensional code review with quality gates across five axes: correctness, checking that the change matches spec, handles edge and error cases, and that tests actually test the right things; readability, checking descriptive names, straightforward control flow, fewer lines where possible, earned abstractions, and no dead code or bolted-on conditionals signaling a missing model; architecture, checking that the change fits existing patterns, has no circular dependencies, that refactors actually reduce complexity rather than relocate it, that feature-specific logic doesn't leak into shared modules, and that type boundaries are explicit instead of gratuitous casts; security, checking input validation, no hardcoded secrets, parameterized queries, output encoding, and untrusted external data handled as such, deferring finer detail to a companion security skill; and performance, checking for N+1 patterns, unbounded loops, missing pagination, and unnecessary re-renders, deferring detail to a companion performance skill. The approval standard is pragmatic: approve a change when it definitely improves overall code health even if imperfect, rather than blocking it because it isn't exactly how the reviewer would have written it.

When flagging structural problems, it proposes a named remedy rather than just naming the problem - replacing conditional chains with a typed dispatcher, collapsing duplicate branches, separating orchestration from business logic, moving feature-specific logic to its owning module, reusing canonical helpers, making type boundaries explicit, deleting pass-through wrappers, or extracting and splitting oversized files - preferring remedies that remove moving pieces over ones that relocate the same complexity elsewhere. Change sizing guidance targets around 100 lines as easily reviewable, around 300 as acceptable for a single logical change, and around 1000 as too large and requiring a split, watching total file size as a separate signal from diff size, with four splitting strategies and a rule that refactoring and feature work ship as separate changes. Change descriptions need a short, imperative, standalone first line plus a body explaining what and why, avoiding vague messages like generic bug-fix descriptions.

The review process itself understands context first, reviews tests before implementation to check they actually test behavior and cover edge cases, walks the five axes per changed file, categorizes every finding by severity - critical, required, nit, optional, or informational - so authors know what's mandatory, leads with the highest-leverage issues rather than burying real problems under nits, and verifies the author's own verification story. It recommends a multi-model review pattern where one model writes the code, a different model reviews for correctness and architecture, the first addresses feedback, and a human makes the final call, since different models have different blind spots. Dead code found during review is listed explicitly and confirmed with the author before removal, never silently deleted. Review speed should stay under one business day maximum, prioritizing fast individual responses over a single final approval. Disagreements resolve via a hierarchy - technical facts over opinions, style guides as absolute authority on style, engineering principles over personal preference, codebase consistency where it doesn't degrade health - and deferred cleanup is never accepted without a filed, self-assigned bug. Honesty in review means no rubber-stamping, no softening real issues, quantifying problems where possible, and pushing back on flawed approaches rather than deferring to sycophancy. Dependency review checks whether the existing stack already solves the problem, bundle impact, maintenance activity, known vulnerabilities, and license compatibility before adding anything new.

Use it before merging any PR, after completing a feature, when evaluating code produced by another agent or model, when refactoring existing code, or after any bug fix, reviewing both the fix and its regression test.

Given a diff or PR, it produces a five-axis review with severity-labeled findings, named structural remedies for flagged problems, a dead-code removal proposal pending confirmation, and an approve or request-changes verdict following a documented checklist.

Companion skills for detailed security and performance guidance, npm audit and license checks for dependency review, and support for a multi-model review workflow across different LLMs.

Teams and AI-agent workflows enforcing a consistent, no-exceptions code review gate before merge - especially useful for scrutinizing AI-generated code, which the skill explicitly treats as needing more, not less, review rigor.