architecture
This Claude Code skill enforces architectural rules during code generation and modification by loading either clean architecture defaults or custom team-defined standards from configuration files. Use it when generating code, reviewing architecture, creating new files, or when users reference architecture topics like layers, dependencies, hexagonal or onion architecture, ensuring generated code complies with layer responsibilities, dependency direction, and structural constraints through automated validation checklists.
git clone --depth 1 https://github.com/techygarg/lattice /tmp/architecture && cp -r /tmp/architecture/skills/atoms/architecture ~/.claude/skills/architectureSKILL.md
# Architecture
## Config Resolution
Skill support two mode: **clean architecture** (default) and **custom architecture** (team-define). Mode determine which rule load.
**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 custom doc
2. If found, read doc and check YAML frontmatter for `mode`:
- **`mode: overlay`**: Read `./references/clean-architecture-defaults.md` first, then apply custom doc section on top. Section match by heading — custom section replace matching default, new section append.
- **`mode: override`**: Custom doc take full precedence. Must be comprehensive.
3. If no custom doc → 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` exist in config, read **"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 generate each component. Read **Self-Validation Checklist** and **Anti-Pattern Scan** from loaded enforce rule (clean-architecture.md or custom-architecture.md) and apply.
**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. These are team-customized checks produced by the architecture-refiner.Audit and fix all Lattice documentation, README, docs/, GitHub issue templates, and CLAUDE.md to ensure they are fully aligned with the current skill inventory. Documentation drift is the most common source of user confusion in Lattice — a skill exists in the codebase but not in the docs, or a renamed skill leaves a stale reference in the bug report template. If you've made any change to skills/ and haven't run this, run it now. Use when the user says 'align docs', 'audit docs', 'update documentation', 'skill align', 'check docs are in sync', 'audit skill inventory', 'ensure docs are aligned', 'are the docs up to date', or 'what needs updating'. Standalone — does not call other skills.
Create a new Lattice skill — atom, molecule, or refiner — following all framework conventions. Writing skill files manually almost always produces convention violations: wrong section order, missing confirmation gates, defaults.md without the right structure. This skill knows all of that and guides you through it. Use whenever adding any new atom, molecule, or refiner to Lattice, or when the user says 'create a new skill', 'add an atom', 'add a molecule', 'add a refiner', 'build X for Lattice', 'new lattice skill', or 'skill forge'. Does not validate, align docs, or deploy — those are separate skills you run after.
Deep behavioral audit of a Lattice skill — proposes 3 review personas relevant to the skill, runs independent scenario analysis from each persona's perspective, then merges only the high-confidence, practical findings into a severity-ordered gap report with proposed fixes. Structural validation (conventions, cross-references) is skill-validate's job — this skill finds gaps that would realistically surface when someone actually uses the skill: missing scenario handling, ambiguous instructions, silent failure cases, and behavioral inconsistencies. Filters out theoretical edge cases, low-likelihood speculation, and findings owned by other skills. Use after writing or significantly changing any skill, or when the user says 'review this skill', 'deep review', 'does this skill work', 'find gaps in this skill', 'stress test this skill', 'review from different angles', or 'skill review'. Standalone — does not call other skills.
Validate any Lattice SKILL.md against all tier conventions — atoms, molecules, and refiners. Catches structural errors, broken cross-references, and convention violations before they reach the repo. If you just wrote or modified a Lattice skill file and haven't run this yet, run it now — manual review consistently misses the same categories of errors this skill is specifically designed to catch. Use when the user says 'validate this skill', 'check this skill', 'does this follow conventions', 'review this skill file', 'check my SKILL.md', or 'skill validate'. Reports PASS/FAIL with specific file-and-section findings and actionable fixes. Standalone — does not call other skills.
Architectural thinking partner for an existing repository — scans the codebase, conducts a structured interview, agrees on current architectural state and recommended direction, and produces a shareable insights document. Scoped to one repository, module, or folder. Does not execute transformation — it orients. Use when the user says 'assess my codebase architecture', 'what direction should my codebase go', 'architecture compass', 'understand my architecture', 'audit architecture drift', 'architectural assessment', or 'help me understand what is wrong with my codebase'.
Facilitate a structured conversation to define architecture principles for a repository. Supports multiple architecture styles: clean architecture (default), hexagonal / ports & adapters, modular monolith, or custom. Produces a formal architecture document that the corresponding atom will use. Use when setting up a new project, defining architecture standards, or when the user says 'setup architecture', 'define layers', 'architecture principles', 'help me define my architecture', 'hexagonal architecture', 'modular monolith', 'ports and adapters', or 'define my architecture style'.
Investigate, reproduce, and safely fix a bug with regression protection. Composes context, diagnosis, architecture, code quality, and testing guardrails into a reproduce-first repair workflow. Use when the user says 'fix this bug', 'debug this', 'investigate this failure', 'patch this regression', 'repair this issue', or 'why is this broken'.
Facilitate a structured conversation to define clean code principles for a repository. Produces a formal clean-code.md document that the clean-code atom will use as its override. Use when setting up coding standards, defining code quality rules, or when the user says 'setup clean code', 'define coding standards', 'code quality principles', 'coding guidelines', or 'help me define my code standards'.