skill-llm-wiki

skill-llm-wiki

⚠ SKILL.md と、そこから指定された特定の guide/ ファイルのみを読みます

厳守事項： SKILL.md がエントリーポイントです。このスキルの guide/ サブディレクトリ内のファイルも読めますが、ルーティング手順で現在の操作用に明示されたファイルに限ります。このスキルディレクトリ内のそれ以外のファイルは、絶対に読まないでください。README.md を開かないでください。scripts/ 配下のファイルを開かないでください。LICENSE を開かないでください。ルーティングで対象になっていない guide/ ファイルを開かないでください。興味本位で任意のファイルを開かないでください。内容を確認するためだけにファイルを cat / head / tail / Read しないでください。

scripts/ 配下のスクリプトは参照資料ではなくツールです。guide/cli.md に記載されたとおり、node scripts/cli.mjs <subcommand> で実行します。ソースを読まないでください。インポートしないでください。内部を調べないでください。スクリプトについて知る必要があることは、すべて guide/cli.md に記載されています。

このルールが重要な理由： 読み取るバイトごとにトークンを消費します。このスキルは、現在の操作に必要な部分だけを読むよう、意図的に分割されています。通常の Validate では約 18 KB、通常の Build では約 32 KB を読みます。このスキルの機能に関する質問なら、このファイル（約 12 KB）だけを読みます。予算を守ってください。

⚠ 事前確認：Node.js がインストールされていることを確認します

いずれかの操作で最初に node scripts/cli.mjs を実行する前に、Bash ツールで次を実行します。

node --version 2>/dev/null || printf '%s\n' '__NODE_MISSING__'

出力された1行を解釈します。

• __NODE_MISSING__ — Node.js がインストールされていません。guide/ux/preflight.md を読み、「Case A」のメッセージを選んで、そのままユーザーに伝えてください。操作を中止します。 node scripts/cli.mjs コマンドを実行しないでください。自分で Node をインストールしようとしないでください。
• v<N>.x.x で N < 18 の場合 — Node.js のバージョンが古すぎます。guide/ux/preflight.md を読み、「Case B」のメッセージを選び、バージョン文字列を置き換えて、そのまま伝えてください。操作を中止します。
• v<N>.x.x で N ≥ 18 の場合 — 事前確認に合格しました。続行してください。

事前確認は、すべての操作の開始時に実行します。結果をキャッシュしないでください。省略しないでください。余計な処理で囲まないでください。scripts/cli.mjs も実行時にチェックを行い、サポート対象外の Node で実行された場合はコード 4 で終了します。これは多層防御にすぎません。必ず先に Bash で事前確認を行い、ユーザーに guide/ux/preflight.md の詳細なインストール／アップグレード案内が表示されるようにしてください。

このスキルの機能

LLM ウィキを構築し、維持します。LLM が決定論的かつトークン効率よく情報を取得できるように構造化された、ファイルシステムベースのナレッジストアです。操作は Build、Extend、Validate、Rebuild、Fix、Join の6種類です。レイアウトモードは3種類です。

• sibling（デフォルト） — 安定した同階層の <source>.wiki/ に書き込みます。ウィキは1つ、同階層のディレクトリも1つで、以後も変わりません。以前の状態には、非公開リポジトリ <wiki>/.llmwiki/git/ 内の Git タグ（pre-op/<id>、op/<id>）からアクセスできます。.llmwiki.v<N> のようなバージョン付きディレクトリが増えていくことはありません。
• in-place — ソースフォルダー自体をウィキとして使用します。<source>/.llmwiki/git/ がソース内に作成され、pre-op/<first-op> スナップショットでは、ユーザーの元のコンテンツをバイト単位で正確に記録します。ロールバックすると、元のツリーが正確に復元されます。ユーザーが --layout-mode in-place を明示的に指定した場合にのみ実行されます。推測による選択や、別モードへの置き換えは行いません。
• hosted — .llmwiki.layout.yaml コントラクトを備えた、ユーザーが選択したパスに書き込みます。ユーザーは --layout-mode hosted --target <path> を指定します。

