在 Kilo 编码代理中使用 /graphify 技能：把任意目录构建成可查询的知识图谱

graphify 是一套随项目分发的 Agent 技能（SKILL.md），在 Kilo、Claude Code、Cursor、Codex、Gemini CLI 等宿主上把任意目录（代码、文档、论文、图片、视频）转成可查询的持久化知识图谱，并配套 God Nodes（枢纽节点）、社区发现与 query/path/explain 工具。本篇文章完整解析该技能的命令清单、九步执行流水线与诚实审计规则，并结合当前仓库源码说明每一步背后的实现依据，让读者既能在 Kilo 会话中直接复现完整流程，也能理解图谱各阶段产物（HTML、JSON、GRAPH_REPORT.md）是如何从源码一步步构造出来的。

关联文档 tools/skillgen/expected/graphify__skill-kilo.md 是面向 Kilo 平台渲染的“期望产物”，其同源技能正文位于 graphify/skill-kilo.md，运行期加载的辅助参考文档统一放在 graphify/skills/kilo/references/ 下。从仓库结构看，tools/skillgen/ 按 tools/skillgen/platforms.toml 将同一份核心技能渲染成各平台变体（如本文件 graphify__skill-kilo.md），并生成对应的 always-on 指令片段（graphify/always_on/ 目录）。

一、graphify 是什么：一次调用，三份核心产物

技能文档开篇给出其定位：把任意一个文件目录变成可导航的知识图谱，最终交付三类核心产物：

产物	路径/形式	用途
交互式 HTML	graph.html	浏览器中拖拽浏览节点与连边
GraphRAG-ready JSON	graph.json	作为图数据源，供查询与下游 RAG 消费
纯语言报告	GRAPH_REPORT.md	面向人类的审计报告

文档同时强调它的两个核心卖点，这也正是命名“诚实审计轨迹”的由来：

• 跨会话持久：图谱写入磁盘（默认 graphify-out/），下次会话直接复用；
• 诚实审计轨迹：每一条边都带证据标签 EXTRACTED / INFERRED / AMBIGUOUS，社区发现则会暴露“你根本不会想到去问”的跨文档连接。

从源码看，图构建与分析由 graphify/build.py（build_from_json，见第 798 行附近）、graphify/cluster.py（cluster/score_all，第 223、357 行附近）与 graphify/analyze.py（god_nodes、surprising_connections、suggest_questions）实现；报告由 graphify/report.py（generate，第 96 行附近）生成；graph.json 落盘则由 graphify/export.py（to_json，第 266 行附近）负责。

二、命令总览：从全量构建到图谱查询

技能在会话中以 /graphify 为入口暴露全部能力，文档给出了完整命令清单，按用途可分为四组：

2.1 全量流水线（构建图谱）

/graphify                                             # 对当前目录跑完整流水线（默认生成 HTML；追加 --obsidian 生成 vault）
/graphify <path>                                      # 对指定路径跑完整流水线
/graphify https://github.com/<owner>/<repo>           # 先 clone 仓库再对其跑完整流水线
/graphify https://github.com/<owner>/<repo> --branch <branch>  # clone 指定分支
/graphify <url1> <url2> ...                           # clone 多个仓库，各自建图后合并为一张跨仓库图

2.2 提取/建图模式开关

/graphify <path> --mode deep                          # 深入提取，产出更丰富的 INFERRED 边
/graphify <path> --update                             # 增量更新：只重提取新增/变更文件
/graphify <path> --directed                           # 构建有向图（保留 source→target 方向）
/graphify <path> --whisper-model medium               # 使用更大的 Whisper 模型提升转写精度
/graphify <path> --cluster-only                       # 在既有图谱上重跑社区聚类
/graphify <path> --no-viz                             # 跳过可视化，只输出报告 + JSON
/graphify <path> --html                               # HTML 默认生成，此参数为 no-op（保留兼容）

2.3 导出与集成

