| name | context-anchoring |
| description | 管理每个功能的活文档，在活跃开发期间跨 AI 会话捕获决策、约束和推理。范围限定在功能级别——设计、实现、缺陷修复、重构——不用于整个代码库评估或产品级规范（这些定义自己的文档生命周期）。处理创建新上下文文档、加载现有文档，并用新决策丰富它们。在开始新功能、恢复工作、做出技术决策、解决问题时使用，或当上下文需要在会话间持久化时使用。每当用户提到'load context'、'update context'、'context doc'、'decisions'、'continue where we left off'、'what did we decide'或'capture this decision'时使用此 skill。 |
Context Anchoring（上下文锚定）
范围（Scope）
仅限功能级别——在功能从设计→实现→缺陷修复→重构的流程中锚定决策。
配置解析（Config Resolution）
Skill 管理每个功能上下文文档的目录。解析顺序：
- 在仓库根目录查找
.lattice/config.yaml
- 如果找到，检查
paths.context_base 获取自定义目录路径
- 如果自定义路径存在，使用该目录作为上下文文档存储位置
- 如果没有配置/路径未找到，使用默认
.lattice/context/
每个功能在 <context_base>/<feature-name>.md 获得一个文档。没有默认原则、没有叠加模式、没有覆盖文件——只有薄模板和通过丰富而增长的功能文档。
问题（Problem）
AI 没有持久记忆。上下文衰减是真实的：在第 30+ 条消息时，早期决策被矛盾、命名不一致、"为什么"蒸发。损害累积——遗忘的决策成为潜在矛盾，丢失的约束成为违规，未解决的问题成为静默假设。
上下文锚文档解决：
- 功能绑定——每个功能一个文档，仅限定范围的决策
- 决策聚焦——捕获每个选择的什么、为什么、考虑了什么其他选项
- 仅追加——决策永不删除/重写，仅按时间顺序添加
- 跨会话——文档超越对话生命周期，携带上下文向前传递
- Git 原生——存在于仓库中，与代码一起版本控制
每个功能两个文档：需求文档（静态、预先编写、不由本 skill 管理）和 上下文锚文档（活文档、演进中、由本 skill 管理）。需求文档定义构建什么。上下文锚文档捕获如何构建和为什么——在开发过程中出现的决策、约束、推理。
文档生命周期（Document Lifecycle）
三种行为管理上下文锚文档的生命周期。每种由响应式（用户询问）或主动式（AI 建议）触发。两种情况下，AI 总是在行动前确认——提出方案，用户决定。
| 行为 | 目的 | 响应式触发 | 主动式触发 |
|---|
| Create（创建） | 启动新上下文文档 | 用户要求创建一个 | AI 检测到功能工作开始但没有文档 |
| Load（加载） | 从现有文档恢复上下文 | 用户要求加载/恢复 | AI 检测到现有文档并建议加载 |
| Enrich（丰富） | 添加新决策、约束、解决方案 | 用户要求捕获某些内容 | AI 检测到对话中做出的决策 |
Create Behavior（创建行为）
创建前必须确认。
步骤：
- 识别功能名称。 从功能名称派生 kebab-case 文件名（例如，"User Authentication" →
user-authentication.md）。与用户确认名称。
- 询问需求文档。 如果用户有需求文档，捕获
requirement_doc frontmatter 字段的路径。如果没有，留为 null。
- 创建目录如果
<context_base>/ 尚不存在。
- 从模板生成。 读取
./assets/feature-doc-template.md 并填写：
- 确认创建。 向用户展示建议的路径和内容摘要。仅在确认后创建。
Load Behavior（加载行为）
加载前必须确认。
步骤：
- 读取上下文文档。 解析 frontmatter 和所有部分。
- 如果
requirement_doc 不为 null，读取链接的需求文档。 用于理解功能目标和范围，但不修改。
- 呈现结构化确认（见下面的输出格式）：
- 功能名称和摘要
- 需求文档状态（已链接或未链接）
- 决策数量和最新决策
- 开放问题（如果有）
- 约束（如果有）
- 尊重所有记录的决策。 日志中的每个决策都视为活跃承诺。未经明确讨论和新决策条目解释变更，永不与记录的决策矛盾。
- 将约束视为不可协商的。 约束比决策更严格——代表不能跨越的边界，除非有明确的、文档化的覆盖。
- 当工作触及开放问题时标记。 如果当前任务涉及有未解决问题的区域，立即浮现。不要静默假设答案。
Enrich Behavior（丰富行为）
写入前必须确认。
在决策日志中捕获的内容：
- Date（日期）——决策做出的时间
- Decision（决策）——决定什么，清晰简洁地陈述
- Reasoning（推理）——为什么做出这个选择，关键因素
- Alternatives Considered（考虑的替代方案）——还评估了什么以及为什么拒绝
规则：
- 仅追加。 新条目放在决策日志表的底部。永不修改或删除现有条目。
- 时间顺序。 条目反映决策做出的顺序，不按主题分组。
- 简洁但完整。 每个条目独立可理解，无需重新阅读完整对话。
- 仅限功能绑定。 仅捕获与此特定功能相关的决策。跨关注点、项目级约定、一般偏好属于其他地方。
- 明确解决开放问题。 当开放问题被回答时，将答案作为决策添加到日志中并从开放问题列表中移除该问题。
- 约束不可协商。 一旦记录约束，它就具有约束力。更改约束需要新的决策条目解释为什么正在修订约束。
- 约束覆盖协议。 如果用户明确说覆盖约束（例如，"忘记那个约束，我们改变了方向"），不要静默删除。而是：(a) 要求用户明确确认覆盖，(b) 在约束部分中删除线约束（前缀
~~），以及 (c) 在决策日志中添加决策条目记录覆盖和推理。保留约束历史；撤销约束状态。
文档发现（Document Discovery）
当用户要求加载或恢复但未指定哪个功能时：
- 扫描上下文基础目录查找
.md 文件。
- 通过 frontmatter
feature 字段或文件名匹配。
- 如果存在多个文档，呈现带有功能名称、创建日期、决策数量的编号列表。让用户选择。
- 如果只存在一个文档，建议加载它。在继续前确认。
- 如果没有文档存在，通知用户并建议创建一个。
- 模糊匹配： 如果用户术语部分匹配多个文档（例如，"auth" 匹配
user-authentication.md 和 oauth-authentication.md），显示所有部分匹配项及完整文件名，让用户选择。永不猜测。
当用户在对话中提到功能名称时，检查是否存在匹配的上下文文档。如果存在且未在当前会话中加载，建议加载它。
输出格式（Output Formats）
Load（加载）：显示功能名称、需求文档状态、决策数量、开放问题、约束、最新决策。以以下语句结束："所有记录的决策都是活跃的。约束是不可协商的。当工作触及开放问题时，我会标记它们。"
Enrich（丰富）：显示将添加的确切内容（决策、推理、考虑的替代方案）。写入前等待确认。
Create（创建）：显示建议路径、功能名称、需求文档链接。创建前等待确认。
与其他 Skills 的集成（Integration with Other Skills）
此 atom 由编排功能工作流的 molecules 组合：
design-blueprint——在步骤 1（建立上下文）中调用 Create 或 Load，然后在每个设计级别检查点调用 Enrich 以捕获出现的决策code-forge——在步骤 1（建立实现上下文）中调用 Load 以加载蓝图，然后在步骤 3-5 期间调用 Enrich 以捕获实现决策、关键文件、已解决问题
当上下文文档活跃（在当前会话中加载）时，Enrich 持续运行——AI 监控对话中值得捕获的决策并在出现时建议丰富。不限于加载文档的 molecule；任何产生决策的 skill 都可以触发丰富建议。
