菜单
构建并打磨项目的领域模型。当用户想要确定领域术语或统一语言（ubiquitous language）、记录架构决策，或当其他技能需要维护领域模型时使用。
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
从两个维度审查自某个固定基点（提交、分支、标签或 merge-base）以来的改动 —— 规范（代码是否遵循本仓库有文档记录的编码规范？）与 需求（代码是否符合最初发起的 issue/PRD 的要求？）。以并行子代理运行两项审查并并排汇报。当用户想要审查某个分支、PR、进行中的改动，或要求“审查自 X 以来的改动”时使用。
基于一份规格或一组工单来实现一部分工作。
设计深模块的共享术语体系。当用户想要设计或改进某个模块的接口、寻找加深（deepening）的机会、决定接缝（seam）放在哪里、让代码更易测试或更利于 AI 导航时，或当其他技能需要用到深模块术语时使用。
通过一场刨根问底的访谈来打磨一份计划或设计。
通过一场刨根问底的访谈来打磨一份计划或设计，并在过程中同时产出文档（ADR 和词汇表）。
就一份计划、决策或想法对用户刨根问底地追问。当用户想要对自己的思路进行压力测试，或使用了任何 'grill' 触发短语时使用。
| name | domain-modeling |
| description | 构建并打磨项目的领域模型。当用户想要确定领域术语或统一语言（ubiquitous language）、记录架构决策，或当其他技能需要维护领域模型时使用。 |
在设计过程中主动构建并打磨项目的领域模型。这是一门 主动 的功夫——挑战术语、构造边界情形的场景，并在术语与决策刚刚清晰下来的那一刻就把它们写下来。（仅仅 阅读 CONTEXT.md 获取词汇并不属于这个技能——那是任何技能都能顺手做的一件小事。这个技能面向的是你正在 修改 模型的场景，而不只是消费它。）
大多数仓库只有单一上下文（context）：
/
├── CONTEXT.md
├── docs/
│ └── adr/
│ ├── 0001-event-sourced-orders.md
│ └── 0002-postgres-for-write-model.md
└── src/
如果根目录存在 CONTEXT-MAP.md，说明该仓库有多个上下文。这张映射表指明每个上下文所在的位置：
/
├── CONTEXT-MAP.md
├── docs/
│ └── adr/ ← 系统级决策
├── src/
│ ├── ordering/
│ │ ├── CONTEXT.md
│ │ └── docs/adr/ ← 上下文专属决策
│ └── billing/
│ ├── CONTEXT.md
│ └── docs/adr/
延迟创建文件——只在你确实有内容要写时才创建。如果 CONTEXT.md 尚不存在，就在第一个术语被确定下来时创建它。如果 docs/adr/ 尚不存在，就在第一次需要 ADR 时创建它。
当用户使用的术语与 CONTEXT.md 中现有语言相冲突时，立刻指出来。"你的词汇表把 'cancellation' 定义为 X，但你现在的意思似乎是 Y——到底是哪个？"
当用户使用含糊或含义过载的术语时，提出一个精确的规范术语。"你说的是 'account'——你指的是 Customer 还是 User？这是两个不同的东西。"
在讨论领域关系时，用具体场景来压力测试它们。构造能探测边界情形的场景，迫使用户对概念之间的边界表述得更精确。
当用户陈述某个东西如何工作时，检查代码是否认同。如果发现矛盾，就把它摆出来："你的代码取消的是整个 Order，但你刚才说可以部分取消——哪个才对？"
当一个术语被确定下来时，当场更新 CONTEXT.md。不要把它们攒起来批量处理——在它们发生时就捕获下来。使用 CONTEXT-FORMAT.md 中的格式。
CONTEXT.md 应当完全不含实现细节。不要把 CONTEXT.md 当作规格说明、草稿本或实现决策的存放处。它是一份词汇表，仅此而已。
只有当以下三点全部成立时，才提议创建 ADR：
只要三者中缺少任何一条，就跳过 ADR。使用 ADR-FORMAT.md 中的格式。