/graphify <path> --svg                                # 额外导出 graph.svg（可嵌入 Notion、GitHub）
/graphify <path> --graphml                            # 导出 graph.graphml（用于 Gephi、yEd）
/graphify <path> --neo4j                              # 为 Neo4j 生成 graphify-out/cypher.txt
/graphify <path> --neo4j-push bolt://localhost:7687   # 直接推送到 Neo4j
/graphify <path> --falkordb                           # 为 FalkorDB 生成 cypher.txt
/graphify <path> --falkordb-push falkordb://localhost:6379   # 直接推送到 FalkorDB
/graphify <path> --mcp                                # 启动 MCP stdio server 供 Agent 访问
/graphify <path> --watch                              # 监视目录，代码变更自动重建（无需 LLM）
/graphify <path> --wiki                               # 生成 Agent 可爬取的 wiki（index.md + 每个社区一篇文章）
/graphify <path> --obsidian --obsidian-dir ~/vaults/my-project  # 把 vault 写入自定义路径（如既有库）

2.4 语料扩展与图谱问答

/graphify add <url>                                   # 抓取 URL 存到 ./raw 并更新图谱
/graphify add <url> --author "Name"                   # 标注作者
/graphify add <url> --contributor "Name"              # 标注语料贡献者
/graphify query "<question>"                          # BFS 遍历：广泛上下文
/graphify query "<question>" --dfs                    # DFS：追踪特定链路
/graphify query "<question>" --budget 1500            # 用 token 上限约束答案长度
/graphify path "AuthModule" "Database"                # 两个概念之间的最短路径
/graphify explain "SwinTransformer"                   # 对某个节点给出白话解释

这些子命令在 CLI 层都有对应实现，graphify/main.py 中给出了等价的命令行参考，例如 query 支持 --dfs、--context、--budget（默认 2000）、--graph；add 支持 --author、--contributor、--dir（默认 ./raw）；path/explain 也均支持 --graph 指定 graph.json 路径（默认 graphify-out/graph.json）。留意子命令前会先检查 graphify-out/.graphify_python 是否存在（见“解释器守卫”一节），保证后续所有步骤复用同一套已解析的 Python 解释器。

2.5 调用约定（What You Must Do When Invoked）

技能对“被调用时”定义了三条约定的入口行为：

1. /graphify --help（或 -h）且无其他参数：原样打印 ## Usage 小节后立即返回，不执行任何命令、不做文件探测、不把路径默认成 .。
2. 快路径——既有图谱优先：在执行任何操作前，先检查当前工作目录下 graphify-out/graph.json 是否存在；若存在且用户的问题是对代码库的自然语言提问（如 “X 是怎么工作的”“谁调用了 Y”“追踪 Z 的数据流”），且不是显式的重建命令（--update、--cluster-only 或裸路径/URL 暗示全新提取），则直接跳过 Step 1–5，跳转到“For /graphify query”小节执行 graphify query "<question>"——不运行 detect、不检查语料规模、不要求用户收窄范围。图谱已经建好，直接使用。
3. 路径默认值：未给路径则用 .（当前目录），不要向用户索要路径；路径以 https://github.com/ 或 http://github.com/ 开头则视为 GitHub URL，先执行 Step 0 再继续处理解析后的本地路径。

这一“快路径”设计的价值在于把图谱当作记忆层：会话之间不重建，直接对既有图问答。其可靠性由诚实审计与后续 Integrity Gate（Step 4.5）共同保障。

三、九步流水线逐段精读

Step 0 —— GitHub 仓库与多路径合并（仅 URL / 多路径时需要）

仅当入参是一个或多个 https://github.com/... URL，或多个本地子目录需要合并时执行本步，其完整 clone、跨仓库合并与 monorepo 流程见 graphify/skills/kilo/references/github-and-merge.md，完成后继续使用解析出的本地路径。普通本地路径直接跳过。

Step 1 —— 确保 graphify 已安装：解释器解析与持久化

这一步解决多安装方式下的解释器定位问题。技能给出了一段完整的 bash 探测脚本，逻辑按优先级排列：

