query

技能：查询

WHAT

用途和上下文

• 用途： 综合 Wiki 知识来回答问题。Wiki 中未收录的有价值发现会整理为新页面，让知识随时间不断积累。
• 触发条件（何时调用）： 用户提出的问题需要综合多个 Wiki 页面或原始来源时；或需要了解“依据是什么”“哪条边提供引用”“图中的路径”“引用证据”时。
• 非目标： 不使用 Wiki / raw/ 之外的知识回答（不编造事实）；不自行摄取整个来源（存在缺口 → 调用 ingest）；不修改页面的 drift 标记（由 /lint / wiki-sync 负责）。

心智模型

问题 → 第 0 层 mem-rank（情景记忆）→ 第 1 层 rg 按术语覆盖率排序 → 第 2 层读取排名前 N 的完整页面 → 第 3 层 wikilinks → drift 检查门 → 综合 → [有新见解时创建新 Wiki 页面] → 日志 + telemetry → Evidence（边 eid）。

输入和输出约定

	字段	必填？	含义
In	问题	是	需要综合多个 Wiki 页面 / raw
Out	答案	是	如有警告，则在答案开头显示 ⚑ CẢNH BÁO DRIFT
Out	## Evidence 部分	是	提供实际依据的边 eid，或 Evidence: none (page-level only)
Out	新 Wiki 页面 + index + 日志	仅当有新见解时	概念或来源
Out	wiki/log.md 行 + query-log.py 记录	是	日志格式为 ## YYYY-MM-DD — query — <question summary>；telemetry 采用 fail-open
Out	输出报告草稿	是（0 个 artifact 时除外）	Delivery 部分

规则和能力

• RULE-01（MUST）：OKF v0.1（R9）： 每个新 Wiki 页面都必须以 YAML frontmatter 块（---）开头，并包含非空的 type；复制匹配的 _template.md，并保留 ## Origin 部分。
• RULE-02（MUST）：绝不编造事实。只能综合 Wiki 和 raw/ 中的内容。
• RULE-03（SHOULD）：查询揭示知识缺口（缺少实体、缺少概念）时，如果存在相关 raw/ 来源，应触发 ingest。
• RULE-04（MUST）：渐进式披露——第 1 步不要加载整个页面；只读取排名前 N 的页面。
• RULE-05（MUST）：必须将 drift 警告原文放入答案——不得省略，也不得拒绝回答。
• 能力：读取 Wiki + raw/ + 情景记忆层 + Wiki 图谱；写入新 Wiki 页面、index、日志和 telemetry。有关代码的问题可使用代码图谱。

故障边界

• Wiki 和 raw/ 中没有相关信息 → 明确说明缺少依据（partial），不得编造。
• 没有任何边提供依据 → Evidence: none (page-level only)。
• 读取的页面带有 drift 标记 → 仍然回答，并在答案开头附上警告。
• 第 0 层脚本 / drift / telemetry 出错 → fail-open，跳过该步骤，不中断会话。

HOW

主要工作流

步骤	类型	输入	操作	输出/退出	故障/后续
W01	确定性	问题	第 0 层 mem-rank.py retrieve	top-k 记忆/事件	NOOP → 跳过
W02	确定性	问题	第 1 层 rg 按术语覆盖率排序（代码 → search_symbols）	slug 列表	—
W03	效果型	top-N	第 2 层读取排名前 N 的完整页面（约 5 个）；如有需要，第 3 层遍历 wikilinks	页面内容	—
W04	确定性	已读取的 slug	drift 检查门 wiki-sync.py --flags-for	警告或无提示	始终 exit 0
W05	判断型	内容	若有缺失 → 检查 raw/；综合并回答	答案	缺少依据 → partial
W06	判断型	答案	是否有新见解？→ 创建页面 + index + 日志	新页面 / 跳过	否 → 跳过
W07	效果型	结果	记录到 wiki/log.md + telemetry query-log.py --record	日志 + 记录	fail-open
W08	确定性	依据页面	wiki-graph.py cite <page> → ## Evidence 部分	边 eid	none → 仅页面级

各步骤详情（W01–W08 的事实依据）：

步骤——渐进式披露的 3 层流程（第 1 步不要加载整个页面）

