---
name: Architecture
slug: architecture-4
category: Quality
description: Architecture enforces architectural rules when generating or reviewing code, and checks proposed designs against loaded architecture standards. It validates layer responsibilities, dependency direction, and structural constraints for clean, hexagonal, modular monolith, or custom architectures.
github: "https://github.com/techygarg/lattice/tree/main/skills/architecture"
language: Shell
stars: 185
forks: 13
install: "npx degit https://github.com/techygarg/lattice/tree/main/skills/architecture ~/.claude/skills/architecture"
installs_to: ~/.claude/skills/architecture
source_path: skills/architecture/SKILL.md
collection_size: 25
category_size: 1745
collection_url: "https://dirskills.com/collections/techygarg/lattice"
added: 2026-09-06T05:20:41.507Z
last_synced: 2026-09-06T05:20:41.507Z
canonical_url: "https://dirskills.com/skills/architecture-4"
---

# Architecture

Architecture enforces architectural rules when generating or reviewing code, and checks proposed designs against loaded architecture standards. It validates layer responsibilities, dependency direction, and structural constraints for clean, hexagonal, modular monolith, or custom architectures.

**Install:**

```bash
npx degit https://github.com/techygarg/lattice/tree/main/skills/architecture ~/.claude/skills/architecture
```

## README

# Architecture

## Config Resolution

**Step 1 — Determine mode:**

1. Read `.lattice/config.yaml` in repo root
2. Check `architecture_mode` key
   - If `architecture_mode: custom` → **custom mode**
   - If absent, or other value → **clean architecture mode** (default)

**Step 2 — Load enforce rule:**

- **Clean architecture mode** → Read `./references/clean-architecture.md` for enforce instruction (Self-Validation Checklist, Anti-Pattern Scan, Ambiguity Signals, structural principles)
- **Custom mode** → Read `./references/custom-architecture.md` for enforce instruction

**Step 3 — Load architecture content:**

- **Clean architecture mode:**
  1. Check `paths.architecture` in `.lattice/config.yaml` for a custom document path.
  2. If a document exists at that path → read it and check its YAML frontmatter for `mode`:
     - **`mode: overlay`** (or no mode field): read `./references/clean-architecture-defaults.md` first, then apply the custom document's sections on top. Sections match by exact heading — a custom section replaces the matching default; new sections append after the defaults.
     - **`mode: override`**: the custom document takes full precedence. It must be comprehensive.
  3. If the path is configured but no document exists at it → tell the user which configured path is missing, then read `./references/clean-architecture-defaults.md`.
  4. If there is no configured path → read `./references/clean-architecture-defaults.md`.

- **Custom mode:**
  1. Check `paths.architecture` in `.lattice/config.yaml` for team architecture doc
  2. If found → read it. Sole reference — no default.
  3. If not found → surface: "No architecture document found. Run `/architecture-refiner` and select your architecture style to define your team's standards."

**Step 4 — Language adaptation:**

If `paths.language_idioms` is set in the config and the document exists, read its **"Dependency Management"** section and adapt dependency direction enforcement to language idioms (e.g., Go interface-at-consumer, Java DI containers, Rust trait bounds). Language idioms take precedence over pseudocode defaults.

## Enforcement

**STOP after generating each component.** Read the **Self-Validation Checklist** and **Anti-Pattern Scan** from the loaded enforce rule (clean-architecture.md or custom-architecture.md) and apply them.

**Project-specific checks:** If architecture content doc (loaded in Step 3) contains a **Validation Checklist** section (§6), apply those checks as additional project-specific validation after the enforce rule checklist.

## Design Mode

When invoked during design — no code is being written; a planning molecule is validating a proposed design artifact — apply the same enforce rule as a forward-looking check:

1. Take the proposed artifact (component list, layer assignment, data flow, or contract set) as the unit of validation.
2. Evaluate it against the **Self-Validation Checklist** and **Anti-Pattern Scan** from the loaded enforce rule, plus the project-specific Validation Checklist if present — before the artifact is presented for user approval.
3. Report violations as concrete findings on the artifact ("Component X reaches from layer A to layer C, skipping B"), not generic advice. Resolve them through the design.
4. **STOP:** do not skip checklist evaluation on the grounds that no code exists yet — the proposed structure is what gets validated.