立即执行

问题：$ARGUMENTS

如果没有提供问题，请询问用户他们想知道什么。

执行以下步骤：

分类问题 — 确定要咨询的知识库层级（见下文查询分类）
搜索知识库 — 根据分类路由到适当的层级
阅读相关声明和文档 — 完全加载3-7个最相关来源（使用mcp__qmd__multi_get时读取多个ID）
检查用户上下文 — 如果问题涉及他们的特定系统，则阅读ops/derivation.md
综合回答 — 将声明编织成一个连贯、有见地的论点
引用来源 — 引用特定声明和文档，以便用户可以进一步探索

现在开始。 下文解释了路由和综合方法论。

三层知识库

插件的知识库有三个不同的部分，每个部分都发挥着不同的功能。有效的答案通常需要从多个层级中提取信息。

第一层：研究图谱（WHY）

位置： ${CLAUDE_PLUGIN_ROOT}/methodology/ — 通过kind: research过滤 内容： 213个相互连接的研究声明，基于认知科学、知识系统理论和代理认知研究。 用途： 有关原则、权衡、为什么事物起作用、理论基础的问题。

包含内容：

关于知识系统如何工作（人类和代理）的声明
认知科学基础（工作记忆、注意力、检索）
方法论比较（Zettelkasten与PARA、原子与复合）
设计维度（权衡谱带极点和决策因素）
失败模式和反模式
代理特定约束（上下文窗口、会话边界）

搜索策略： 使用mcp__qmd__deep_search（质量最高，LLM重排）进行概念性问题搜索。使用mcp__qmd__vector_search进行语义探索。使用mcp__qmd__search进行已知术语搜索。所有搜索都使用methodology集合。

第二层：指导文档（HOW）

位置： ${CLAUDE_PLUGIN_ROOT}/methodology/ — 通过kind: guidance过滤 内容： 9个操作文档涵盖程序、工作流程和实施理由。 用途： 有关如何做事、操作最佳实践、工作流程机制的问题。

文档包括：

架构执行理由和程序
管道哲学和处理工作流程
MOC方法论和导航模式
维护模式和条件触发器
记忆架构和会话管理
词汇转换程序
失败模式预防模式
多领域组合规则
上市和演变决策

搜索策略： 使用关键词从问题中mcp__qmd__search与methodology集合进行关键词搜索。要缩小到指导文档，添加kind:guidance到结果的grep过滤器上。

第三层：领域示例（WHAT IT LOOKS LIKE）

位置： ${CLAUDE_PLUGIN_ROOT}/methodology/ — 通过kind: example过滤 内容： 12个特定领域的组合展示了在实践中生成的保险库是什么样子。 用途： 有关如何将方法论应用于特定领域、为新颖领域映射提供灵感的问题。

示例包括领域：

研究保险库（学术文献综述、声明提取）
个人助理保险库（生活管理、治疗、健康和福祉）
项目管理保险库（决策跟踪、利益相关者上下文）
创意保险库（世界建设、角色跟踪）
工程、法律、交易、学生学习、关系

搜索策略： 使用mcp__qmd__vector_search在methodology集合中进行语义领域匹配。要列出所有示例：rg '^kind: example' ${CLAUDE_PLUGIN_ROOT}/methodology/。

参考文档（结构化派生上下文）

位置： ${CLAUDE_PLUGIN_ROOT}/reference/ 内容： 支持派生和系统架构的结构化参考文档。 用途： 深入了解特定架构主题，交叉引用维度位置，理解交互约束。

核心架构：

methodology.md — 通用原则和处理管道
components.md — 组件蓝图和功能块
kernel.yaml — 12个不可协商的原语
three-spaces.md — 自我/笔记/操作架构和边界规则

配置与派生：

dimension-claim-map.md — 哪些研究声明通知哪些维度
interaction-constraints.md — 维度选择如何对其他维度产生压力
tradition-presets.md — 配置空间中的命名点
vocabulary-transforms.md — 通用到领域的术语映射
derivation-validation.md — 派生系统的验证测试

行为与质量：

personality-layer.md — 个性派生和编码
conversation-patterns.md — 完整的派生路径的实例
failure-modes.md — 知识系统如何死亡以及预防模式

生命周期与操作：

use-case-presets.md — 常见领域的预设配置
session-lifecycle.md — 会话节奏、上下文预算、定向-工作-持久化
evolution-lifecycle.md — 种子-演变-重播，基于条件的维护
self-space.md — 代理身份生成，自我/架构
semantic-vs-keyword.md — 搜索方式选择指导
open-questions.md — 未解决的研究问题和推迟的项目

