techygarg Knowledge Priming
Config Resolution
- Look for
.lattice/config.yamlin the repo root. - If found, check
paths.knowledge_basefor a custom document path. - If a document exists at that path, read the full document.
- STOP: Apply the loaded document as ambient context before any design, implementation, or review work begins.
- If a path is configured but no document exists at it → tell the user which configured path is missing, then see "When No Document Exists".
- If there is no config file or no
paths.knowledge_basekey → see "When No Document Exists".
When No Document Exists
Inform the user:
No project knowledge base found. AI skills will operate from generic assumptions about tech stack, architecture, and conventions.
To create one, trigger knowledge-priming-refiner — a guided interview (
10 questions) producing a concise document (50 lines).You can also create
.lattice/standards/knowledge-base.mdmanually and reference it in.lattice/config.yamlunderpaths.knowledge_base.
Do not block. Continue without the knowledge base.
What the Document Contains
| # | Section | What It Captures |
|---|---|---|
| 1 | Architecture Overview | App type, 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 (5–10 max) |
| 4 | Project Structure | Directory layout showing where things live |
| 5 | Project Conventions | Project-specific conventions other skills cannot infer from code |
Scope Boundary
| Concern | Owned By |
|---|---|
| Coding style, naming principles, function design | clean-code atom |
| Architectural layers, dependency direction | architecture atom |
| Domain modeling, aggregate design | domain-driven-design atom |
| Input validation, injection prevention | secure-coding atom |
| Test structure, assertion quality | test-quality atom |
Knowledge priming answers "what are we working with?" — not "how should we write?"