knowledge-priming-refiner

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 之一，而非此处。知识基线回答"我们使用什么？"——而非"我们应该如何编写？"

开始之前

检查现有文档

在开始访谈之前：

1. 读取 .lattice/config.yaml —— paths.knowledge_base 是否指向某个文件？
2. 如果是，读取该文件。询问用户：
   • "你已经有知识基线文档了。你想修订它（更新特定部分）、重新开始（新访谈）还是补充它？"
   • 修订：加载现有文档，仅 walkthrough 用户想要更改的部分。
   • 重新开始：继续下面的完整访谈流程。
3. 如果没有配置或没有现有文档，继续完整访谈流程。

扫描仓库

寻找影响对话的信号：

• 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 -- 精选来源	每项技术都有值得整理的权威文档

输出组装

1. YAML frontmatter：mode: override（或选择性使用的 overlay）
2. 序言文本（来自模板）
3. 包含用户内容的所有部分
4. 用户跳过的部分获得 <!-- TODO: 在下次修订期间填写 --> 注释
5. 从输出中剥离所有 <!-- INTERVIEW GUIDANCE: --> 注释

确定输出路径：

1. 如果 .lattice/config.yaml 存在且有 paths.knowledge_base，使用该路径。
2. 否则，默认为 .lattice/standards/knowledge-base.md。

更新配置：

1. 如果 .lattice/config.yaml 不存在，创建它并将 paths.knowledge_base 指向输出文件。
2. 如果存在但缺少该键，添加它。保留现有内容。

文档质量检查

在编写最终文档之前，验证：

• 内容具体而非通用（"Fastify 4.x"而非"现代框架"）
• 技术栈条目包含适用的版本号
• "非 X"澄清引导 AI 远离不适用的常见默认值
• 精选来源限制在 5-10 个高价值条目
• 不包含编码指南（命名规则、代码示例、反模式）——这些属于其他 skills
• 文档保持聚焦内容约 50 行（不包括标题和格式）
• 新开发者会发现此文档对理解这个项目是什么有用吗？