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`](../../code-review/six-dimension-review.js)
(`@process specializations/collaboration/code-review/six-dimension-review`) and depended on
by [`../../github/pr-lifecycle-feature.js`](../../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:

```json
{
  "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`](../../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.