mcpField
W
wiki-room

wiki-room

github.com/rheinmirエージェントワークフロー10216 回インストール2 週間前に更新
リポジトリ

wiki-room について

wiki-roomは、メインセッションのコンテキストを膨らませずに複数のWikiページを詳しく調べるエージェントスキルです。読み取り専用のサブエージェント1つで調査し、長いセッションや関連ページにまたがる質問に、出典付きの要約を返します。

主な機能

  1. 01読み取り専用サブエージェント1つでの詳細調査
  2. 02関連ページを1段階たどって参照
  3. 03ページ数の上限を適用
  4. 04500語以内の出典付き結論
  5. 05古いページと不足情報の明示

活用シーン

  1. 01長いセッションでのWiki詳細調査
  2. 023ページを超える関連ページの確認
  3. 03コンテキストが逼迫した際の要点把握

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/rheinmir/setup --skill wiki-room

インストール後、Claude Code で/wiki-roomを入力して読み込まれたか確認します。

詳細

スキル:wiki-room

wiki-core v2 の Tier C(concept wiki-core-relations):メインセッションのコンテキストが長くなったり、ローテーションが発生したりしたときは、メインセッションに詳細を追加で読み込ませません。1 つの room(サブエージェント)を開いて全情報を読み込ませ、圧縮した結論を返します。メインセッションは地図(Tier A)を保持し、詳細は room 内で使い捨てにします。

WHAT

目的とコンテキスト
  • 目的: メインセッションのコンテキストを膨らませずに、複数の wiki ページから詳細な情報が必要な質問に回答します。詳細は room(サブエージェント)で読み込んで使い捨てにし、メインセッションには出典付きの圧縮した結論のみを返します。
  • 使用するタイミング:
    • メインセッションが長くなり(要約が何度も行われており)、複数の wiki ページから詳細な情報が必要な場合。
    • 3 ページを超える wiki ページと、その関連ページをすべて読む必要がある質問の場合。
    • ユーザーが「room を開いて」「context rot」「wiki の詳細を追加で読み込んで」「wiki を深掘りして」「/wiki-room」と言った場合。
  • 対象外:
    • 具体的なページが 1〜2 ページだけ必要な場合は使用しません。room を使うより直接読むほうが低コストです(速度基準)。
    • 長期記憶としては使いません。残すべき知識は /ingest またはページの更新を通して wiki に抽出します。
    • wiki は編集しません。room は読み取りと要約のみを行います。
メンタルモデル

質問 → Tier A brief(id の一覧 + stale ページ + きっかけとなる episode)→ budget B → 1 つの room(サブエージェント、depth 1)が Tier B + 1 段階の関連ページを読む → 出典付きの圧縮した結論 ≤500 語 → メインセッションが対応

入力と出力の契約
FieldRequired?意味
In質問はいwiki で深掘りする内容
Inbudget Bいいえ(デフォルト 12)関連する 1 段階のページも含む、Tier B のページ数の上限
Inページ id の一覧W01 で作成質問 + wiki/index.md + wiki/stale.json + episode の検索結果から作成
Out圧縮した結論はい≤500 語。すべての主張に出典ページを付記し、stale ページにはフラグを付けます。budget に達した場合は「budget に到達、未読:」と記載します。データが不足している場合は「不足:<何が>」と記載します。

「完了」とは、メインセッションが圧縮した結論を受け取り、それをもとに対応することです。ページ全文を貼り付けません。

ルールと機能

3 つの厳守ルール(room のプロンプトにそのままコピーします):

  • RULE-01 (MUST): 深度上限 = 1(G3): room はどのような理由があっても、room/サブエージェントを子として開いてはいけません。データが不足している場合は、結論に「不足:<何が>」と記載し、メインセッションに判断を委ねます。
  • RULE-02 (MUST): 厳格な budget: 最大 B ページまで読みます。上限に達したら読むのを停止し、得られた情報をもとに要約します(サーキットブレーカー — 「budget に到達、未読:」という注記を付けて、部分的な結果を返します)。
  • RULE-03 (MUST): 出典付きの圧縮した結論: すべての主張に出典ページ(concepts/x.md)を付記します。brief に記載された出典ページが stale の場合は、「(stale — 信頼する前に再確認)」というフラグを付けます。

