name: wiki-query description: 基于本知识库已构建的 wiki 和源文件回答用户关于库内内容的问题，或为库内主题的任何任务（写作、分析、咨询等，形式不限）提供依据。先读 wiki/hot.md 与根 wiki/INDEX.md、再按需读相关目录的 INDEX.md 定位页面，读取最相关的 wiki 页面，必要时回溯源文件，再用 [[wikilink]] 引用并标注来源给出综合回答或创作依据——默认检索优先，问答与库内主题的创作都要先查本库，即使话题熟悉也不能凭训练记忆产出库内内容。领域无关，适用于任何已构建 wiki 的知识库。Triggers on: 介绍, 讲解, 总结, 概括, 梳理, 有哪些, 是什么, 是谁, 怎么回事, 为什么, 怎么办, 怎么处理, 怎么解决, 如何, 怎样, 方法, 方案, 原因, 影响, 作用, 对比, 区别, 关系, 根据知识库回答, 查知识库, 查一下知识库, wiki 里怎么说的, 知识库里有没有, 问问知识库, answer from the wiki, what does the knowledge base say, who is, what is, how to, how do I, summarize from notes. version: 2.3.0

wiki-query: 知识库问答

使用 vault 的 wiki 和源文件来回答问题、为库内主题的创作与分析提供依据。先检索、后产出——wiki 的价值就在于避免每次从零检索，也避免凭训练记忆作答或创作（记忆可能与本库版本不符）。不只是问答：主题与本库重叠的任何任务都是检索任务（形式不限），产出必须基于本库材料。

核心原则

• 检索优先，禁止凭记忆：回答关于本知识库资料内容的问题前，必须先读 wiki（见「回答流程」）。即使你"觉得自己知道"，也要以本库 wiki/源文件为准——本库可能是特定版本、摘编或带标注，与你的训练记忆不一致。凭记忆直接作答是本 skill 最要避免的错误。
• 源文件不可变：只能读取源文件，绝对不能修改或删除。
• wiki 优先：先从已编译的 wiki 页面回答，wiki 不足时再回溯源文件。
• 来源标注：回答中必须注明信息来源（哪些 wiki 页面和源文件提供了关键信息）。
• 引用格式：凡引用 wiki 页面或源文件，一律用 [[页面名]] 双括号 wikilink 语法（如 [[知识库五范式]]），不要用纯文本路径或 [文字](路径) markdown 链接——只有 wikilink 能在界面中点击跳转。页面名可用裸名（无需目录），系统会自动定位。

检索优先（默认）

• 默认先查：被调用时先读 wiki/hot.md / 根 wiki/INDEX.md（再按需读相关目录的 INDEX.md）定位相关页面——即使问题看起来是你熟悉的话题也要先查本库（本库可能是特定 / curated / 摘编版本，与你的训练记忆不同，不查无从得知）。确认 wiki 有相关内容后据此作答；wiki 无相关内容时再回溯源文件，或明确说明知识库尚未覆盖。
• 唯一例外：问题问的是工作区的近期活动或状态（如「总结今天的工作」「最近改了哪些文件」——依赖 git log / 文件系统 mtime）。这类直接用原生 Bash/检索回答，不必查 wiki。

Vault 结构

vault 根目录就是当前工作目录。源文件在子目录中（如 raw/、notes/、docs/）。 wiki 相关内容的目录结构：

• raw/ — 未处理的原始资料目录
• raw/wechat/ — 微信通道收到的网页、文件等原始资料统一先放在这里
• wiki/ — 所有 wiki 页面的根目录
• wiki/INDEX.md — 根索引：只列目录级概览（各目录页数 + 覆盖范围）与概述入口页，不逐页罗列
• wiki/<dir>/INDEX.md — 每个内容目录（sources/entities/concepts/comparisons/questions）自己的索引，列全该目录页面及一句话摘要
• wiki/log.md — 按时间顺序记录的操作日志（最新条目在最上面）
• wiki/hot.md — 近期上下文缓存（~500 字，每次操作后刷新）
• wiki/meta/ — 元数据目录（lint 报告等）
• wiki/sources/ — 源文件摘要页，由 raw/、notes/、docs/ 等原始资料生成
• wiki/entities/ — 人物、组织、工具等实体页
• wiki/concepts/ — 概念、模式、框架等
• wiki/comparisons/ — 对比分析页
• wiki/questions/ — 归档的问答页

页面路径规则：

• 默认使用单文件页面，例如 wiki/entities/molio.md、wiki/concepts/agent-routing.md
• 只有当某个实体、项目或主题需要拆成多个稳定页面时，才建立同名目录，并用 index.md 作为该目录入口

回答流程

1. 先读 `wiki/hot.md`（如果存在）：近期上下文缓存，快速了解 wiki 当前状态。
2. 读根 `wiki/INDEX.md`：了解 wiki 全貌（有哪些目录、各自覆盖什么、各多少页），判断哪些目录与问题相关。
3. 读相关目录的 `wiki/<dir>/INDEX.md`：按根 INDEX 的目录行，读一两个相关目录的索引，从中定位最相关的页面。若目录没有 INDEX.md（旧库为单索引布局，根 INDEX 本身逐页列全），直接用根 INDEX 定位即可——不要因找不到目录索引而报错，也不要回头整读根 INDEX 之外的东西。
4. 读相关 wiki 页面：读取定位出的最相关 3-5 个页面。
5. 按需回溯源文件：wiki 页面不能完全回答时，读取原始源文件（raw/、notes/、docs/ 等）获取更多细节。
6. 综合回答：组织一个清晰、结构良好的回答，带 [[wikilink]] 引用与来源标注。

检索义务与任务形式无关：只要任务主题与本库内容重叠——无论它是问答、写作、分析、咨询、决策、策划还是这里没列出的任何形式——都先走同一套检索流程（hot.md → 根 INDEX → 目录 INDEX → 相关页面，必要时回溯源文件），然后基于检索到的库内材料产出，引用 [[wikilink]] 并标注来源。不要检索完又丢开材料凭记忆产出，那等于没查。

根据问题的复杂度自行决定检索深度：

• 简单事实查询：hot.md + 根 INDEX + 相关目录 INDEX + 1 个相关页面通常就够。
• 需要综合多个页面的问题：多读几个相关页面。
• 深度研究性问题：可能需要扫描更多页面甚至回溯源文件。

如果 wiki 尚未构建

wiki/INDEX.md 不存在时：直接检索源文件（raw/、notes/、docs/ 等）回答，并在结尾提示用户可用 wiki-build skill 构建结构化 wiki 以获得更好的问答质量。不要假装 wiki 存在，也不要凭记忆冒充库内内容。

回答格式

提供：

• 对问题的直接回答
• 要点及简要解释
• 相关 [[wiki 链接]] 供进一步阅读
• 来源标注：列出哪些 wiki 页面和源文件为你的回答提供了信息

归档建议

每次回答后，评估回答是否具有归档价值。以下特征命中任一即有归档价值：

• 跨多个来源的综合分析
• 概念对比或方法论比较
• 某个主题的深入探讨（超出 wiki 已有内容）
• 发现了新的实体、关系或洞察

如果有归档价值，在回答末尾提出建议：

• 说明为什么值得归档
• 建议的页面路径和标题
• 等用户确认后再创建页面并更新 INDEX.md 和 log.md（或调用 wiki-save skill）

如果是简单的事实查询或已有 wiki 页面覆盖的内容，不提归档建议。