infranodus

InfraNodus

InfraNodus MCP サーバーを介したテキストネットワーク分析とナレッジグラフのツールです。

このスキルと InfraNodus の連携方法

• クエリと分析 — セッション内のネイティブ MCP ツールを使用します （mcp__infranodus__<tool>、または InfraNodus コネクターに相当するもの）。 各ツールのパラメーターやワークフローのパターンについては、サーバー独自の 指示とツールスキーマが正式な参照情報です。ここで内容を重複させたり、 独自に判断したりしないでください。
• 一括アップロード（リポジトリ／Vault のグラフ）— まずセッションサーバーを使用します。 セッションにすでに接続されている InfraNodus MCP サーバー（例：claude.ai InfraNodus コネクター）を優先してください。エージェントがそのサーバーの create_knowledge_graph ツールを使って、references/repo-graph.md のステップ 3 に記載された アップロード契約に従い、チャンク単位でアップロードします（スコープごとに graphName を 1 つ使用し、見出しを考慮したチャンク、maxNodes: 500、スコープで 宣言された wikilinksMode、間隔を空けた呼び出し、429 のバックオフ、413 の 二分割、スクリプトと同じマニフェストおよびレポートの記録）。
• フォールバック — 同梱スクリプト。 セッションに InfraNodus MCP ツールが 接続されていない場合に限り、scripts/upload_scopes.py を使用します。このスクリプトは、 このエージェント独自の設定に登録された MCP サーバーを介してアップロードします。 設定の優先順位は <project>/.mcp.json、次に ~/.claude.json（このプロジェクトの セクション、次にグローバル）、最後に ~/.claude/settings.json で、プロジェクトの設定が 優先されます。http エントリはその url に接続し、stdio エントリ （ローカルまたはセルフホスト可能なサーバー）は独立したサブプロセスとして起動します。 事前確認：upload_scopes.py [project_dir] --check-auth。このスクリプトからクラウド OAuth コネクターに接続することはできません。トークンがリモートに保存されているためです。 そのため、上記のコネクターパスはエージェント主導で実行します。
• 認証情報（スクリプト経由の場合のみ）は設定ファイルから読み込みません。 http サーバーの場合、キーは環境変数 INFRANODUS_API_KEY からのみ取得し、 それ以外からは取得しません。stdio サーバーの場合、エントリ独自の env ブロックを変更せずにサブプロセスへ渡します。エンドポイントのデフォルト値も 認証情報のフォールバックもありません。サーバーは 1 つ、試行も 1 回です。 接続に失敗した場合、セッションコネクターがあればそちらにフォールバックし、 なければそこで処理を停止します。別のアプリケーションの設定から見つけたキーを エクスポートして、この動作を回避しないでください。そうすると、ユーザーが選んでいない アカウントにコンテンツが保存される可能性があります。
• どちらも利用できない場合（セッションツールも設定済みサーバーもない場合）、 --check-auth はホスト型とローカル型の両方のオプションについて、 claude mcp add コマンドを表示します。いずれかの実行を提案するか、抽出した スコープファイルをローカルに保持するよう提案してください。エンドポイントを推測してはいけません。
• 出所情報 — アップロードされた各スコープについて、endpoint、transport、 account、verified（グラフの読み戻しに成功した日付）をマニフェストに記録します。 グラフクエリが失敗した場合、グラフが存在しないと決めつける前に、 マニフェストの endpoint／account とセッション独自のサーバーを照合してください。 同じ graphName でも、サーバーやアカウントが異なれば別のグラフを指します。

クイックガイド（詳細はサーバーのツールスキーマを参照）

• テキスト／URL／グラフの構造的な概要：generate_knowledge_graph、 generate_topical_clusters。create_knowledge_graph で保存します （同じ graphName へのアップロードではステートメントが追加されます）。保存済みグラフから delete_statements でステートメントを削除します（カテゴリ、完全一致テキスト、 クエリ、日付、ID、またはすべてで指定できます。confirm: false は一致項目を一覧表示する ドライランです。リポジトリ／ボルトの更新フローでは、変更されたファイルをその場で置き換えるために使用します）。update_statements でステートメントをその場で編集します（ID、日付、 順序は維持されます）。個々の行（要約の原則や記憶項目など）を修正するには edits: [{match, content}] を指定し、 1つのセレクターと set を使うとカテゴリやタイムスタンプを追加／削除できます。replace: {pattern, with} を使うと、 グラフ全体でソースのラベルを付け直したり、[[concept]] の名称を変更したりできます。同じドライラン → confirm: true の手順です。
• 不足点の特定／アイデア出し：generate_content_gaps → generate_research_questions ／ generate_research_ideas。 一連のパイプラインには develop_text_tool を使用します。
• 検索：retrieve_from_knowledge_base（保存済みグラフに対する GraphRAG）、 analyze_existing_graph_by_name（保存済みグラフの構造）、 generate_contextual_hint（軽量な構造的概要。幅広い質問に答える前のコンテキスト注入に適しています）、 generate_responses_from_graph（保存済みグラフから生成する、プロンプトベースの回答と専門的なアドバイス。グラフ独自の視点で答えるべき助言／推奨の質問に適しています）、 list_graphs ／ search ／ fetch（探索用）。
• 推論の確認：草稿の統合結果に対して optimize_reasoning を使用します。偏向／集中／多様／分散の状態を診断し、さらに展開すべきトピックや不足点を提案します。
• 比較：overlap_between_texts、difference_between_texts、 merged_graph_from_texts（いずれも contexts 配列を受け取ります）。
• SEO／GEO：generate_seo_report（タイムアウトは90秒以上）、または個別の analyze_google_search_results ／ analyze_related_search_queries ／ search_queries_vs_search_results ツールを使用します。
• 回答に含まれる多様性の統計：biased → 集中しすぎ、focused → やや集中、diversified → バランスが取れている、dispersed → 散漫。

