Strict Code Review

Problem

Many code reviews stop at visible syntax issues and miss requirement fit, boundary conditions, transaction consistency, unsafe defaults, and test coverage. code-review treats the review as a bounded diff analysis of a branch or workspace, aiming for an engineering decision with evidence, not style suggestions.

Workflow

The skill first asks for a PRD, issue, acceptance criteria, or short business goal. If none exists, it marks the review as limited. It then selects origin/master...HEAD when available, otherwise master...HEAD, and records the base in the report. Coverage is built per file and per hunk. Major checks include:

• Correctness: business meaning, null handling, type conversion, precision, timezone, idempotency.
• Reliability: transactions, retries, concurrency, partial batch failures.
• Security: authentication, authorization, injection, path traversal, unsafe deserialization, sensitive logs.
• Data: migration compatibility, duplicate data, rollback risk.
• Performance: N+1 queries, unbounded loops, large object loading, blocking calls.
• Tests: happy paths, error paths, edge cases, regressions.

It produces code-review-report-YYYYMMDD-HHmm.md, classifies findings as Critical, Major, Minor, or Suggestion, and summarizes highest-risk issues, verification status, and merge recommendation.

Boundaries

It does not edit product code unless explicitly asked. If local commands are unsafe, tests cannot run, or the diff is too large for reliable context, the report must note limited verification. Privacy rules require redacting secrets, internal endpoints, customer identifiers, and absolute paths.