wiki-query

Wiki Query — ナレッジ検索

生のソースドキュメントではなく、コンパイル済みの Obsidian wiki を対象に質問に回答します。この wiki には、あらかじめ統合され、相互参照されたナレッジが含まれています。

このスキルは読み取り専用です

wiki-query は質問に回答します。wiki のコンテンツを作成または変更してはなりません。唯一許可される書き込みは、Step 6 で log.md に追記することです。

変更が明らかに有益に思える場合でも、以下は決して行わないでください。

• concepts/、entities/、skills/、references/、synthesis/、journal/、projects/ 配下のページを作成または編集する
• index.md、hot.md、_insights.md、.manifest.json を変更する

ユーザーのメッセージに新しい発見、操作の依頼（「これを保存して」「X を禁止して」「これを記録して」など）、または変更を示唆する内容が含まれている場合、実行しないでください。質問に回答し、変更案を提案して、適切なスキルを案内してください。

• 簡単なメモ／注意点 → wiki-capture --quick
• 新しいページ全体 → wiki-capture
• プロジェクトナレッジの同期 → wiki-update

開始前

1. 設定を解決する — llm-wiki/SKILL.md の Config Resolution Protocol に従います（インラインの @name による上書き → CWD から上位へたどって .env を検索 → グローバル設定 → セットアップを促す）。プロジェクトをまたぐクエリで @name がない場合、グローバル設定が存在するなら、Vault の .env へのシンボリックリンクであっても、グローバル設定を優先します。これにより、OBSIDIAN_VAULT_PATH と QMD の各種変数を取得できます。どのプロジェクトディレクトリからでも機能します。
2. 取得方法を決める前に、解決した設定から QMD の設定を読み込みます。QMD_WIKI_COLLECTION が設定されている場合、以下のトランスポート／ツールの確認を条件として、QMD を利用可能なものとして扱います。空または未設定の場合は、grep／ページの読み取りを使う前に、QMD をスキップする理由を簡潔に説明します。
3. $OBSIDIAN_VAULT_PATH/hot.md が存在する場合、最初に読み取ります。最近のアクティビティをすぐに把握できます。ユーザーの質問が最近取り込まれた内容についてであれば、index.md を開く前に hot.md で回答できることがあります。
4. $OBSIDIAN_VAULT_PATH/index.md を読み取り、wiki の対象範囲と構成を把握します。

表示フィルター（任意）

デフォルトでは、表示タグに関係なくすべてのページが返されます。これにより既存の動作が維持され、ユーザーからの要望がない限り変更はありません。

ユーザーのクエリに**「公開情報のみ」「ユーザー向け」「内部情報なし」「ユーザーから見える内容で」「内部情報を除外」**などの表現が含まれる場合、フィルターモードを有効にします。

• ブロックするタグのセットを作成します：{visibility/internal, visibility/pii}
• Index Pass（Step 2）では、フロントマターのタグにブロック対象のタグが含まれる候補をスキップします
• Section／Full Read Pass（Steps 3–4）では、ブロック対象のページを読み取ったり引用したりしません
• 許可されたページのみを使って回答を統合します。除外されたページが存在することには触れません。

visibility/ タグがないページ、または visibility/public タグが付いたページは、常に含めます。

フィルターモードでは、Step 6 のログエントリーにフィルターを記録します：mode=filtered。

取得プロトコル

llm-wiki/SKILL.md の Retrieval Primitives 表に従ってください。このスキルで最もコストがかかるのは読み取りです。質問に回答できる最も低コストのプリミティブを使い、それで対応できない場合にのみ段階的に切り替えてください。最初からページ全体を読み取ることは決してしないでください。

Step 0：GraphRAG の事前確認（高速なインデックスクエリ — ページの読み取りなし）

ページを開く前に、コンパイル済みのグラフインデックスにクエリを実行します。

obsidian-wiki graph-query "$OBSIDIAN_VAULT_PATH" "<question>" --pretty

出力フィールド：

