query

スキル：query

WHAT

目的とコンテキスト

• 目的： Wiki の知識を統合して質問に回答します。Wiki にない価値ある知見は新しいページにまとめ、時間とともに知識を蓄積します。
• 呼び出すタイミング： 複数の Wiki ページまたは生のソースを横断した統合が必要な質問をユーザーがしたとき。または、「根拠は何か」「どのエッジを引用するか」「グラフ上の経路」「エビデンスの引用」を知る必要があるとき。
• 対象外： Wiki／raw/ 以外の知識で回答しない（事実を捏造しない）。ソース全体を自動で取り込まない（不足があれば → ingest を呼び出す）。ページの drift フラグを変更しない（これは /lint／wiki-sync の役割）。

メンタルモデル

質問 → レイヤー 0 mem-rank（エピソード記憶） → レイヤー 1 term の網羅度に基づく rg ランキング → レイヤー 2 上位 N 件を全文読み込み → レイヤー 3 wikilinks → drift ゲート → 統合 → [新しい知見があれば新しい Wiki ページ] → ログ + テレメトリー → エビデンス（eid エッジ）。

入出力の契約

	フィールド	必須？	意味
入力	質問	はい	複数の Wiki ページ／raw を統合する必要がある
出力	回答	はい	drift 警告がある場合は ⚑ CẢNH BÁO DRIFT を回答の先頭に置く
出力	## Evidence セクション	はい	実際に根拠となる eid エッジ、または Evidence: none (page-level only)
出力	新しい Wiki ページ + index + log	新しい知見がある場合のみ	concept または source
出力	wiki/log.md の行 + query-log.py の記録	はい	ログ ## YYYY-MM-DD — query — <question summary>。テレメトリーは fail-open
出力	出力レポートの下書き	はい（artifact が 0 件の場合を除く）	Delivery セクション

ルールと機能

• RULE-01（必須）：OKF v0.1（R9）： 新しい Wiki ページはすべて、空でない type を持つ YAML frontmatter ブロック（---）から始めます。一致する _template.md をコピーし、## Origin セクションを残してください。
• RULE-02（必須）：事実を捏造しないでください。Wiki と raw/ のみから統合します。
• RULE-03（推奨）：不足（エンティティの欠落、概念の欠落）が明らかになった場合、該当する raw/ ソースがあれば ingest を実行します。
• RULE-04（必須）：段階的開示 — 手順 1 でページ全体を読み込まないでください。上位 N 件のみ全文を読み込みます。
• RULE-05（必須）：drift 警告は回答に原文のまま含めてください。省略せず、回答を拒否しないでください。
• 機能：Wiki、raw/、エピソード記憶レイヤー、Wiki グラフを読み込みます。新しい Wiki ページ、index、ログ、テレメトリーを書き込みます。コードに関する質問には code-graph を使用します。

失敗時の境界

• Wiki と raw/ に情報がない場合 → 根拠がないことを明示します（partial）。捏造しません。
• 根拠となるエッジがない場合 → Evidence: none (page-level only)。
• 読み込んだページに drift フラグがある場合 → 回答を続け、回答の先頭に警告を付けます。
• レイヤー 0 スクリプト／drift／テレメトリーでエラーが発生した場合 → fail-open とし、そのステップをスキップします。セッションを中断しません。

HOW

メインワークフロー

ステップ	種別	入力	アクション	出力／終了	失敗時／次の処理
W01	決定的	質問	レイヤー 0 mem-rank.py retrieve	上位 k 件の memory／episode	NOOP → スキップ
W02	決定的	質問	レイヤー 1 term の網羅度に基づく rg ランキング（code → search_symbols）	slug の一覧	—
W03	副作用あり	上位 N 件	レイヤー 2 上位 N 件（約 5 件）を全文読み込み。必要に応じてレイヤー 3 で wikilinks をたどる	ページ内容	—
W04	決定的	読み込んだ slug	drift ゲート wiki-sync.py --flags-for	警告または何も出力しない	常に exit 0
W05	判断	内容	不足があれば raw/ を確認。統合して回答	回答	根拠がなければ partial
W06	判断	回答	新しい知見があるか？ → ページ + index + log を作成	新しいページ／スキップ	なければスキップ
W07	副作用あり	結果	wiki/log.md に記録 + テレメトリー query-log.py --record	ログ + 記録	fail-open
W08	決定的	根拠ページ	wiki-graph.py cite <page> → ## Evidence セクション	eid エッジ	なし → page-level only

