git:20260901.7df2a8c to git:20260908.342c001

---

name: infranodus

description: >-

Text network analysis and knowledge graphs via the InfraNodus MCP server:

analyze text structure, find content gaps, generate research questions and

ideas, compare texts, optimize content for SEO/GEO, analyze Google search

results, GraphRAG retrieval, structured memory. Accepts text, URLs (YouTube

transcription included), and saved graphs. Also builds knowledge graphs of

code repos and Obsidian vaults: invoked in a project folder ("graph this

repo", "analyze this vault", "/infranodus") it mines docs, PDF text,

docstrings, WHY/NOTE comments, and commit/PR/issue history into saved graphs

with a report, and keeps them current by replacing the statements of changed

files in place. When infranodus/manifest.json exists in the project root,

answer questions about themes, decisions, rationale, or gaps by querying the

existing graphs FIRST, before reading files. For an LLM-authored knowledge

base built from sources (wiki pages, curated ontologies), prefer the llm-wiki

skill.

metadata:

homepage: https://infranodus.com

openclaw:

emoji: "🕸️"

requires:

env: ["INFRANODUS_API_KEY"]

primaryEnv: INFRANODUS_API_KEY

---

# InfraNodus

Text network analysis and knowledge graph tools via the InfraNodus MCP server.

## How this skill talks to InfraNodus

- **Queries and analysis** — use the native MCP tools in the session

(`mcp__infranodus__<tool>`, or the InfraNodus connector's equivalents).

The server's own instructions and tool schemas are the authoritative

reference for every tool's parameters and workflow patterns — do not

duplicate or second-guess them here.

- **Bulk uploads (repo/vault graphs) — session server FIRST.** Prefer the

InfraNodus MCP server already connected to this session (e.g. the

claude.ai InfraNodus connector): the agent performs the upload itself

with that server's `create_knowledge_graph` tool, chunk by chunk,

following the upload contract in

[references/repo-graph.md](references/repo-graph.md) Step 3 (one

`graphName` per scope, heading-aware chunks, `maxNodes: 500`, the

scope's declared `wikilinksMode`, paced calls, 429 backoff, 413

bisection, and the same manifest + report bookkeeping the script does).

- **Fallback — the bundled script.** Only when the session has NO

InfraNodus MCP tools connected, use `scripts/upload_scopes.py`, which

uploads through the MCP server configured in this agent's own config —

`<project>/.mcp.json`, then `~/.claude.json` (this project's section,

then global), then `~/.claude/settings.json` — with project scope

winning. An `http` entry is reached at its own `url`; a `stdio` entry

(a local or self-hosted server) is launched as its own subprocess.

Preflight: `upload_scopes.py [project_dir] --check-auth`. The script

can never reach a cloud OAuth connector — that token lives remotely —

which is exactly why the connector path above is agent-driven.

- **Credentials (script path only) are never read from config files.**

For an `http` server the key comes from `INFRANODUS_API_KEY` in the

environment and nowhere else; for a `stdio` server the entry's own

`env` block is passed to the subprocess untouched. There is no endpoint

default and no credential fallback: one server, one attempt, and a

failed connection falls back to the session connector if one exists —

otherwise it is a hard stop. Do not work around this by exporting a key

you found in some other application's config — that is how content

lands in an account the user never chose.

- **If neither is available** (no session tools AND no configured server),

`--check-auth` prints the `claude mcp add` commands for both the hosted

and the local option. Offer to run one of them, or offer to keep the

extracted scope files local. Never guess an endpoint.

- **Provenance** — each uploaded scope records `endpoint`, `transport`,

`account`, and `verified` (the date the graph was successfully read back)

in the manifest. When a graph query fails, compare the manifest's

`endpoint`/`account` against the session's own server before assuming the

graph is missing: the same `graphName` means different graphs on different

servers and accounts.

## Quick orientation (details live in the server's tool schemas)

- Structural overview of a text/URL/graph: `generate_knowledge_graph`,

`generate_topical_clusters`; persist with `create_knowledge_graph`

(uploads to the same `graphName` append statements); remove statements

from a saved graph with `delete_statements` (by category, exact text,

query, date, ids, or all — `confirm: false` is a dry run that lists the

matches; the repo/vault update flow uses it to replace changed files in

place); edit statements IN PLACE (id, date, order kept) with

`update_statements` — `edits: [{match, content}]` to correct individual

lines (a digest principle, a memory item), or one selector plus `set`

(add/remove categories, timestamp) / `replace: {pattern, with}` to

relabel a source or rename a `[[concept]]` across a graph; same dry

run → `confirm: true` contract.

- What's missing / ideation: `generate_content_gaps` →

`generate_research_questions` / `generate_research_ideas`;

`develop_text_tool` for the combined pipeline.

- Retrieval: `retrieve_from_knowledge_base` (GraphRAG over a saved graph),

`analyze_existing_graph_by_name` (structure of a saved graph),

`generate_contextual_hint` (lightweight structural overview — good

context injection before answering broad questions),

`generate_responses_from_graph` (prompt-based answers and expert

advice generated from a saved graph — good for advice/recommendation

questions the graph should answer in its own voice),

`list_graphs` / `search` / `fetch` for discovery.

- Reasoning check: `optimize_reasoning` on a draft synthesis — diagnoses

biased/focused/diversified/dispersed and suggests which topics or gaps

to develop further.

- Comparison: `overlap_between_texts`, `difference_between_texts`,

`merged_graph_from_texts` (each takes a `contexts` array).

- SEO/GEO: `generate_seo_report` (90s+ timeout) or the individual

`analyze_google_search_results` / `analyze_related_search_queries` /

`search_queries_vs_search_results` tools.

- Diversity stats in responses: `biased` → too concentrated, `focused` →

somewhat concentrated, `diversified` → balanced, `dispersed` → scattered.

## Repo / Vault Graphs (invoked inside a project folder)

When asked to graph, analyze, or ask questions about a repo, project, or

Obsidian vault, follow [references/repo-graph.md](references/repo-graph.md)

— it is the single authoritative runbook. In short:

1. `infranodus/manifest.json` exists + the request is a question → route

via the manifest (each graph records its `purpose` and `topics`) and

query the graphs; do NOT re-extract. The content lives only in the

graphs — there are no local content files.

Manifest exists + build/update intent (or bare `/infranodus`) → run

`python3 scripts/repo2statements.py . --detect` first and lead the

AskUserQuestion with "Update changed scopes (<its summary>)", then

"Rebuild a scope in place", "Add a new scope", "Full rebuild". Update =

`repo2statements.py . --update [--scope X]` → `upload_scopes.py .`

(the uploader deletes the changed files' old statements by category

with `delete_statements`, then appends the delta to the same graph;

files that only moved — same content, new path — are relabelled in

place with `update_statements`, nothing re-extracted); rebuild =

re-extract → `upload_scopes.py . --force` (clears the graph first,

same name). No changes → offer query mode. Correcting a few lines of

the authored digest = edit the file + `update_statements` edits, not a

rebuild (repo-graph.md, Digest step 4).

2. On a bare launch with no manifest (no target named), inventory the folder, then

AskUserQuestion what to build: full graph (recommended) / a specific

folder / docs containing certain terms / one document (see the runbook

for the follow-up questions). Skip that question when the user already

named the target. Then ALWAYS ask the build mode (multi-select): **full

ingestion** (all prose scopes, no LLM), **structure map** (deterministic:

tree, imports, exports, docstring headlines in a repo, page links in a

vault — cheap, no LLM), **digest + structural feedback** (YOU read the

target and write simple statements on how it works — principles, rules,

procedures, hand-offs — then `optimize_knowledge_base` on the uploaded

graph: what dominates, what is under-developed, which clusters never

connect), and/or

**ontology** (the server distils entities and typed relations from the

structure or docs graph into `onto-<project>` — how the parts fit together;

costs server LLM tokens). The digest is for reviewing and improving the

project; ontology is for navigating it. Ontology needs a structure or docs

upload to exist first; the digest needs nothing.

3. Build: `python3 scripts/repo2statements.py .` (full), `... --structure`,

and/or `... --digest` (prints the reading list and the format, exit

code 2 = "now write the file", not an error; write the file it names;

run it again with the same flags to register) — one flag per run →

`python3 scripts/upload_scopes.py .`

(upload, run in background — records routing metadata into the

manifest, appends a dated section to the append-only

`INFRANODUS_REPORT.md` log, deletes the intermediate scope files; add

`--ontology` for the ontology layer, or call `generate_ontology_graph`

with `sourceGraphName` yourself on Path A) →

## Companion skills

Sibling skills from the same family that compose with this one. Invoke

via the Skill tool ONLY when the skill appears in the available-skills

listing (match by name/description — never assume an install path; names

can vary slightly by install). If one is absent, mention it can be

installed from https://github.com/infranodus/skills and continue.

Knowledge-base workflows:

- **llm-wiki** — builds and maintains an LLM-authored knowledge base

(summarized wiki pages, curated ontologies) from raw sources. Route

there when the corpus needs authored content — scanned PDFs, "second

brain" / research-wiki requests, anything meant to compound over time.

This skill maps what exists; llm-wiki writes new knowledge on top. Its

curated scopes share the same `infranodus/` manifest and their `wiki-*`

graphs are equally queryable (see the runbook's policy rules).

- **project-learnings** — what agents *learned operating in* a project

(traps, conventions, where things live, decisions), saved to an opt-in

`learn-<project>` graph via the server's `get_project_learnings` /

`add_project_learnings` tools. This skill maps what a repo contains; that

one records what working in it taught the agent. Same entity names, so

the graphs compose (`difference_between_texts` between them shows modules

with code but no learnings). Route there at the start/end of substantive

tasks and on "save what you learned" — never enable it unasked.

- **ontology-generator** — LLM-generated `[[wikilinks]]` ontology with

`[relationCode]` tags from a topic or text. Offer it when the user

wants semantic relations (X causes Y) rather than this skill's

deterministic co-occurrence mining; output pastes straight into

InfraNodus.

- **seo-analysis** — full SEO research workflow (keyword research, search

intent, informational supply vs demand) on the same MCP tools. Prefer

it when the request is an SEO project rather than a one-off report

(a single `generate_seo_report` call needs no extra skill).

Thinking and analysis lenses — offer these when a graph diagnosis

suggests them, or on the user's own cues:

- **shifting-perspective** — diagnoses a discourse's structural diversity

(`optimize_text_structure`) and develops under-represented viewpoints.

Offer when a graph comes back biased/focused or the user is stuck in

one frame ("what am I missing?").

- **cognitive-variability** — guides shifts between zoom levels and

connect/explore modes to break rigid or looping thinking; the natural

follow-up to a shifting-perspective structural diagnosis.

- **critical-perspective** — questions assumptions and hunts blind spots

through curiosity-driven challenge. Offer when a synthesis needs to be

challenged rather than expanded.

- **rhetorical-analyst** — analyzes arguments and debate tactics across

persuasion, rhetoric, and logic; it opens with this skill's graph

tools. Offer for debates, speeches, comment threads, "why is this

persuasive?".

- **perspective-reversal** — flips a conflict or negotiation to the

opponent's viewpoint for tactical advice. Offer when the analyzed

discourse is adversarial (dispute, standoff, negotiation).

- **embodied-navigation** — applies embodied movement principles

(equanimous scanning, adaptive fluidity, tensegrity) to situations

mapped as networks. Offer for stuckness, rigidity, or conflict framed

as dynamics rather than argument.

- **vipassana-meditation** — equanimous, non-reactive observation that

breaks fixation loops. Offer when the conversation shows craving for a

particular outcome or aversion to an uncomfortable finding, and bare

attention should precede analysis.