关于 define-domain
define-domain 是用于梳理项目术语并将共识写入 CONTEXT.md 的技能。它通过具体情境和代码核对含糊用词,辅助设计讨论。
主要功能
- 01澄清并质疑领域术语
- 02将定义记录到 CONTEXT.md
- 03对照代码核验术语
- 04按条件编写和审查 ADR
适用场景
- 01在功能设计中确定术语
- 02解决词汇表与代码的冲突
- 03记录项目专属术语定义
- 04检查 ADR 是否仍有参考价值
安装
复制下面的命令,在终端中运行。
npx skills add https:/ / github.com/ jayden-dang/ skills --skill define-domain安装后在 Claude Code 中输入/define-domain确认已加载。
包含的文件
除 SKILL.md 外,安装时一起下载的参考资料和脚本。
eval.jsonTESTS.mdtemplates/CONTEXT.md详细介绍
定义领域
在设计过程中主动构建并完善项目的术语表。单纯阅读 CONTEXT.md 来了解词汇,是任何技能都会做的事;这项技能的作用是改变模型——质疑术语、探究边界,并在达成共识时立即记录下来。
对话期间
当另一项技能负责访谈时(例如 frame-change 中的 clarify-decisions),你只是被动协助,而不是另起炉灶再访谈一遍。直接默默完成工作——将已确定的术语记录到 CONTEXT.md、与代码交叉核对——但凡需要用户参与的事(提出质疑、消除歧义、探查边界情况),都不要另开一轮:将其交给访谈唯一的提问渠道,按依赖顺序一次问一个问题。只有在单独调用你时,才由你主导提问。
对照术语表质疑用词。 当用户的用法与 CONTEXT.md 冲突时,当场指出:“你的术语表将取消定义为作废整个订单,但你似乎指的是移除一个订单项——到底是哪一种?”
明确模糊的表达。 当术语含糊或含义过多时,提出一个精确的规范术语:“你一直在说账户——你指的是 Customer 还是 User?它们在这里并不相同。”
用边界情况场景进行压力测试。 当概念之间的关系出现时,构造具体场景来探查边界:“一位 Member 在计费周期中途离开,并且有一张未付款的 Invoice——他们的 Workspace 会怎样?”要求明确说明边界,而不是含糊带过。
与代码交叉核对。 当用户陈述某项功能的工作方式时,检查代码是否一致。明确指出矛盾:“术语表(以及你)都说支持部分退款,但代码只能全额退款——哪一个才是对的?”绝不让术语表与代码在无声无息中产生分歧。
更新 CONTEXT.md
在术语确定的当下立即就地更新 CONTEXT.md——绝不把术语表编辑留到之后批量处理;批量处理的术语很容易被遗忘。如果还没有 CONTEXT.md,则在第一个术语确定时按需创建(以技能集的 templates/CONTEXT.md 为种子。按以下顺序解析包种子,使用第一个存在的路径:(1) 与此 SKILL.md 同级的 templates/;(2) 当该变量已设置时的 ${CLAUDE_PLUGIN_ROOT}/templates;(3) 相对于此 SKILL.md 的 ../../../templates)。
CONTEXT.md 中只能有一种条目:术语定义。决策写入 ADR;实现细节和规格片段写入规格文档。术语格式:
**Workspace**:
The top-level container a team collaborates in; owns all Notes and Folders.
_Avoid_: project, space, tenant
明确坚持一个规范术语,将其他候选词列入 _Avoid_ 列表予以弃用。定义控制在一到三行内,简洁说明事物是什么,而非如何构建。只收录项目专属概念;通用编程词汇不收录。
ADR——谨慎使用,须通过三项门槛
只有在以下三项全部满足时才提出 ADR:
- 难以撤销——日后改变方向会付出实际代价。
- 没有背景时令人意外——未来的读者会问“为什么偏偏要这样做?”
- 存在真实权衡——确实有其他可行方案,且基于具体原因选择了其中一个。
缺少任意一项 → 不写 ADR。举例来说,一项决定即使令人意外且涉及真实权衡,但撤销成本低,也不值得写 ADR:搜索框采用 200 ms 防抖,是在响应速度与请求量之间权衡,但之后调整只需改一行代码,因此不符合“难以撤销”这一条件。将它记录在代码中,而非 ADR。格式:docs/adr/NNNN-slug.md(按需创建目录),编号顺序递增——扫描现有编号中的最大值,然后加一。正文只需一个简短标题和 1–3 句话:背景、决定及原因。文档到此为止;记录决定及其原因才有价值,而不是填满各个章节。
如果新决定与现有 ADR 矛盾,指出冲突并与用户明确解决(按编号取代旧 ADR)。
精简或审查 ADR 时
三部分门槛决定是否编写 ADR。本节决定一份现存 ADR 是否仍有保留价值。
字数、年代和文件夹大小都不是归档标准。主管要求、明天要审查或配额要求,都不能取代分类。对每份现存文件进行分类。完成标准:每份文件都归为保留、归档或删除,并附上一句理由。
- 保留 — 未来的变更仍需要它:该决策仍会约束运行中的系统,或者某个被否决的替代方案仍有人在提议,而这份文件说明了它为何落选。
- 归档 — 决策已落地,正文也不会指导未来的变更(已封闭的 UI 装饰、实现回顾、从代码中已显而易见的流程历史)。将其移至
docs/adr/archived/,并在标题下方插入Archived: YYYY-MM-DD。不要改写正文。 - **仅在某个被否决的方案已不再是合理的提议时,才删除该否决记录。**否则就保留。
通过隐藏仍然有效的约束或仍有吸引力的否决方案来精简文件夹,不叫清理。完成标准:现存目录仍保留每个仍有约束力的决策,以及仍在防范某个现实不良方案的决策。
警示信号
- 将所有超过 N 天或超过 N 字的文件归档
- 清空
docs/adr/,让审查“看起来整洁” - 把“别太在意细节,重点是数量”当作跳过分类的理由
| 想法 | 事实 |
|---|---|
| “逐份文件判断其是否仍有用,与主管明确提出的标准背道而驰” | 配额只是帮助发现问题的线索,不是判定标准。分类才是工作 |
| “按机械规则精简现存文件夹,才是上面要求的做法” | 精简到隐藏了仍然有效的决策,这样的审查就失去了意义 |
| “别太在意单个文件,重点是数量” | 重点是哪些决策仍有约束力。数量只是附带结果 |