各ステップの詳細（W01–W08 の正となる情報源）：

ステップ — 3 層の段階的開示（手順 1 でページ全体を読み込まないでください）

原則：まず低コストでスキャンして順位付けし、上位の数ページのみ全文を読みます。ゴールデンセット wiki/sources/evals/retrieval/ での測定では、この方法は recall を維持しながら、「一致するすべてのページを読む」 方法（ベースライン L0）と比べてトークンを約 65% 削減することが示されています。検証：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 — スキャンします。ページ全体は開きません： ripgrep で質問を wiki/index.md と wiki の内容から検索し（rg -c '<term>' wiki/ で一致数を数えます）、用語の網羅度（質問に含まれる用語をより多く含むページほど上位）でページを順位付けします。コードに関する質問では、rg の代わりに code-graph MCP（search_symbols）を使います。このレイヤーの結果は slug と一致した行のリストです。まだどのページも全体を Read しません。

2. レイヤー 2 — 深掘り： スコア上位の N ページだけを全体 Read します（既定では約 5 ページ）。ランキングの下位は、「念のため」と思っても読みません。

3. レイヤー 3 — コンテキスト： 回答に関連するつながりが必要なら、先ほど読んだページの [[wikilinks]] をたどります（engram の timeline/related と同等です）。リンク先のページだけを開き、すべてのページを開くことはしません。 3b. 読み取り時のドリフトチェック（0 トークン、fail-open） — 回答をまとめる前に、読み取ったページの内容がコードと食い違っていないか確認します： 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 したページを正確に渡します。このコマンドは常に exit 0で終了します。出力がなければ、フラグの付いたページはありません。 ⚑ CẢNH BÁO DRIFT の行があれば、警告文をそのまま回答に含めてください（ページごとに 1 行、回答の冒頭に配置）。そのうえで通常どおり回答してください。警告を無視したり、回答を拒否したりしないでください。 この手順がある理由：wiki-sync --check は stale.json に code-drift フラグを書き込みますが、2026-07-19 までは /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. テレメトリ（検索精度を測定 — fail-open）： 回答後、検索の有効性を測定できるように質問を記録します： 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）。スクリプトは fail-open で、セッションを中断することはありません。既知の制限：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) と明記します。経路をでっち上げるよりも、正直に伝えるほうがよいです。型付きエッジ（supports／contradicts／supersedes／derives-from／depends-on）は、ページの frontmatter relations: で宣言されます。関係を明確に示すため、単なる wikilink よりも強い根拠になります。

Branches

ID	Kind	Guard	挙動	スキップ／失敗	再合流
B01	conditional_required	コードに関する質問	Layer 1 では rg の代わりに code-graph MCP（search_symbols）を使う	—	W03
B02	conditional_required	⚑ CẢNH BÁO DRIFT の行がある	そのまま回答の先頭に記載する	何もせず → スキップ	W05
B03	conditional_required	downstream のリポジトリに harness/ がない	グローバル版 ~/.claude/harness/harness/scripts/wiki-sync.py --root . を使う	—	W05
B04	conditional_required	回答に wiki にない新しい洞察がある	concept/source ページ＋index＋log を作成する（OKF）	いいえ → スキップ	W07
B05	conditional_required	クエリから不足が判明し、関連する raw/ ソースがある	そのソースで ingest を呼び出す	ソースがない → 不足を記録する	W07

検証と停止条件

必須：retrieval-eval.py --check で progressive disclosure の再現率／トークン数を測定し、wiki-graph.py cite で実際の eid を生成します。判断事項：統合と「新しい洞察」の評価です。W08＋Delivery の後に停止し、「念のため」top-N 以外のページを追加で開かないでください。

例

• 良い例：「adapt-modes がなぜ 3 種類の absorb に分かれているのか？」→ rg で順位付けし、concepts/adapt-modes.md と上位 2 ページを Read し、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)。

---

Delivery — 出力レポート

すべてのメインスキルタスクが完了したら、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 — 1 行追加：| [DDMMYY-<ten>](sources/draft/DDMMYY-<ten>.md) | draft | YYYY-MM-DD |
• llmwiki/wiki/log.md — 追加：## YYYY-MM-DD — <skill-name> — <ten>

スキルが成果物も判断事項も一切生成しない場合（例：/caveman-stats のような表示のみのモード）に限り、スキップしてください。