• answer_type: direct | path | list | gap | impact | bridges | hubs | clusters | surprising — 次に何を行うかを決定づけます。最後の 5 つは構造的インテントです。つまり、質問は Vault の形に関するものであり、回答は graph（後述）内で完全に計算済みの状態で返され、ページの読み取りは一切発生しません。
• graph: 構造的インテントの場合にのみ存在します — 計算済みの回答です。それ以外の場合は null になります。
• candidates: タイトル/タグ/サマリーの一致 + 次数による上位ランクのページ。スコアとサマリー付き
• should_read: 最も開く価値のあるページ — 当て推量で多くのファイルを読む代わりに、ここから始めてください
• path: マルチホップクエリの場合、2 つの概念間の最短ウィキリンクパス
• god_nodes_relevant: クエリ語句に関連するハブページ — 常に有用なコンテキストです
• index_only: true の場合、最上位候補のサマリーがすでに質問に答えています — ページの読み取りをスキップしてください
• temporal: as_of、retrievable、excluded_historical — イベント時刻フィルターがどれだけのページを除外したか（後述）

構造的インテント — これらは完全にグラフから回答されます。ユーザーの言い回しによって自動的にルーティングされます:

ユーザーの質問	answer_type	graph に含まれる内容
「X を削除すると何が壊れるか」/「X に依存しているものは何か」/「X にリンクしているものは何か」	impact	direct_dependents、transitive_dependents、total
「どのページがクラスターを橋渡ししているか」/「何が Vault を分断するか」	bridges	媒介中心性順のページ。label と connects_labels 付き
「中心にあるのは何か」/「トップハブ」/「主なトピック」	hubs	次数順のページ。in/out の内訳付き
「どのようなクラスターがあるか」/「Wiki はどう構成されているか」	clusters	各クラスターの label、size、cohesion、fragmented
「意外なつながり」/「予想外のリンク」	surprising	クラスター間リンク。まれなものから順に

graph ペイロードを直接報告してください — ページを読んで再導出しないでください。構造的な質問が解決できないページを名指しした場合、CLI は direct にフォールバックし、graph は null になります。

デシジョンツリー:

1. graph が非 null の場合 → 構造的な回答は完全です。それを報告して停止してください。ページの読み取りは不要です。
2. index_only: true の場合 → candidates[0].summary から直接回答してください。ステップ 1〜4 をスキップし、ステップ 5 に進んでください。
3. answer_type == "path" かつ path が空でない場合 → つながりは path にあります。それらのページのみを読んでください。
4. それ以外の場合 → should_read のページのみを開いてください（すべての候補ではありません）。これにより、旧フローで必要だった当て推量の 5〜10 ページの読み取りが置き換えられます。

ここで使用されるグラフは、Vault の管理ファイル（index.md、log.md、hot.md、_insights.md）を除外しています。これらのファイルはほぼすべてのページにリンクしているため、含めてしまうと任意の 2 ページが約 2 ホップ離れているように見え、無意味な A → index → B パスが生成されていました。

イベント時刻。 ページは valid_from / valid_until / superseded_by のフロントマターを持つことがあります。valid_until が過ぎたページは履歴的です。つまり、Vault とグラフには残りますが、デフォルトでは candidates から外れます。そのため、「どの X を使うか？」という質問には、最初に書かれたものではなく、現在 真であることが回答されます。

• temporal.excluded_historical が非ゼロの場合、それが回答にとって重要であればその旨を伝えてください — ユーザーは置き換えられた状態について尋ねている可能性があります。
• 質問が過去に関するもの（「2025 年には何を使っていたか」、「移行前は」）である場合は、--as-of YYYY-MM-DD を付けて再実行し、その時点で有効だったものを取得してください。
• ユーザーが明示的に履歴全体を求めている場合、またはある決定がどのように変わったかを追跡している場合は、--include-historical を使用してください。
• 返された候補が superseded_by を持つ場合、それは置き換え先を名指ししています — 古い主張を現在のものとして報告するのではなく、それを追ってください。

obsidian-wiki graph-query "$OBSIDIAN_VAULT_PATH" "<question>" --as-of 2025-06-01 --pretty
obsidian-wiki graph-query "$OBSIDIAN_VAULT_PATH" "<question>" --include-historical --pretty

