knowledge-priming-refiner

Name: knowledge-priming-refiner
Author: techygarg

165stars12forks

How to install knowledge-priming-refiner?

techygarg/lattice/knowledge-priming-refiner

$npx -y skills add techygarg/lattice --skill knowledge-priming-refiner

Installs into the current project.

Summary

Facilitate a structured conversation to create a project-specific knowledge base document. Produces a knowledge-base.md that primes AI with the project's tech stack, architecture, trusted sources, and project structure. Use when the user says 'set up knowledge base', 'prime the p

Files · 1

View on GitHub

SKILL.md

1	# Knowledge Priming Refiner
2
3	## Purpose
4
5	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?"
6
7	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.
8
9	## What This Produces
10
11	- Output: `.lattice/standards/knowledge-base.md` (or custom path from `.lattice/config.yaml` -> `paths.knowledge_base`)
12	- 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.
13	- Config key: `paths.knowledge_base` in `.lattice/config.yaml`
14	- Template: Read `./assets/template.md` for the full document structure and interview guidance comments
15	- Consumed by: The `knowledge-priming` atom loads this document via config resolution and provides it as ambient project context to all skills and molecules
16
17	## Scope Boundary
18
19	Knowledge priming captures project identity and technical context. It deliberately excludes concerns covered by other skills:
20
21	\| Concern \| Where It Belongs \| Not In Knowledge Priming \|
22	\|---------\|-----------------\|--------------------------\|
23	\| Language idioms (error handling, type system, naming, testing patterns, DI) \| `language-idioms` document \| No language-level patterns or idioms \|
24	\| Coding style, naming principles, function design \| `clean-code` atom \| No code examples, no naming rules \|
25	\| Architectural layers, dependency direction \| `architecture` atom \| No structural rules \|
26	\| Domain modeling, aggregate design \| `domain-driven-design` atom \| No DDD patterns \|
27	\| Code-level anti-patterns (god functions, deep nesting) \| `clean-code` atom \| No coding anti-patterns \|
28
29	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?"
30
31	## Before You Begin
32
33	### Check for existing documents
34
35	Before starting the interview:
36
37	1. Read `.lattice/config.yaml` -- does `paths.knowledge_base` point to a file?
38	2. If yes, read that file. Ask the user:
39	- "You already have a knowledge base document. Would you like to revise it (update specific sections), start fresh (new interview), or add to it?"
40	- Revise: Load the existing document, walk through only the sections the user wants to change.
41	- Start fresh: Proceed with the full interview flow below.
42	3. If no config or no existing document, proceed with the full interview flow.
43
44	### Scan the repository
45
46	Look for signals that inform the conversation:
47
48	- package.json / Cargo.toml / go.mod / pyproject.toml: What languages, frameworks, and versions are in use?
49	- Directory structure: How is the project organized? Monorepo, single app, modules?
50	- Existing docs: README, ADRs, contributing guides, architecture docs?
51	- Config files: Linter configs, formatter configs, CI pipeline files -- these reveal conventions.
52
53	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."
54
55	## Facilitation Approach
56
57	- One section at a time. Walk through the 5 sections sequentially.
58	- Show examples first. For each section, explain what it captures, show a concrete example, then ask the user.
59	- Record the user's content, not the discussion. The output document reads as a reference.
60	- Encourage specificity. "Fastify 4.x" is useful; "modern framework" is not. Version numbers matter because APIs change between versions.
61	- Keep it lean. Target under 3 pages / ~50 lines of focused content. Every token competes for context window space.
62
63	## Section-by-Section Interview Guide
64
65	Read `./assets/template.md` and follow the `<!-- INTERVIEW GUIDANCE: -->` comments for each section.
66
67	### The 5 sections
68
69	\| # \| Section \| What It Captures \|
70	\|---\|---------\|-----------------\|
71	\| 1 \| Architecture Overview \| Big picture: what kind

People who liked this also viewed

6 picks

Type

knowledge-priming-refiner

165stars12forks

View on GitHub

How to install knowledge-priming-refiner?

techygarg/lattice/knowledge-priming-refiner

$npx -y skills add techygarg/lattice --skill knowledge-priming-refiner

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# Knowledge Priming Refiner
2
3	## Purpose
4
5	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?"
6
7	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.
8
9	## What This Produces
10
11	- Output: `.lattice/standards/knowledge-base.md` (or custom path from `.lattice/config.yaml` -> `paths.knowledge_base`)
12	- 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.
13	- Config key: `paths.knowledge_base` in `.lattice/config.yaml`
14	- Template: Read `./assets/template.md` for the full document structure and interview guidance comments
15	- Consumed by: The `knowledge-priming` atom loads this document via config resolution and provides it as ambient project context to all skills and molecules
16
17	## Scope Boundary
18
19	Knowledge priming captures project identity and technical context. It deliberately excludes concerns covered by other skills:
20
21	\| Concern \| Where It Belongs \| Not In Knowledge Priming \|
22	\|---------\|-----------------\|--------------------------\|
23	\| Language idioms (error handling, type system, naming, testing patterns, DI) \| `language-idioms` document \| No language-level patterns or idioms \|
24	\| Coding style, naming principles, function design \| `clean-code` atom \| No code examples, no naming rules \|
25	\| Architectural layers, dependency direction \| `architecture` atom \| No structural rules \|
26	\| Domain modeling, aggregate design \| `domain-driven-design` atom \| No DDD patterns \|
27	\| Code-level anti-patterns (god functions, deep nesting) \| `clean-code` atom \| No coding anti-patterns \|
28
29	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?"
30
31	## Before You Begin
32
33	### Check for existing documents
34
35	Before starting the interview:
36
37	1. Read `.lattice/config.yaml` -- does `paths.knowledge_base` point to a file?
38	2. If yes, read that file. Ask the user:
39	- "You already have a knowledge base document. Would you like to revise it (update specific sections), start fresh (new interview), or add to it?"
40	- Revise: Load the existing document, walk through only the sections the user wants to change.
41	- Start fresh: Proceed with the full interview flow below.
42	3. If no config or no existing document, proceed with the full interview flow.
43
44	### Scan the repository
45
46	Look for signals that inform the conversation:
47
48	- package.json / Cargo.toml / go.mod / pyproject.toml: What languages, frameworks, and versions are in use?
49	- Directory structure: How is the project organized? Monorepo, single app, modules?
50	- Existing docs: README, ADRs, contributing guides, architecture docs?
51	- Config files: Linter configs, formatter configs, CI pipeline files -- these reveal conventions.
52
53	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."
54
55	## Facilitation Approach
56
57	- One section at a time. Walk through the 5 sections sequentially.
58	- Show examples first. For each section, explain what it captures, show a concrete example, then ask the user.
59	- Record the user's content, not the discussion. The output document reads as a reference.
60	- Encourage specificity. "Fastify 4.x" is useful; "modern framework" is not. Version numbers matter because APIs change between versions.
61	- Keep it lean. Target under 3 pages / ~50 lines of focused content. Every token competes for context window space.
62
63	## Section-by-Section Interview Guide
64
65	Read `./assets/template.md` and follow the `<!-- INTERVIEW GUIDANCE: -->` comments for each section.
66
67	### The 5 sections
68
69	\| # \| Section \| What It Captures \|
70	\|---\|---------\|-----------------\|
71	\| 1 \| Architecture Overview \| Big picture: what kind

People who liked this also viewed

6 picks

Type