リポジトリ／Vault のグラフ（プロジェクトフォルダー内で実行）

リポジトリ、プロジェクト、または Obsidian Vault のグラフ化、分析、質問を求められた場合は、references/repo-graph.md に従ってください。これが唯一の正式な手順書です。概要は次のとおりです。

1. infranodus/manifest.json が存在し、依頼が質問の場合 → マニフェストを介してルーティングします（各グラフには purpose と topics が記録されています）。グラフに問い合わせてください。再抽出はしないでください。コンテンツはグラフ内にのみ存在し、ローカルのコンテンツファイルはありません。 マニフェストが存在し、ビルド／更新の意図がある場合（または /infranodus のみが指定された場合）→ まず python3 scripts/repo2statements.py . --detect を実行し、AskUserQuestion の選択肢を「変更されたスコープを更新（<その要約>）」、次に「スコープをその場で再構築」、「新しいスコープを追加」、「全体を再構築」の順に提示します。更新 = repo2statements.py . --update [--scope X] → upload_scopes.py .（アップローダーは、変更されたファイルの古いステートメントをカテゴリ別に delete_statements で削除し、差分を同じグラフに追加します。移動しただけのファイル（内容は同じでパスが新しいもの）は、再抽出せずに update_statements でその場でラベルを変更します）。再構築 = 再抽出 → upload_scopes.py . --force（グラフを先にクリアし、同じ名前で再構築します）。変更がない場合は、クエリモードを提案します。作成済みのダイジェストの数行を修正する場合は、ファイルを編集して update_statements で変更します。再構築はしません（repo-graph.md の Digest ステップ 4）。
2. マニフェストのない状態で何も指定せず起動した場合（対象名がない場合）、フォルダーの内容を確認してから、何をビルドするかを AskUserQuestion で尋ねます。全体のグラフ（推奨）／特定のフォルダー／特定の用語を含むドキュメント／1 つのドキュメント（追加の質問については手順書を参照）。ユーザーがすでに対象を指定している場合、この質問は省略します。その後、必ずビルドモードを尋ねてください（複数選択可）。全量取り込み（すべての文章スコープ、LLM なし）、構造マップ（決定論的：リポジトリではツリー、インポート、エクスポート、docstring の見出し、Vault ではページリンク。低コストで、LLM なし）、ダイジェスト＋構造的フィードバック（対象を読み、その仕組みを表す簡潔なステートメント（原則、ルール、手順、引き継ぎ）を作成し、アップロード済みグラフに対して optimize_knowledge_base を実行します。何が優勢か、十分に掘り下げられていない内容は何か、どのクラスターが一度もつながっていないかを確認します）、および／または オントロジー（サーバーが構造グラフまたはドキュメントグラフからエンティティと型付き関係を抽出し、onto-<project> にまとめます。各要素がどう結び付いているかを示します。サーバーの LLM トークンを消費します）。ダイジェストはプロジェクトのレビューと改善に、オントロジーはプロジェクト内のナビゲーションに使います。オントロジーを作成するには、先に構造またはドキュメントをアップロードしておく必要があります。ダイジェストには何も必要ありません。
3. ビルド：python3 scripts/repo2statements.py .（全体）、... --structure、および／または ... --digest（読み取りリストと形式を出力します。終了コード 2 はエラーではなく、「ファイルを今すぐ作成してください」という意味です。指定されたファイルを作成し、同じフラグで再実行して登録します）。1 回の実行につきフラグは 1 つ → python3 scripts/upload_scopes.py . （アップロードし、バックグラウンドで実行します。ルーティングのメタデータをマニフェストに記録し、追記専用の INFRANODUS_REPORT.md ログに日付付きのセクションを追加して、中間スコープファイルを削除します。オントロジーレイヤーには --ontology を追加するか、Path A で sourceGraphName を指定して generate_ontology_graph を自分で呼び出します）→ upload_scopes.py . --register-project（1 回）。登録ステップでは AskUserQuestion を 1 回だけ行います（仕様は手順書のステップ 4 を参照。CLAUDE.md に infranodus-memory マーカーブロックがすでにある場合は省略します）。ルーティングルールのみを登録するか、セッション終了時のインサイト記憶の規約も追加するかを尋ねます（--register-project --with-memory）。後者は 2 つ目のマーカーブロックを追加し、実質的な内容のある各セッションでユーザーのインサイトを抽出し、ユーザーの承認を得て memory_add_relations を使い <slug>-insights メモリーグラフに保存する規約です（呼び出しは memory_get_relations）。求められていない場合は、絶対に設定しないでください。インサイトとはユーザー自身の気づきです。プロジェクトの学び（エージェントの操作）やコンテンツグラフ（ファイルの内容）とは分けてください。