構造的インテントは意図的にこのフィルターを無視します。ページを削除しても、それにリンクしている履歴ページは依然として壊れるため、依存先がもはや現行でなくなったという理由だけで影響範囲を縮小してはなりません。

フォールバック（obsidian-wiki がインストールされていない場合）: grep と index.md を使用して、通常どおりステップ 1 に進んでください。

ステップ 1：質問を理解する

クエリの種類を分類します。

• 事実の検索 — 「X とは何ですか？」→ 関連するページを探します
• 関係性のクエリ — 「X は Y とどのような関係がありますか？」／「X と矛盾するものは何ですか？」→ 両方のページと、それらの相互参照、型付きエッジを示す relationships: フロントマターブロックを確認します
• パス／マルチホップクエリ — 「X は Y とどのようにつながっていますか？」／「X と Y をつなぐものは何ですか？」／「X から Z までのつながりをたどってください」／「X が推移的に依存するものは何ですか？」→ X と Y は直接リンクしておらず、中間ページを経由してつながっています。ステップ 4b のマルチホップグラフ探索を使います。
• 統合クエリ — 「X について現在どのように考えられていますか？」→ X に触れているすべてのページを見つけて、内容を統合します
• ギャップクエリ — 「X について何を知らないのでしょうか？」→ 不足している情報を探し、未解決の質問のセクションを確認します

また、モードを決めます。

• インデックスのみモード — 「簡潔に回答して」「ざっと確認して」「ページを読まないで」「素早く検索して」などの指示で開始します。ステップ 3 で終了します。フロントマターと index.md のみを参照して回答します。
• 通常モード — 以下の段階的なパイプライン全体を実行します。

ステップ 2：インデックスの確認（低コスト）

ページ本文を開かずに、候補の集合を作成します。

• すでに上記の index.md を読んでいるので、最初の絞り込みに使います。各ページの説明とタグが 1 行ずつ記載されています。
• Grep を使って、ページのフロントマターのみを対象に、タイトル、タグ、別名、概要の一致を検索します。ボールト内の .md ファイルに対象を絞った ^(title|tags|aliases|summary): のようなパターンは、本文全体の検索よりもはるかに低コストです。
• 次の順で順位付けした、上位 5～10 件の候補ページパスを集めます。
  1. タイトルまたは別名の完全一致
  2. タグの一致
  3. summary フィールドにクエリ語が含まれる
  4. index.md の項目にクエリ語が含まれる
• 各順位グループ内でティアの順序を適用します。 2 つの候補の評価が同じ場合は、tier: core を tier: supporting より優先し、tier: supporting を tier: peripheral より優先します。ほかのフィールドと同じ低コストの grep で、tier: フロントマターフィールドを読み取ります。tier: フィールドがないページは supporting として扱います。

取得数を随時記録します（ステップ 5／6 の透明性レポートで使用）：

• candidates_seen — 上記のいずれかの順位付け条件に一致した、重複のないページの合計数。上位 5～10 件に絞り込む前の数です。
• candidates_used — そのうち、実際にステップ 3／4 へ引き継いだ数です。
• dropped — candidates_seen − candidates_used。つまり、一致したものの、読まれなかったページ数です。0 以外の場合は、除外したページ（多数ある場合はその数）を示して、取得が網羅的ではなかったことをユーザーに伝えます。これはエラーではなく、除外した内容を正直に報告するためのものです。

インデックスのみモードの場合は、ここで終了します。summary: フィールド、タイトル、index.md の説明だけをもとに回答します。回答には明確に 「（インデックスのみの回答 — ページ本文は未読です。以下の情報はページの概要に基づいており、細部を見落としている可能性があります）」 と記載します。その後、ステップ 5 へ進みます。

ステップ 2b：QMD セマンティック検索（任意 — 解決済み設定に QMD_WIKI_COLLECTION が必要です）

ガード：設定の解決後に $QMD_WIKI_COLLECTION が空または未設定の場合は、このステップ全体をスキップしてステップ 3 に進んでください。作業状況の更新で、変数が不足していることに触れてください。

QMD がない場合： ステップ 3 に進み、ボルトを直接 Grep で検索してください。QMD は高速で概念も考慮しますが、grep による方法も問題なく機能します。セットアップについては .env.example を参照してください。

