Knowledge Priming

---
name: knowledge-priming
description: "Load project-specific context -- tech stack, architecture overview, directory layout, trusted sources, and conventions -- so that all skills operate with awareness of what this project actually is. Use when a knowledge base document exists, or when the user asks about the project's tech stack, architecture, conventions, framework, directory layout, or says 'tell me about this project', 'what are we using?', 'what's our stack?', or 'what framework is this?'. Use the knowledge-priming-refiner to create a knowledge base document."
---

# Knowledge Priming

## Config Resolution

1. Look for `.lattice/config.yaml` in the repo root.
2. If found, check `paths.knowledge_base` for a custom document path.
3. If a document exists at that path, read the full document.
4. **STOP: Apply the loaded document as ambient context before any design, implementation, or review work begins.**
5. 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".
6. If there is no config file or no `paths.knowledge_base` key → 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.md` manually and reference it in `.lattice/config.yaml` under `paths.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?"*