Skip to content
cccskills
FreePublished on GitHub

architecture

Enforce architectural rules when generating or modifying code, and validate proposed designs before approval (design mode). Defaults to clean architecture; supports any architecture style via the architecture-refiner. Validates layer responsibilities, dependency direction, and structural constraints using the loaded architecture rules. Use when generating code, reviewing architecture, creating new files, or when the user mentions 'architecture', 'layers', 'structure', 'dependency rules', 'hexagonal architecture', 'ports and adapters', 'modular monolith', or 'onion architecture'. Also use when reviewing generated code for structural compliance.

The English summary is being prepared. Showing the original description.

See how to install

Files included (4)

  • SKILL.md4.0 KB
  • references/clean-architecture-defaults.md15.3 KB
  • references/clean-architecture.md5.5 KB
  • references/custom-architecture.md4.6 KB

SKILL.md (original)

Review the instructions the agent will receive before you install.

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.

Reviews

No reviews yet. Tell others what you thought.

Comments

No login needed. Share how it worked for you, ask a question, or note where it did not run.

No comments yet. Be the first to write one.

Comments are published right away. Do not include personal information such as email addresses or phone numbers. Up to 2 URLs.

0 / 1,000 characters

This form is protected by reCAPTCHA, and the Google Privacy Policy and Terms of Service apply.

More skills from this repository

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'.

The English summary is being prepared. Showing the original description.

techygarg/lattice205Updated Oct 10, 2026

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'.

The English summary is being prepared. Showing the original description.

techygarg/lattice205Updated Oct 10, 2026

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'.

The English summary is being prepared. Showing the original description.

techygarg/lattice205Updated Oct 10, 2026

Apply clean code principles when generating or modifying implementation code. Enforces function focus, naming clarity, complexity management, error handling, and self-documenting style. Use when the user mentions 'clean code', 'code quality', 'coding guidelines', or 'implementation quality'. Loaded automatically by the code-generating molecules (code-forge, refactor-safely, bug-fix). This skill governs the craft of writing individual code units -- not architecture (see architecture), not security posture (see secure-coding), not test structure (see test-quality), and not refactoring workflows (see refactor-safely).

The English summary is being prepared. Showing the original description.

techygarg/lattice205Updated Oct 10, 2026

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'.

The English summary is being prepared. Showing the original description.

techygarg/lattice205Updated Oct 10, 2026

Generate implementation code from an approved design blueprint or verbal requirements. Composes context anchoring, architecture, clean code, DDD, security, and test quality into an inside-out implementation workflow. Use when moving from design to code, implementing approved contracts, or when the user says 'implement', 'code this', 'build it', 'forge the code', or 'generate the code'.

The English summary is being prepared. Showing the original description.

techygarg/lattice205Updated Oct 10, 2026

See all skills by techygarg

Report a problem with this skill