QMD_WIKI_COLLECTION が設定されている場合は、質問への回答が hot.md または index.md のメタデータだけですでに得られる場合を除き、Grep を使う前に QMD を実行してください。意味に関する質問、プロジェクト固有の質問、関連するコンテキストを求める質問、タイトルやフロントマターにそのまま記載されていない可能性のある用語を使った質問では、特に QMD の利用を推奨します。

$QMD_TRANSPORT に従って QMD の通信方式を選択します。

• mcp（デフォルト）：エージェントで設定された QMD MCP ツールを使用します。
• cli：ローカルの qmd CLI を実行します。設定されていれば $QMD_CLI を使用し、そうでなければ qmd を使用します。

CLI コマンドの選択、メンテナンス、VM に関する注意事項の詳細については、インストール済みであればローカルの $qmd-cli スキルを使用してください。

選択した通信方式が利用できない場合（MCP ツールがない、qmd が PATH 上にない、またはコマンドがエラーになる場合）は、QMD をスキップしてステップ 3 に進んでください。

MCP 通信方式の場合：

mcp__qmd__query:
  collection: <QMD_WIKI_COLLECTION>   # e.g. "knowledge-base-wiki"
  intent: <the user's question>
  searches:
    - type: lex    # keyword match — good for exact names, file paths, error messages
      query: <key terms>
    - type: vec    # semantic match — good for concepts, patterns, "what is X like"
      query: <question rephrased as a description>

CLI 通信方式の場合は、$QMD_CLI_SEARCH_MODE に従ってコマンドを選択します。

no-sudo、ansible_become=false、~/.local/bin のような演算子的なトークンや句読点を多く含むトークンは、lex: 行に残してください。vec: 行は、ハイフン付きの -term 形式の語を含まない自然な文章に書き換えてください。QMD は -term を否定として扱いますが、vec／hyde クエリでは否定がサポートされていません。

• quality（デフォルト）：最も高い関連性が得られますが、CPU では低速です。

  ${QMD_CLI:-qmd} query $'lex: <key terms>\nvec: <question rephrased as a description>' -c "$QMD_WIKI_COLLECTION" -n 8 --files
  

• balanced：LLM による再ランキングを行わないハイブリッド検索です。quality が遅すぎる場合に使用してください。

  ${QMD_CLI:-qmd} query $'lex: <key terms>\nvec: <question rephrased as a description>' -c "$QMD_WIKI_COLLECTION" -n 8 --no-rerank --files
  

• fast：セマンティック検索のみで再現率を重視します。正確な名前、ファイルパス、エラーメッセージが重要な場合は、代わりに search を使用してください。

  ${QMD_CLI:-qmd} vsearch "<question rephrased as a description>" -c "$QMD_WIKI_COLLECTION" -n 8 --files
  

CLI の出力に docid が含まれている場合は、${QMD_CLI:-qmd} get "#docid" を使用して、ランキングされたドキュメントを取得します。

返されたスニペットやランキングされたファイルは、事前に読み込むセクションの要約として機能します。それだけで質問に十分に回答できる場合は、ステップ 3 をスキップし、ステップ 4 に直接進んでください（QMD が最上位にランク付けしたページのみを読みます）。不十分な場合は、ランキングされたファイルの一覧を参考に、ステップ 3 で grep または読み込みを行うファイルを選んでください。

QMD の検索結果は、ステップ 2 の candidates_seen 件数にまとめてください（パスで重複を除外します。フロントマターの grep と QMD の両方で見つかったページは 1 件として数えます）。

防御的なフィルター：ウィキコレクションの検索結果から _raw/ パスをすべて除外してください。 ウィキコレクションにはコンパイル済みページのみがインデックスされている想定ですが、コレクションの設定を誤ると（.env.example を参照）、すでに昇格したページに置き換えられた _raw/_archived/ 内の古いドラフトを含め、_raw/ がインデックスされることがあります。$QMD_WIKI_COLLECTION からの QMD 検索結果を使用する前に、そのパスを確認してください。_raw/ を含む場合は、ウィキコレクションの検索結果から除外します（生のソースとして引用する場合は、$QMD_PAPERS_COLLECTION から適切に見つかる可能性があります）。これにより、設定ミスが「コンパイル済みの知識として、置き換え済みのドラフトを気付かれないまま引用する」のではなく、「検索結果の不足」にとどまります。ウィキコレクションから _raw/ のパスが返された場合は、コレクションの対象範囲を修正する必要があることをユーザーが把握できるよう、作業状況の更新でその旨に触れてください（.env.example の QMD セクションを参照）。