1. uv tool 安装（现代 Mac/Linux 最可靠）：uv tool run --from graphifyy python -c "import sys; print(sys.executable)"；
2. 从 graphify 可执行文件读取 shebang（适配 pipx 与直接 pip 安装）：head -1 "$GRAPHIFY_BIN"，并校验第一行是否“像”解释器路径（用 case 字符集检查避免恶意内容）；
3. 回退 python3。

随后验证 import graphify 是否成功：失败则优先 uv tool install --upgrade graphifyy，否则 python3 -m pip install graphifyy，并兼容 PEP 668 的 --break-system-packages。最关键的是两个持久化文件：

mkdir -p graphify-out
"$PYTHON" -c "import sys; open('graphify-out/.graphify_python', 'w', encoding='utf-8').write(sys.executable)"
echo "$(cd INPUT_PATH && pwd)" > graphify-out/.graphify_root

• graphify-out/.graphify_python：记录解释器绝对路径，后续所有 bash 块都须用 $(cat graphify-out/.graphify_python) 替换 python3，保证整条流水线跨调用使用同一解释器；
• graphify-out/.graphify_root：记录扫描根目录，使后续无参数的 graphify update 知道该去哪里增量扫描。

若导入成功则不打印任何内容，直接进入 Step 2。

Step 2 —— 探测文件（Detect）与语料摘要

技能调用 graphify/detect.py 的 detect 函数（第 1665 行附近），把结果以 JSON 形式写入 graphify-out/.graphify_detect.json（刻意从 Python 侧写盘而不是 shell 重定向，是为了在 PowerShell 宿主上避免控制台编码漂移，技能注释标注为 issue #2528）。随后以简洁摘要呈现，而不是打印原始 JSON：

Corpus: X files · ~Y words
  code:     N files (.py .ts .go ...)
  docs:     N files (.md .txt ...)
  papers:   N files (.pdf ...)
  images:   N files
  video:    N files (.mp4 .mp3 ...)

类别数为 0 的行省略。随后按文档逻辑分支处理：

• total_files == 0：停止并提示 “No supported files found in [path].”；
• skipped_sensitive 非空：报告数量并列出被跳过的文件名（含跳过原因，如 “symlink target outside scan root”“not a regular file”，甚至 “Google Workspace export produced no readable text”），让误伤的文件可见、可改名或移动（issue #2106）；
• 超大语料（total_words > 2,000,000 或 total_files > 500）：读取 scan_root，把所有类型文件拼起来并剔除 scan_root + "/graphify-out/" 前缀（避免把转写边车算进去），按“第一层子目录”聚合统计 Top 5，询问用户运行哪个子目录；若全部文件都在根 (root)（无子目录），则不要求收窄，而是建议 --no-cluster 跳过昂贵的聚类步骤继续；
• 否则：若检测到视频文件进入 Step 2.5，否则直接进入 Step 3。

源码侧印证：detect 返回结构包含 total_files、total_words、skipped_sensitive 等字段（见 graphify/detect.py 第 1935–1958 行附近），阈值常量 CORPUS_WARN_THRESHOLD、CORPUS_UPPER_THRESHOLD、FILE_COUNT_UPPER 亦在此文件中定义。

Step 2.5 —— 音视频转写（仅检测到 video 时）

若 detect 返回 0 个 video 文件，整步跳过。有视频/音频时按 graphify/skills/kilo/references/transcribe.md 先转写成文本，Step 3 中把转写稿当作文档处理。命令清单中 --whisper-model medium 即用于调大 Whisper 模型以提升转写精度。

Step 3 —— 实体与关系提取：结构提取 + 语义提取双轨并行

这是流水线的核心，明确分为两部分：

• 结构化提取（structural）：对代码做确定性 AST 解析，免费、无 LLM；
• 语义提取（semantic）：只针对文档/论文/图片，消耗 token。

技能的 API Key 纪律值得单独强调：graphify 全程不需要 API Key，禁止向用户索要、也禁止因缺 Key 而阻塞。纯代码语料（最常见的 /graphify .）会完全跳过语义提取，直接进入 Part C。只有文档/论文/图片的语义提取才需要 LLM，且只读取 GEMINI_API_KEY/GOOGLE_API_KEY；两个 Key 都未设置时，打印一行提示后继续、不等待：