すべての操作は、preflight → pre-op snapshot → phase commits → validation → commit-finalize の Git シーケンスとして実行されます。ロールバック、diff、ログ、blame、reflog、履歴、リモートミラーリングは、node scripts/cli.mjs <subcommand> から実行できる、このスキルの主要なサブコマンドです。すべて明示的な呼び出しによってのみ実行されます。フック、ウォッチャー、自動化はありません。

曖昧な呼び出しは拒否し、確認を促します。 ユーザーのリクエストに2通りの解釈があり得る場合（デフォルトの sibling が無関係なディレクトリを上書きしてしまう、hosted ターゲットにコントラクトがない、--layout-mode in-place と --target が併用されている、など）、CLI は推測せず、構造化された INT-NN エラーを返してコード2で終了します。すべてのケースについては guide/ux/user-intent.md を参照してください。

別のスキルやエージェントを利用側として連携する

ユーザーがこのスキルにプログラムからアクセスするスキル、エージェント、CI ジョブを作成している場合（このセッションでウィキの構築を依頼しているのではない場合）は、guide/consumers/index.md を案内してください。このサブツリーでは、format_version に基づく判定方法、1つのコマンドでトピックウィキを init する方法、各リーフへの書き込み後に heal する方法、スキルが存在しない場合の検出方法、同梱の scripts/testkit/ ヘルパーを使った利用側テストの作成方法を説明しています。利用側向けの各レシピは guide/consumers/index.md から案内されています。SKILL.md だけをもとに連携方法を独自に導き出さないでください。

簡単な確認方法：skill-llm-wiki contract --json は format_version、CLI 全体、フロントマターのスキーマを返し、skill-llm-wiki where --json はインストール先の絶対パスを返します。どちらも実行時依存関係の事前チェックの対象外なので、利用側はスキルのセットアップ完了前に確認できます。

自動化を行わないための契約

このスキルには、フック、ファイルシステムウォッチャー、PostToolUse リスナー、インストール時の設定、バックグラウンドプロセスは一切ありません。すべての操作は、明示されたターゲットディレクトリに対するユーザーの明示的なリクエストに直接応じてのみ実行されます。ユーザーから依頼がなければ、何もしないでください。自動化を提案しないでください。フックを作成しないでください。スケジュールを設定しないでください。

ユーザーがウィキを手動で編集してインデックスが古くなった場合も、ユーザーが明示的に更新を依頼するまでは何も起こりません。依頼があった時点で、要求された操作を実行してください。

⚠ エージェント委任の契約

すべての Wiki 操作は、現在のセッション内で直接実行するのではなく、専用のサブエージェントで実行します。 これは最適化ではなく、必須のルールです。

ユーザーが6つの操作（Build、Extend、Validate、Rebuild、Fix、Join）のいずれかを依頼した場合、メインチャットから node scripts/cli.mjs <operation> ... を直接実行してはいけません。その代わりに、次の手順に従います。

1. 依頼内容を明確にする — 操作、ソース、ターゲット、レイアウトモード、制約を特定します。必要に応じて、ユーザーに確認を求めます（guide/ux/user-intent.md を参照）。
2. メインセッションで Node.js の事前チェックを実行する — これは低コストで、出力もわずかです。失敗時に詳細なインストール／アップグレードメッセージをユーザーに表示できるよう、エージェントを起動する前に必ず実行します。事前チェックが失敗した場合は操作を中止し、エージェントを起動しません。
3. ホストハーネスのサブエージェント呼び出しプリミティブ（Claude Code：Agent ツール、Codex CLI：同等の機能。仕様は subagent-dispatch-v1 を参照）を使って、専用の「wiki-runner」サブエージェントを起動します。操作、確定した CLI 呼び出し、対象となる guide/ のリーフファイル名、品質モード／レイアウトモードのフラグ、完了条件を含む、自己完結したプロンプトを渡します。サブエージェントは CLI を実行し、Tier 2 のサブ委任を処理し、自身のコンテキストを管理し、完了後に概要を報告します。
4. サブエージェントの概要をユーザーに伝える — メインセッションで Wiki の内容を自身のコンテキストウィンドウに読み込むことはありません。

理由

