mcpField
A
add-domain

add-domain

github.com/agenticnotetaking生产力3.5k44 次安装36 周前更新
代码仓库

关于 add-domain

用于向现有知识系统添加新领域,同时保留共享导航和各领域的独立结构。它引导用户完成系统盘点、配置推导、组合检查、文件生成与验证。

主要功能

  1. 01盘点现有系统与领域
  2. 02推导领域词汇和架构
  3. 03检查命名与架构冲突
  4. 04验证跨领域组合规则
  5. 05生成领域文件与指南
  6. 06生成前等待用户批准

适用场景

  1. 01为现有知识系统添加领域
  2. 02设计领域专属笔记与模板
  3. 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 个后续问题,重点关注:

  1. 确认词汇——“你说的 [用户用词] 是指单条见解,还是较长的条目?”
  2. 跨领域联系模式——“[新领域] 笔记会与你的 [现有领域] 笔记建立联系吗?如何联系?”

不要直接询问维度。留意自然对话中的相关信号。


阶段 3:推导领域配置

3a. 将信号映射到可调整的领域维度

对于每个可调整维度,确定新领域的位置:

  • 用户信号(优先级最高)
  • ${CLAUDE_PLUGIN_ROOT}/reference/use-case-presets.md 中最接近的用例预设
  • 从系统级维度继承
3b. 构建词汇映射

读取 ${CLAUDE_PLUGIN_ROOT}/reference/vocabulary-transforms.md 以获取转换表。

优先级顺序:

  1. 对话中用户自己的用词
  2. 用例预设词汇
  3. 最接近的参考领域组合

为新领域构建完整映射:

通用术语新领域术语来源
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. 冲突检查

**这对多领域组合至关重要。**请确认:

  1. 文件名唯一性——新领域的笔记标题不会与现有笔记冲突。Wiki 链接会按文件名在整个工作区解析,因此每个文件名都必须唯一。

  2. 架构字段名——新领域字段不会与现有领域字段冲突。如果两个领域使用相同字段名(例如 type),其枚举值必须互不重叠,或者该字段必须具有兼容的语义。

  3. 模板名称——新领域模板的名称与现有模板不同。

  4. 文件夹名称——新领域文件夹不会与现有文件夹冲突。

如果检测到任何冲突,请先解决再继续。


阶段 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:验证

新领域文件的内核检查

对新领域的文件运行内核验证:

  1. 所有新文件的 YAML frontmatter 均有效
  2. 新文件中的 Wiki 链接均可解析(包括跨领域链接)
  3. 可从中心访问新领域 MOC
  4. 描述字段均已填写
  5. Topics 页脚均引用该领域 MOC
组合验证
  1. 无字段冲突——搜索所有模板中的字段名称,确认不存在语义冲突
  2. Hub 可访问性——Hub MOC 链接到所有领域 MOC,所有领域 MOC 链接到各自的笔记
  3. 跨领域链接测试——从新领域创建一个指向现有领域的测试链接,确认链接有效
  4. 文件名唯一性——确认各领域之间没有重复的文件名:
    find . -name "*.md" -not -path "./.git/*" -not -name "README.md" -not -name "SKILL.md" \
      -exec basename {} \; | sort | uniq -d
    
  5. 词汇隔离——搜索新领域的文件,查找现有领域的词汇术语(这些术语不应出现)
汇报结果
=== 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 中记录所有内容——未来重新播种时需要了解多领域组合方式

评论

支持 Markdown