Code Review

The Review Gap

Many code reviews get stuck on naming, formatting, and line-level style, while missing the issues that actually cause production incidents: business logic drift, missing exception compensation, broken state machines, and concurrency or transaction hazards. This skill focuses Git branch changes on three priorities: consistency between implementation and design, correctness and simplicity of logic, and core architecture and concurrency safety. It first reads requirements or design documents from ./review/, then compares changed files against origin/master...HEAD, so the review does not rely only on diff fragments.

How It Works

The workflow includes:
- Environment check: run git fetch origin master --depth=1, git branch --show-current, and git --no-pager diff --name-status origin/master...HEAD to identify the current branch and changed files; when more than 20 files change, it suggests prioritizing core business paths.
- Context loading: scan ./review/ for .md, .docx, and other design documents; use docx-reader or read_docx.py to extract text and images from .docx files, helping clarify flows, state machines, and constraints.
- Deep review: read full method context for complex changes, cross-check whether code matches design documents, whether exception branches are complete, and whether overly complex logic can be simplified.
- Report output: write ./review/review_[branch].md, replacing / in branch names with _; the report covers business summary, risk assessment, core hazards, logic simplification, positive findings, and open questions.

Scope and Caveats

It works best for business code with clear requirements, high-level design, or state machine notes. If no documents are present, the skill should mark the result as code-only inference, which lowers confidence. It deliberately de-emphasizes formatting, naming, and comment style. For changes that depend heavily on runtime environment, external systems, or legacy constraints, tests and operational context are still required.