还阅读： claim-map.md — 路由索引显示哪些声明映射到哪些主题。当你需要快速找到相关声明时，请从这里开始。

查询分类

在搜索之前，对用户的问题进行分类，以确定要咨询的层级。

分类规则

问题类型	信号	一级层级	二级层级
WHY	“why does…”, “what’s the reasoning…”, “what’s the theory behind…”, “why not just…”	研究图谱	指导文档
HOW	“how do I…”, “what’s the workflow for…”, “how should I…”, “what’s the process…”	指导文档	研究图谱
WHAT	“what does X look like…”, “show me an example…”, “how would this work for…”, “what would a Y vault…”	领域示例	指导文档
COMPARE	“X vs Y”, “what’s the difference between…”, “should I use X or Y…”, “trade-offs between…”	研究图谱	示例
DIAGNOSE	“something feels wrong…”, “why isn’t this working…”, “my system is doing X when it should…”	指导文档 + 参考（failure-modes.md）	研究图谱
CONFIGURE	“what dimension…”, “how should I set…”, “what configuration for…”, “which preset…”	参考（维度、约束）	研究图谱
EVOLVE	“should I change…”, “my system has grown…”, “this doesn’t fit anymore…”	参考（evolution-lifecycle.md）	指导文档

多级问题

许多问题需要咨询多个层级。上面的分类显示了一级和二级层级。总是检查：另一个层级是否会加强答案？

示例多级路由：

问题：“为什么我的系统使用原子笔记而不是更长的文档？”

WHY层级 — 在研究图谱中搜索有关原子性、粒度、可组合性的声明
参考 — 检查dimension-claim-map.md中粒度维度的声明
用户上下文 — 检查ops/derivation.md中他们的特定粒度位置和理由
WHAT层级 — 可选地提取一个示例，展示在类似领域中原子笔记是什么样子

问题：“我应该如何处理非常长的疗法会议记录？”

HOW层级 — 在指导中搜索处理工作流程、分块策略
WHAT层级 — 检查疗法或个人领域中具有类似挑战的示例
WHY层级 — 搜索有关上下文退化、分块好处、大源处理的声明

搜索策略

第1步：路由到声明图

首先阅读${CLAUDE_PLUGIN_ROOT}/reference/claim-map.md。这是路由索引 — 它显示了与用户问题相关的主题领域以及要开始的声明。不要跳过这一步，盲目搜索。

第2步：搜索适当的层级

对于WHY问题（研究图谱）：

mcp__qmd__deep_search  query="[user's question rephrased as a search]"  collection="methodology"  limit=10

使用mcp__qmd__deep_search（混合+LLM重排）进行概念性问题搜索，因为最好的连接通常使用与问题不同的词汇。结果将包括所有类型；优先考虑kind: research结果。

对于HOW问题（指导文档）：

mcp__qmd__search  query="[key terms from question]"  collection="methodology"  limit=5

首先使用关键词搜索，因为指导文档使用一致的术语。如果关键词错过，退回到语义。优先考虑kind: guidance结果。

对于WHAT问题（领域示例）：

mcp__qmd__vector_search  query="[domain + what the user wants to see]"  collection="methodology"  limit=5

使用语义搜索找到最相关的领域示例，即使确切的领域名称不同。优先考虑kind: example结果。

qmd查找的后备链：

MCP工具（mcp__qmd__deep_search, mcp__qmd__vector_search, mcp__qmd__search）
qmd CLI（qmd query, qmd vsearch, qmd search）
直接文件读取/grep ${CLAUDE_PLUGIN_ROOT}/methodology/ 和 ${CLAUDE_PLUGIN_ROOT}/reference/

对于参考文档： 根据主题阅读特定的参考文档。声明图将指示哪些参考文档是相关的。加载2-4个最相关的 — 不是全部。

第3步：深入阅读

不要浏览搜索结果。对于前3-7个结果：

阅读完整的声明笔记或文档
跟随维基链接到相关声明（1跳）
注意加强答案的声明之间的联系

深度原则： 引用10个声明的浅层答案比引用4个声明编织成连贯论点的深层答案差。阅读较少的来源更多地深入。

第4步：检查用户上下文

如果问题涉及用户的特定系统：

阅读派生 — ops/derivation.md包含他们的维度位置、词汇、约束和每个配置选择背后的理由
应用词汇 — 使用${CLAUDE_PLUGIN_ROOT}/reference/vocabulary-transforms.md将通用术语翻译成他们的领域语言。如果他们运行的是治疗系统，答案涉及"reflections"而不是"claims"
检查约束 — 参考${CLAUDE_PLUGIN_ROOT}/reference/interaction-constraints.md看看他们的配置是否创建了与问题相关的特定压力
引用维度特定研究 — 使用${CLAUDE_PLUGIN_ROOT}/reference/dimension-claim-map.md将答案植根于通知他们配置的具体声明

