/review

name: review
description: "Perform a structured code review by composing validation checklists from relevant atoms based on what code changed. Loads atoms conditionally -- clean-code always, architecture/DDD/security/tests only when the delta touches their domain. Produces a severity-ordered report with specific locations and fixes. Use when the user asks to 'review this', 'code review', 'quality check', 'validate the code', 'check my code', 'review the delta', or 'review this PR'."

Review

Required Skills

Load/apply skills based on scope (see Step 2 for conditional loading):

1. `framework:knowledge-priming` -- Load project context (tech stack, architecture, conventions) to evaluate against real standards (always loaded) 2. `framework:learning-harvest` -- Load prior operational learnings inform review; harvest new patterns at session end (always) 3. `framework:collaborative-judgment` -- Surface borderline findings with both interpretations instead of silently classifying (always loaded) 4. `framework:clean-code` -- Code craft: SRP, naming, complexity, error handling (always loaded) 5. `framework:architecture` -- Structural: layer rules, dependency direction, architectural flows (conditional) 6. `framework:domain-driven-design` -- Domain modeling: aggregates, entities, value objects (conditional) 7. `framework:secure-coding` -- Security: trust boundaries, injection, secrets, input handling (conditional) 8. `framework:test-quality` -- Test: AAA structure, isolation, assertions, naming (conditional)

Config Resolution

Review molecule supports optional config thru review-standards doc from review-refiner (or hand-written). Configures review *process* — not what atoms check (that's atom-level config via atom refiners).

**Resolution steps:**

1. Look for `.lattice/config.yaml` in repo root. 2. Check for config key `paths.review_standards`. 3. If doc exists at path, read & check YAML frontmatter for `mode`:

• **`mode: overlay`**: Read embedded defaults first, then apply doc's sections on top. Sections matched by heading — custom replaces matching defaults, new appended.
• **`mode: override`** (or no mode): Custom doc full precedence. Must be comprehensive.

4. If no config or no review-standards doc found, use embedded defaults thruout workflow (full backward compat — identical to review with no config).

Review-standards doc has 7 sections map to workflow steps:

| Section | Affects step | |---------|-------------| | §1 Atom Loading Policy | Step 2 (Load Relevant Atoms) | | §2 Severity Classification | Step 4 (Produce Report) | | §3 Report Preferences | Step 4 (Produce Report) | | §4 Scope Rules | Step 1 (Identify the Delta) | | §5 Insight Capture Preferences | Step 5 (Harvest Learnings and Log Review) | | §6 Health Log Preferences | Step 5 (Harvest Learnings and Log Review) | | §7 Custom Review Dimensions | Step 3 (Run Targeted Validation) |

Each step notes where config applies with "**Config override**" callouts.

Workflow

Step 1: Identify the Delta

Use `framework:learning-harvest` Load behavior. Focus hint: "review session — focus: all categories".

Determine what code reviewing & establish scope.

• **PR or commit**: Use `git diff` for changed files/lines. Delta is changes, not entire codebase.
• **Set of files**: User specifies files. Delta is those files.
• **Feature or module**: User points to feature. Identify relevant files from codebase.

Classify delta:

1. **Which architectural layers touched?** (per loaded architecture rules) -- determines if `architecture` loads. 2. **Is domain code included?** (files in configured `domain_folder` or containing aggregates, entities, value objects) -- determines if `domain-driven-design` loads. 3. **Security-sensitive areas touched?** (auth, authz, input handling, DB queries, external API calls, file I/O, config, secrets) -- determines if `secure-coding` loads. 4. **Test files included?** -- determines if `test-quality` loads.

**Config override (§4 Scope Rules):** If review-standards doc defines scope rules, apply after identifying delta:

• **Directory exclusions**: Remove files matching exclusion patterns from delta before classification.
• **Directory inclusions (always-full-scan)**: When delta touches file in always-full-scan dir, expand delta to include all files in that dir.
• **Surrounding-code policy**: Use configured policy (strict/default/expansive) instead of default.
• **Dependency expansion**: If enabled, also include files that directly import from changed files.

Step 2: Load Relevant Atoms

**Always load**: `framework:clean-code` -- applies to all code regardless of layer/purpose.

**Conditionally load** based on delta classification:

| Condition | Load | |-----------|------| | Delta touches multiple layers, adds new files, or changes file locations | `framework:architecture` | | Delta includes files in domain folder or modifies domain objects | `framework:domain-driven-design` | | Delta touches trust boundaries (HTTP handlers, auth, DB queries, external APIs, secrets, config) | `framework:secure-coding` | | Delta includes test files | `framework:test-quality` |

When multiple atoms load, run independently -- each atom's checklist applied to parts of delta relevant to it. Findings from different atoms merged Step 4.

**Config override (§1 Atom Loading Policy):** If review-standards doc defines atom loading rules, apply instead of (override) or on top of (overlay) table above:

• **Always-load overrides**: Additional atoms moved to always-load (e.g., `secure-coding` every review). `clean-code` and `knowledge-priming` must remain always-loaded regardless of config.
• **Suppressed atoms**: Atoms listed as suppressed never loaded, even if delta matches trigger condition.
• **Custom path-based triggers**: If delta includes files matching custom path pattern, load associated atom regardless of standard conditions.
• **Modified conditions**: Replacement trigger conditions for conditional atoms.

###