infranodus

InfraNodus

通过 InfraNodus MCP 服务进行文本网络分析和知识图谱工具。

此技能如何与 InfraNodus 交互

• 查询和分析 — 在会话中使用原生 MCP 工具 （mcp__infranodus__<tool>，或 InfraNodus 连接器的等效工具）。 服务自身的说明和工具架构是每个工具的参数与工作流模式的权威参考——请勿在此重复或自行推断。
• 批量上传（仓库／知识库图谱）——优先使用会话服务。 优先使用已连接到此会话的 InfraNodus MCP 服务（例如 claude.ai InfraNodus 连接器）：Agent 使用该服务的 create_knowledge_graph 工具自行逐块上传，并遵循 references/repo-graph.md 第 3 步中的上传约定（每个范围使用一个 graphName、根据标题划分区块、maxNodes: 500、该范围声明的 wikilinksMode、控制调用频率、遇到 429 时退避、遇到 413 时二分拆分，以及与脚本相同的清单和报告记录）。
• 备用方案——随附脚本。 仅当此会话未连接任何 InfraNodus MCP 工具时，才使用 scripts/upload_scopes.py。该脚本通过此 Agent 自身配置中设置的 MCP 服务上传——依次检查 <project>/.mcp.json，然后是 ~/.claude.json（先检查此项目对应的部分，再检查全局设置），最后是 ~/.claude/settings.json——项目范围的设置优先。http 条目通过其自身的 url 访问；stdio 条目（本地或可自托管的服务）则作为独立子进程启动。预检命令：upload_scopes.py [project_dir] --check-auth。脚本无法访问云端 OAuth 连接器——其令牌存储在远程端——这正是上述连接器路径由 Agent 驱动的原因。
• 凭据（仅限脚本路径）绝不会从配置文件读取。 对于 http 服务，密钥仅从环境变量 INFRANODUS_API_KEY 中读取；对于 stdio 服务，条目自身的 env 区块会原样传递给子进程。没有默认端点，也没有凭据回退：只尝试一个服务、连接一次；连接失败时，若存在会话连接器，则回退到该连接器——否则立即停止。不要通过导出在其他应用配置中找到的密钥来绕过这一机制——否则内容可能会进入用户从未选择的账户。
• 两者都不可用时（没有会话工具，也没有已配置的服务），--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}] 修正单独的行（例如摘要原则、 记忆条目）；或使用一个选择器加 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 → 分散。

仓库 / 知识库图谱（在项目文件夹内调用）

当用户要求绘制图谱、分析仓库、项目或 Obsidian 知识库，或询问相关问题时，请遵循 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，摘要步骤 4）。
2. 在没有清单的情况下直接启动（未指定目标），请先盘点文件夹，然后通过 AskUserQuestion 询问要构建什么：完整图谱（推荐）/ 特定文件夹 / 包含特定词语的文档 / 单个文档（后续问题见操作手册）。用户已指定目标时跳过此问题。然后始终询问构建模式（多选）：完整摄取（所有散文范围，不使用 LLM）、结构映射（确定性：仓库中的目录树、导入、导出、文档字符串标题；知识库中的页面链接——成本低，不使用 LLM）、摘要 + 结构反馈（由你阅读目标，并撰写关于其工作方式的简明陈述——原则、规则、流程、交接；然后对上传的图谱运行 optimize_knowledge_base：哪些内容占主导、哪些内容发展不足、哪些簇彼此从未连接），和 / 或 本体（服务端从结构或文档图谱中提炼实体和带类型的关系，生成 onto-<project>——说明各部分如何组合；会消耗服务端 LLM 令牌）。摘要用于审查和改进项目；本体用于浏览项目。本体要求先存在结构或文档上传；摘要则无此要求。
3. 构建：python3 scripts/repo2statements.py .（完整）、... --structure，和 / 或 ... --digest（打印阅读清单和格式，退出代码 2 表示“现在撰写文件”，不是错误；请撰写其指定的文件；然后用相同标志再次运行以完成注册）——每次运行使用一个标志 → python3 scripts/upload_scopes.py . （上传，在后台运行——将路由元数据记录到清单中，将带日期的部分追加到只追加的 INFRANODUS_REPORT.md 日志中，并删除中间范围文件；为本体层添加 --ontology，或在路径 A 上自行使用 sourceGraphName 调用 generate_ontology_graph）→ upload_scopes.py . --register-project（执行一次）。注册步骤会提出一个 AskUserQuestion（具体要求见操作手册步骤 4；如果 CLAUDE.md 中已有 infranodus-memory 标记区块，则跳过）：仅设置路由规则，还是也启用会话结束时的洞见记忆约定（--register-project --with-memory）——第二个标记区块要求每个实质性会话都提炼用户的洞见，并在用户批准后，通过 memory_add_relations 将其保存到 <slug>-insights 记忆图谱中（回忆时使用 memory_get_relations）。切勿未经询问就安装。洞见是用户的领悟——请将其与项目经验（Agent 的操作经验）以及内容图谱（文件所述内容）分开。