Wiki の規模はさまざまです。10件のメモが入ったフォルダーから、1万件のエントリーを持つナレッジベースまであります。文章主体の1万件のコーパスのフロントマターを作成する Build では、Tier 2 でホスト LLM が数千件のエントリーを処理する場合があります。すべてをメインセッション内で実行すると、ユーザーが見ることを求めていない内容でコンテキストの予算を消費し、その後の会話に使える余裕がなくなります。wiki-runner サブエージェントは独自のコンテキストウィンドウを持つため、メインセッションの予算をユーザーとの継続中のチャットに温存できます。

wiki-runner サブエージェントの担当範囲

• CLI サブコマンドを実行し、定期的に進捗を返します（各フェーズで何度も報告する必要はありません。フェーズごとに1行で十分です）。
• 自身のコンテキストウィンドウを管理します。 サブエージェントは残りの予算を監視し、上限に近づくと自動的にコンテキストを圧縮します。プロトコルについては、guide/isolation/scale.md の「wiki-runner におけるコンテキストウィンドウの管理」を参照してください。要点は、プライベート git におけるフェーズのコミットが永続的なチェックポイントになるため、サブエージェントは前のフェーズの会話履歴を安全に破棄し、次のフェーズに必要な内容だけを再読み込みできるということです。
• Tier 2 の終了コード 7 のハンドシェイクを処理します。 スキルの CLI は Node 上で実行され、サブエージェントを直接起動できません。オペレーター統合フェーズで Tier 2 のリクエスト（クラスタの命名、中間帯のマージ判断、propose_structure のディレクトリ全体に関する依頼、nest_decision のゲート判断など）が蓄積されると、CLI はそれらを <wiki>/.work/tier2/pending-<batch-id>.json に書き込み、コード 7（NEEDS_TIER2）で終了します。各保留中のリクエストは subagent.dispatch.v1 の形式（prompt、inputs、effort、任意の model、response_schema、outputs_path）に従うため、どの Agent Skills ハーネスでも処理できます。終了コード 7 は失敗ではなく、一時停止して再開するためのシグナルです。wiki-runner は次の手順を実行する必要があります。
  1. CLI の終了コード 7 を検出します。
  2. <wiki>/.work/tier2/ 以下にある pending-*.json ファイルをすべて読み込みます。
  3. 各リクエストを処理します（下記の「インライン処理とファンアウト」を参照）。
  4. 各サブエージェントの構造化 JSON 応答を収集します。
  5. 統合した結果を <wiki>/.work/tier2/responses-<batch-id>.json に書き込みます（保留中のバッチごとに1ファイル。バッチ ID を一致させてください）。
  6. 同じ位置引数で CLI を再実行します。オーケストレーターは再開時に応答を階層化された判断マップに取り込み、最後にコミットされた反復から処理を続行します。
  7. 再実行で終了コード 7 が再び発生した場合（より深いサブクラスタ、残りのディレクトリ、または早期の NEST 後に生成された追加の propose_structure リクエスト）、ループを続けます。終了コード 0（完了）またはそれ以外のゼロ以外のコード（実際の失敗。メインセッションに報告）で終了します。

インライン処理とファンアウト処理

wiki-runner は、バッチサイズに基づいてインライン処理かファンアウト処理を選択します。skill CLI のワイヤープロトコルはどちらの場合も同じです。保留中のファイルを受け取り、レスポンスファイルを出力し、その間に終了コード 7 で終了します。そのため、選択は実行時に wiki-runner が判断するコンテキスト予算とスループットの問題だけです。

• インライン（バッチあたり約 50 件以下）。 wiki-runner は、Tier 2 ワーカー自身として推論し、すべてのリクエストに直接回答します。リクエストごとに子サブエージェントをディスパッチすることはありません。各リクエストの prompt、inputs、response_schema、effort（任意の model オーバーライドを含む）は wiki-runner から確認でき、JSON レスポンスをインラインで書き込みます。これは、約 10～50 件のリーフコーパスを対象にした一般的な build／rebuild に適しています。バッチサイズは小さく、ファンアウトのオーバーヘッドが作業量を大きく上回るためです。また、数十件のフロントマターの塊を比較するには wiki-runner 自身のコンテキストで十分です。環境上の制約として、現在の Agent Skills ハーネス（Claude Code、Codex CLI）における汎用サブエージェントは、自らさらにサブエージェントを起動できません。そのため wiki-runner 自体がネストされたサブエージェントである場合、インライン処理が実際には唯一の選択肢となり、skill の設計でファンアウトを必須にしてはいけません。