関連スキル

このスキルと組み合わせて使える、同じファミリーの関連スキルです。スキルが利用可能なスキル一覧に表示されている場合に限り、Skill ツール経由で呼び出してください（名前と説明で照合してください。インストール先を決めつけないでください。インストールによって名前が多少異なる場合があります）。見つからない場合は、https://github.com/infranodus/skills からインストールできることを伝えてから続行してください。

ナレッジベースのワークフロー：

• llm-wiki — 生の情報源から、LLM が作成するナレッジベース（要約した wiki ページ、厳選されたオントロジー）を構築し、保守します。スキャンした PDF、「第二の脳」／リサーチ wiki の依頼など、時間とともに蓄積していくコンテンツの作成が必要なコーパスはこちらに振り分けてください。このスキルは存在するものをマッピングします。llm-wiki はその上に新しい知識を書き加えます。厳選されたスコープは同じ infranodus/ マニフェストを共有し、その wiki-* グラフも同様にクエリできます（runbook のポリシールールを参照してください）。
• project-learnings — エージェントがプロジェクト内で作業して得た知見（落とし穴、慣習、情報の所在、決定事項）を、サーバーの get_project_learnings ／ add_project_learnings ツールを使って、オプトイン式の learn-<project> グラフに保存します。このスキルはリポジトリに含まれる内容をマッピングしますが、こちらはそこでの作業からエージェントが学んだことを記録します。エンティティ名が同じなので、グラフを組み合わせられます（両者間の difference_between_texts により、コードはあるものの知見がないモジュールがわかります）。実質的なタスクの開始時と終了時、および「学んだことを保存して」という依頼があったときは、こちらに振り分けてください。求められていない場合は、決して有効にしないでください。
• ontology-generator — トピックやテキストから、LLM が [relationCode] タグ付きの [[wikilinks]] オントロジーを生成します。このスキルの決定論的な共起マイニングではなく、意味的な関係（X が Y を引き起こすなど）をユーザーが求めている場合に提案してください。出力はそのまま InfraNodus に貼り付けられます。
• seo-analysis — 同じ MCP ツールを使った、SEO 調査の完全なワークフロー（キーワード調査、検索意図、情報の供給と需要）を提供します。単発のレポートではなく SEO プロジェクトの依頼であれば、こちらを優先してください（generate_seo_report の呼び出しを1回行うだけなら、追加のスキルは必要ありません）。

思考と分析のレンズ — グラフの診断結果から必要性が示された場合、またはユーザー自身がきっかけを示した場合に提案してください。

• shifting-perspective — 談話の構造的な多様性（optimize_text_structure）を診断し、十分に表現されていない視点を掘り下げます。グラフに偏りや焦点の偏りが見られる場合や、ユーザーが一つの見方にとらわれている場合（「何を見落としているのか？」）に提案してください。
• cognitive-variability — ズームレベルや、つなげる／探索するモードの切り替えを促し、硬直した思考や堂々巡りを解消します。構造的な診断を行う shifting-perspective の後に使うのが自然です。
• critical-perspective — 好奇心に基づく問いかけを通して、前提を問い直し、見落としを探します。内容を広げるのではなく、統合した内容を批判的に検証する必要がある場合に提案してください。
• rhetorical-analyst — 説得、修辞、論理に関する議論や討論の戦術を分析します。このスキルのグラフツールを使って分析を始めます。討論、スピーチ、コメント欄、「なぜ説得力があるのか？」といった依頼に提案してください。
• perspective-reversal — 対立や交渉を相手の視点から捉え直し、戦術的な助言を提供します。分析対象の談話が敵対的なもの（争い、対立、交渉）である場合に提案してください。
• embodied-navigation — ネットワークとしてマッピングされた状況に、身体化された動きの原則（平静なスキャン、適応的な流動性、テンセグリティ）を適用します。行き詰まり、硬直、または議論ではなく力学として捉えられる対立に提案してください。
• vipassana-meditation — 平静で反応にとらわれない観察により、執着のループを断ち切ります。会話に特定の結果への強い欲求や、不快な発見への回避が見られ、分析に先立ってただ観察することが必要な場合に提案してください。