質問に _raw/ 内の資料が含まれる可能性がある場合は、papers も検索してください。

QMD_PAPERS_COLLECTION が設定されており、ユーザーが取り込み済みの論文で扱われている可能性が高いトピック（研究、理論、背景情報など）について質問している場合は、papers コレクションも並行して検索してください。回答では、生のソースとコンパイル済みのウィキページを分けて引用してください。

ステップ 3：セクション単位の確認（中程度のコスト — ステップ 2／2b で結論が出ない場合のみ）

上位候補ごとに、ページ全体を読まずに関連セクションを取得します。

• Grep -A 10 -B 2 "<query-term>" <candidate-file> を使い、該当箇所の前後の行だけを取得します。
• 通常、ヒットごとに 100～500 行ではなく、15～30 行が返されます。
• セクションの grep で明確な答えが得られたら、ステップ 5 に進みます。

ステップ 4：全文を読む（コスト大 — 最終手段）

ステップ 2 と 3 で質問への答えが得られない場合に限ります。

• 上位候補のうち最大 3 件を全文読みます。読む 3 件を選ぶ際は、階層の順序を適用します。core のページを supporting より先に読み、peripheral のページは、唯一の一致候補でない限りスキップします。
• 回答に相互参照が必要な場合は、これらのページから [[wikilinks]] をたどるのは最大 1 ホップまでにします。
• 関係性に関する質問（「X は Y とどのような関係にありますか？」／「X と矛盾するものは何ですか？」）の場合は、候補ページの relationships: フロントマターブロックも読みます。各エントリは、型と方向を持つエッジ（extends、implements、contradicts、derived_from、uses、replaces、related_to）を示します。回答では、これらを明示してください。「ページ A はページ B にリンクしています」よりも、「ページ A はページ B と矛盾しています（型付きエッジ）」の方が有用です。
• 「Open Questions」セクションを確認し、既知のギャップがないか調べます。
• まだ情報が不足している場合は、その時点で Vault 全体を対象にした広範なコンテンツ grep に切り替えます。コストの高い方法に切り替えたことをユーザーに伝えてください。

ステップ 4b：マルチホップのグラフトラバーサル（型付きエッジ）

通常の検索で見つかるのは、クエリの用語に言及しているページです。しかし、X と Y が同じページに現れない場合、「X は Y とどのようにつながっていますか？」「X は推移的に何に依存していますか？」「X から Z までのつながりをたどってください」といった経路／マルチホップクエリには答えられません。答えは個々のページ本文ではなく、型付きエッジで構成されたグラフの形状にあります。このステップでは、そのグラフをたどります。

このステップは、経路／マルチホップクエリの場合（または、関係性に関するクエリで2つのページ間に直接のエッジが見つからない場合）のみ実行してください。ここではフロントマターだけを使い、ページ本文は読みません。

1. 型付きエッジの隣接関係を作成します（低コスト）。 すべてのページの relationships: ブロックを一度に Grep します（フロントマターのみ）。Grep -A 20 "^relationships:" <vault>/**/*.md。各項目から、有向の型付きエッジ source —type→ target が得られます。「つながっている」は対称的ですが、型付きの記述は有向なので、たどれるエッジとして逆方向も追加し、(reverse) と記します。通常の本文中の [[wikilinks]] は、経路を完成させる必要がある場合に限り、型なしの related_to エッジとして扱います。まずは型付きエッジを優先してください。

2. 端点を特定します。 ステップ2のレジストリを使い、X（クエリでYも指定されている場合はYも）のページパスを解決します。端点が曖昧な場合は、tier: core の候補を選び、その前提を記してください。