• ファンアウト（バッチあたり約 50 件超、またはリクエストごとに effort／model が異なる場合）。 wiki-runner はバッチサイズをメインセッションに報告し、メインセッションはホストハーネスのサブエージェント起動機能を使って、リクエストごと（または同質なリクエストの小グループごと）に範囲を絞ったサブエージェントを 1 つディスパッチします。その際、リクエストの prompt、inputs、response_schema、effort、任意の model を渡します。サブエージェントから見えるのはそれらの入力だけです（merge_decision なら 2 つのフロントマターの塊、cluster_name ならクラスターのリーフメタデータ、propose_structure ならディレクトリ内のすべてのリーフの一覧など）。wiki 全体を渡してはいけません。大規模なコーパス（数千件のリーフに対し、数千件のドラフトフロントマターおよびマージ判断のリクエストが発生する場合）では、インライン処理では wiki-runner のコンテキストを使い切ってしまうため、ファンアウトが適しています。

どちらの場合も skill CLI は変わりません。常に保留中のファイルを出力して終了コード 7 で終了します。レスポンスファイルが作成されるまで、実際の推論方法は wiki-runner が自由に決定できます。

Tier 2 の種類ごとのプロンプトテンプレート

小規模バッチをインライン処理する場合、wiki-runner は以下の既成のひな形を使用できます。各ひな形はリクエストの response_schema に一致する厳密な JSON を返します。JSON オブジェクトの外に説明文を付けるのはテスト上の不具合です。

propose_structure：

You are a Tier 2 sub-agent for skill-llm-wiki acting as a structural optimiser. Answer in STRICT JSON matching the response_schema. Return ONLY the JSON object, no commentary.

Directory: <inputs.directory>
Leaves:
```json
<inputs.leaves array>
```

Your task:
Propose the optimal nested structure for this directory. Group related leaves into named subcategories (slug + purpose + member ids). Leaves that genuinely stand alone should be reported as siblings. You SHOULD favour nesting over flatness whenever 2+ leaves share a defensible conceptual grouping — err on the side of nesting if in doubt.

Response schema:
{
  "subcategories": [ { "slug": "<kebab-case>", "purpose": "<one line>", "members": ["<leaf-id>", ...] }, ... ],
  "siblings": ["<leaf-id>", ...],
  "notes": "..."
}

Return your answer now as a single JSON object.

nest_decision：

You are a Tier 2 sub-agent for skill-llm-wiki acting as a nesting gate. Answer in STRICT JSON.

Cluster candidates:
```json
<inputs.leaves array>
```

Should these N sibling leaves be grouped together under a new parent subcategory? Answer `nest` if they share a defensible conceptual grouping that would meaningfully improve routing, `keep_flat` if the overlap is incidental and nesting would add noise, or `undecidable` if you cannot tell from the frontmatter.

Response: { "decision": "nest"|"keep_flat"|"undecidable", "reason": "<one line>" }

cluster_name：

You are a Tier 2 sub-agent for skill-llm-wiki naming a cluster. Answer in STRICT JSON.

Cluster members:
```json
<inputs.leaves array>
```

Return a short kebab-case slug (one or two words, e.g., `history` or `layout-modes`) and a one-line purpose. If the leaves are clearly unrelated, return decision `reject` with a reason.

Response: { "slug": "<kebab-case>", "purpose": "<one line>" } or { "decision": "reject", "reason": "<...>" }

• 完了の報告。1 段落の要約と、オーケストレーターが割り当てた op-id を添えて報告します。

デフォルトのモデルと作業量

ユーザーが別途指定しない限り、wiki-runner とその Tier 2 のファンアウトでは、デフォルトの作業量レベルでタスクの規模に最も適したモデルを選択します。具体的には、次のとおりです。

