context-anchoring

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 管理每个功能上下文文档的目录。解析顺序：

1. 在仓库根目录查找 .lattice/config.yaml
2. 如果找到，检查 paths.context_base 获取自定义目录路径
3. 如果自定义路径存在，使用该目录作为上下文文档存储位置
4. 如果没有配置/路径未找到，使用默认 .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（创建行为）

创建前必须确认。

步骤：

1. 识别功能名称。 从功能名称派生 kebab-case 文件名（例如，"User Authentication" → user-authentication.md）。与用户确认名称。
2. 询问需求文档。 如果用户有需求文档，捕获 requirement_doc frontmatter 字段的路径。如果没有，留为 null。
3. 创建目录如果 <context_base>/ 尚不存在。
4. 从模板生成。 读取 ./assets/feature-doc-template.md 并填写：
   • Frontmatter：feature、requirement_doc、created（今天日期）
   • H1 标题：功能名称
   • Summary：一行描述（询问用户或从上下文中推导）
   • 如果未找到模板文件，使用此最小结构生成文档：

     ---
     feature: <feature-name>
     requirement_doc: <path or null>
     created: <today's date>
     ---
     # <Feature Name>
     <one-line summary>
     ## Decisions Log
     | Date | Decision | Reasoning | Alternatives Considered |
     |------|----------|-----------|------------------------|
     ## Open Questions
     ## Constraints
     ## Key Files
     

5. 确认创建。 向用户展示建议的路径和内容摘要。仅在确认后创建。

Load Behavior（加载行为）

加载前必须确认。

步骤：

1. 读取上下文文档。 解析 frontmatter 和所有部分。
2. 如果 requirement_doc 不为 null，读取链接的需求文档。 用于理解功能目标和范围，但不修改。
3. 呈现结构化确认（见下面的输出格式）：
   • 功能名称和摘要
   • 需求文档状态（已链接或未链接）
   • 决策数量和最新决策
   • 开放问题（如果有）
   • 约束（如果有）
4. 尊重所有记录的决策。 日志中的每个决策都视为活跃承诺。未经明确讨论和新决策条目解释变更，永不与记录的决策矛盾。
5. 将约束视为不可协商的。 约束比决策更严格——代表不能跨越的边界，除非有明确的、文档化的覆盖。
6. 当工作触及开放问题时标记。 如果当前任务涉及有未解决问题的区域，立即浮现。不要静默假设答案。

Enrich Behavior（丰富行为）

写入前必须确认。

在决策日志中捕获的内容：

• Date（日期）——决策做出的时间
• Decision（决策）——决定什么，清晰简洁地陈述
• Reasoning（推理）——为什么做出这个选择，关键因素
• Alternatives Considered（考虑的替代方案）——还评估了什么以及为什么拒绝

规则：

1. 仅追加。 新条目放在决策日志表的底部。永不修改或删除现有条目。
2. 时间顺序。 条目反映决策做出的顺序，不按主题分组。
3. 简洁但完整。 每个条目独立可理解，无需重新阅读完整对话。
4. 仅限功能绑定。 仅捕获与此特定功能相关的决策。跨关注点、项目级约定、一般偏好属于其他地方。
5. 明确解决开放问题。 当开放问题被回答时，将答案作为决策添加到日志中并从开放问题列表中移除该问题。
6. 约束不可协商。 一旦记录约束，它就具有约束力。更改约束需要新的决策条目解释为什么正在修订约束。
7. 约束覆盖协议。 如果用户明确说覆盖约束（例如，"忘记那个约束，我们改变了方向"），不要静默删除。而是：(a) 要求用户明确确认覆盖，(b) 在约束部分中删除线约束（前缀 ~~），以及 (c) 在决策日志中添加决策条目记录覆盖和推理。保留约束历史；撤销约束状态。

文档发现（Document Discovery）

当用户要求加载或恢复但未指定哪个功能时：

1. 扫描上下文基础目录查找 .md 文件。
2. 通过 frontmatter feature 字段或文件名匹配。
3. 如果存在多个文档，呈现带有功能名称、创建日期、决策数量的编号列表。让用户选择。
4. 如果只存在一个文档，建议加载它。在继续前确认。
5. 如果没有文档存在，通知用户并建议创建一个。
6. 模糊匹配： 如果用户术语部分匹配多个文档（例如，"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 都可以触发丰富建议。