code-review

这段内容是审核时保存的快照。外部来源才是完整且最新的版本。

---
name: code-review
description: >-
  Three-stage code review protocol covering spec compliance, code quality, and
  domain integrity. Use this skill whenever the user asks to review code,
  prepare or check a PR, assess implementation quality, verify code against a
  spec or acceptance criteria, or audit for security and domain modeling issues.
  Triggers on: "review this code", "review my PR", "check implementation
  against spec", "code quality audit", "does this match the requirements",
  "review for security issues", "check for primitive obsession", "monetary
  precision review", "review test coverage gaps". Also activates when the user
  wants structured PASS/FAIL verdicts per requirement, severity-rated findings,
  or a gated review that blocks on critical issues. NOT for: style/formatting
  linting, debugging runtime errors, writing new code, or automated CI checks.
license: CC0-1.0
compatibility: Designed for any coding agent (Claude Code, Codex, Cursor, OpenCode, etc.)
metadata:
  author: jwilger
  version: "2.2.0"
  requires: [domain-modeling]
  context: [source-files, test-files, domain-types, git-history]
  phase: ship
  standalone: true
  constraint_resolution: true
effort: high
---

# Code Review

**Value:** Feedback and communication -- structured review catches defects that
the author cannot see, and separating review into stages prevents thoroughness
in one area from crowding out another.

## Purpose

Teaches a systematic three-stage code review that evaluates spec compliance,
code quality, and domain integrity as separate passes. Prevents combined
reviews from letting issues slip through by ensuring each dimension gets
focused attention.

## Practices

### Three Stages, In Order

Review code in three sequential stages. Do not combine them. Each stage has a
single focus. A failure in an earlier stage blocks later stages -- there is no
point reviewing code quality on code that does not meet the spec.

**Stage 1: Spec Compliance.** Does the code do what was asked? Not more, not
less.

For each acceptance criterion or requirement:

1. Find the code that implements it
2. Find the test that verifies it
3. Confirm the implementation matches the spec exactly

Mark each criterion: PASS, FAIL (missing/incomplete/divergent), or CONCERN
(implemented but potentially incorrect). Flag anything built beyond
requirements as OVER-BUILT.

If any criterion is FAIL, stop. Return to implementation before continuing.

**Architecture Compliance Check** (run after the per-criterion loop, before
moving to Stage 2):

- If `docs/ARCHITECTURE.md` exists: verify this change complies with all
  documented constraints and patterns (Components, Patterns, Constraints
  sections). Non-compliance is a FAIL — same severity as a missing acceptance
  criterion.
- If `docs/ARCHITECTURE.md` does not exist: flag as a Stage 2 CONCERN:
  "No architecture document found; architectural compliance cannot be verified."

Include in Stage 1 output: `Architecture Compliance: PASS / FAIL / N/A (no ARCHITECTURE.md)`

### Vertical Slice Layer Coverage

For tasks that implement a vertical slice (adding user-observable behavior), perform the following checks in order:

1. **Entry-point wiring check (diff-based):** Examine whether the changeset includes modifications to the application's entry point or its wiring/routing layer. If the slice claims to add new user-observable behavior but the diff does not touch any wiring or entry-point code, the review **fails** unless the author explicitly documents why existing wiring already routes to the new behavior.

2. **End-to-end traceability:** Verify that a path can be traced from the application's external entry point, through any infrastructure or integration layer, to the new domain logic, and back to observable output. If any segment of this path is missing from the changeset and not already present in the codebase, flag the gap.

3. **Boundary-level test coverage:** Confirm that at least one test exercises the ne