---
name: mywiki-query
description: "查询 myWiki 知识库——搜索节点、综合回答并引用来源，有价值的洞见可回写为新节点。"
---

# myWiki 查询

用户提出一个问题。你用 wiki 积累的知识来回答，带引用。

## Step 0 — 定位 wiki

按主 SKILL.md 的路径查找规则定位 wiki 目录（优先 `~/.mywiki/config.json` 中的 `wikiDir`，默认 `~/mywiki`）。以下用 `<wiki>` 指代实际路径。

## Step 1 — 搜索

1. 读 `<wiki>/meta/index.md`，识别候选节点
2. 扫描 `<wiki>/nodes/` 文件名，关键词匹配
3. 读取最相关的节点（通常 3~10 个）

如果相关节点少于 2 个，或只有孤立 seed 节点，不要强行综合。明确告诉用户 wiki 尚未覆盖这个领域，并建议先 ingest 相关素材。仍可基于已找到的节点给出有限回答，但要标明覆盖不足。

## Step 2 — 综合回答

将多个节点的信息编织成答案。使用 `[[node-id]]` 作为内联引用。

回答应该展示 wiki 的价值——呈现用户可能没看到的节点间联系。跨域连接尤其有价值。

不要忽略 `observation` 节点。事实/概念节点是回答的证据层；当问题问“是什么、怎么理解、为什么这个洞见成立”时，优先把相关 observation 和上层 insight 一起引用。

如果引用的是 `insight`，尽量标明它属于 `explicit` 还是 `inferred`：前者是素材/用户显式写出的洞察，后者是 wiki 基于事实节点推出来的洞察。不要把两者混成同一种来源。

只有在节点之间确实存在语义连接时才做跨域综合。wiki 很小或命中很少时，优先诚实说明缺口，而不是制造联系。

## Step 3 — 提议回写

如果你的回答包含真正新的洞见（不只是已有节点的复述），主动提议：

> "这个综合连接了 [X] 和 [Y]，现有节点中没有捕获这个理解。要不要存为新节点？"

用户同意后，按 mywiki-ingest 流程创建节点。

## Step 4 — 记录日志

追加到 `<wiki>/meta/log.md`：
```markdown
## [YYYY-MM-DD] query | <问题摘要>
- 查阅: node-a, node-b, node-c
- 新建节点: <id 或 "无">
```

## 规则

- ✅ 总是用 `[[node-id]]` 引用具体节点
- ✅ 主动呈现跨域连接
- ✅ 只有真正新的洞见才提议回写，复述不需要
- ❌ 不捏造 wiki 中没有的信息——如实说"wiki 中尚未覆盖这个话题"
