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.
1---2name: six-dimension-code-review3description: 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.4---5
6# Six-Dimension Code Review
7
8The rubric hardcoded as the `DIMENSIONS` array in
9[`../../code-review/six-dimension-review.js`](../../code-review/six-dimension-review.js)
10(`@process specializations/collaboration/code-review/six-dimension-review`) and depended on
11by [`../../github/pr-lifecycle-feature.js`](../../github/pr-lifecycle-feature.js). Each
12dimension is reviewed independently and in parallel; one lens per pass.
13
14## The six dimensions
15
16- **correctness** — Does the code do what the PR claims? Any logical bugs, off-by-one,
17 race conditions, null/undef hazards, error-path gaps?
18- **clarity** — Is intent obvious from the code? Names, structure, comments where
19 non-obvious. Flag cleverness that sacrifices readability.
20- **consistency** — Does the change match existing patterns, conventions, and
21 architectural boundaries in the repo?
22- **coverage** — Are there tests for the new behavior? Do existing tests still exercise
23 the right paths? Any coverage gaps for edge cases?
24- **complexity** — Is the solution as simple as it can be? Any over-engineering,
25 premature abstraction, unused flexibility?
26- **change-scope** — Is the PR focused on one concern? Any drive-by edits, mixed
27 refactor+feature, or churn that belongs in a separate PR?
28
29## Output shape
30
31Each dimension pass returns:
32
33```json
34{
35 "findings": [
36 {
37 "severity": "block",
38 "path": "src/example.ts",
39 "line": 42,
40 "detail": "…",
41 "suggestion": "…"
42 }
43 ],
44 "summary": "string"
45}
46```
47
48`severity` is one of `block`, `nit`, or `info`. The process aggregates the six passes
49into a per-dimension verdict map plus two flattened lists — `blockingFindings` (every
50`block` finding, tagged with its dimension) and `nits` (every `nit` finding, likewise
51tagged) — and a joined `summary`. The review succeeds only when `blockingFindings` is
52empty.
53
54## Related
55
56[`../../code-review/validator.js`](../../code-review/validator.js) uses a different,
57broader dimension set — `quality`, `architecture`, `tests`, `security`, `ux`, `business` —
58and materialises non-blocking findings as deferred debt on disk. This skill documents the
59six-dimension rubric only; the two are not interchangeable.
a5c-ai