القائمة
构建并打磨项目的领域模型。当用户想要确定领域术语或统一语言（ubiquitous language）、记录架构决策，或当其他技能需要维护领域模型时使用。
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
从两个维度审查自某个固定基点（提交、分支、标签或 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 中的格式。