six-dimension-code-review

name	six-dimension-code-review
description	Structured pull-request review across six fixed dimensions — correctness, clarity, consistency, coverage, complexity, and change-scope — producing a per-dimension verdict plus severity-tagged findings. Use when reviewing a PR diff or running the collaboration PR lifecycles.
allowed-tools	["Read","Glob","Grep"]
graph	{"domains":["domain:software-engineering"],"specializations":["specialization:collaboration"],"skillAreas":["skill-area:code-review-practice"],"roles":["role:tech-lead","role:backend-engineer"],"workflows":["workflow:pull-request-lifecycle"]}

Six-Dimension Code Review

The rubric hardcoded as the DIMENSIONS array in ../../code-review/six-dimension-review.js (@process specializations/collaboration/code-review/six-dimension-review) and depended on by ../../github/pr-lifecycle-feature.js. Each dimension is reviewed independently and in parallel; one lens per pass.

The six dimensions

• correctness — Does the code do what the PR claims? Any logical bugs, off-by-one, race conditions, null/undef hazards, error-path gaps?
• clarity — Is intent obvious from the code? Names, structure, comments where non-obvious. Flag cleverness that sacrifices readability.
• consistency — Does the change match existing patterns, conventions, and architectural boundaries in the repo?
• coverage — Are there tests for the new behavior? Do existing tests still exercise the right paths? Any coverage gaps for edge cases?
• complexity — Is the solution as simple as it can be? Any over-engineering, premature abstraction, unused flexibility?
• change-scope — Is the PR focused on one concern? Any drive-by edits, mixed refactor+feature, or churn that belongs in a separate PR?

Output shape

Each dimension pass returns:

{
  "findings": [
    {
      "severity": "block",
      "path": "src/example.ts",
      "line": 42,
      "detail": "…",
      "suggestion": "…"
    }
  ],
  "summary": "string"
}

severity is one of block, nit, or info. The process aggregates the six passes into a per-dimension verdict map plus two flattened lists — blockingFindings (every block finding, tagged with its dimension) and nits (every nit finding, likewise tagged) — and a joined summary. The review succeeds only when blockingFindings is empty.

Related

../../code-review/validator.js uses a different, broader dimension set — quality, architecture, tests, security, ux, business — and materialises non-blocking findings as deferred debt on disk. This skill documents the six-dimension rubric only; the two are not interchangeable.