用途：在设计与开发过程中主动构建并打磨项目的领域模型，而不是仅仅读取已有词汇表。适用于需要确定领域术语与统一语言、记录架构决策、澄清模糊或过载概念的场景。
主要能力：对照 CONTEXT.md 中的既有语言，立即指出用户用词冲突；把含糊或一词多义的表述替换为精确的规范术语；用具体场景压力测试领域关系，逼出概念边界；把用户描述与代码交叉核对，暴露矛盾；术语一旦确定就即时更新 CONTEXT.md，不批量积压；把已解决的实现相关结论（约束、否定性需求、边界情况、数值默认值、顺序决策）追加到功能决策台账；仅在难以逆转、缺少上下文会令人困惑、且确为真实权衡三者同时成立时，才提议创建 ADR。
文件结构：多数仓库只有一个上下文，根目录放 CONTEXT.md，决策放 docs/adr/。若根目录存在 CONTEXT-MAP.md，则说明有多个上下文，由该映射指向各上下文位置，各上下文可有自己的 CONTEXT.md 与 docs/adr/。文件按需惰性创建：第一个术语确定时创建 CONTEXT.md，需要第一条 ADR 时创建 docs/adr/。CONTEXT.md 只作术语表，不含实现细节，不是规格、草稿本或实现决策仓库。
相关文档：涉及 UI 时，视觉系统有独立术语表 DESIGN.md，记录已定型的颜色、字体、间距、组件清单与布局模式等约定，按需创建，格式见 DESIGN-FORMAT.md，硬性视觉决策的理由写入 ADR。工作属于更大目标的一个切片时，上层计划在 ROADMAP.md，记录更高目标与尚未推进的领域，按需创建，格式见 ROADMAP-FORMAT.md；若仓库已有 PRODUCT.md 或 VISION.md，则更新既有文档。规划期间新建的 ADR 通常先提议、待实现落地后再提升为已接受；若记录的是当前代码已体现的决策，则标记为已接受。
限制：资料未提供该技能的具体安装命令、支持的平台、收费方式或效果数据。