3. 深さを制限した幅優先探索（BFS）。 obsidian-wiki がインストールされている場合は、まずCLIを使ってwikilinkグラフを探索します。正確かつ瞬時に実行できます。

   obsidian-wiki graph-analyse "$OBSIDIAN_VAULT_PATH" --path "<X>" "<Y>"                  # two-endpoint: shortest chain + hop count
   obsidian-wiki graph-analyse "$OBSIDIAN_VAULT_PATH" --around "<X>" --depth 3 [--direction out|in]  # one-endpoint: reachable pages by hop
   

   --path は --direction out が指定されていない限り、リンクを双方向にたどります。--around --direction in は「X に何が依存していますか？」（影響範囲）に答えます。ステップ1の型付きエッジで、返された経路を補足してください（CLIが認識するのは [[wikilinks]] であり、関係性の型ではありません）。それ以外の場合、または別の経路を見つける場合は、手動で探索します。

   • デフォルトの最大深度は3ホップです（それ以上先のつながりは、ほとんど意味を持ちません）。ユーザーが「深く」または「必要なだけホップして」と指示した場合に限り、4に引き上げます。
   • 探索範囲の上限： 訪問済みページが約60件を超えたら、そのノードの展開を停止します。Vault全体に探索を広げるのではなく、部分的な結果を報告してください。
   • 2つの端点を指定するクエリ（X→Y）：最短経路が見つかった時点で停止し、その後、存在する場合は最大2つの別経路も短く探索して提示します。
   • 端点が1つのクエリ（Xからの推移的なつながり）：深度制限内で到達可能なすべてのノードを集め、ホップ数ごとに分類します。

4. エッジの型とともに経路を報告します。 端点だけでなく、つながりを示してください。型付きエッジそのものが答えです。

   [[concepts/transformers]] —uses→ [[concepts/attention]] —derived_from→ [[concepts/rnn-seq2seq]] —contradicts (reverse)→ [[concepts/lstm]]
   

   ホップ数と、いずれかのホップが (reverse) による探索か、型なしの related_to による代替かを明記します（これらの経路は信頼性が低いため、その旨を示してください）。深度制限内に経路が見つからない場合は、「X から Y への型付きエッジ経路は3ホップ以内にありません。両者はグラフ内の別々の領域にあります。」とはっきり伝えてください。これは、それ自体が有用な発見（グラフの欠落）です。

コストに関する注意： このステップでは、grepを使ってフロントマターのみを読み取ります。隣接関係のgrepで何も見つからない（まだ relationships: を使っているページがない）場合は、グラフにたどれる型付きエッジがないことを報告し、cross-linker を実行して追加するよう提案してから、通常の1ホップ検索に切り替えてください。

ステップ 5：回答をまとめる

Wiki の内容をもとに回答を作成します。

• 特定の Wiki ページは [[page-name]] 形式で引用します
• 回答の根拠となったステップを記載します（「summary で確認」か「セクションを grep」か「ページ全体を読んだ」か）。ユーザーが確信度を理解するのに役立ちます
• Wiki に矛盾がある場合は、両方の見解を示します
• Wiki に記載がない場合は、そのことを明確に伝えます
• 不足を補える可能性のある情報源を提案します

ページの信頼性に関する注記： 回答で引用するページごとに、lifecycle フロントマターを確認し、is_stale = (today − updated) > 90 days を計算します。リスクのあるページにはインラインで注記を付け、引用内容の確認が必要だとユーザーに伝えます。

条件	注記
lifecycle: archived	(ARCHIVED: superseded by [[target]]) — 後継ページを使用します
lifecycle: disputed	(DISPUTED, marked <lifecycle_changed>: <lifecycle_reason or "reason unspecified">)
is_stale + lifecycle: verified	(VERIFIED but stale: last updated <updated>) — 参照する前に再確認が必要です
is_stale（その他のライフサイクル）	(stale: last updated <updated>)

回答をまとめる際の例：

[[concept-page]] (stale: last updated 2026-01-15) — Original claim was X.
[[verified-page]] (VERIFIED but stale: last updated 2025-09-10) — Reader should reverify before relying.
[[disputed-page]] (DISPUTED, marked 2026-04-30: contradicted by [[new-source]]) — Earlier said Y, now uncertain.
[[old-page]] (ARCHIVED: superseded by [[new-page]]) — Use the successor.