• Wiki-runner：CLI のサブプロセスをオーケストレーションし、操作全体をコンテキスト内に保持できるサブエージェントタイプで起動します。非常に大規模なコーパス（項目数が 1k 超、または 10 MB 超）では、高い作業量（effort: "heavy"）で 1M コンテキストのモデルを優先してください。
• Tier 2 の draft-frontmatter サブエージェント：ホストが effort: "light" に割り当てるモデルを選択します。単一のソースファイルから約 200 語の focus と covers[] の組み合わせを作成する用途に適した、費用対効果の高いモデルです。
• Tier 2 の operator-convergence サブエージェント：ペアの曖昧さに応じて、effort: "light" から "balanced" を指定します。ホストが割り当てるモデルは、frontmatter のペアに関する構造的な判断に優れている必要があります。
• Tier 2 の rebuild plan review サブエージェント：「深い理解」が求められるケースのため、effort: "heavy" を指定します。
• HUMAN クラスの Fix サブエージェント：判断の根拠が必要なため、effort: "balanced" を指定します。

ユーザーによる上書き。 ユーザーがモデル（"use sonnet"、"use gpt-5-codex"、"use opus 1M for the whole thing" など）または作業量レベル（"light effort"、"maximum quality" など）を指定した場合は、ディスパッチエンベロープの省略可能な model フィールドと必須の effort フィールドに渡します。ホストのハーネスは、明示的に model が設定されていればそれを優先し、設定されていなければ effort を独自のモデル構成に割り当てます。wiki-runner だけでなく、操作で起動するすべてのサブエージェントに上書き指定を適用してください。ユーザーが競合する上書き指定をした場合（たとえば、要求された作業量レベルに対応していないモデルを指定した場合）は、続行する前に確認してください。

インライン実行は緊急時の手段であり、通常の方法ではありません

メインセッションから node scripts/cli.mjs を直接実行するのは、出力がごく少量の一度限りの読み取り専用プローブ（--version、--help、validate <small-wiki>、log <wiki>、diff <wiki> --op <id> --stat、resolve-wiki）に限ります。プローブの出力が数百行を超える可能性がある場合や、変更を伴う場合は、サブエージェントを起動してください。

レイアウトモードの検出

デフォルトは sibling です。スキルの intent.mjs リゾルバーは呼び出し内容から有効なモードを決定し、推測は行いません。操作ごとの検出の流れは次のとおりです。

• Build。 ユーザーが --layout-mode <mode> を明示的に指定した場合は、それに従います。それ以外の場合は sibling がデフォルトです。ソースにすでに .llmwiki/git/ が含まれている場合、スキルは INT-02（「これはすでに wiki です。extend／rebuild／fix のいずれかを意図していますか？」）で処理を拒否します。デフォルトの sibling <source>.wiki/ が、空でない別のディレクトリと競合する場合、スキルは INT-01 で処理を拒否します。
• Extend／Rebuild／Fix。 既存の wiki を操作します。レイアウトモードには、その wiki の構築時に使用されたモードが適用されます。リゾルバーは sibling／in-place の場合は <wiki>/.llmwiki/git/ を、hosted の場合は <target>/.llmwiki.layout.yaml を読み取ります。
• Join。 ユーザーが指定した <target> にコントラクトがあれば hosted、なければ sibling として扱います。複数のソースを結合する場合は、正規の対象を明示的に指定する必要があります。指定がない場合は INT-07 になります。
• Hosted。 ユーザーは --layout-mode hosted --target <path> を指定します。<target>/.llmwiki.layout.yaml がない場合、スキルは INT-01b で処理を拒否し、コントラクトを作成するか、別の対象を選ぶかを確認します。

対象を手作業で解析してモードを推測してはいけません。常にユーザーが明示したフラグを使って CLI を呼び出し、リゾルバーの判断を信頼してください。INT-NN エラーはそのままユーザーに提示します。

モードは操作ごとに一度だけ決定します。途中でモードを切り替えてはいけません。

スキルの呼び出し方法

ユーザーが操作を依頼した場合：