原则：先低成本扫描并排序，只完整读取排名靠前的少数页面。在 wiki/sources/evals/retrieval/ 的 golden 数据集上测得，与“读取所有匹配页面” （L0 基线）相比，这种方法在保持 recall 不变的同时减少约 65% 的 token。验证方式：retrieval-eval.py --check。

0. 第 0 层 — 语义检索（情节记忆 + 记忆），而不只是按链接检索：在扫描 wiki 前，先询问情节记忆层，看看之前的会话是否处理过这个问题： python3 harness/scripts/mem-rank.py retrieve "<câu hỏi>" --k 5（添加 --kind-filter episode 可仅检索会话事件）。按语义返回相关度最高的 k 条记忆/情节（基于词元重叠；当适配器 mem-rank.config.yaml 接入后将使用嵌入）——也能找到没有任何 [[wikilink]] 指向的页面。若结果为 NOOP（空），则跳过，不要填入噪声。用这些结果为第 1 层提供页面候选，并了解“这件事在哪次会话中处理过”。

1. 第 1 层 — 扫描，而不打开任何完整页面：在 wiki/index.md 和 wiki 内容中用 ripgrep 搜索问题（使用 rg -c '<term>' wiki/ 统计匹配数），按术语覆盖率对页面排序（包含问题中最多术语的页面排在前面）。关于代码的问题 → 使用 code-graph MCP 的 search_symbols，而不是 rg。本层结果 = slug 列表 + 匹配行；此时不要 Read 任何完整页面。

2. 第 2 层 — 深入查阅：只 Read 得分最高的前 N 个完整页面（默认约 5 个）。跳过排名末尾的页面——不要为了“保险”而阅读。

3. 第 3 层 — 上下文：如果回答需要了解相关脉络，沿着刚读过页面中的 [[wikilinks]] 追踪（相当于 engram 的时间线/相关内容）——仍然只打开被链接的页面，不要全部打开。 3b. 读取过程中的漂移检查关卡（0 个词元，失败时放行）——综合内容前，检查刚读过的页面是否与代码不一致： RUN: python3 harness/scripts/wiki-sync.py --flags-for "<slug1,slug2,…>"（下游仓库中没有 harness/ 时，使用全局版本：python3 ~/.claude/harness/harness/scripts/wiki-sync.py --flags-for "…" --root .）。 传入第 2–3 层中实际 Read 的页面。命令始终以 0 退出；无输出表示没有页面被标记。 若出现 ⚑ CẢNH BÁO DRIFT 行 → 将该警告原样放入回答（每个页面一行，置于回答正文开头），然后照常作答；不要吞掉警告，也不要拒绝回答。 为什么要有这一步：wiki-sync --check 会将 code-drift 标记写入 stale.json，但在 2026-07-19 之前，只有 /lint 会读取该标记——而 lint 按周期运行，因此两次 lint 之间，/query 会返回已与代码不一致的页面，却不发出任何警告。这正是“wiki 是事实来源，但内容已经过时”这一情况，会导致模型基于旧知识自信地推理。

4. 如果回答需要 wiki 中没有的信息，检查 raw/ 中是否有尚未处理的来源。

5. 综合内容并直接作答。

6. 评估：回答是否包含 wiki 中尚未记载的非显而易见的见解、关联或结论？

   • 如果有：创建新的 wiki 页面（概念或来源），更新 wiki/index.md，并记录到 wiki/log.md。
   • 如果没有：跳过。

7. 在 wiki/log.md 中追加：## YYYY-MM-DD — query — <question summary>，并注明是否创建了新页面。

8. **遥测（测量检索效果 — 失败时放行）：**回答后，记录查询，以便衡量检索效果： python3 harness/scripts/query-log.py --record --question "<câu hỏi>" --pages "<slug1,slug2>" --tokens <ước tính token đã đọc> --tier <1|2|3> --pages = 实际读取的 wiki 页面；--tier = 到达的最深层级（1 扫描 / 2 读取完整页面 / 3 wikilinks）。脚本失败时放行——绝不会中断会话。已知限制：仅在调用 query 技能时测量，不会记录模型直接执行 Read 的轮次。

