关于 add-domain
用于向现有知识系统添加新领域,同时保留共享导航和各领域的独立结构。它引导用户完成系统盘点、配置推导、组合检查、文件生成与验证。
主要功能
- 01盘点现有系统与领域
- 02推导领域词汇和架构
- 03检查命名与架构冲突
- 04验证跨领域组合规则
- 05生成领域文件与指南
- 06生成前等待用户批准
适用场景
- 01为现有知识系统添加领域
- 02设计领域专属笔记与模板
- 03检查跨领域链接和导航
安装
复制下面的命令,在终端中运行。
npx skills add https:/ / github.com/ agenticnotetaking/ arscontexta --skill add-domain安装后在 Claude Code 中输入/add-domain确认已加载。
附带文件skill.json
详细介绍
你正在为现有知识系统扩展一个新领域。这是组合,而非替换。新领域必须与现有领域共存,同时保留自己的词汇、架构和处理模式。共享图谱(Wiki 链接、中心 MOC、描述字段)将所有内容连接起来。
你的任务
添加一个新的知识领域:$ARGUMENTS
参考文件
在推导阶段阅读以下文件:
组合规则:
${CLAUDE_PLUGIN_ROOT}/reference/derivation-validation.md-- 测试 4(多领域组合)用于验证此模式${CLAUDE_PLUGIN_ROOT}/reference/three-spaces.md-- 三空间架构(各领域共用)${CLAUDE_PLUGIN_ROOT}/reference/interaction-constraints.md-- 验证领域配置的一致性
领域配置:
${CLAUDE_PLUGIN_ROOT}/reference/vocabulary-transforms.md-- 领域原生术语映射${CLAUDE_PLUGIN_ROOT}/reference/tradition-presets.md-- 经过预验证的领域配置${CLAUDE_PLUGIN_ROOT}/reference/use-case-presets.md-- 含配置的 3 个预设${CLAUDE_PLUGIN_ROOT}/reference/dimension-claim-map.md-- 维度取值的研究依据${CLAUDE_PLUGIN_ROOT}/reference/failure-modes.md-- 领域脆弱性矩阵
验证:
${CLAUDE_PLUGIN_ROOT}/reference/kernel.yaml-- 12 项不可妥协的原语${CLAUDE_PLUGIN_ROOT}/reference/validate-kernel.sh-- 内核验证脚本
阶段 1:扫描现有系统
自动执行。在添加内容前,先了解现有系统。
1a. 阅读系统配置
阅读 ops/derivation.md,了解:
- 当前维度取值
- 词汇映射
- 平台与自动化级别
- 已启用的功能模块
阅读 ops/config.yaml,了解当前配置值。
1b. 清点现有领域
识别所有现有知识领域:
- 主笔记文件夹及其领域词汇
- 任何现有的次要领域(文件夹、模板、MOC)
- 各领域正在使用的架构字段
1c. 识别维度类型
将 8 个维度划分为系统级或领域可调整:
| 维度 | 类型 | 理由 |
|---|---|---|
| 组织 | 系统级 | 扁平或分层结构适用于整个工作区 |
| 自动化 | 系统级 | 钩子和技能属于工作区级基础设施 |
| 导航深度 | 系统级 | 中心 MOC 结构为共享结构 |
| 颗粒度 | 领域可调整 | 不同领域可能需要不同的颗粒度 |
| 处理 | 领域可调整 | 研究需要较重处理,关系需要较轻处理 |
| 维护 | 领域可调整 | 不同领域的增长速度对应不同的状态阈值 |
| 架构 | 领域可调整 | 各领域的专属字段有所不同 |
| 链接 | 领域可调整 | 有些领域需要语义搜索,有些则不需要 |
系统级维度由现有系统固定。领域可调整维度可针对新领域进行调整。
阶段 2:对话
通过 1–3 轮对话了解新领域。每一轮都使用 AskUserQuestion。
开场问题
围绕新领域提出一个聚焦的问题:
“请介绍一下 [来自 $ARGUMENTS 的领域提示]——你会跟踪哪些内容?这与你现有的 [当前领域词汇] 工作有什么关系?”
第二部分至关重要:了解领域之间的关系,是做出组合决策的关键。
信号提取
随着用户作出回应,提取可调整领域的维度信号:
| 信号 | 维度 | 位置 |
|---|---|---|
| “关于人物的简短笔记” | 粒度 | 适中 |
| “深入分析会话” | 处理 | 重度 |
| “只记住关键时刻” | 处理 | 轻度 |
| “我会经常回顾和更新” | 维护 | 严格阈值 |
| “记录后基本保持不变” | 维护 | 宽松阈值 |
| “需要查找条目之间的模式” | 链接 | 显式+隐式 |
还要提取:
- 数量估计——每批处理多少条笔记
- 时间动态——内容变化有多快
- 词汇——用户自己用来描述笔记、流程和组织方式的词语
- 跨领域关系——这如何与现有领域建立联系
后续提问策略
在开场回应后,提出 1-2 个后续问题,重点关注:
- 确认词汇——“你说的 [用户用词] 是指单条见解,还是较长的条目?”
- 跨领域联系模式——“[新领域] 笔记会与你的 [现有领域] 笔记建立联系吗?如何联系?”
不要直接询问维度。留意自然对话中的相关信号。
阶段 3:推导领域配置
3a. 将信号映射到可调整的领域维度
对于每个可调整维度,确定新领域的位置:
- 用户信号(优先级最高)
${CLAUDE_PLUGIN_ROOT}/reference/use-case-presets.md中最接近的用例预设- 从系统级维度继承
3b. 构建词汇映射
读取 ${CLAUDE_PLUGIN_ROOT}/reference/vocabulary-transforms.md 以获取转换表。
优先级顺序:
- 对话中用户自己的用词
- 用例预设词汇
- 最接近的参考领域组合
为新领域构建完整映射:
| 通用术语 | 新领域术语 | 来源 |
|---|---|---|
| note | [术语] | [用户 / 预设 / 组合] |
| extract / reduce | [术语] | [用户 / 预设 / 组合] |
| connect / reflect | [术语] | [用户 / 预设 / 组合] |
| MOC | [术语] | [用户 / 预设 / 组合] |
| description | [术语] | [用户 / 预设 / 组合] |
| topics | [术语] | [用户 / 预设 / 组合] |
| inbox | [术语] | [用户 / 预设 / 组合] |
3c. 设计领域专属架构
从基础笔记架构(description、topics)开始,并添加领域专属字段:
_schema:
entity_type: "[domain]-note"
applies_to: "[domain-folder]/*.md"
required:
- description
- topics
optional:
- [domain-specific fields based on conversation signals]
enums:
[field]:
- [domain-relevant values]
3d. 冲突检查
**这对多领域组合至关重要。**请确认:
-
文件名唯一性——新领域的笔记标题不会与现有笔记冲突。Wiki 链接会按文件名在整个工作区解析,因此每个文件名都必须唯一。
-
架构字段名——新领域字段不会与现有领域字段冲突。如果两个领域使用相同字段名(例如
type),其枚举值必须互不重叠,或者该字段必须具有兼容的语义。 -
模板名称——新领域模板的名称与现有模板不同。
-
文件夹名称——新领域文件夹不会与现有文件夹冲突。
如果检测到任何冲突,请先解决再继续。
阶段 4:检查组合规则
读取 ${CLAUDE_PLUGIN_ROOT}/reference/derivation-validation.md(测试 4:多领域组合),了解已验证的组合模式。
检查每条组合规则:
规则 1:Wiki 链接在共享命名空间中可明确解析
所有领域的笔记文件名都必须唯一。新领域的命名约定必须与现有约定兼容。
规则 2:中心 MOC 链接到所有领域 MOC
必须更新现有中心 MOC(index.md 或同等文件),使其包含新领域的入口 MOC。层级结构如下:
hub -> existing domain MOCs
-> new domain MOC
规则 3:跨领域反思会搜索所有笔记文件夹
如果连接发现(反思)已启用,就必须跨所有领域进行搜索——新领域中的笔记可能与现有领域中的笔记相关联。语义搜索集合必须包含新领域文件夹。
规则 4:领域专属处理可以并存
如果新领域所需的处理强度与现有领域不同,工作流就必须按笔记类型进行路由。例如,研究笔记采用深度处理,关系笔记采用轻度处理等。
规则 5:逐步加载上下文文件
新领域的方法指南应仅在该领域工作时加载,而不是在每次会话开始时加载。这样可以避免领域不断增加时上下文臃肿。
一致性检查
根据 ${CLAUDE_PLUGIN_ROOT}/reference/interaction-constraints.md 检查新领域的配置:
- 新领域配置与系统级维度之间的硬约束违规
- 新领域特有的软约束警告
- 对现有领域的级联影响
阶段 5:提出方案
向用户准确展示将创建的内容,以及它与现有内容的关联方式。
输出格式:
=== ADD DOMAIN PROPOSAL ===
New domain: [domain name]
Vocabulary: [key term mappings]
--- What will be created ---
Folder structure:
[domain-folder]/ <- [description]
index.md <- domain hub MOC
[domain-inbox]/ <- capture zone (if processing >= moderate)
templates/[domain]-note.md <- note template with domain schema
--- Connections to existing system ---
- Hub MOC (index.md): add [new domain] section with link to [[domain-index]]
- Cross-domain links: [new domain] notes can link to [existing domain] notes and vice versa
- Shared infrastructure: self/, ops/, templates/ remain shared
- Semantic search: [new collection added / not needed at current volume]
--- What does NOT change ---
- Existing [domain] folder: untouched
- Existing templates: untouched
- Existing MOC hierarchy: untouched (hub gains one new link)
- self/ space: shared (methodology.md updated with multi-domain patterns)
- ops/ space: shared (derivation.md updated with domain addition)
--- Domain Configuration ---
| Dimension | Position | Rationale |
|-----------|----------|-----------|
| Granularity | [val] | [reason] |
| Processing | [val] | [reason] |
| Maintenance | [val] | [reason] |
| Schema | [val] | [reason] |
| Linking | [val] | [reason] |
| (system-level dimensions inherited from existing system) |
--- Schema Preview ---
[Show the _schema block for the new domain template]
--- Vocabulary Mapping ---
| Universal | New Domain | Existing Domain |
|-----------|-----------|-----------------|
| note | [term] | [existing term] |
| ... | ... | ... |
Would you like me to create this? I can adjust anything before generating.
=== END PROPOSAL ===
继续操作前等待用户批准。
阶段 6:生成
创建新领域的基础结构。顺序很重要——后续产物会引用前面的产物。
步骤 1:领域文件夹结构
创建领域的笔记文件夹和可选的收件箱文件夹:
mkdir -p [domain-folder]
mkdir -p [domain-inbox] # if processing >= moderate
步骤 2:领域笔记模板
创建 templates/[domain]-note.md,其中包含推导出的 _schema 块、必填和可选字段,以及注释和示例中的领域词汇。
步骤 3:领域中心 MOC
创建 [domain-folder]/index.md:
---
description: [entry point description in domain vocabulary]
type: moc
---
# index
[Orientation paragraph in domain vocabulary]
## [domain:Topics]
(topics will emerge as notes accumulate)
## Getting Started
1. Capture your first [domain:note]
2. Connect it to this hub
步骤 4:领域指南
创建一份领域专属的方法文档,在该领域工作时加载。对于 Claude Code:创建 .claude/skills/[domain]-guide/SKILL.md,或在上下文文件中添加一个章节。对于其他平台:创建独立的指南文件。
指南涵盖:
- 如何在该领域捕获内容
- 如何处理(按推导出的强度)
- 何时进行跨领域关联
- 领域专属质量标准
- 领域词汇参考
步骤 5:更新中心 MOC
将新领域添加到现有中心 MOC(index.md):
## [New Domain Name]
- [[domain-index]] -- [description of what this domain tracks]
步骤 6:更新上下文文件
在上下文文件中添加:
- 领域路由:在 [domain] 工作时,加载 [domain guide]
- 词汇:将新领域术语添加到词汇参考
- 处理:如果处理强度不同,记录路由方式
- 跨领域链接:何时以及如何跨领域关联
步骤 7:更新 self/methodology.md
添加多领域工作模式:
- 如何在不同领域间切换
- 何时创建跨领域关联
- 各领域的处理触发条件
步骤 8:更新 ops/derivation.md
记录领域的添加:
- 新领域名称和词汇
- 可调整的领域维度位置及其理由
- 已验证的组合规则
- 跨领域关联模式
- 添加日期和上下文
步骤 9:更新语义搜索(如已配置)
如果已配置 qmd 或同类工具:
# Add new collection for domain folder
qmd update
qmd embed
更新 .mcp.json 或同类配置,以包含新集合。
步骤 10:领域处理技能(如果处理强度 >= 中等)
如果新领域需要自己的处理技能(因为处理强度或词汇与现有领域不同),生成适配该领域的 reduce/reflect/verify 技能版本。
如果现有技能能够按笔记类型处理多领域路由,则更新现有技能,而不是创建重复技能。
阶段 7:验证
新领域文件的内核检查
对新领域的文件运行内核验证:
- 所有新文件的 YAML frontmatter 均有效
- 新文件中的 Wiki 链接均可解析(包括跨领域链接)
- 可从中心访问新领域 MOC
- 描述字段均已填写
- Topics 页脚均引用该领域 MOC
组合验证
- 无字段冲突——搜索所有模板中的字段名称,确认不存在语义冲突
- Hub 可访问性——Hub MOC 链接到所有领域 MOC,所有领域 MOC 链接到各自的笔记
- 跨领域链接测试——从新领域创建一个指向现有领域的测试链接,确认链接有效
- 文件名唯一性——确认各领域之间没有重复的文件名:
find . -name "*.md" -not -path "./.git/*" -not -name "README.md" -not -name "SKILL.md" \ -exec basename {} \; | sort | uniq -d - 词汇隔离——搜索新领域的文件,查找现有领域的词汇术语(这些术语不应出现)
汇报结果
=== DOMAIN ADDITION VALIDATED ===
Domain: [name]
Files created: [N]
Hub updated: yes
Cross-domain links: functional
Filename uniqueness: verified
Schema conflicts: none
Your system now has [N] domains:
- [existing domain] ([N] notes)
- [new domain] (0 notes -- ready to start)
Next steps:
1. Capture your first [domain:note] in [domain-folder]/
2. Cross-domain connections will emerge naturally as you work
3. Run /health when /next flags maintenance issues in either domain
=== END VALIDATION ===
质量标准
- 除非明确说明,否则绝不修改现有内容(更新 Hub MOC、上下文文件和推导文件是唯一允许修改现有文件的情况)
- 每个领域都有自己的词汇——疗法用户绝不会在自己的反思文件夹中看到“理赔”
- 鼓励跨领域关联,但绝不强求
- Hub MOC 是唯一统一的入口——必须链接到所有领域
- 模板是各领域架构的唯一事实来源——绝不在两个位置定义架构
- 如果新领域的处理需求存在显著差异,应优先采用独立的处理路径,而不是一刀切
- 验证添加新领域后系统仍能通过内核检查
- 在 ops/derivation.md 中记录所有内容——未来重新播种时需要了解多领域组合方式