0. Node.js の事前チェックを実行します。 上記を参照してください。失敗した場合は、処理を停止し、guide/ux/preflight.md に記載されたユーザー向けメッセージを伝えます。
1. 依頼を注意深く読みます。 どの操作か、何がソースか、何がターゲットかを確認します。確信が持てない点は、何かを変更する前に確認してください。依頼が曖昧な場合（例：「ノートを移行して」「その場で実行して」「メモリフォルダーに入れて」）は、CLI を呼び出す前にユーザーに曖昧さを解消してもらいます。該当するシナリオについては guide/ux/user-intent.md を参照してください。
2. 正確なターゲットを特定します。 ターゲットを推測してはいけません。不明な場合は質問してください。build ./docs のデフォルトの兄弟ディレクトリは ./docs.wiki/ です。
3. レイアウトモードを決定します。 上記の「レイアウトモードの検出」を参照してください。デフォルトは sibling です。in-place と hosted には、明示的な --layout-mode フラグが必要です。
4. 各インデックスから guide/ に進みます — 下記のルーティングセクションを参照してください。guide/index.md を読み、ユーザーの依頼から有効化される項目を特定して、有効化された末端ファイルのみを読みます。ウィキ外から guide/ のファイルを選んではいけません。
5. 各フェーズを計画します。 長時間の操作では TodoWrite を使い、ユーザーが進捗を確認して中断できるようにします。
6. 最もリスクの低いフェーズから開始します。 既存のウィキに触れる操作では、構造を変更する前に Validate を実行し、結果を報告します。
7. 決定論的なフェーズには CLI を使います。 すべてのサブコマンドは guide/cli.md に記載されています。
8. AI 集約型の作業は自身のコンテキストで処理します。 散文から focus と covers[] を作成すること、タクソノミーなしで分類すること、意味に基づいて DECOMPOSE で分割すること、AI-ASSIST による Fix の修復は、すべて自身で行います。Read でソースファイルを読み、Write でフロントマターを書き込み、ラウンドトリップを検証します。
9. コミット前に検証します。 コミット前に必ず新しい状態で Validate を実行します。ウィキを壊れた状態のままにしてはいけません。
10. 依頼された操作が完了したら停止します。 依頼されていない限り、Rebuild や Fix に続けて進んではいけません。ユーザーが言及していないウィキに対して shape-check を実行してはいけません。比較のために兄弟ウィキを開いてはいけません。

guide/ へのルーティング

guide/ は実際の LLM ウィキであり、このスキルがユーザー向けに構築するものと同種の構造です。Claude は、手作業で管理された表ではなく、メソドロジーの標準的な意味的ルーティング手順を使って guide/ に進みます。これにより、後に操作するあらゆるウィキに応用できるルーティングの規律を、一度に身につけられます。

手順

1. ユーザーの依頼からコンテキストプロファイルを作成します。プロファイルは、Claude が内部で作成する3つのフィールドを持つ小さな構造化オブジェクトです。これらのフィールドは、ウィキに対して意味的に組み立てるクエリを形作ります。集約されたルーティングテーブルに対するリテラルなキーワードやタグの照合には、もう使用しません。

   • keywords — 依頼に含まれるトークンです。操作名（build、extend、validate、rebuild、fix、join）、一般的な同義表現（create wiki、check wiki、repair、optimise、merge wikis）、サブコマンド名（ingest、shape-check）、およびユーザーが使ったその他の具体的な用語を含めます。これらを使って、各エントリーの focus と照合する意味的な意図を組み立てます。
   • tags — Claude が依頼から導き出す短い分類ラベルです。
     • operation — ユーザーが6つの操作のいずれかを依頼した場合に設定します。
     • hosted-mode — ターゲットがホスト型である場合に設定します（モード検出のステップで決定します）。
     • mutation — Validate 以外のすべての操作で設定します（構造が変更される可能性があります）。
     • preflight-failure — Node.js の事前チェックが実際に失敗した場合に限って設定します。デフォルトでは設定しません。
   • operation — 依頼が対象とする1つの操作 ID（build / extend / validate / rebuild / fix / join）、または情報を求める依頼の場合は null です。操作サブツリーが対象範囲に含まれることを示します。

2. guide/index.md を読みます。 フロントマターを解析します。entries[] フィールドには、id、file、type、focus、および作成者が付けたタグがあればそのタグとともに、すべての直接の子が記載されています。親インデックスには、サブツリー内のすべての子に共通する内容を示す、作成者が記述した shared_covers リストもあります。子の階層をさらにたどるかどうかを判断する際は、これも追加のコンテキストとして使用してください。