Tip: set GEMINI_API_KEY or GOOGLE_API_KEY to use Gemini for semantic extraction (pip install 'graphifyy[gemini]').

若两个 Key 已设置，则改用 graphify/llm.py 的 extract_corpus_parallel（第 2509 行附近，backend="gemini"）走库内并行提取，而不是派发子代理；默认模型为 gemini-3-flash-preview，可用 GRAPHIFY_GEMINI_MODEL 或 headless CLI 的 --model 覆盖。graphify 不读取 ANTHROPIC_API_KEY、OPENAI_API_KEY 等其他 provider 的 Key——技能反复强调：如果你正准备因为缺 API Key 去提示/等待/中止，那是对这份技能文档的误读，直接继续即可。

--mode deep 必须全程跟踪并在 Part B2 的每个子代理中传入 DEEP_MODE=true。

Part A —— 代码文件的结构化（AST）提取

对检测到的代码文件，读取 detect 结果中的 files.code 列表，用 collect_files 展开目录，调用 graphify/extract.py 的 extract（第 5859 行附近）执行 AST 提取并写入 graphify-out/.graphify_ast.json；无代码文件时写入一个空结构占位并提示跳过。技能明确要求 Part A 与 Part B 并行启动（同一消息内同时派发所有语义子代理并开始 AST 提取），对大型语料可节省 5–15 秒——AST 确定性快，正好在子代理处理文档/论文期间跑完。

Part B —— 语义提取：缓存、分块与并行子代理

Part B 是纯代码语料唯一会被整体跳过的部分。其“快速路径”有一个易踩的坑：必须先写一个空的 semantic 文件（内容为 {'nodes':[],'edges':[],'hyperedges':[],'input_tokens':0,'output_tokens':0}），否则 Part C 无条件读取 .graphify_semantic.json 会触发 FileNotFoundError。

非快速路径下的子流程为：

• B0 查缓存：调用 graphify/cache.py 的 check_semantic_cache（第 1233 行附近）。关键设计：语义提取只处理 document/paper/image 三类内容文件——代码已由 AST 覆盖，若把所有类别都拍平传给子代理，会导致每个源码文件被重复通读（issue #1392）。缓存条目以提取提示词（references/extraction-spec.md 的绝对路径）为“归属戳”：升级改变提示词后旧条目自动重提取，提示词不变则沿用条目（issue #1939）。命中则写 .graphify_cached.json，否则删除遗留文件防止 Part C 合并到过期缓存；未命中清单写入 .graphify_uncached.txt。
• B1 分块：未命中文件按 20–25 个一组切块，每张图片独占一块（视觉需要独立上下文）；同目录文件尽量放同块，以提高跨文件关系被提取出来的概率。
• B2 同一响应内派发全部子代理：技能以“3 块 → 3 个 Agent tool 调用放同一条消息”为例说明并行语义——逐个等待调用是串行，违背初衷。子代理类型必须为 general-purpose（Kilo 平台上即 subagent_type="general"），绝不能是只读的 Explore——只读代理无法把 chunk 文件写盘，会静默丢失提取结果。CHUNK_PATH 必须为绝对路径，形如 ${PROJECT_ROOT}/graphify-out/.graphify_chunk_0N.json。每个子代理的提示词模板见 graphify/skills/kilo/references/extraction-spec.md（JSON schema、节点 ID 规则、置信度打分标准、frontmatter、超边、视觉规则都在其中），仅在确实存在 doc/paper/image 分块时加载。
• B3 收集、缓存与合并：以“磁盘上存在 .graphify_chunk_NN.json”作为成功信号；文件缺失多半是派发了只读子代理，须打印显式警告而非静默跳过；失败/非法 JSON 的块跳过但不中止；若超过一半块失败，则停下要求用户用 general-purpose 重跑。合并所有块到 .graphify_semantic_new.json 前，要从 Agent 工具结果的 usage 字段读回真实 token 数写进 chunk JSON（chunk 内默认是占位 0）。新结果经 graphify/cache.py 的 save_semantic_cache（第 1379 行附近）入库（沿用与 B0 相同的 SPEC_PATH 归属戳），再与缓存合并、按节点 id 去重后写入 .graphify_semantic.json。

