ws-search

Wiki 検索

ユーザーの wiki 内で情報を検索し、保存されている内容に基づいて回答します。ユーザーが該当ページに移動できるよう、ページを引用してください。wiki にトピックの情報がない場合は、その不足を明示してください。wiki にない知識で回答を水増ししてはいけません。

wiki のモデル

wiki は、index.md に ## Spaces 見出しがあるフォルダーです。## Spaces はナビゲーションの規約です。直下にあるすべてのスペースが - [label](path/index.md) — description の形式で記載されており、ツールはそこに記載されたものだけをたどります。スペースは再帰的にネストでき、各スペースは一段下の wiki として機能します。index.md のない通常のフォルダーは、ファイルをまとめるだけです。Markdown の方言は Obsidian です。ウィキリンク、フロントマター、コールアウト、埋め込みを使用します。構文については、付属の obsidian-markdown スキルと obsidian-bases スキルで説明しています。

wiki の解決

解決の順序は次のとおりです。ユーザーが指定したパス → CWD の祖先フォルダーのうち最も近い、wiki であるフォルダー、または wiki である .wiki-spaces/ フォルダーを持つフォルダー（フォルダー自体のスペース） → ~/.config/wiki-spaces/config の wiki キー。ユーザーの言葉が仕組みより優先されます。「自分の wiki」と指定された場合、CWD が別の wiki（たとえば会社のリポジトリ）内にあっても、設定された wiki を意味します。CWD の wiki と、別に設定された wiki の両方が存在する場合は、解決したルートを伝えてください。意図が曖昧な場合は一度確認してください。誤った wiki を黙って操作してはいけません。

同梱スクリプト

ws.py はこの SKILL.md と同じ場所にある、依存関係のない読み取り専用の標準ライブラリ Python 3（3.9 以降）スクリプトです。スクリプトが解析するのは規約であり、コンテンツではありません。構造（走査、範囲、上限、ずれ）の確認はスクリプトの役割で、内容の読解と意味の判断はあなたの役割です。作業ディレクトリは通常別の場所にあるため、絶対パスで実行してください。

• python3 <skill-dir>/scripts/ws.py list --wiki <root> — ## Spaces の規約から到達可能なスペースと、それぞれのエントリーの説明を表示します（マウントをまたぐ場合は --external を指定します）。
• … files --wiki <root> — 規約から到達可能な Markdown ファイルを表示します。
• … grep <pattern> [-i] [-F] --wiki <root> — 対象ファイルを正規表現で行検索します。リテラル文字列を検索する場合は -F を指定してください（メタ文字を含む名前も完全一致で検索します）。rel:line: text の形式で出力し、一致がなければ終了コード 1 を返します。検索の基本単位はパターンと、ヒットに対するあなたの判断です。リンクの作業リスト、タグの一覧、参照のエスケープ確認はいずれも、パターンとヒットに対するあなたの判断で実施できます。
• … check-size <target> [--stdin] --wiki <root> — ファイルの上限判定を行います。書き込む前に確認する場合は、予定する内容を --stdin にパイプで渡してください。
• … audit --wiki <root> — 規約のずれ、スペース境界をまたぐエントリー、上限超過または読み取り不能なファイル、正常でないマウントを検出します。安全に修正方法を示せる問題には、修正内容も表示されます（missing entry の場合は、追加する正確な行が出力されます）。修正は通常の編集として適用し、再度監査を実行して確認してください。スクリプトが書き込みを行うことはありません。

手作業で構造を再解析するより、スクリプトの出力を優先してください。標準出力はデータです。標準エラーには解決されたルートが出力されます（audit の場合は標準出力のヘッダーに出力されます）。また、走査でスキップされた項目、ルートが別の wiki 内にある場合のその wiki、ルートとは別に設定されている wiki を示す note: の注意事項も出力されます。回答に影響する可能性がある場合は、これらの注意事項を伝えてください。

信頼範囲とサイズ管理

所有範囲か外部範囲かは、解決済みのルートを基準に決まります。任意の階層にある shared/ という名前のフォルダー、Git サブモジュール、またはいずれかを参照するシンボリックリンクの配下は外部範囲です。ツリー外のフォルダーを参照するシンボリックリンクは、クローンと同様に、リンクが置かれている場所に従います。読み取りはデフォルトで所有範囲をまたいで行い、外部範囲に入るのはユーザーから明示的な依頼があった場合のみです。書き込みは対象の範囲内にとどめます。それ以外の範囲（所有範囲か外部範囲かを問わず）への書き込みは、明示的な指示がある場合のみ行います。

上限は、フロントマターを含む UTF-8 バイト数で、ベース名ごとに設定されます。index.md は 5000、log.md と hot.md は 100000、その他の *.md は 15000 です。