3. 現在の依頼に関連するエントリを判断します。 各エントリの focus を読み（また、サブツリー全体に共通するコンテキストとして親の shared_covers も参考にし）、意味に基づいて関連性を判断します。そのエントリの目的は、ユーザーの依頼内容と重なっていますか？ 依頼に含まれるキーワードやフレーズがエントリの focus に現れる場合は、関連性を強く示す肯定的なシグナルです。表面的な一致がなくても、依頼の意図と意味的に類似していれば、同様に強いシグナルです。同義語や言い換えも考慮してください。漏れなく拾いつつ、無差別に選ばないようにしてください。エントリの focus が今回の依頼と明らかに無関係なら、対象から外します。照合するためのキーワードやタグの固定リストはありません。判断はあなたに委ねられています。

4. 一致したサブカテゴリーをたどります。 一致したエントリの type: index の場合は、その index.md を読み、同じ階層の手順 2 から繰り返します。AND フィルターも、段階的に候補を絞り込む仕組みもありません。手順 3 の意味的な関連性判断だけが唯一のゲートです。たとえば guide/ では、「このスキルは何をするのか」といった情報を求める質問の場合、focus が「6 つの CLI 操作とそのフェーズ」である operations/ サブツリーは通常たどりません。これが意図どおりの早期終了です。

5. 一致したリーフを読み込みます。 一致したリーフエントリごとに、リーフファイル全体を読みます。リーフを開いた後に activation.{keyword_matches,tag_matches,escalation_from} ブロックがあれば、これはルーティング規則ではなく、あくまで補足的なヒント情報です。作成者が、特定の状況でそのリーフが関連すると考えた理由を示しており、その後の判断に役立ちます（たとえば、このリーフの escalation_from に fix があるなら、Fix 操作を行う際に、隣接する correctness/invariants.md も対象にするべきか確認するとよいでしょう）。ただし、リーフを読み込むかどうかを文字列の一致で判断するために使ってはいけません。その判断はすでに、手順 3 で親の focus の説明に基づいて行われています。

6. プリフライトの失敗時は、専用の経路をたどります。 Node.js のプリフライトに失敗した場合、コンテキストプロファイルは操作の意図を含まず、tags: [preflight-failure] のみです。プリフライトの概念に関する wiki の項目を、意味に基づいてたどります。ux/preflight.md リーフの focus は明らかに一致し、その親カテゴリーである ux/ にはユーザー向けメッセージに関する共通カバーもあるため、一致をさらに裏付けます。そのリーフだけを読み込み、該当する Case メッセージを一字一句そのまま伝え、そこで終了します。操作に関するリーフは読み込まないでください。

7. 情報を求める質問の場合。 ユーザーが「このスキルは何をするのか」「ホストモードを説明して」「どのような操作があるのか」、または対象に対する操作を求めていないその他の質問をした場合、手順 3 の意味的な判断では、ルートの entries[] との一致が ゼロ件 になるはずです。各エントリの focus は「X とは何か」ではなく、「X の実行方法」に関する内容を記述しているため、情報を求める意図とは重なりません。guide/ からは何も読みません。回答は SKILL.md のみを参照してください。ただし、ユーザーが wiki 内の特定のトピック（「ホストモードを説明して」「レイアウトコントラクトの仕組みを教えて」など）について明示的に尋ねた場合は例外です。その場合は、意味に基づいて該当するリーフまでたどり、そのリーフだけを読みます。

手作業で管理する表よりも優れている理由