Part C —— 合并 AST + 语义为最终提取结果

以 AST 节点为基底、按 id 去重追加语义节点；边直接相加（ast['edges'] + sem['edges']），超边取自语义结果。产物写入 graphify-out/.graphify_extract.json，并打印 Merged: N nodes, M edges (A AST + B semantic)。

Step 4 —— 建图、聚类、分析与产出

调用链上聚合了多个核心模块：

• graphify/build.py build_from_json(extraction, root='INPUT_PATH', directed=IS_DIRECTED)（第 798 行附近）：IS_DIRECTED 由 --directed 决定，为真时构建保留方向 source→target 的 DiGraph，否则默认无向 Graph；
• graphify/cluster.py cluster 与 score_all（第 223、357 行附近）：社区发现与内聚度评分；
• graphify/analyze.py god_nodes / surprising_connections / suggest_questions（第 109、133、428 行附近）：枢纽节点、跨社区意外连接、建议问题；
• graphify/report.py generate（第 96 行附近）：报告文本；
• graphify/export.py to_json（第 266 行附近）：写 graph.json。

技能在此处施加了两道关键护栏：

1. 空图护栏：build_from_json 后若 G.number_of_nodes() == 0，立即报错并 SystemExit(1)，绝不用空提取覆盖已有的好图（issue #1392）；
2. #479 缩容护栏（shrink-guard）：to_json 在新图节点数小于既有 graph.json 时返回 False 且不写任何内容；只有真正写盘成功才继续写 GRAPH_REPORT.md 与 .graphify_analysis.json，避免报告描述的图与磁盘上的图不一致。若用户确实删了文件而缩容是有意的，需带 --force 重跑全量构建。

同时 root= 参数与 --update 运行书对齐（issue #1361）：把 source_file 相对到同一基准，保证全量构建与增量 --update 在重提取时永不漂移。社区标签先用占位符 Community N，真实标签在 Step 5 生成后再重算建议问题（标签会影响问题措辞）。

Step 4.5 —— 图谱健康检查（只读完整性门禁）

这是对提取结果做的一次非破坏性诊断，在任何标签化之前运行，用于暴露“增量更新与 AST/LLM id 失配”造成的静默损坏模式——边坍缩、悬空/缺失端点与自环。调用 graphify/diagnostics.py 的 diagnose_extraction 与 format_diagnostic_report（第 156、348 行附近），逐项统计：

• dangling_endpoint_edges：悬空端点边；
• missing_endpoint_edges：缺失端点边；
• self_loop_edges：自环边；
• directed_same_endpoint_collapsed_edges / undirected_same_endpoint_collapsed_edges：有向/无向同端点坍缩边。

有任一计数即打印 GRAPH HEALTH WARNING（图谱仍可用，但完整性问题必须可见，且要在最终摘要中浮出，遵守诚实规则）；全部为零则打印 Graph health: OK。只读、永不中止。

Step 5 —— 给社区命名并重生成报告

读取 graphify-out/.graphify_analysis.json，为每个社区写一个 2–5 词的白话名称（如 “Attention Mechanism”“Training Pipeline”“Data Loading”），构造形如 {0: "Attention Mechanism", 1: "Training Pipeline"} 的 LABELS_DICT 替换占位符。随后重建图、重算基于真实标签的建议问题、重新生成 GRAPH_REPORT.md、写 .graphify_labels.json，并再次 to_json 以便 graph.json 的节点携带策展后的 community_name（issue #2490）。此步同样受 #479 缩容护栏约束：若拒绝写盘，浮出护栏信息，不可强行越过。

Step 6 —— Obsidian vault（可选）+ HTML（默认）

• HTML 始终生成（除非 --no-viz）；graphify export html 在节点超 5000 时自动聚合为社区视图；
• Obsidian 仅在显式传 --obsidian 时生成（每个节点一个文件，成本高）；--obsidian-dir <path> 会以 --dir 透传，否则默认 graphify-out/obsidian。

