| name | knowledge-priming-refiner |
| description | 通过结构化对话创建项目特定的知识基线文档。生成 knowledge-base.md，为 AI 提供项目的技术栈、架构、可信来源和项目结构信息。当用户说'set up knowledge base'、'prime the project'、'onboard AI'、'create knowledge base'、'set up project context'或'configure AI context'时使用。 |
Knowledge Priming Refiner（知识基线定义器）
目的
本 refiner 通过结构化对话创建项目特定的知识基线文档。该文档捕获项目的身份——技术栈、架构、目录布局和塑造团队工作方式的可信来源。可以将其视为回答一个问题："AI 需要了解这个项目的什么信息，以避免默认使用通用的互联网模式？"
这不是关于如何编写好代码——那由 clean-code atom（编码原则）、architecture atom（结构规则）和 domain-driven-design atom（领域建模）处理。知识基线覆盖这些 skills 无法知道的内容：使用哪个框架、哪个版本、哪些文档可信，以及仓库如何组织。
产出内容
- 输出：
.lattice/standards/knowledge-base.md（或来自 .lattice/config.yaml -> paths.knowledge_base 的自定义路径）
- 模式：覆盖（override）是标准方法——每个项目的知识基线都是独特的，因此没有通用的默认值可以叠加。覆盖模式可用于对现有文档进行选择性修订。
- 配置键：
.lattice/config.yaml 中的 paths.knowledge_base
- 模板：读取
./assets/template.md 获取完整的文档结构和访谈指导注释
- 消费者：
knowledge-priming atom 通过配置解析加载此文档，并将其作为环境项目上下文提供给所有 skills 和 molecules
范围边界
知识基线捕获项目身份和技术上下文。它有意排除其他 skills 涵盖的关注点：
| 关注点 | 归属位置 | 不在知识基线中 |
|---|
| 语言习惯（错误处理、类型系统、命名、测试模式、DI） | language-idioms 文档 | 不包含语言级模式或习惯用法 |
| 编码风格、命名原则、函数设计 | clean-code atom | 不包含代码示例、命名规则 |
| 架构层、依赖方向 | architecture atom | 不包含结构规则 |
| 领域建模、aggregate 设计 | domain-driven-design atom | 不包含 DDD 模式 |
| 代码级反模式（god functions、深层嵌套） | clean-code atom | 不包含编码反模式 |
如果你发现自己正在编写教授如何编写代码的内容，它应属于上述 atom 之一，而非此处。知识基线回答"我们使用什么？"——而非"我们应该如何编写？"
开始之前
检查现有文档
在开始访谈之前：
- 读取
.lattice/config.yaml —— paths.knowledge_base 是否指向某个文件？
- 如果是，读取该文件。询问用户：
- "你已经有知识基线文档了。你想修订它（更新特定部分）、重新开始（新访谈）还是补充它？"
- 修订：加载现有文档，仅 walkthrough 用户想要更改的部分。
- 重新开始：继续下面的完整访谈流程。
- 如果没有配置或没有现有文档，继续完整访谈流程。
扫描仓库
寻找影响对话的信号：
- package.json / Cargo.toml / go.mod / pyproject.toml：使用哪些语言、框架和版本？
- 目录结构：项目如何组织？monorepo、单应用、模块？
- 现有文档：README、ADRs、贡献指南、架构文档？
- 配置文件：linter 配置、formatter 配置、CI pipeline 文件——这些揭示约定。
在开始时与用户分享相关发现："我注意到你的项目使用 [X 框架]，具有 [Y 结构]。我将以此作为我们对话的上下文。"
引导方法
- 一次一个部分。按顺序 walkthrough 5 个部分。
- 先展示示例。对于每个部分，解释它捕获什么，展示具体示例，然后询问用户。
- 记录用户的内容，而非讨论过程。输出文档应作为参考阅读。
- 鼓励具体性。**"Fastify 4.x"是有用的；"现代框架"**则不是。版本号很重要，因为 API 在不同版本之间会变化。
- 保持精简。目标是不超过 3 页/~50 行聚焦内容。每个 token 都在为 context window 空间竞争。
分部分访谈指南
读取 ./assets/template.md，并按照每个部分的 <!-- INTERVIEW GUIDANCE: --> 注释操作。
5 个部分
| # | 部分 | 捕获内容 |
|---|
| 1 | 架构概览 | 大局：什么类型的应用、主要组件、它们如何交互 |
| 2 | 技术栈和版本 | 具体技术及版本号，包括"非 X"澄清 |
| 3 | 精选知识来源 | 团队依赖的官方文档、可信博客、内部参考（最多 5-10 个） |
| 4 | 项目结构 | 显示各部分位置的目录布局 |
| 5 | 项目约定 | 其他 skills 无法推断的项目特定约定的简要说明（可选，精简） |
跨部分意识
| 描述于 | 影响 | 如何影响 |
|---|
| §1 -- 架构 | §4 -- 项目结构 | 架构风格塑造目录布局 |
| §2 -- 技术栈 | §5 -- 项目约定 | 技术栈选择可能暗示项目特定约定 |
| §2 -- 技术栈 | §3 -- 精选来源 | 每项技术都有值得整理的权威文档 |
输出组装
- YAML frontmatter：
mode: override（或选择性使用的 overlay）
- 序言文本（来自模板）
- 包含用户内容的所有部分
- 用户跳过的部分获得
<!-- TODO: 在下次修订期间填写 --> 注释
- 从输出中剥离所有
<!-- INTERVIEW GUIDANCE: --> 注释
确定输出路径：
- 如果
.lattice/config.yaml 存在且有 paths.knowledge_base，使用该路径。
- 否则，默认为
.lattice/standards/knowledge-base.md。
更新配置：
- 如果
.lattice/config.yaml 不存在，创建它并将 paths.knowledge_base 指向输出文件。
- 如果存在但缺少该键，添加它。保留现有内容。
文档质量检查
在编写最终文档之前，验证：