• 自動で最新状態に保たれます。 guide/ に新しいリーフを追加する場合、その focus を明確に記述し、適切なサブカテゴリの下に配置するだけです。次回の index-rebuild でルーティングに反映されます。SKILL.md を編集する必要はありません。
• 各キーワードを記述するのは一度だけです。 作成者がルーティングに関係する各単語を記述するのは、リーフ自身の focus（または任意で activation ヒントブロック、あるいは親の shared_covers）だけです。以前の基盤では、すべてのキーワードを絞り込みの階層に沿って各祖先の activation_defaults に重複して記述していたため、1つのリーフのキーワードが3つか4つのインデックスに載っていました。新しい基盤では、この重複がなくなります。
• 意味的マッチングで、同義語、言い換え、新しい語彙にも対応できます。 以前のリテラルルーターでは、作成者が列挙したキーワードしかマッチしませんでした。意味的マッチングを使えば、「blame a line」は、「per-line authorship を調べる」と記述されたリーフに到達します。2つの表現に共通するリテラルトークンがなくても問題ありません。これは、Claude がこのスキルのほかのあらゆる部分ですでに行っている推論の仕方であり、ルーターもこれに一貫するようになりました。
• ルーティングがスキルのほかの部分と整合します。 Tier 2 の判断はすでに意味的に行われています（クラスタの命名、ネストのゲーティング、propose_structure）。ルーターは最後の決定論的なレイヤーであり、その決定性の代償として、すべてのインデックスファイルに集約コストを課していました。意味的ルーティングにより基盤が全体に整合し、このコストがなくなります。
• 応用可能なスキルが身につきます。 guide/ に適用する手順は、ユーザー自身の ./memory.wiki/ や ./docs.wiki/ など、あらゆる LLM ウィキに適用する手順と同じです。1つの手順で、無数のウィキに対応できます。
• 情報を尋ねるクエリを早期に処理できます。 「このスキルは何をするのか？」という質問では、ルートで意味的マッチが0件となり、SKILL.md だけを参照して回答できます。これが最も低コストな経路であることに変わりはありません。

禁止されている近道

• SKILL.md からハードコードしたパスで guide/ のファイルを読んではいけません。必ずルーティング手順に従ってください。
• guide/index.md を先に読んで各リーフの focus を確認せずに、リーフを読んではいけません。
• マッチするかを判断する前に、リーフのフロントマターを覗いてはいけません。ルートインデックスの entries[] にリーフの focus 文字列がすでに含まれており、関連性を判断するにはそれだけで十分です。
• 情報を尋ねるクエリの早期処理を省略し、先回りしてすべてを読んではいけません。1バイトごとにトークンを消費します。

よくある避けるべきミス

• guide/ ファイルをハードコードしたパスで読む。 必ずルーティング手順に従ってください。ルーティングはこの方法論の要です。迂回しないでください。
• 情報を尋ねるクエリで guide/ ファイルを読む。 「このスキルは何をしますか？」という質問では、ルートエントリーとの意味的な一致はゼロになります。SKILL.md のみを参照して回答してください。
• 一致するかどうかを判断する前に、リーフのフロントマターを覗く。 guide/index.md の entries[] には各子項目の focus 文字列がすでに含まれています。それを照合してください。リーフを開いて独自のフロントマターを読むのは無駄です。関連性の判断は親レベルで行います。
• スクリプトをソースとして読む。 絶対にしないでください。ルーティング手順でたどり着く guide/cli.md に記載された CLI サブコマンドを使ってください。
• Node.js の事前チェックを省略する。 例外なく、すべての操作の前に実行します。
• 自分で Node.js をインストールまたはアップグレードしようとする。 絶対にしないでください。事前チェックに失敗した場合は、事前チェックの概念を意味的にたどってウィキを調べてください。guide/ux/preflight.md の focus が一致します。そこを読み、内容を一字一句そのまま伝えてください。
• sibling モードでユーザーのソースフォルダー内に書き込む。 絶対にしないでください。sibling モードではソースは変更不可です。すべての書き込み先は <source>.wiki/ です。
• hosted モードでレイアウト契約の範囲外に書き込む。 契約が優先されます。
• in-place モードだと推測する。 絶対にしないでください。ユーザーは --layout-mode in-place を明示的に指定する必要があります。曖昧な場合は INT-02 または INT-09a で拒否されます。
• リーフの内容を index.md に書き込む。 インデックスの本文はナビゲーション専用です。リーフの内容はリーフファイルに記載します。
• 自動化を提案する。 フック、ウォッチャー、スケジュールは設定しないでください。すべての操作はユーザーからの明示的な依頼が必要です。
• ユーザーが依頼していない操作を実行する。 依頼されていない限り、Validate の後に Rebuild を続けて実行しないでください。
• 1 回の操作でレイアウトモードを混在させる。 intent.mjs が一度だけ解決し、そのモードを操作全体で適用します。
• 操作中に同じ guide/ ファイルを再読する。 1 回の操作につき 1 回で十分です。