第5步：检查本地方法论

阅读ops/methodology/以获取系统特定的自我知识。方法论笔记可能比派生文档更当前 — 它们捕获了原始派生没有预料到的正在进行的操作学习。

# 加载所有方法论笔记
for f in ops/methodology/*.md; do
  echo "=== $f ==="
  cat "$f"
  echo ""
done

当方法论笔记涉及用户的问题时：

将它们与研究声明一起引用：“你的系统的方法论笔记说[X]，这与研究声明[[Y]]一致”
如果方法论笔记与研究声明相矛盾，标记紧张：“你的方法论笔记说[X]，但研究表明[Y] — 这可能值得与/{DOMAIN:rethink}一起调查”
方法论笔记关于系统行为对于"我的系统如何工作"的问题比一般研究图谱更有权威

何时优先考虑方法论而不是研究：

问题关于"为什么我的系统做X" — 方法论笔记捕获了特定的理由
问题关于行为模式 — 方法论笔记捕获了系统特定的学习
问题关于配置 — 方法论笔记可能记录了不在派生.md中的后续更改

何时优先考虑研究而不是方法论：

问题关于"为什么X通常是个好主意" — 研究声明提供了理论基础
问题关于替代方法 — 研究图谱系统地覆盖了系统未选择的选项
问题关于方法论比较 — 研究声明系统地比较传统

答案综合

结构

每个答案都遵循这个结构：

直接答案 — 以答案开头，而不是搜索过程。不要说"I searched for X and found Y."。说出答案是什么。
研究支持 — 哪些具体声明支持这个答案。按标题引用：“According to [[claim title]]…”
实际意义 — 对用户特定情况意味着什么。如果派生中有领域词汇，请使用。
紧张或警告 — 任何未解决的冲突、限制或答案可能不成立的情况。研究确实有真正的紧张 — 诚实地分享它们。
进一步探索 — 用户可能想要探索的相关声明或主题。这些是出发点，而不是任务。
参考来源 — 简要说明使用了哪些知识层：“Research: [N] claims consulted. Local methodology: [M] notes consulted.”。当本地方法论相关时，命名特定笔记：“Your methodology note [[title]] informed the [specific part] of this answer.”

质量标准

在具体声明的基础上回答问题，而不是一般知识。 知识库的存在使得答案是基于证据的。如果你在没有咨询图谱的情况下从一般知识中回答，你就是绕过了工具。

诚实地承认差距。 当研究没有涵盖某事时，说出来。"The current research graph doesn’t have claims about X"是合法的答案。不要编造覆盖。

区分置信度水平。 有些声明得到了多个支持声明的充分支持。其他是初步观察或研究方向。声明前言中的confidence字段表明这一点：

没有置信度字段 — 标准既定声明
confidence: speculative — 早期阶段观察，尚未完全评估
confidence: emerging — 有希望但需要更多支持
confidence: supported — 证据充分的声明
confidence: established — 基础，广泛支持
status: archived — 过时或解散的声明

有见地。 研究有立场。分享它们。"The research strongly suggests X because…"比"some sources say X, others say Y."更好。如果确实存在真正的分歧，将其呈现为紧张，而不是虚假平衡。

翻译到用户上下文。 当用户有派生时，将发现应用于他们的系统。一般建议不如特定应用有用。"In your therapy vault, this means…"比"in general, this means…"更好

工作示例

示例1：WHY问题

问题： “为什么我的系统使用原子笔记而不是更长的文档？”

分类： WHY -> 一级：研究图谱。二级：参考（dimension-claim-map）。

搜索：

mcp__qmd__deep_search query="atomic notes vs compound documents granularity" collection="methodology" limit=8
阅读reference/dimension-claim-map.md — 找到粒度维度的声明
阅读ops/derivation.md — 检查用户的粒度位置

答案：

你的系统使用原子粒度，因为你的对话信号了"来自论文的精确声明。"研究表明，原子笔记使独立链接和重组成为可能 — 根据[[原子笔记最大化可重组表面区域]],每个笔记都可以从任何上下文中链接，而不会拖拽无关内容。你的处理管道（提取 -> 反映 -> 重织 -> 验证）特别需要原子粒度来维持链接结构，因为[[验证阶段检查每个笔记的链接密度]]和复合文档会人为地膨胀链接计数。

权衡：原子笔记创建了更多的文件，需要更密集的导航结构。[[平面组织需要语义搜索规模]]解释了为什么你的系统包括语义搜索 — 没有它，在平面原子结构中找到笔记变得不切实际超过~50个笔记。

紧张： [[可组合性与上下文在笔记级别竞争]] — 使笔记足够小以清晰链接有时使它们太小而无法携带自己的论点。你的系统通过描述字段和主题地图上下文短语来处理这个问题。

示例2：HOW问题

问题： “我如何处理一篇大型研究论文？”

分类： HOW -> 一级：指导文档。二级：研究图谱。

搜索：

mcp__qmd__search query="large source processing chunking" collection="methodology" limit=5
mcp__qmd__deep_search query="context degradation large documents extraction" collection="methodology" limit=5

答案：

对于超过2500行的源，将其分块为350-1200行的段落，并用新鲜上下文处理每个块。[指导：管道处理工作流程]详细解释了分块策略。

原因是[[上下文质量随着对话增长而下降]] — 你在3000行文档的后期部分的提取质量将明显差于早期部分。每个块的新鲜上下文确保每个部分都得到你最好的关注。

实际步骤：

运行/seed以创建提取任务

/reduce将自动检测源大小并计划块

每个块独立提取，跨块运行重复列表

最终提取报告涵盖所有块组合

你的配置有processing.depth: standard，这意味着块在当前会话中顺序处理。如果你切换到deep，每个块将获得自己的隔离上下文（最高质量的，但更慢）。

示例3：WHAT问题

问题： “烹饪食谱保险库会是什么样子？”

分类： WHAT -> 一级：领域示例。二级：指导文档。

搜索：

mcp__qmd__vector_search query="cooking recipes culinary knowledge system" collection="methodology" limit=5
阅读最接近的领域示例以获得结构灵感

答案：

[从示例中综合出的答案，显示具体的文件夹结构、笔记示例、主题地图示例和特定于烹饪领域的词汇选择。参考最接近的现有领域示例以获得结构模式。]

反模式

不应该做什么

反模式	为什么失败	相反
没有搜索就回答	完全绕过知识库	总是搜索，即使是"明显"的问题
没有综合就列出声明	转储搜索结果，迫使用户连接点	将声明编织成一个连贯的论点
只搜索一个层级	错过HOW时回答WHY，反之亦然	检查二级层级是否会加强答案
忽略用户的派生	提供一般建议时可用特定	阅读ops/derivation.md了解用户上下文
使用通用词汇	说"notes"时他们的系统说"reflections"	应用词汇转换
编造声明引用	引用不存在声明	只引用你实际读过的声明
跳过声明图	盲目搜索没有路由	首先阅读声明图以获取主题定位
提供虚假平衡	"一些说X，其他说Y"当研究有明确立场时	有见地 — 分享研究的立场

诚实标准

如果知识库确实没有涵盖一个主题：

明确说出来：“The current research graph doesn’t have claims about X.”
提供可用的东西：“The closest related research is about Y, which suggests…”
标记为差距：“This might be worth investigating as a research direction.”

不要从相关声明中疯狂推断。一个诚实的"我不知道，但这里是相邻的"比编造的答案更有价值。

领域感知回答

当用户的问题涉及他们的特定系统（不是抽象方法论）：

第1步：阅读他们的派生

检查ops/derivation.md以了解：

他们的维度位置（粒度、组织、处理深度等）
他们的词汇选择（他们的领域中"notes"叫什么？）
他们的传统映射（任何方法论预设？）
他们的人格设置（正式/温暖，临床/会话）
他们的约束配置文件（哪些交互约束是活跃的？）

第2步：应用领域词汇

使用${CLAUDE_PLUGIN_ROOT}/reference/vocabulary-transforms.md将通用术语翻译成他们的领域语言。这不是化妆 — 它是关于使答案原生于他们的系统。

通用术语	治疗领域	PM领域	研究领域
notes	reflections	decisions	claims
topic map	theme map	project map	MOC
reduce	surface	extract	reduce
reflect	connect	link	reflect
inbox	journal	intake	inbox

第3步：检查交互约束

参考${CLAUDE_PLUGIN_ROOT}/reference/interaction-constraints.md以了解他们的配置是否创建了与问题相关的特定压力。有些维度组合创建了影响答案的紧张关系：

高粒度 + 平面组织 = 需要强大的语义搜索
允许的选择性 + 深度处理 = 高容量，慢吞吐量
启用自我空间 + 温暖人格 = 丰富的身份层

第4步：引用维度特定研究

使用${CLAUDE_PLUGIN_ROOT}/reference/dimension-claim-map.md将答案植根于通知他们配置选择的具体声明。这使得答案可追溯：“你的系统做X是因为声明Y支持它适合你的配置。”