From lattice
Guides structured conversations to define repository architecture principles in clean (default), hexagonal/ports & adapters, modular monolith, or custom styles. Produces formal architecture.md document for project standards.
npx claudepluginhub techygarg/lattice --plugin latticeThis skill uses the workspace's default tool permissions.
Before anything else, ask the user which architecture style their team uses:
Guides system design, architecture reviews, ADR creation, hexagonal compliance, Mermaid/PlantUML diagram generation, and layer dependency enforcement.
Initializes new projects with architecture-aware setup: researches best practices online, selects from 14 paradigms, customizes templates, creates ADRs. For uncertain architecture choices.
Advises on architecture for new features, modules, refactoring, or system boundaries by asking questions, surfacing trade-offs, and presenting options. Does not execute.
Share bugs, ideas, or general feedback.
Before anything else, ask the user which architecture style their team uses:
"What architecture style does your team use?
Branching:
./assets/template-clean-arch.md. Output: .lattice/standards/architecture.md. Config key: paths.architecture. No architecture_mode key needed (defaults to clean)../assets/template-generic.md. Output: .lattice/standards/architecture.md. Config key: paths.architecture. Additionally, set architecture_mode: custom in .lattice/config.yaml.The rest of this document describes the clean architecture flow (Option 1). For the generic flow (Options 2–4), read ./assets/template-generic.md and follow its <!-- INTERVIEW GUIDANCE: --> comments. The facilitation approach, conversation style, output assembly, and document quality checks below apply to both flows — substitute the appropriate template, output path, and config key.
For clean architecture (Option 1):
.lattice/standards/architecture.md (or custom path from .lattice/config.yaml → paths.architecture)mode: overlay): A slim document containing only sections that differ from the defaults. The architecture atom reads its embedded clean-architecture defaults first, then applies this document's sections on top. This is the expected common case.mode: override): A comprehensive standalone document that fully replaces the atom's embedded defaults. For teams that want to define clean architecture from scratch.paths.architecture in .lattice/config.yaml./assets/template-clean-arch.md for the full document structure, default content, and interview guidance commentsFor other styles (Options 2–4):
.lattice/standards/architecture.md (or custom path from .lattice/config.yaml → paths.architecture)override — there are no embedded defaults to overlay onto for non-clean-architecture stylespaths.architecture in .lattice/config.yamlarchitecture_mode: custom in .lattice/config.yaml./assets/template-generic.md for the document structure and interview guidance commentsBefore starting the interview, check whether a custom document already exists:
.lattice/config.yaml — check paths.architecture.Look for signals that inform the conversation:
src/ (or equivalent) already have layers? What are they named?Share relevant findings with the user at the start: "I noticed your project already has [X structure]. I'll use that as context."
If the project is new with no code, proceed with pure defaults as the starting point.
The first decision in the conversation. Present the three options:
"How would you like to define your architecture principles?
The defaults cover standard clean architecture well. Option 1 is recommended unless your architecture is fundamentally different."
Map the choice:
mode: overlaymode: overrideThis should be fast. Many sections will be "keep as-is."
This is thorough. Every section gets attention and appears in the output.
Read ./assets/template-clean-arch.md (for clean architecture) or ./assets/template-generic.md (for other styles) and follow the <!-- INTERVIEW GUIDANCE: --> comments for each section. Those comments contain the specific questions to ask, probing questions, and what is customizable vs fixed.
Decisions in early sections affect later sections. When a user changes an early section, flag the dependent sections:
| Decision in | Affects | How |
|---|---|---|
| §1 — Layer names | All sections | Names must be consistent everywhere |
| §1 — Extra layers | §2 (diagram), §3 (per-layer rules) | New layers need dependency placement and rules |
| §3.2 — Service pattern (unified vs CQRS) | §4.1, §4.2 | CQRS uses separate handlers instead of unified service |
| §3.4 — Provider pattern (yes/no) | §4.2, §4.3, §6 | No Provider → reads go through Repository; comparison table and checklist change |
When a dependency is triggered, inform the user: "Since you changed [X], we should also review [Y] — it's affected by that decision."
For each of the 6 default sections:
For each of the 6 default sections:
mode: overlayclean-architecture-defaults.md exactly (the atom matches sections by heading)mode: overrideStrip all <!-- INTERVIEW GUIDANCE: --> comments from the output. The final document is a clean specification.
Determine output path:
.lattice/config.yaml exists and has paths.architecture, use that path..lattice/standards/architecture.md.This is the same for all styles — both clean architecture customizations and other styles write to paths.architecture.
Write the document:
.lattice/standards/ directory (and .lattice/ parent) if it does not exist.Update config:
For clean architecture (Option 1):
.lattice/config.yaml does not exist, create it with:
paths:
architecture: .lattice/standards/architecture.md
.lattice/config.yaml exists but has no paths.architecture, add the key. Preserve all existing content..lattice/config.yaml exists and already has the key, no config change needed.For other styles (Options 2–4):
.lattice/config.yaml does not exist, create it with:
paths:
architecture: .lattice/standards/architecture.md
architecture_mode: custom
.lattice/config.yaml exists, add or update:
paths.architecture pointing to the output patharchitecture_mode: customConfirm to user:
For clean architecture:
"Your architecture document has been written to [PATH] in [overlay|override] mode. The architecture atom will now use it [on top of the clean-architecture defaults | instead of the clean-architecture defaults]."
For other styles:
"Your architecture document has been written to [PATH] with architecture_mode: custom. The architecture atom will use it as your project's sole architecture standard."
Before writing the final document, verify:
defaults.md exactly (for section matching by the atom)<!-- INTERVIEW GUIDANCE: --> comments remainmode: overlay<!-- INTERVIEW GUIDANCE: --> comments remainmode: overridemode: override in frontmatter<!-- INTERVIEW GUIDANCE: --> comments remainarchitecture_mode: custom set.lattice/config.yaml) is correctly updated