code-review
Code Review
Concept of the skill
A code review is a pre-merge risk assessment over a proposed change. Its primitives are intent, diff, test evidence, implementation behavior, public-contract blast radius, project conventions, tool findings, reviewer qualifications, severity, and the final merge decision.
Concept of the Skill
What it is: Code review is the discipline of evaluating a proposed code change before it becomes shared code. It checks whether the diff matches the stated intent, has meaningful test evidence, preserves contracts, fits the surrounding system, and carries an explicit merge decision.
Mental model: A review has ten moving parts — the author's intent, the changed files, the tests, the implementation, the call sites, the blast radius, the project rules, tool output, reviewer qualification, and the final verdict. Every comment should tie back to one of those parts.
Why it exists: Modern PRs increasingly include generated code, automated summaries, and AI reviewer comments. Those tools can improve coverage, but they also create automation bias. This skill keeps the agent acting as an accountable reviewer: inspect evidence, verify claims, grade severity, and decide.
What it is NOT: It is not implementing the fix, debugging a failure that already shipped, designing a test strategy before the diff exists, doing a security-only deep audit, or explaining a raw patch without an approve/request-changes/close decision.
One-line analogy: A code review is an airlock — the change can pass through only after its purpose, evidence, and blast radius are checked against the environment it is entering.
Common misconception: Green CI does not mean the change is safe. CI answers whether configured checks passed; code review asks whether the right thing is being changed, whether the checks are meaningful, and whether untested risk remains acceptable.