Steps 6b–8 —— 仅按需执行的可选导出

只有对应 flag 出现才运行：--wiki、--neo4j/--neo4j-push、--falkordb/--falkordb-push、--svg、--graphml、--mcp；另外当 total_words 超过 5000 时会跑 token 削减基准测试。无导出 flag 的默认运行会全部跳过。各项细节见 graphify/skills/kilo/references/exports.md。--wiki 导出须在 Step 9 清理前执行，以保留 .graphify_labels.json。

Step 9 —— 清单、成本跟踪、清理与汇报

本步做三件事：

1. 保存 manifest（供 --update 使用）：核心逻辑调用 graphify/detect.py 的 save_manifest（第 2112 行附近）与 graphify/cli.py 的 _stamped_manifest_files（第 88 行附近）。这里有一组相当精细的“只给真正产出的语义文件盖章”规则：若某检测到的文件因 chunk 失败被遗漏，必须保持未盖章状态，否则它会被标记为完成、内容永久丢失（issue #2015）；代码文件因 AST 确定性总是盖章，只有 document/paper/image 语义类型按是否产出收口（clear_semantic 清掉陈旧 semantic_hash，issue #1948）；scan_corpus 使用原始全量语料而非盖章子集，保证本次运行后被排除的 in-root 文件被正确丢弃而非冒充删除，未触碰文件的旧行保留（issue #1908）。root= 把 manifest 键相对化到扫描根，让磁盘上的 manifest 跨 clone/跨机器可移植（issue #1417）。
2. 累计成本跟踪：读写 graphify-out/cost.json，累计 total_input_tokens/total_output_tokens 与逐次运行记录（UTC 时间戳 + token + 文件数），最后打印本次与历史合计。
3. 清理临时产物并汇报：删除 .graphify_detect/extract/ast/semantic/analysis.json 及 .graphify_chunk_*.json、.needs_update 等中间文件，然后向用户输出产物清单。

汇报阶段技能还定义了明确的“会话引导”行为：只粘贴 GRAPH_REPORT.md 的 God Nodes、Surprising Connections、Suggested Questions 三节（不全量贴报告），随即挑一个跨越最多社区边界/桥接节点最出人意料的问题询问用户是否追踪，回答基于图结构讲解节点连接与社区跨越，且每个回答都以自然追问结尾——“The graph is the map. Your job after the pipeline is to be the guide.”

四、解释器守卫与增量子命令

4.1 解释器守卫

在运行任何子命令（--update、--cluster-only、query、path、explain、add）之前，先检查 .graphify_python 是否存在；若缺失（例如用户删除了 graphify-out/），技能给出了一段守卫脚本重新解析解释器：优先从 graphify 可执行文件读取 shebang，否则回退 python3，并重建 graphify-out/.graphify_python。这让所有后续子命令都能在“干净环境”下自愈。

4.2 --update 与 --cluster-only

两者都非默认子命令。--update 只重提取新增/变更文件（省 token 省时间），--cluster-only 在既有图上重跑聚类。完整流程见 graphify/skills/kilo/references/update.md，其中增量探测调用 detect_incremental，会把“变更子集”放入 files、把“全量语料”放入 all_files，供下游 Step 3A/3B0 只针对变更内容做 AST 与缓存检查；若变更全部是代码文件则连语义部分都可以整体跳过。底层 detect_incremental 与相关增量逻辑集中在 graphify/detect.py，语义去重/超边机制可参考 graphify/dedup.py。

五、图谱问答：query / path / explain 的玩法与约束

当 graphify-out/graph.json 已存在而用户提出关于语料的问题时，直接运行：

graphify query "<question>"

技能强调在遍历前要做受限查询扩展：query CLI 依赖“大小写折叠子串 + IDF”的节点匹配，没有词干、同义词与跨语言匹配。因此要先从图谱节点标签提取真实词表，再从中挑出最多 12 个与问题语义匹配的 token 组成扩展查询串——绝不从训练记忆里臆造近义词；若词表中完全没有匹配 token，就明确告知用户该语料没有相关词汇并停止，不能伪造搜索。扩展结果要先向用户打印以便审计。扩展、BFS/DFS 模式选择、--budget 上限、graphify query CLI 不可用时的内联 NetworkX 遍历回退、save-result 反馈回路，以及 path/explain 流程的完整说明见 graphify/skills/kilo/references/query.md。回答只使用图输出所包含的内容，引用具体事实时须引用 source_location。匹配与遍历的具体实现位于 graphify/cli.py、graphify/querylog.py 与 graphify/analyze.py 等相关模块。