アンチパターン(メインセッション向けの補助ルール):

  • RULE-04 (MUST NOT): 1 つの質問に対して複数の room を並行して開いてはいけません(budget の合計を管理できなくなります)。1 つの質問につき 1 つの room です。

  • RULE-05 (MUST NOT): room を長期記憶として使ってはいけません。room は使い捨てです。残すべき知識は /ingest またはページの更新を通して wiki に抽出し、room の transcript には残しません。

  • RULE-06 (SHOULD NOT): メインセッションがまだ短いときは room を呼び出さないでください。直接読むほうが速いです。

  • 機能:wiki の読み取り(index、stale リスト、frontmatter の relations:)、episodic の意味検索、読み取り専用のサブエージェントを 1 つだけ起動できます。wiki への書き込みはできません。

失敗時の境界
  • 質問に必要なページが 1〜2 ページだけの場合 → room は開かず、直接読みます(適切な判断です)。
  • room が budget B に達した場合 → partial:部分的な結論と未読ページのリストを返します。
  • room でデータが不足している場合 → 「不足:<何が>」と記載し、メインセッションに判断を委ねます(子 room は開きません)。
  • 出典ページが stale の場合 → 使用しつつ、再確認が必要なことを示すフラグを付けます。

HOW

メインワークフロー
StepTypeInputsActionOutputs/exitFailure/next
W01judgment質問、wiki/index.md、wiki/stale.json、mem-rank.pyTier A のブリーフを作成する(メインセッション、低コスト)ページ ID のリスト + stale フラグ + きっかけとなるエピソード≤2 ページ → 直接読む。終了
W02deterministicID リスト、frontmatter relations:開く前に予算 B を確定する(デフォルト 12、1 ステップ隣接ページを含む)B + 上限内のリスト—
W03effectブリーフ、B、3 つの厳守ルールroom を正確に 1 つ開く(subagent Explore/general-purpose)room が実行される—
W04judgmentroom の結論要約された結論(≤500 語 + 出典)を受け取り、次のアクションを決めるメインセッションの判断予算に到達/不足 → B01

各ステップの詳細(W01~W04 の信頼できる情報源):

  1. Tier A のブリーフを作成する(メインセッション、低コスト): 質問 + wiki/index.md から調査が必要なページ ID のリストを集めます
    • wiki/stale.json(関連する stale ページは、ブリーフに「古くなっている可能性あり」と明記します)。 エピソードのセマンティック検索で補足します:python3 harness/scripts/mem-rank.py retrieve "<質問>" --kind-filter episode — [[wikilink]] がなくても「前のセッションで何をしたか」を捉え、 浮上したファイル/エピソードを room のブリーフに含めます。
  2. 開く前に予算を確定する: Tier B ページは最大 B 件(デフォルト 12)+ 1 ステップの関連隣接ページ (リスト内のページの relations: frontmatter を読み取ります。これも B に含めます)。
  3. room を正確に 1 つ開く: 質問、ID リスト、 予算 B、および Rules セクションにある 3 つの厳守ルールを含むプロンプトで、Explore/general-purpose の subagent を 1 つ起動します (プロンプトには原文のままコピーします)。
  4. 要約された結論を受け取る(≤500 語 + 出典の引用)。メインセッションではその内容に基づいて次のアクションを行います — room が読んだページの全文をメインセッションに貼り付けてはいけません。
分岐
IDKindGuard動作Skip / failureRejoin
B01recoveryroom が予算 B に到達する、または「不足:<何か>」と報告するメインセッションで判断します:途中までの結論を使うか、不足分のページをいくつか直接読む子 room は開かず、2 つ目の room を並行して開かないW04
検証と停止

room はリストを読み終えるか、B に到達した時点で停止します(ページ数を数える決定論的なサーキットブレーカー)。レビューで検証します:結論は ≤500 語で、すべての主張に出典ページがあり、stale ページにはフラグが付いていること。質問 1 件につき room は最大 1 つです。

例
  • 正常系: 長時間のセッションで「wiki-core v2 は各 tier で stale をどう扱いますか?」と質問 → 6 ページ + 3 つの隣接ページをブリーフに含める(B=12) → room を 1 つ起動 → concepts/wiki-core-relations.md を引用した 400 語の結論。1 ページには「(stale — 信頼する前に再確認)」と付記。
  • 境界/失敗: 質問には 20 ページ必要で、B=12 → room は 12 ページ目で停止し、「予算に到達したため、未読:<8 ページ>」を添えて結論を返す。子 room は開かない。
  • 境界: concepts/solid-what-how.md だけで十分 → room は開かず、直接読む。

起源

  • Source: concept wiki-core-relations §2.4 Tier C + council 020726 guardrail G3/G6
  • Date: 2026-07-02

コメント