{"id":95625,"plugin_id":"plugin_asdk_app_6ae63868f408819192babc43cdbcefdd","kind":"skill","collection_source":"plugin_package","comparison_source":null,"observed_at":"2026-11-13T18:12:33.249Z","digest":"ca88884eb48739a62f3142a967079ee1a6dc44366c94e50801212ee7287cf9ad","against":null,"payload":{"description":"Text network analysis and knowledge graphs via the InfraNodus MCP server: text structure, content gaps, research questions and ideas, text comparison, SEO/GEO and Google search analysis, GraphRAG retrieval, structured memory. Accepts text, URLs (incl. YouTube), and saved graphs. Analyzes and optimizes an AI assistant's memories (memory files and external memory stores): optimizes their structure with optimize_knowledge_base and finds gaps to bridge them and enhance the memories. Also graphs code repos and Obsidian vaults: in a project folder (\"graph this repo\", \"analyze this vault\") it mines docs, PDF text, docstrings, WHY/NOTE comments, and commit/PR/issue history into saved graphs with a report, and keeps them current as files change. 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.","included_files":[{"relative_path":"references/repo-graph.md","size_in_bytes":36841},{"relative_path":"scripts/repo2statements.py","size_in_bytes":71821},{"relative_path":"scripts/upload_scopes.py","size_in_bytes":76462}],"name":"infranodus","skill_md_contents":"---\nname: infranodus\ndescription: >-\n  Text network analysis and knowledge graphs via the InfraNodus MCP server:\n  text structure, content gaps, research questions and ideas, text comparison,\n  SEO/GEO and Google search analysis, GraphRAG retrieval, structured memory.\n  Accepts text, URLs (incl. YouTube), and saved graphs. Analyzes and optimizes\n  an AI assistant's memories (memory files and external memory stores):\n  optimizes their structure with optimize_knowledge_base and finds gaps to\n  bridge them and enhance the memories. Also graphs code repos and Obsidian\n  vaults: in a project folder (\"graph this repo\", \"analyze this vault\") it\n  mines docs, PDF text, docstrings, WHY/NOTE comments, and commit/PR/issue\n  history into saved graphs with a report, and keeps them current as files\n  change. When infranodus/manifest.json exists in the project root, answer\n  questions about themes, decisions, rationale, or gaps by querying the\n  existing graphs FIRST, before reading files.\nmetadata:\n  homepage: https://infranodus.com\n  openclaw:\n    emoji: \"🕸️\"\n    requires:\n      env: [\"INFRANODUS_API_KEY\"]\n    primaryEnv: INFRANODUS_API_KEY\n---\n\n# InfraNodus\n\nText network analysis and knowledge graph tools via the InfraNodus MCP server.\n\n## How this skill talks to InfraNodus\n\n- **Queries and analysis** — use the native MCP tools in the session\n  (any InfraNodus prefix: `mcp__infranodus__<tool>`, a plugin's\n  `mcp__plugin_<plugin>_infranodus__<tool>`, the claude.ai connector's\n  `mcp__claude_ai_InfraNodus__<tool>`, or the plain tool name in ChatGPT\n  and Codex).\n  The server's own instructions and tool schemas are the authoritative\n  reference for every tool's parameters and workflow patterns — do not\n  duplicate or second-guess them here.\n- **Not signed in** — if the InfraNodus server is installed but not signed\n  in (its tools are missing or return an authentication error), tell the\n  user to sign in: in Claude Code, run `/mcp`, select InfraNodus and sign\n  in; in ChatGPT or Codex, reconnect the InfraNodus plugin in its\n  settings. Then continue.\n- **Bulk uploads (repo/vault graphs) — session server FIRST.** Prefer the\n  InfraNodus MCP server already connected to this session (e.g. the\n  claude.ai InfraNodus connector): the agent performs the upload itself\n  with that server's `create_knowledge_graph` tool, chunk by chunk,\n  following the upload contract in\n  [references/repo-graph.md](references/repo-graph.md) Step 3 (one\n  `graphName` per scope, heading-aware chunks, `maxNodes: 500`, the\n  scope's declared `wikilinksMode`, paced calls, 429 backoff, 413\n  bisection, and the same manifest + report bookkeeping the script does).\n- **Fallback — the bundled script.** Only when the session has NO\n  InfraNodus MCP tools connected, use `scripts/upload_scopes.py`, which\n  uploads through the MCP server configured in this agent's own config —\n  `<project>/.mcp.json`, then `~/.claude.json` (this project's section,\n  then global), then `~/.claude/settings.json` — with project scope\n  winning. An `http` entry is reached at its own `url`; a `stdio` entry\n  (a local or self-hosted server) is launched as its own subprocess.\n  Preflight: `upload_scopes.py [project_dir] --check-auth`. The script\n  can never reach a cloud OAuth connector — that token lives remotely —\n  which is exactly why the connector path above is agent-driven.\n- **Credentials (script path only) are never read from config files.**\n  For an `http` server the key comes from `INFRANODUS_API_KEY` in the\n  environment and nowhere else, and is only sent to `infranodus.com` or\n  a loopback address (any other host is refused); for a `stdio` server\n  the entry's own `env` block is passed to the subprocess untouched.\n  There is no endpoint default and no credential fallback: one server,\n  one attempt, and a failed connection falls back to the session\n  connector if one exists —\n  otherwise it is a hard stop. Do not work around this by exporting a key\n  you found in some other application's config — that is how content\n  lands in an account the user never chose.\n- **If neither is available** (no session tools AND no configured server),\n  `--check-auth` prints the `claude mcp add` commands for both the hosted\n  and the local option. Offer to run one of them, or offer to keep the\n  extracted scope files local. Never guess an endpoint.\n- **Provenance** — each uploaded scope records `endpoint`, `transport`,\n  `account`, and `verified` (the date the graph was successfully read back)\n  in the manifest. When a graph query fails, compare the manifest's\n  `endpoint`/`account` against the session's own server before assuming the\n  graph is missing: the same `graphName` means different graphs on different\n  servers and accounts.\n\n## Quick orientation (details live in the server's tool schemas)\n\n- Structural overview of a text/URL/graph: `generate_knowledge_graph`,\n  `generate_topical_clusters`; persist with `create_knowledge_graph`\n  (uploads to the same `graphName` append statements); remove statements\n  from a saved graph with `delete_statements` (by category, exact text,\n  query, date, ids, or all — `confirm: false` is a dry run that lists the\n  matches; the repo/vault update flow uses it to replace changed files in\n  place); edit statements IN PLACE (id, date, order kept) with\n  `update_statements` — `edits: [{match, content}]` to correct individual\n  lines (a digest principle, a memory item), or one selector plus `set`\n  (add/remove categories, timestamp) / `replace: {pattern, with}` to\n  relabel a source or rename a `[[concept]]` across a graph; same dry\n  run → `confirm: true` contract.\n- What's missing / ideation: `generate_content_gaps` →\n  `generate_research_questions` / `generate_research_ideas`;\n  `develop_text_tool` for the combined pipeline.\n- Retrieval: `retrieve_from_knowledge_base` (GraphRAG over a saved graph),\n  `analyze_existing_graph_by_name` (structure of a saved graph),\n  `generate_contextual_hint` (lightweight structural overview — good\n  context injection before answering broad questions),\n  `generate_responses_from_graph` (prompt-based answers and expert\n  advice generated from a saved graph — good for advice/recommendation\n  questions the graph should answer in its own voice),\n  `list_graphs` / `search` / `fetch` for discovery.\n- Reasoning check: `optimize_reasoning` on a draft synthesis — diagnoses\n  biased/focused/diversified/dispersed and suggests which topics or gaps\n  to develop further.\n- Comparison: `overlap_between_texts`, `difference_between_texts`,\n  `merged_graph_from_texts` (each takes a `contexts` array).\n- SEO/GEO: `generate_seo_report` (90s+ timeout) or the individual\n  `analyze_google_search_results` / `analyze_related_search_queries` /\n  `search_queries_vs_search_results` tools.\n- Diversity stats in responses: `biased` → too concentrated, `focused` →\n  somewhat concentrated, `diversified` → balanced, `dispersed` → scattered.\n\n## Analyze and optimize memories\n\nWhen the user asks to analyze, audit, clean up, or improve an LLM's memory\n— Claude's (`CLAUDE.md` files, the auto-memory folder\n`~/.claude/projects/<project>/memory/`), Codex's (`AGENTS.md` and its\nmemory files), or an external provider's (mem0, claude-mem, read through\nthat provider's own MCP search/list tools) — treat the memories as a small\nknowledge base:\n\n1. **Collect** the memories the user points at. Pass them as `statements`\n   (one memory item per statement), with `categories` set to the source\n   (file, provider, or memory type) and `timestamps` when the store has\n   dates. Do not send secrets or anything the user excludes.\n2. **Optimize structure** with `optimize_knowledge_base` (`focus:\n   \"general\"`): what dominates, what is under-developed, which clusters\n   never connect, and contradictions or duplicates worth merging. It\n   analyzes without saving; pass `saveAs` only if the user wants the\n   memory graph kept (e.g. `memory-<project>`), which also allows\n   `compareWith` against a repo or vault graph.\n3. **Find gaps to bridge** with `generate_content_gaps` (and\n   `develop_conceptual_bridges` for links to the wider context): each gap\n   is a missing connection between two groups of memories.\n4. **Enhance the memories**: propose concrete edits — merge duplicates,\n   fix contradictions, add a memory that bridges a gap, split overloaded\n   ones — and show them to the user. Write changes back to the original\n   store (the memory files, or the provider's own add/update tools) only\n   after the user agrees.\n\n## Repo / Vault Graphs (invoked inside a project folder)\n\nWhen asked to graph, analyze, or ask questions about a repo, project, or\nObsidian vault, follow [references/repo-graph.md](references/repo-graph.md)\n— it is the single authoritative runbook. In short:\n\n1. `infranodus/manifest.json` exists + the request is a question → route\n   via the manifest (each graph records its `purpose` and `topics`) and\n   query the graphs; do NOT re-extract. The content lives only in the\n   graphs — there are no local content files.\n   Manifest exists + build/update intent (or bare `/infranodus`) → run\n   `python3 scripts/repo2statements.py . --detect` first and lead the\n   AskUserQuestion with \"Update changed scopes (<its summary>)\", then\n   \"Rebuild a scope in place\", \"Add a new scope\", \"Full rebuild\". Update =\n   `repo2statements.py . --update [--scope X]` → `upload_scopes.py .`\n   (the uploader deletes the changed files' old statements by category\n   with `delete_statements`, then appends the delta to the same graph;\n   files that only moved — same content, new path — are relabelled in\n   place with `update_statements`, nothing re-extracted); rebuild =\n   re-extract → `upload_scopes.py . --force` (clears the graph first,\n   same name). No changes → offer query mode. Correcting a few lines of\n   the authored digest = edit the file + `update_statements` edits, not a\n   rebuild (repo-graph.md, Digest step 4).\n2. On a bare launch with no manifest (no target named), inventory the folder, then\n   AskUserQuestion what to build: full graph (recommended) / a specific\n   folder / docs containing certain terms / one document (see the runbook\n   for the follow-up questions). Skip that question when the user already\n   named the target. Then ALWAYS ask the build mode (multi-select): **full\n   ingestion** (all prose scopes, no LLM), **structure map** (deterministic:\n   tree, imports, exports, docstring headlines in a repo, page links in a\n   vault — cheap, no LLM), **digest + structural feedback** (YOU read the\n   target and write simple statements on how it works — principles, rules,\n   procedures, hand-offs — then `optimize_knowledge_base` on the uploaded\n   graph: what dominates, what is under-developed, which clusters never\n   connect), and/or\n   **ontology** (the server distils entities and typed relations from the\n   structure or docs graph into `onto-<project>` — how the parts fit together;\n   costs server LLM tokens). The digest is for reviewing and improving the\n   project; ontology is for navigating it. Ontology needs a structure or docs\n   upload to exist first; the digest needs nothing.\n3. Build: `python3 scripts/repo2statements.py .` (full), `... --structure`,\n   and/or `... --digest` (prints the reading list and the format, exit\n   code 2 = \"now write the file\", not an error; write the file it names;\n   run it again with the same flags to register) — one flag per run →\n   `python3 scripts/upload_scopes.py .`\n   (upload, run in background — records routing metadata into the\n   manifest, appends a dated section to the append-only\n   `INFRANODUS_REPORT.md` log, deletes the intermediate scope files; add\n   `--ontology` for the ontology layer, or call `generate_ontology_graph`\n   with `sourceGraphName` yourself on Path A) →\n   `upload_scopes.py . --register-project` (once). The register step asks\n   ONE AskUserQuestion (spec in the runbook's Step 4; skip it when\n   CLAUDE.md already has the `infranodus-memory` marker block): routing\n   rules only, or also the end-of-session insight-memory convention\n   (`--register-project --with-memory`) — a second marker block that has\n   every substantive session distill the USER's insights and save them,\n   on their approval, to a `<slug>-insights` memory graph via\n   `memory_add_relations` (recall: `memory_get_relations`). Never install\n   it unasked. Insights are the user's realizations — keep them apart\n   from project-learnings (agent operations) and from the content graphs\n   (what the files say).\n\n## Companion skills\n\nSibling skills from the same family that compose with this one. Invoke\nvia the Skill tool ONLY when the skill appears in the available-skills\nlisting (match by name/description — never assume an install path; names\ncan vary slightly by install). If one is absent, mention it can be\ninstalled from https://github.com/infranodus/skills and continue.\n\nKnowledge-base workflows:\n\n- **llm-wiki** — builds and maintains an LLM-authored knowledge base\n  (summarized wiki pages, curated ontologies) from raw sources. Route\n  there when the corpus needs authored content — scanned PDFs, \"second\n  brain\" / research-wiki requests, anything meant to compound over time.\n  This skill maps what exists; llm-wiki writes new knowledge on top. Its\n  curated scopes share the same `infranodus/` manifest and their `wiki-*`\n  graphs are equally queryable (see the runbook's policy rules).\n- **project-learnings** — what agents *learned operating in* a project\n  (traps, conventions, where things live, decisions), saved to an opt-in\n  `learn-<project>` graph via the server's `get_project_learnings` /\n  `add_project_learnings` tools. This skill maps what a repo contains; that\n  one records what working in it taught the agent. Same entity names, so\n  the graphs compose (`difference_between_texts` between them shows modules\n  with code but no learnings). Route there at the start/end of substantive\n  tasks and on \"save what you learned\" — never enable it unasked.\n- **ontology-generator** — LLM-generated `[[wikilinks]]` ontology with\n  `[relationCode]` tags from a topic or text. Offer it when the user\n  wants semantic relations (X causes Y) rather than this skill's\n  deterministic co-occurrence mining; output pastes straight into\n  InfraNodus.\n- **seo-analysis** — full SEO research workflow (keyword research, search\n  intent, informational supply vs demand) on the same MCP tools. Prefer\n  it when the request is an SEO project rather than a one-off report\n  (a single `generate_seo_report` call needs no extra skill).\n\nThinking and analysis lenses — offer these when a graph diagnosis\nsuggests them, or on the user's own cues:\n\n- **shifting-perspective** — diagnoses a discourse's structural diversity\n  (`optimize_text_structure`) and develops under-represented viewpoints.\n  Offer when a graph comes back biased/focused or the user is stuck in\n  one frame (\"what am I missing?\").\n- **cognitive-variability** — guides shifts between zoom levels and\n  connect/explore modes to break rigid or looping thinking; the natural\n  follow-up to a shifting-perspective structural diagnosis.\n- **critical-perspective** — questions assumptions and hunts blind spots\n  through curiosity-driven challenge. Offer when a synthesis needs to be\n  challenged rather than expanded.\n- **rhetorical-analyst** — analyzes arguments and debate tactics across\n  persuasion, rhetoric, and logic; it opens with this skill's graph\n  tools. Offer for debates, speeches, comment threads, \"why is this\n  persuasive?\".\n- **perspective-reversal** — flips a conflict or negotiation to the\n  opponent's viewpoint for tactical advice. Offer when the analyzed\n  discourse is adversarial (dispute, standoff, negotiation).\n- **embodied-navigation** — applies embodied movement principles\n  (equanimous scanning, adaptive fluidity, tensegrity) to situations\n  mapped as networks. Offer for stuckness, rigidity, or conflict framed\n  as dynamics rather than argument.\n- **vipassana-meditation** — equanimous, non-reactive observation that\n  breaks fixation loops. Offer when the conversation shows craving for a\n  particular outcome or aversion to an uncomfortable finding, and bare\n  attention should precede analysis.\n"},"changes":[],"summary":"First saved snapshot. No earlier version is available for comparison.","summary_kind":"deterministic","summary_metadata":{}}