六、add / watch 与钩子集成

/graphify add <url>（把 URL 抓进语料，可通过 --author 标注作者、--contributor 标注语料贡献者）与 --watch（监视目录、代码变更时自动重建、无需 LLM）均不属于默认构建，细节见 graphify/skills/kilo/references/add-watch.md。用户若想安装 post-commit 自动重建钩子或把 graphify 写进项目的 CLAUDE.md，按 graphify/skills/kilo/references/hooks.md 操作——对应 CLI 侧的 graphify hook install/uninstall/status 以及 claude install 等命令（见 graphify/main.py），相关实现位于 graphify/hooks.py 与 graphify/install.py。

七、Kilo 专属规则

本份技能是面向 Kilo 平台渲染的变体，其差异集中在代理编排层：

• 语义提取扇出使用 Kilo 原生的 Task 工具；
• 所有 chunk 任务必须在同一条响应内全部发起，保证并行（逐个等待即串行）；
• 提取 chunk 一律使用 subagent_type="general"；
• 会话中修改过代码文件后，运行 graphify update . 让图谱跟上代码变化。

这四条正是把第 2.4/3 节描述的“子代理派发协议”落到 Kilo 具体工具上的翻译。安装侧，仓库为 Kilo 提供了专门的 graphify kilo install/uninstall 子命令（安装原生 Kilo skill + command + AGENTS.md + .kilo 插件，相关实现符号在 graphify/install.py 中，如 _kilo_install、_install_kilo_plugin、_KILO_PLUGIN_JS 等）。

八、诚实规则：审计是产品的一等公民

技能文档以六条 Honesty Rules 收束整份操作规范，它们定义了图谱作为“可信记忆”的行为底线：

• 永不虚构一条边：不确定就标 AMBIGUOUS；
• 永不跳过语料规模警告（第 2 节的大语料询问流程不可绕过）；
• 报告中永远展示 token 成本；
• 绝不用符号隐藏内聚度分数——展示原始数字；
• 对超过 5000 节点的图运行 HTML 可视化前必须警告用户（Step 6 的自动聚合社区视图正是为此而生）。

这些规则与 Step 4 的 #479 缩容护栏、Step 4.5 的健康检查、Step 9 的“只给真正产出的文件盖章”一脉相承，共同构成“EXTRACTED/INFERRED/AMBIGUOUS 诚实审计轨迹”的实现闭环。工作区中的 worked/ 目录（含 GRAPH_REPORT.md、graph.json 等样例产物）可以作为阅读图谱产出的参考样例。

九、一次完整的落地参考：从安装到探索

综合上述流程，一次在 Kilo 中对当前仓库建立图谱并追问的典型路径为：

1. 安装/自愈解释器并建立 graphify-out/（Step 1）；
2. 输入 /graphify .（或带 --directed/--mode deep 的变体）；
3. 技能自动执行 detect →（视频转写）→ AST+语义并行提取 → 缓存查重 → 合并 → 建图/聚类/分析 → 健康检查 → 社区命名 → HTML/报告落盘（Steps 2–9）；
4. 汇报只贴 God Nodes / Surprising Connections / Suggested Questions 三节，并从最有趣的跨社区问题开始引导 query 探索；
5. 再次会话直接提问即可命中“快路径”，无需重建。

这套流程既有对既有语料开箱即用的易用性（纯代码零 API Key、全自动 detect→extract→build），又通过缓存、manifest 与增量更新为大型长期演进的项目提供了可持续维护的机制——而“每条边都有证据、每个数字都诚实”的审计设计，让 Agent 基于图谱做出的每一次断言都可被追溯到具体文件与提取方式。