knowledge-priming
Knowledge-priming loads project-specific context including tech stack, architecture overview, directory layout, trusted sources, and conventions before other skills execute. Use it when a knowledge base document exists or when users ask about project fundamentals like tech stack, architecture, framework, directory layout, or request a project overview. The skill reads configuration from `.lattice/config.yaml` and applies the referenced knowledge base as ambient context to prevent generic assumptions.
git clone --depth 1 https://github.com/techygarg/lattice /tmp/knowledge-priming && cp -r /tmp/knowledge-priming/skills/atoms/knowledge-priming ~/.claude/skills/knowledge-primingSKILL.md
# Knowledge Priming ## Purpose AI default = internet average. No project context → guesses framework, invents conventions, generic code not match stack. Knowledge priming fix: load concise project identity doc before design/implement/review. Not teach code principles (clean-code), structure rules (architecture), domain modeling (domain-driven-design). Answer different question: **"What is this project?"** -- tech stack, architecture style, directory layout, trusted docs, conventions other skills not infer from code. ## Config Resolution 1. Look `.lattice/config.yaml` in repo root 2. If found, check `paths.knowledge_base` for custom doc path 3. If doc exist at path, read + apply as ambient project context 4. If no config/path/doc found -- see "When No Document Exists" No embedded defaults. Every project identity unique -- no sensible generic default for "what your project." Knowledge base doc created by `knowledge-priming-refiner` skill or hand-written. ## When No Document Exists If no knowledge base doc found during config resolution, inform user: > No project knowledge base found. Without it, AI skills work from generic assumptions about tech stack, architecture, conventions. > > To create one, trigger **knowledge-priming-refiner** skill -- guided interview (~10 questions) that produces concise document (~50 lines). Once created, every Lattice skill use it as ambient context. > > Can also create `.lattice/standards/knowledge-base.md` manually and reference in `.lattice/config.yaml` under `paths.knowledge_base`. Message informational, not blocking. All skills continue work without knowledge base -- just operate without project-specific context. ## What the Document Contains Knowledge base doc from `knowledge-priming-refiner` has 5 sections: | # | Section | What It Captures | |---|---------|-----------------| | 1 | **Architecture Overview** | Big picture: what kind application, major components, how interact | | 2 | **Tech Stack and Versions** | Specific technologies with version numbers, including "not X" clarifications | | 3 | **Curated Knowledge Sources** | Official docs, trusted blogs, internal references team relies on (5-10 max) | | 4 | **Project Structure** | Directory layout showing where things live | | 5 | **Project Conventions** | Brief project-specific conventions other skills not infer | Doc intentionally lean -- under 50 lines focused content. Every token compete for context window, so knowledge base capture what matter most, omit what other skills already handle. ## How It Is Used When knowledge base doc loaded, become **ambient context** for all skills. Any molecule compose this atom load first, before design/implement/review work. Examples how used: - **Design molecules** use ground design decisions in actual tech stack + architecture -- propose components fit real project structure not generic patterns - **Implementation molecules** use generate code match project framework, version-specific APIs, directory conventions, naming patterns - **Review molecules** use evaluate changes against project actual standards -- flag deviations from documented conventions not generic best practices Knowledge base always-on context. Unlike conditional atoms (DDD, secure-coding, test-quality) activate based on what code touched, knowledge base apply every interaction because project identity always relevant. ## Scope Boundary Knowledge priming capture **project identity + technical context**. Deliberately exclude concerns covered by other atoms: | Concern | Where It Belongs | Not Here | |---------|-----------------|----------| | Coding style, naming principles, function design | clean-code atom | No code examples, no naming rules | | Architectural layers, dependency direction | architecture atom | No structural rules | | Domain modeling, aggregate design | domain-driven-design atom | No DDD patterns | | Input validation, injection prevention | secure-coding atom | No security rules | | Test structure, assertion quality | test-quality atom | No testing patterns | If content teach *how write code*, belong in atoms above. Knowledge priming answer *"what we working with?"* -- not *"how should write?"* ## Integration with Other Skills This atom composed by all three molecules: - **`design-blueprint`** -- load knowledge base at start ground design in real tech stack + architecture - **`code-forge`** -- load knowledge base inform implementation decisions, framework-specific patterns, directory placement - **`review`** -- load knowledge base evaluate changes against project-specific conventions + stack constraints When composed by molecule, knowledge base loaded once at beginning, remain active throughout workflow. When used standalone, load on first reference to project context.
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'.
Enforce architectural rules when generating or modifying code. 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'.