Code Review

Correctness and security gate. Report only high-conviction findings: flag issues you are certain about. Ambiguity defaults to "request changes". Structural concerns (cohesion, abstraction altitude, circular dependencies, dead code) belong to a structural review; own correctness and security here.

If the repo has automated rule-compliance checks for its stack rules (package manager, CSS framework, framework version, UI library), do not re-flag what they already cover.

Scope

• Input: one diff, branch, or PR. Gather scope with read-only git and gh commands.
• Output: a findings list bucketed into Block Merge / Request Changes / Approve, each with file, line, and a one-sentence rationale, plus a separate Spec report.
• Read-only: this skill reports. It does not edit files, open PRs, mutate anything, or deploy. All output is advisory; no confirmation is needed.
• Boundaries: for an individual diff or PR only. Do not re-litigate structural axes (module cohesion, abstraction altitude, circular dependencies, dead-code introduction, API surface sprawl, architecture fit); hand those to a structural review. Surface obvious security issues in the diff but do not attempt a full audit (OWASP rubric, dependency CVEs, timing attacks, privilege escalation paths); hand that to a dedicated security audit. If a finding is about module depth or seam placement, recommend a codebase-design review. Never infer a merge or queue-drain action from a review request.

Two axes

The checklist below is the Standards axis (correctness, security, repo hygiene). Run a Spec axis alongside it so a change that follows every standard but implements the wrong thing cannot hide, and a change that matches the issue but breaks conventions cannot hide.

• Follows every standard but implements the wrong thing: Standards pass, Spec fail.
• Does exactly what the issue asked but breaks project conventions: Spec pass, Standards fail.