# Critique

> Review backend architecture for SOLID violations, coupling issues, and dependency direction problems. Use when evaluating structural design decisions or preparing for refactoring. Triggers: 'review architecture', 'check SOLID', 'critique code', or /axiom:critique. Do NOT use for error handling — use axiom:harden instead.

- Skill: `lvlup-sw/critique` (Agent Skill, multi-file: 4 files)
- Install (CLI): `npx skillmds@latest add lvlup-sw/critique`
- Raw SKILL.md: https://api.skillmd.com/api/skills/lvlup-sw/critique/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: lvlup-sw (https://skillmd.com/u/lvlup-sw)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/lvlup-sw/critique

---


# Critique Skill — Architecture Review

## Overview

Architecture review skill covering two quality dimensions:

- **DIM-6 (Architecture):** SOLID principles adherence, module boundaries, responsibility allocation
- **DIM-1 (Topology):** Dependency graph health, coupling metrics, layering discipline

Use this skill to evaluate structural design decisions, identify architectural drift, or prepare a codebase for refactoring. It combines deterministic scanning (via `axiom:scan`) with qualitative agent assessment to produce actionable findings.

## Triggers

### Positive Triggers

Activate this skill when:
- User says "review architecture" or "architecture review"
- User says "check SOLID" or "SOLID violations"
- User says "critique code" or "critique this module"
- User runs `/axiom:critique`
- User asks about coupling, dependency direction, or module boundaries
- Preparing for a major refactoring effort

### Negative Triggers

Do NOT activate this skill when:
- User wants error handling review — use `axiom:harden` instead
- User wants test quality review — use `axiom:verify` instead
- User wants performance review — performance profiling is out of scope for axiom
- User wants a general code review — use `axiom:scan` for a broad sweep first

## Process

### Step 1: Load Dimension Definitions

Load the relevant dimension definitions for this review:

- `@skills/backend-quality/references/dimensions.md` — Read DIM-1 (Topology) and DIM-6 (Architecture) sections for scoring criteria, signal definitions, and severity thresholds.

### Step 2: Run Deterministic Scan

Execute `axiom:scan` targeting Architecture and Topology dimensions specifically:

- Collects measurable signals: file sizes, parameter counts, import depth, circular references
- Establishes a baseline of deterministic findings before qualitative assessment
- Each automated finding sets `skill: "scan"` and `deterministic: true`

### Step 3: Layer Qualitative Assessment

On top of the scan baseline, perform agent-driven qualitative evaluation across five areas:

#### 3a. SOLID Evaluation

Assess adherence to each SOLID principle. For definitions, violation signals, and severity guidance, see `@skills/critique/references/solid-principles.md`.

- **Single Responsibility Principle (SRP):** Does each module/class have one reason to change?
- **Open/Closed Principle (OCP):** Are modules open for extension but closed for modification?
- **Liskov Substitution Principle (LSP):** Can subtypes replace their base types without breaking behavior?
- **Interface Segregation Principle (ISP):** Are interfaces focused, or do clients depend on methods they do not use?
- **Dependency Inversion Principle (DIP):** Do high-level modules depend on abstractions, not concretions?

#### 3b. Coupling Analysis

Measure and evaluate module coupling:

- **Afferent coupling (Ca):** How many modules depend on this module?
- **Efferent coupling (Ce):** How many modules does this module depend on?
- **Instability (I = Ce / (Ca + Ce)):** Is the module stable (depended-upon) or unstable (depends-on-others)?
- Flag modules with high instability that are also heavily depended-upon (unstable foundation)
- For detailed coupling metrics and patterns, see `@skills/critique/references/dependency-patterns.md`

#### 3c. Dependency Direction

Evaluate whether dependencies point in the correct direction:

- Dependencies should flow inward: infrastructure depends on domain, not the reverse
- Core/domain modules should never import from infrastructure, framework, or I/O layers
- Check for proper use of dependency inversion — abstractions at boundaries
- See `@skills/critique/references/dependency-patterns.md` for healthy vs unhealthy patterns

#### 3d. God Object Detection

Identify modules with too many responsibilities:

- Modules handling more than 3 distinct concerns
- Files exceeding complexity thresholds (lines, function count, branching depth)
- Classes or modules that are modified in every feature branch (shotgun surgery indicator)
- Modules that import from many unrelated domains

#### 3e. Readability Patterns

Evaluate code-level readability and structural clarity:

- **DRY violations:** Duplicated logic across multiple locations that should be extracted
- **Deep nesting:** Functions with excessive indentation that could use guard clauses / early returns
- **Composition over inheritance:** Class hierarchies that would be simpler as composed components
- **Parameter discipline:** Long parameter lists and boolean flags that obscure call-site meaning
- For definitions, violation signals, and refactoring approaches, see `@skills/critique/references/readability-patterns.md`

#### 3f. Circular Dependency Identification

Detect import cycles between modules:

- Direct circular imports (A imports B, B imports A)
- Transitive cycles (A -> B -> C -> A)
- Barrel-file-mediated cycles (index.ts re-exports creating hidden loops)
- See `@skills/critique/references/dependency-patterns.md` for detection approach and remediation

### Step 4: Output Findings

Format all findings per `@skills/backend-quality/references/findings-format.md`:

- Each finding includes: dimension, severity, title, evidence, explanation, suggestion (optional), skill, deterministic
- Scan findings use `deterministic: true`; qualitative findings use `deterministic: false`
- Grouped by dimension (Architecture, then Topology), sorted by severity within each group
- Include an executive summary with finding counts by severity

## Error Handling

- **Empty scope:** If the target scope contains no analyzable files (e.g., empty directory, only config files), return an informative message: "No backend source files found in the specified scope. Verify the path and ensure it contains TypeScript/JavaScript source files."
- **Scope validation:** Before analysis, validate that the provided path exists and contains source files. If the path does not exist, report the error immediately rather than producing empty results.
- **Partial failures:** If the deterministic scan fails on a subset of checks, continue with available results and note which checks were skipped in the output.

## References

- `@skills/backend-quality/references/dimensions.md` — Dimension definitions for DIM-1 and DIM-6
- `@skills/backend-quality/references/findings-format.md` — Standard output format for findings
- `@skills/critique/references/solid-principles.md` — SOLID principle definitions, violation signals, severity guide, and detection heuristics
- `@skills/critique/references/dependency-patterns.md` — Dependency pattern catalog, coupling metrics, circular dependency detection, and layered architecture guidance
- `@skills/critique/references/readability-patterns.md` — DRY, early returns, composition over inheritance, and parameter discipline