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
1---2name: critique3description: 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.4---56# Critique Skill — Architecture Review78## Overview910Architecture review skill covering two quality dimensions:1112- **DIM-6 (Architecture):** SOLID principles adherence, module boundaries, responsibility allocation13- **DIM-1 (Topology):** Dependency graph health, coupling metrics, layering discipline1415Use 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.1617## Triggers1819### Positive Triggers2021Activate this skill when:22- User says "review architecture" or "architecture review"23- User says "check SOLID" or "SOLID violations"24- User says "critique code" or "critique this module"25- User runs `/axiom:critique`26- User asks about coupling, dependency direction, or module boundaries27- Preparing for a major refactoring effort2829### Negative Triggers3031Do NOT activate this skill when:32- User wants error handling review — use `axiom:harden` instead33- User wants test quality review — use `axiom:verify` instead34- User wants performance review — performance profiling is out of scope for axiom35- User wants a general code review — use `axiom:scan` for a broad sweep first3637## Process3839### Step 1: Load Dimension Definitions4041Load the relevant dimension definitions for this review:4243- `@skills/backend-quality/references/dimensions.md` — Read DIM-1 (Topology) and DIM-6 (Architecture) sections for scoring criteria, signal definitions, and severity thresholds.4445### Step 2: Run Deterministic Scan4647Execute `axiom:scan` targeting Architecture and Topology dimensions specifically:4849- Collects measurable signals: file sizes, parameter counts, import depth, circular references50- Establishes a baseline of deterministic findings before qualitative assessment51- Each automated finding sets `skill: "scan"` and `deterministic: true`5253### Step 3: Layer Qualitative Assessment5455On top of the scan baseline, perform agent-driven qualitative evaluation across five areas:5657#### 3a. SOLID Evaluation5859Assess adherence to each SOLID principle. For definitions, violation signals, and severity guidance, see `@skills/critique/references/solid-principles.md`.6061- **Single Responsibility Principle (SRP):** Does each module/class have one reason to change?62- **Open/Closed Principle (OCP):** Are modules open for extension but closed for modification?63- **Liskov Substitution Principle (LSP):** Can subtypes replace their base types without breaking behavior?64- **Interface Segregation Principle (ISP):** Are interfaces focused, or do clients depend on methods they do not use?65- **Dependency Inversion Principle (DIP):** Do high-level modules depend on abstractions, not concretions?6667#### 3b. Coupling Analysis6869Measure and evaluate module coupling:7071- **Afferent coupling (Ca):** How many modules depend on this module?72- **Efferent coupling (Ce):** How many modules does this module depend on?73- **Instability (I = Ce / (Ca + Ce)):** Is the module stable (depended-upon) or unstable (depends-on-others)?74- Flag modules with high instability that are also heavily depended-upon (unstable foundation)75- For detailed coupling metrics and patterns, see `@skills/critique/references/dependency-patterns.md`7677#### 3c. Dependency Direction7879Evaluate whether dependencies point in the correct direction:8081- Dependencies should flow inward: infrastructure depends on domain, not the reverse82- Core/domain modules should never import from infrastructure, framework, or I/O layers83- Check for proper use of dependency inversion — abstractions at boundaries84- See `@skills/critique/references/dependency-patterns.md` for healthy vs unhealthy patterns8586#### 3d. God Object Detection8788Identify modules with too many responsibilities:8990- Modules handling more than 3 distinct concerns91- Files exceeding complexity thresholds (lines, function count, branching depth)92- Classes or modules that are modified in every feature branch (shotgun surgery indicator)93- Modules that import from many unrelated domains9495#### 3e. Readability Patterns9697Evaluate code-level readability and structural clarity:9899- **DRY violations:** Duplicated logic across multiple locations that should be extracted100- **Deep nesting:** Functions with excessive indentation that could use guard clauses / early returns101- **Composition over inheritance:** Class hierarchies that would be simpler as composed components102- **Parameter discipline:** Long parameter lists and boolean flags that obscure call-site meaning103- For definitions, violation signals, and refactoring approaches, see `@skills/critique/references/readability-patterns.md`104105#### 3f. Circular Dependency Identification106107Detect import cycles between modules:108109- Direct circular imports (A imports B, B imports A)110- Transitive cycles (A -> B -> C -> A)111- Barrel-file-mediated cycles (index.ts re-exports creating hidden loops)112- See `@skills/critique/references/dependency-patterns.md` for detection approach and remediation113114### Step 4: Output Findings115116Format all findings per `@skills/backend-quality/references/findings-format.md`:117118- Each finding includes: dimension, severity, title, evidence, explanation, suggestion (optional), skill, deterministic119- Scan findings use `deterministic: true`; qualitative findings use `deterministic: false`120- Grouped by dimension (Architecture, then Topology), sorted by severity within each group121- Include an executive summary with finding counts by severity122123## Error Handling124125- **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."126- **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.127- **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.128129## References130131- `@skills/backend-quality/references/dimensions.md` — Dimension definitions for DIM-1 and DIM-6132- `@skills/backend-quality/references/findings-format.md` — Standard output format for findings133- `@skills/critique/references/solid-principles.md` — SOLID principle definitions, violation signals, severity guide, and detection heuristics134- `@skills/critique/references/dependency-patterns.md` — Dependency pattern catalog, coupling metrics, circular dependency detection, and layered architecture guidance135- `@skills/critique/references/readability-patterns.md` — DRY, early returns, composition over inheritance, and parameter discipline