lifecycle フィールドがないページ（スキーマ導入前のレガシーページ）は、draft と同様に扱います。古ければ注記を付け、そうでなければ省略します。lifecycle_reason を捏造してはいけません。このフィールドがない場合は、注記から理由を省略します。

プロジェクトのソースコードの場所を示す（プロジェクトに関するクエリ）。 引用したページがプロジェクトに属する場合（パスが projects/<name>/... 配下にある場合、またはフロントマターに source_path／source_repo フィールドがある場合）、実際のコードの場所を特定します。これにより、修正案で実在するファイルを指定でき、後続のターンで編集できるようになります。

1. $OBSIDIAN_VAULT_PATH/.manifest.json を読み込み、.projects.<name>.source_repo を確認します。これは信頼できる、マシンに依存しない識別情報です（例：github.com/owner/name）。ここに記載された情報を報告します。
2. ローカルのチェックアウトのルートは、以下の順に確認し、最初に存在するものを使用します。.projects.<name>.source_cwd_hint（~ 相対のヒント）、次にレガシーの .projects.<name>.source_cwd（古いマニフェストのみの絶対パス）、最後にページの source_path フロントマターです。候補の ~ を展開し、使用する前にディレクトリが実際に存在することを確認します。レガシーの絶対パスはローカルでの便宜にのみ使用し、プロジェクトの識別情報として報告してはいけません。

source_repo を使って Source code: 行を記載します。ステップ 2 でローカルのチェックアウトが見つかった場合は、具体的なパスを追記します（例：<repo> — local checkout at ~/code/name/public/lib/anticheat.js）。クエリからコード修正が必要だと判断でき、ローカルのチェックアウトがある場合は、編集が必要な具体的なファイルを挙げ、別の次のステップとして実装を提案します。ただし、クエリ中に編集してはいけません（上記の READ-ONLY ガードを参照）。ローカルのチェックアウトが見つからない場合は、リポジトリを報告し、このマシンにはコードがチェックアウトされていないと伝えます。

ステップ 6：クエリをログに記録する

このスキルで行う書き込みはこれだけです。他のものは編集せず、log.md に手動で追記してはいけません。

obsidian-wiki memory log QUERY \
  query="the user's question" result_pages=<N> \
  mode=<normal|index_only|filtered> escalated=<true|false> \
  candidates_seen=<N> candidates_used=<N> dropped=<N>

このコマンドはメモリロックを取得して、解析可能な行を 1 行追記します。index.md や hot.md には一切触れません。

ステップ 2 以降に記録した件数を使用します。件数を記録していない場合（たとえば、インデックスのみのモードで候補全体を作成していない場合）は、フィールドを省略せず 0 を記入します。ログの形式は解析可能な状態に保ってください。

回答形式

回答は次の形式にしてください。

Wiki に基づく回答：

[[wikilinks]] を使って参照元ページにリンクした、情報を統合した回答

参照したページ： [[page-a]], [[page-b]], [[page-c]]

不足情報： Wiki で扱われていない、関連する可能性のある情報

検索状況： N 件の候補を確認、M 件を読み込み、D 件を除外（未確認の一致がある場合：[[page-d]], [[page-e]]）

ソースコード： <source_repo>（~/code/<name> にローカルチェックアウト）— 実装する場合、関連ファイルは … です。 （「実装して」と言えば、クエリモードから切り替えて変更します。）

ソースコードの行は任意です。プロジェクトに関するクエリで source_repo を解決できた場合（手順 5 を参照）のみ含めてください。マシンの絶対パスではなくリポジトリを記載し、このマシン上に実際に存在する場合に限りローカルチェックアウトのパスを追加してください。

検索状況の行は必ず含めてください。これは、手順 2 以降で記録された件数に基づく透明性レポートです（手順 6 でログに記録される candidates_seen／candidates_used／dropped の各フィールドに対応します）。インデックスのみのモードでは、フロントマターのスキャン結果から件数を報告してください。D が 0 の場合は、空のリストを示す括弧書きを付けないでください。