9. 证据 — 引用关系边，而不只是页面。对于每个作为依据的 wiki 页面，运行： python3 harness/scripts/wiki-graph.py cite <page> 然后在回答末尾附上 ## Evidence 部分，列出真正支撑结论的边的 eid——不要仅因某条边存在就列出：

   ## Evidence
   - e:4b65f8c5  concepts/decision-anchoring.md -> concepts/adapt-modes.md  (wikilink)
   - e:988aa19d  index.md -> concepts/example-concept.md  (mdlink)
   

   没有任何边能支撑结论 → 直接写 Evidence: none (page-level only)。如实说明胜过编造路径。页面 frontmatter 的 relations: 中声明的带类型边（supports/contradicts/supersedes/derives-from/depends-on），比单纯的 wikilink 更有力，因为它明确说明了关系。

分支

ID	类型	条件	行为	跳过／失败	重新汇合
B01	conditional_required	关于代码的问题	在第 1 层使用 code-graph MCP（search_symbols），而非 rg	—	W03
B02	conditional_required	存在 ⚑ CẢNH BÁO DRIFT 行	将其原样放在回答开头	不提示 → 跳过	W05
B03	conditional_required	下游仓库中没有 harness/	使用全局版本 ~/.claude/harness/harness/scripts/wiki-sync.py --root .	—	W05
B04	conditional_required	回答包含 wiki 中没有的新见解	创建 concept/source 页面 + 索引 + 日志（OKF）	否 → 跳过	W07
B05	conditional_required	查询暴露出缺口，且有相关的 raw/ 来源	对该来源调用 ingest	没有来源 → 记录缺口	W07

验证与停止

确定性检查：retrieval-eval.py --check 用于衡量渐进式披露的召回率／token；wiki-graph.py cite 用于生成真实 eid。判断：综合并评估“新见解”。完成 W08 + 交付后停止；不要为了“保险起见”而打开 top-N 之外的页面。

示例

• 正例：“为什么 adapt-modes 将 absorb 分成 3 种？”→ 使用 rg 排序，读取 concepts/adapt-modes.md + 2 个排名靠前的页面，静默处理 drift → 回答 + ## Evidence，列出 e:4b65f8c5 concepts/decision-anchoring.md -> concepts/adapt-modes.md (wikilink)；没有新见解 → 不创建页面。
• **边界情况／失败：**读取的页面带有 code-drift 标记 → 回答以原样的 ⚑ CẢNH BÁO DRIFT 行开头，然后再回答；没有支撑关系 → Evidence: none (page-level only)。

---

交付 — 输出报告

完成所有主要技能任务后，向 wiki 写入一份提案草稿。

步骤

1. 构建文件名：

• 格式：DDMMYY-<ten>.md
• DDMMYY = 今天的日期（例如，2026 年 6 月 2 日为 020626）
• <ten> = 用 2–4 个 kebab-case 单词概括完成的工作（例如，landing-page-coteccons、brand-kit-fintech、ingest-auth-spec）

2. 写入 llmwiki/wiki/sources/draft/DDMMYY-<ten>.md：

---
type: draft
title: "DDMMYY-<ten>"
status: proposed
tags: [<skill-name>, output-report]
timestamp: YYYY-MM-DD
---

# DDMMYY-<ten>
**Type:** draft
**Status:** proposed
**Tags:** <skill-name>, output-report
**Proposed:** YYYY-MM-DD

## What
<One sentence — what this skill invocation produced or decided>

## Output
<Key artefacts, files created/modified, or decisions made>

## Files
| File | Action |
|------|--------|
| `path/to/file` | created / modified |

## Notes
- Invoked via: `/<skill-name>` skill

## Origin
- **Draft:** `wiki/sources/draft/DDMMYY-<ten>.md`
- **Commit:** _(filled by verify-before-commit)_
- **Date promoted:** _(filled by verify-before-commit)_

3. 更新 wiki 索引和日志：

• llmwiki/wiki/index.md — 追加一行：| [DDMMYY-<ten>](sources/draft/DDMMYY-<ten>.md) | draft | YYYY-MM-DD |
• llmwiki/wiki/log.md — 追加：## YYYY-MM-DD — <skill-name> — <ten>

仅当该技能没有产出任何工件且没有作出任何决定时才跳过（例如，纯显示模式 /caveman-stats）。