From lattice
Facilitates structured conversation to generate knowledge-base.md priming AI with project tech stack, architecture, trusted sources, and structure. Triggers on 'set up knowledge base', 'prime project', or similar phrases.
npx claudepluginhub techygarg/lattice --plugin latticeThis skill uses the workspace's default tool permissions.
This refiner facilitates a structured conversation to create a project-specific knowledge base document. The document captures the project's identity -- its tech stack, architecture, directory layout, and the trusted sources that shaped how the team works. Think of it as answering one question: "What does AI need to know about *this project* to avoid defaulting to generic internet patterns?"
Loads project-specific context from knowledge base: tech stack, architecture overview, directory layout, trusted sources, conventions. Primes skills for project-aware responses; guides creation if missing.
Generates codebase knowledge bases using templates for architecture diagrams (Mermaid), concept maps, module breakdowns, and more. Supports single-project and monorepo structures for project documentation.
Scans codebase to auto-generate CLAUDE.md project config and .rune/ state files for full context in AI coding sessions. Use on new repos or missing/stale context.
Share bugs, ideas, or general feedback.
This refiner facilitates a structured conversation to create a project-specific knowledge base document. The document captures the project's identity -- its tech stack, architecture, directory layout, and the trusted sources that shaped how the team works. Think of it as answering one question: "What does AI need to know about this project to avoid defaulting to generic internet patterns?"
This is not about how to write good code -- that is handled by the clean-code atom (coding principles), architecture atom (structural rules), and domain-driven-design atom (domain modeling). Knowledge priming covers what those skills cannot know: which framework, which version, which docs to trust, and how the repo is organized.
.lattice/standards/knowledge-base.md (or custom path from .lattice/config.yaml -> paths.knowledge_base)paths.knowledge_base in .lattice/config.yaml./assets/template.md for the full document structure and interview guidance commentsknowledge-priming atom loads this document via config resolution and provides it as ambient project context to all skills and moleculesKnowledge priming captures project identity and technical context. It deliberately excludes concerns covered by other skills:
| Concern | Where It Belongs | Not In Knowledge Priming |
|---|---|---|
| Language idioms (error handling, type system, naming, testing patterns, DI) | language-idioms document | No language-level patterns or idioms |
| 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 |
| Code-level anti-patterns (god functions, deep nesting) | clean-code atom | No coding anti-patterns |
If you find yourself writing content that teaches how to write code, it belongs in one of the atoms above, not here. Knowledge priming answers "what are we working with?" -- not "how should we write?"
Before starting the interview:
.lattice/config.yaml -- does paths.knowledge_base point to a file?Look for signals that inform the conversation:
Share relevant findings with the user at the start: "I noticed your project uses [X framework] with [Y structure]. I'll use that as context for our conversation."
Read ./assets/template.md and follow the <!-- INTERVIEW GUIDANCE: --> comments for each section.
| # | Section | What It Captures |
|---|---|---|
| 1 | Architecture Overview | Big picture: what kind of application, major components, how they 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 the team relies on (5-10 max) |
| 4 | Project Structure | Directory layout showing where things live |
| 5 | Project Conventions | Brief project-specific conventions that other skills cannot infer (optional, slim) |
| Described in | Informs | How |
|---|---|---|
| §1 -- Architecture | §4 -- Project Structure | Architecture style shapes directory layout |
| §2 -- Tech Stack | §5 -- Project Conventions | Stack choices may imply project-specific conventions |
| §2 -- Tech Stack | §3 -- Curated Sources | Each technology has authoritative docs worth curating |
mode: override (or overlay for selective)<!-- TODO: Fill in during next revision --> comment<!-- INTERVIEW GUIDANCE: --> comments from the outputDetermine output path:
.lattice/config.yaml exists and has paths.knowledge_base, use that path..lattice/standards/knowledge-base.md.Update config:
.lattice/config.yaml does not exist, create it with paths.knowledge_base pointing to the output file.Before writing the final document, verify: