lattice-init
The lattice-init skill provides a guided setup experience for new Lattice projects by scanning the repository to detect language, framework, and existing configuration, then suggesting refiners in priority order and creating the .lattice/ config directory structure. Use this skill when a user requests project initialization for Lattice, such as "lattice init," "set up lattice," "initialize lattice," "get started with lattice," or "configure lattice for this project."
git clone --depth 1 https://github.com/techygarg/lattice /tmp/lattice-init && cp -r /tmp/lattice-init/skills/molecules/lattice-init ~/.claude/skills/lattice-initSKILL.md
# Lattice Init ## Required Skills Read apply skills order: 1. `framework:knowledge-priming` -- Load project context understand what project is what already exists ## Workflow ### Step 1: Scan the Project Detect signals about project understand shape existing Lattice state. **Language/framework detection** -- check files in repo root: - `package.json` → Node.js / TypeScript - `tsconfig.json` → TypeScript (confirm over JavaScript) - `go.mod` → Go - `pom.xml` or `build.gradle` or `build.gradle.kts` → Java or Kotlin - `Cargo.toml` → Rust - `requirements.txt` or `pyproject.toml` or `setup.py` → Python - `Gemfile` → Ruby - `*.csproj` or `*.sln` → C# / .NET - `Package.swift` → Swift <!-- synced with language-idioms-refiner "Detect the language" -- edit both --> If multiple language markers are found in the repo root, note all of them and ask the user which is the primary stack before continuing. **Directory structure** -- list top-level dirs. Identify common patterns: - `src/`, `lib/`, `app/` → source code - `test/`, `tests/`, `spec/` → test suites - `docs/` → documentation - `cmd/`, `internal/`, `pkg/` → Go project structure - `domain/`, `infrastructure/`, `application/` → layered architecture **Existing `.lattice/` state** -- check what Lattice artifacts already exist: - `.lattice/config.yaml` → central config (check for `language` key) - `.lattice/standards/language-idioms.md` → language idioms refiner output - `.lattice/standards/knowledge-base.md` → knowledge priming output - `.lattice/standards/architecture.md` → architecture refiner output (clean architecture, hexagonal, modular monolith, or custom style) - `.lattice/standards/clean-code.md` → clean code refiner output - `.lattice/standards/ddd-principles.md` → DDD refiner output - `.lattice/standards/review-standards.md` → review refiner output - `.lattice/context/` → feature context documents (count them) - `.lattice/learnings/operational-learnings.md` → accumulated operational learnings (managed by learning-harvest atom) - `.lattice/reviews/review-log.md` → review log - `.lattice/requirements/index.md` → check shape: if epic sections and feature tables are written directly inside it (no `epics/` directory alongside) and `requirements_layout` is absent from config, flag as **legacy layout — upgrade available** - `.lattice/verification.yaml` → verification stages config consumed by the verification runner - `.lattice/scripts/run-verification.sh` → vendored verification runner ### Step 2: Present Findings Present: ``` ## Project Scan Results **Project**: [detected language/framework] at [repo root] **Structure**: [key directories found] ### Lattice Setup Status Running mode: **[customized -- standards docs active below / built-in defaults -- full functionality]** - `.lattice/config.yaml`: [exists / not created yet] - Language: [detected language / language key from config / not detected] - Language idioms: [.lattice/standards/language-idioms.md / built-in default] - Knowledge base: [.lattice/standards/knowledge-base.md / built-in default] - Architecture standards: [.lattice/standards/architecture.md / built-in default] - Clean code standards: [.lattice/standards/clean-code.md / built-in default] - DDD standards: [.lattice/standards/ddd-principles.md / built-in default] - Review standards: [.lattice/standards/review-standards.md / built-in default] - Context documents: [N found / none] - Review learnings: [found at .lattice/learnings/operational-learnings.md / none] - Review log: [found at .lattice/reviews/review-log.md / none] - Requirements layout: [sharded / legacy — upgrade available / not found] - Verification suite: [.lattice/verification.yaml configured / not set up] ``` **STOP (fresh install): if no `.lattice/` state exists at all AND no legacy requirements layout was detected** — create the minimal `.lattice/config.yaml` shown in Step 3, tell the user: "Lattice is ready. It runs on built-in defaults with full functionality. Refiner interviews that pin your team's conventions are optional — ask for them anytime." Skip to Step 4. Do not present the customization menu unprompted. **STOP: If `.lattice/config.yaml` and all core standards docs exist AND no legacy requirements layout was detected:** Tell user "Lattice fully configured." Skip to Step 4. **STOP:** if a legacy requirements layout was detected, do not skip on that basis alone — present it as a gap in Step 3 even when everything else is fully configured. ### Step 3: Guided Setup Reached only when something needs attention (a gap above) or the user asked to customize. Frame every item below as optional refinement -- Lattice is fully functional without any of it. **Priority order**: 1. **Requirements layout upgrade** (if legacy layout detected in Step 1) -- "Your requirements index uses an older layout that hand-edits one shared file per feature, which causes merge conflicts when multiple developers work in parallel. The current layout shards it by epic and generates rollups from feature files instead of hand-editing them. One-time migration; does not touch any feature file's content beyond a link repointing (a rare exception is surfaced and confirmed, never silent). This upgrade only matters if your team keeps requirements in this repo -- teams tracking requirements in an external system (Jira, Linear, etc.) can skip it." 2. **Knowledge-priming-refiner** (if `.lattice/standards/knowledge-base.md` missing) -- "Captures project identity -- tech stack, architecture, directory layout, conventions. Every other skill uses this context make better decisions." 3. **Language-idioms-refiner** (if `.lattice/standards/language-idioms.md` missing) -- "Defines how your language expresses engineering patterns -- error handling, type system, naming, testing, DI. Multiple atoms use this to adapt pseudocode defaults to your language. Fast interview: proposes language-idiomatic defaults, you confirm or adjust." 4. **Architecture-refiner** (if `.lattice/standards/archit
Audit and fix all Lattice documentation, README, docs/, PROJECT.md, 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'.
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.
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'.