context-and-decisions

用途

本技能用于治理“稳定的领域上下文”，并在需要时把难以逆转的决策交接给仓库已有的架构决策记录（ADR）体系。其核心原则是把“这些业务术语是什么意思”与“为什么选择这个方案”分开管理，避免把两类信息混在同一份文档中。同时强调：当没有稳定内容时，不要创建空壳文件。

主要能力

领域上下文工件：只记录领域语言

当出现以下情况时——术语需要反复解释、同一术语有多种含义、或语言不清导致模块边界错误——应首先复用仓库已有的术语表/领域模型文档，或 .governance/docs-map.json 中的 context 角色。只有在不存在等价来源时，才按 templates/context.example.md 惰性创建默认的 CONTEXT.md。

CONTEXT.md 只记录：

领域术语及其精确定义；
核心概念之间的关系；
已确认的歧义及所选解释；
仍等待领域负责人确认的歧义。

不应包含：实现细节、当前状态、任务排期、完整需求、决策理由或历史。这些内容应分别保留在代码/MAP、STATUS/Issue Tracker、Spec、ADR 和 LOG 中。术语必须可追溯到代码、契约或业务证据。未确认的条目应标记为 needs confirmation，不得猜测。

ADR 交接：复用既有能力

本技能不定义第二套 ADR 目录、编号方案、生命周期或模板。当某项决策难以逆转、缺少上下文会让未来读者困惑、且涉及真实权衡时：

阅读并执行 architecture-decision-records，保留仓库既有的 ADR 位置与格式；
若不存在既有约定，由该技能选择最小可行位置，不要在此另建独立体系；
从 CONTEXT.md、项目地图或相关 Spec/Issue 链接到 ADR，而不是复制决策正文；
当决策被接受、取代或弃用时，按活文档规则向项目历史追加事件。

常规实现细节、易于逆转的改动和短期实验不需要 ADR。

使用方式

何时激活

领域术语被反复重新解释，或歧义语言导致实现漂移；
项目需要稳定的领域语言入口，但没有等价文档；
上下文工作发现了应交接给 architecture-decision-records 的持久决策。

何时使用

当稳定的领域语言需要一个有证据支撑的归属地，或上下文工作揭示出应归入仓库既有 ADR 体系的难以逆转决策时，使用本技能。

工作方式

存在已映射的上下文或术语表工件时复用；仅当没有等价事实来源时才创建 CONTEXT.md；
记录精确的领域定义、关系、已确认解释和明确未确认的歧义，不混入实现或任务状态；
将持久权衡交给 architecture-decision-records，并链接生成的 ADR，而不是把其理由复制进上下文文档；
排期、阻塞和执行状态保留在既有问题跟踪器中。

适用场景

一次性定义某个被重载的业务术语，并链接到证明其含义的代码或契约；
在领域负责人解决之前，将某条领域解释标记为 needs confirmation；
将持久的存储或边界决策交接给既有 ADR 工作流，并从上下文工件链接过去。

限制与反模式

不要把当前任务、排期、完整需求或实现细节复制进 CONTEXT.md；
不要为求完整而创建空的上下文文件或第二套 ADR 体系；
不要把未确认的领域解释当作事实，也不要把 ADR 正文复制进地图和日志。

排期与任务边界

任务、状态、阻塞和排期应保留在项目既有跟踪器（如 GitHub Issues 或 Linear）中，作为唯一事实来源。仅当不存在外部跟踪器且项目明确采用时，才使用本地 .scratch/。不要把排期放进 CONTEXT.md、ADR、PROJECT_STATUS 或历史索引数据库。

技能介绍

用途