Knowledge Priming Refiner

Knowledge Priming Refiner

Purpose

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.

What This Produces

• Output: .lattice/standards/knowledge-base.md (or custom path from .lattice/config.yaml -> paths.knowledge_base)
• Mode: Override is the standard approach -- every project's knowledge base is unique, so there are no generic defaults to overlay on. Overlay mode is available for selective revisions of an existing document.
• Config key: paths.knowledge_base in .lattice/config.yaml
• Template: Read ./assets/template.md for the full document structure and interview guidance comments
• Consumed by: The knowledge-priming atom loads this document via config resolution and provides it as ambient project context to all skills and molecules

Scope Boundary

Knowledge priming captures project identity and technical context. It deliberately excludes concerns covered by other skills:

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 You Begin

Check for existing documents

Before starting the interview:

1. Read .lattice/config.yaml -- does paths.knowledge_base point to a file?
2. If yes, read that file. Ask the user:
   • "You already have a knowledge base document. Would you like to revise it (update specific sections), start fresh (new interview), or add to it?"
   • Revise: Load the existing document, walk through only the sections the user wants to change.
   • Start fresh: Proceed with the full interview flow below.
3. If no config or no existing document, proceed with the full interview flow.

Scan the repository

Look for signals that inform the conversation:

• package.json / Cargo.toml / go.mod / pyproject.toml: What languages, frameworks, and versions are in use?
• Directory structure: How is the project organized? Monorepo, single app, modules?
• Existing docs: README, ADRs, contributing guides, architecture docs?
• Config files: Linter configs, formatter configs, CI pipeline files -- these reveal conventions.

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."

Facilitation Approach

• One section at a time. Walk through the 5 sections sequentially.
• Show examples first. For each section, explain what it captures, show a concrete example, then ask the user.
• Record the user's content, not the discussion. The output document reads as a reference.
• Encourage specificity. "Fastify 4.x" is useful; "modern framework" is not. Version numbers matter because APIs change between versions.
• Keep it lean. Target under 3 pages / ~50 lines of focused content. Every token competes for context window space.

Section-by-Section Interview Guide

Read ./assets/template.md and follow the <!-- INTERVIEW GUIDANCE: --> comments for each section.

The 5 sections

Cross-section awareness

Output Assembly

1. YAML frontmatter: mode: override (or overlay for selective)
2. Preamble text (from template)
3. All sections with the user's content
4. Sections the user skipped get a <!-- TODO: Fill in during next revision --> comment
5. Strip all <!-- INTERVIEW GUIDANCE: --> comments from the output

Determine output path:

1. If .lattice/config.yaml exists and has paths.knowledge_base, use that path.
2. Otherwise, default to .lattice/standards/knowledge-base.md.

Update config:

1. If .lattice/config.yaml does not exist, create it with paths.knowledge_base pointing to the output file.
2. If it exists but lacks the key, add it. Preserve existing content.

Document Quality Checks

Before writing the final document, verify:

• Content is specific, not generic ("Fastify 4.x" not "modern framework")
• Tech stack entries include version numbers where applicable
• "Not X" clarifications steer AI away from common defaults that do not apply
• Curated sources are limited to 5-10 high-value entries
• No coding guidelines (naming rules, code examples, anti-patterns) -- those belong in other skills
• Document stays under ~50 lines of focused content (excluding headings and formatting)
• Would a new developer find this useful for understanding what this project is?
• Not a redirect stub — fewer than 3 of the 5 sections populated, or body primarily points to another file → STOP before writing. Say: "This knowledge base is mostly a pointer and won't prime sessions effectively. Should we inline the key content from [referenced file] instead?" Do not write a redirect-only document.

Source: techygarg/lattice — distributed by TomeVault.