用途：在设计中主动构建并打磨项目的领域模型。它针对的是改变模型本身，而非仅仅读取 CONTEXT.md 里的词汇；后者只是任何技能都能做的一行习惯。
主要能力：用既有术语表挑战用户提出的术语冲突；把模糊或过载的用词收窄为精确的规范术语；用具体场景压力测试领域关系，逼出概念边界的精确性；把用户对行为的描述与代码交叉核对，发现矛盾就指出；术语一旦确定，立即写入 CONTEXT.md。
文件结构：多数仓库只有一个上下文，根目录有 CONTEXT.md，docs/adr/ 存放决策记录，源码在 src/。若根目录存在 CONTEXT-MAP.md，则仓库有多个上下文，该文件指向各上下文位置，各上下文可有自己的 CONTEXT.md 与 docs/adr/。文件按需创建：没有 CONTEXT.md，就在第一个术语确定时创建；没有 docs/adr/，就在需要第一个 ADR 时创建。
使用方式：在会话中随时进行。遇到与 CONTEXT.md 中语言冲突的术语要立即指出；遇到含糊或过载的词要建议精确的规范术语；讨论领域关系时用具体、含边缘情况的场景来检验；用户陈述某行为如何工作时，核对代码是否一致，不一致就提出。术语确定后立刻就地更新 CONTEXT.md，不要攒批处理，格式参见 CONTEXT-FORMAT.md。CONTEXT.md 应完全不含实现细节，它只是术语表，不是规格、草稿本或实现决策仓库。
ADR 的时机：仅在三个条件同时成立时才建议创建 ADR——难以逆转、缺少背景会令人意外、是真实权衡的结果。缺少任何一条就跳过。格式参见 ADR-FORMAT.md。
适用场景：设计或修改领域模型时，需要术语统一、边界清晰、代码与模型对齐的编码会话。
限制：不把 CONTEXT.md 用作规格或草稿；不批量写入；ADR 仅在三条件齐备时提出。具体安装命令与价格等资料中暂未提供。