配套技能

同一家族中可与此技能组合使用的同系技能。仅当技能出现在可用技能列表中时，才通过 Skill 工具调用（根据名称／描述匹配，绝不要假定安装路径；不同安装方式的名称可能略有差异）。如果某项技能不存在，请说明可从 https://github.com/infranodus/skills 安装，然后继续。

知识库工作流：

• llm-wiki — 根据原始来源构建并维护由大模型撰写的知识库（摘要维基页面、精选本体）。当语料需要创作内容时，转交给它处理——例如扫描版 PDF、“第二大脑”／研究维基请求，以及任何旨在长期积累的内容。此技能用于映射现有内容；llm-wiki 则在此基础上编写新知识。其精选范围共用同一个 infranodus/ 清单，且其 wiki-* 图谱同样可查询（参见运行手册中的策略规则）。
• project-learnings — Agent 在项目中实际操作时学到的内容（陷阱、惯例、内容所在位置、决策），通过服务端的 get_project_learnings／add_project_learnings 工具保存到可选启用的 learn-<project> 图谱中。此技能用于映射仓库包含的内容；而该技能记录的是 Agent 在项目中工作时学到的内容。实体名称相同，因此这些图谱可以组合使用（在两者之间调用 difference_between_texts，即可显示有代码但没有经验记录的模块）。在实质性任务开始／结束时，以及用户要求“保存你学到的内容”时，转交给它处理——绝不要在用户未要求时启用。
• ontology-generator — 根据主题或文本生成由大模型创建的 [[wikilinks]] 本体，并带有 [relationCode] 标签。当用户需要语义关系（X 导致 Y），而不是此技能采用的确定性共现挖掘时，向用户推荐。输出内容可直接粘贴到 InfraNodus。
• seo-analysis — 使用相同 MCP 工具进行完整的 SEO 研究工作流（关键词研究、搜索意图、信息供给与需求）。当请求属于 SEO 项目而非一次性报告时，优先使用它（单次调用 generate_seo_report 无需额外技能）。

思考与分析视角——当图谱诊断表明适用，或用户主动提出相关线索时，推荐以下技能：

• shifting-perspective — 诊断论述的结构多样性（optimize_text_structure），并拓展代表性不足的观点。当图谱呈现偏见／聚焦过度，或用户困在单一视角中（“我遗漏了什么？”）时，推荐此技能。
• cognitive-variability — 引导用户切换缩放级别以及连接／探索模式，以打破僵化或循环思维；这是 shifting-perspective 结构诊断之后的自然后续。
• critical-perspective — 通过由好奇心驱动的质疑，审视假设并寻找盲点。当综合分析需要受到质疑而非扩展时，推荐此技能。
• rhetorical-analyst — 从说服、修辞和逻辑等角度分析论证与辩论策略；它会使用此技能的图谱工具开始分析。适用于辩论、演讲、评论串以及“为什么这有说服力？”之类的问题。
• perspective-reversal — 从对手的视角重新审视冲突或谈判，并给出策略建议。当分析的论述具有对抗性（争议、僵局、谈判）时，推荐此技能。
• embodied-navigation — 将体现式运动原则（平和扫描、灵活适应、整体协同）应用于映射为网络的情境。适用于陷入停滞、僵化，或被视为动态过程而非论证的冲突。
• vipassana-meditation — 通过平和、不带反应的观察打破固着循环。当对话表现出对特定结果的渴望，或对令人不适的发现有所排斥，且分析前应先进行纯粹觉察时，推荐此技能。