• 上限はユーザーが決めます。異なる上限を設定するウィキでは、_meta/limits.md に記述し、check-size がその値を読み取ります。
• check-size で上限を確認します。新規ページや編集など、すべての書き込みの前に、書き込む内容を --stdin 経由で渡してください。上限超過ファイルを縮小する書き込みは ok と進捗状況を報告するため、修正を積み重ねられます。ディスク上で確認したファイルには、上限のみが適用されます。
• 上限超過は単なるサイズの問題ではなく、構成に関するシグナルです。ページを要約する、スペースを再構成する、または大きく成長したページを独立させます。切り詰めたり、上限を引き上げたりしてはいけません。
• 例外は log.md です。上限を超えたログはローテーションします。内容全体を _archives/log-<YYYYMMDD>.md に移し、新しいログを開始します。履歴はアーカイブし、縮小しません。

規約はウィキごとに任意で適用します。対象のルート（ユーザーが指定したスペース、指定がなければ解決済みのルート）にあるマーカーを確認します。対象は log.md、_meta/taxonomy.md、_meta/limits.md、_meta/ignore.md、ページのフロントマター、_template.md、hot.md、.git です。いずれかが存在しない場合も、適切に処理を続けます。log.md が存在する場合は、操作ごとに 1 行追記します。

printf '%s %s\n' "$(date -u +%Y-%m-%dT%H:%M:%SZ)" '<OP> <details>' >> <scope-root>/log.md

手順

1. Wiki を解決します（上記のコアブロック）。CWD から特定した場合や、曖昧な可能性がある場合はルートを明示します。フォルダー固有の領域にいる場合は、そのフォルダーに関係する情報をここで検索し、質問がその範囲を超えるときはスクリプトが示す設定済みの Wiki も検索します。Wiki がどこにもない場合は、その旨を伝え、ws-update でセットアップすることを提案します。
2. 全体像を把握します。 list で領域の構成を、files でページ一覧を確認します。どちらも負荷が低いため、コンテンツを検索する前に実行します。
   • 大規模な Wiki では、ルートを切り替えるのではなく、一覧を絞り込みます。files は領域ごとにパスをまとめて出力するため、候補となる領域の部分だけを確認します。ルートの信頼範囲と _meta/ の規則は、全体を通して適用されます。
   • 検索時にルートを切り替えてはいけません。領域を単独の --wiki として指定すると、その領域固有の境界が適用されます。ルートで外部と判断されたマウントも、そこでは所有領域として読み取れる場合があります。その場合、スクリプトは外側の Wiki を示します。ルートの切り替えは、領域を単独で評価する場合（ws-update の共有前チェック）に行うものであり、検索のために行うものではありません。
   • ユーザーから依頼がない限り、外部マウントは対象外とします。stderr の note: 行には、スキップした対象と到達できない領域が示されます。スキップされた領域や到達できない領域に回答が含まれる可能性がある場合は、その旨を伝え、対象に含めるか修復することを提案します。
3. 調査の深さを選びます。「ちょっと確認」「X について何かある？」「エージェントの事前調査」などの場合は、簡易検索を行います。手順 4 で候補を構造的に順位付けし、内容は読まず、名前と概要に基づいて回答する旨を伝えます。具体的な質問の場合は、詳細検索に進み、手順 6 まで続けます。
4. 候補を構造的に順位付けします。 クエリと領域ラベルおよび説明（## Spaces の項目）、ファイル名、パスの各要素を照合します。フロントマターが使われている場合、本文を読まなくても summary、aliases、tags によってページを順位付けできます。grep '^(tags|aliases|summary):' --wiki <root> を使うと、一覧を 1 回で検索できます。
5. 構造だけで結論が出ない場合は、まず負荷の低い方法でコンテンツを検索します。
   1. 利用可能であれば、Markdown を認識する検索バックエンド（例：Markdown に対する BM25 とセマンティック検索を行う qmd MCP）を使います。そのインデックスは信頼範囲を認識しないため、ルートの files 検索で一覧に含まれない結果は除外します。
   2. … grep '<term>' -i --wiki <root> — 常に同梱されている汎用のフォールバックです。信頼範囲内のページだけを正確に検索します（shared/、サブモジュール、_archives/ は対象外）。--external はユーザーから依頼があった場合にのみ使います。
6. 上位の検索結果を全文読みます。 ページには上限があるため、ファイル全体を読む負荷は小さいものです。断片を多数読むより、2～4 ページを全文読むことを優先します。
7. Wiki の情報だけに基づいて回答します。 すべての主張について、該当ページを Wiki リンク（[[path/to/page]]）で引用します。Wiki で使用されている場合は、%%inferred%% / %%ambiguous%% の出典マーカーを引き継ぎます。Wiki にない情報は不足点として明示し、ws-update で調査して記録することを提案します。
8. log.md が存在する場合は、コアブロックに従って SEARCH 行を 1 行記録します。

出力

From your wiki (<root>):
- <finding> — [[page]]
- <finding> — [[page]]
Gaps: <topics the wiki doesn't cover, or "none">