infranodus

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 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 — 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 ()", 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) → upload_scopes.py . --register-project (once). The register step asks ONE AskUserQuestion (spec in the runbook's Step 4; skip it when CLAUDE.md already has the infranodus-memory marker block): routing rules only, or also the end-of-session insight-memory convention (--register-project --with-memory) — a second marker block that has every substantive session distill the USER's insights and save them, on their approval, to a <slug>-insights memory graph via memory_add_relations (recall: memory_get_relations). Never install it unasked. Insights are the user's realizations — keep them apart from project-learnings (agent operations) and from the content graphs (what the files say).

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.