使用 graphify /graphify Skill：让任意代码库变成可查询知识图谱的分步运行手册

graphify 的 /graphify 是一个面向 Claude Code、Copilot、Cursor、Codex、Gemini CLI 等编码 Agent 的斜杠技能（slash skill）：执行后，它会按既定步骤把任意文件夹（代码、文档、论文、图片甚至音视频）转换为带社区检测的持久化知识图谱，并产出三种输出——交互式 HTML、GraphRAG 就绪的 JSON、以及人话写的 GRAPH_REPORT.md。本文基于仓库中为 Copilot 平台生成的 skill 工件 tools/skillgen/expected/graphify__skill-copilot.md（与 graphify/skill-copilot.md 内容一致）展开，逐段拆解它的命令全集、九步执行流水线、查询/路径/解释子命令与“诚实性规则”，并结合源码说明每一步背后的实现机制。读完本文，你既能亲手驱动这套流水线，也能理解它为何能做到“无 API Key、确定性 AST 提取 + 诚实审计线索”。

一、这是一份什么文档：Skill 工件与其在仓库中的位置

先交代文档坐标。/graphify 技能的本质是一份高度脚本化的 Agent 提示手册：Agent 被唤起后，必须按手册逐条执行 bash 命令，不得跳过步骤。该手册不是一份写死内容的静态文件，而是由仓库内置的生成器按平台模板渲染出来的产物：

• 平台清单 tools/skillgen/platforms.toml 中声明了 [platform.copilot]：skill_dst = "graphify/skill-copilot.md"、refs_dst = "graphify/skills/copilot/references"、dispatch = "agent-tool-disk"、extraction = "verbose"，即 Copilot 平台使用“Agent 工具写盘”派发方式、完整版提取规范；
• 运行 python -m tools.skillgen 可从仓库根重新生成，--check 校验是否漂移，--bless 刷新 expected/ 下的对照基准——graphify__skill-copilot.md 正是这套回归对照产物。

Skill 本体采用 split（拆分）布局：SKILL.md 只保留精简的核心流程，把“GitHub 仓库克隆与跨仓合并、增量更新、转写、导出、查询、hooks、add/watch”等细节放到同目录的 references/ 边车文档中，主流程按需加载。Copilot 平台对应的 8 份参考文档位于 graphify/skills/copilot/references/。

skill 的 frontmatter 声明了它的触发语义：凡涉及代码库架构、文件关系、项目内容的问题都适用；尤其当 graphify-out/ 已存在时，应把问题当作一次 graphify 查询优先处理——它把任意输入（代码、文档、论文、图片、视频）变成带“神节点（god nodes）”、社区检测以及 query/path/explain 工具的持久化知识图谱。

二、命令全集：一条命令触发完整流水线

## Usage 区块是 /graphify 的参数手册，Skill 文档要求 Agent 在用户执行 /graphify --help 或 /graphify -h（且不带其他参数）时原样输出此节并停止。下表完整继承原文档，并按“构建 → 增量维护 → 导出 → 语料追加 → 问答”归类：

命令	作用
/graphify	对当前目录跑完整流水线（默认生成 HTML 可视化；加 --obsidian 生成 vault）
/graphify <path>	对指定路径跑完整流水线
/graphify https://github.com/<owner>/<repo>	克隆仓库后跑完整流水线
/graphify https://github.com/<owner>/<repo> --branch <branch>	克隆指定分支
/graphify <url1> <url2> ...	克隆多个仓库、各自建图后合并为一张跨仓库图
/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 默认已生成，此 flag 为 no-op
/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 生成 graphify-out/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 写到自定义路径（如已有 vault）
/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	把答案截断到 N tokens
/graphify path "AuthModule" "Database"	两概念间的最短路径
/graphify explain "SwinTransformer"	用自然语言解释某个节点

值得注意：这是一条无 API Key 也成立的流水线——代码由 AST 确定性解析完成，纯代码语料（最常见的 /graphify .）会完全跳过语义提取，因此既不要求也不阻塞在密钥上。这与底层设计一致：本地确定性 AST 解析、每条边都有解释、不依赖向量库。

三、被唤起后的第一件事：三种分派路径

Skill 文档在 ## What You Must Do When Invoked 中规定了调用时的强制决策逻辑，一共有三条分派路径，Agent 不得自作主张：

1. Help 分支：若用户仅执行 /graphify --help 或 -h，原样输出 ## Usage 区块后停止——不运行命令、不做文件探测、不把路径默认为 .。
2. 快路径（已有图）：检查当前工作目录下 graphify-out/graph.json 是否存在。若存在且用户的请求是对代码库的自然语言提问（如 “How does X work?”、“What calls Y?”、“Trace the data flow through Z”），且不是显式重建命令（--update、--cluster-only 或暗示全新提取的裸路径/URL），则跳过 Step 1–5，直接跳到 graphify query。文档强调：图已经建好了，就用它；不跑 detect、不检查语料规模、不让用户收窄问题。
3. 全量构建：未给路径时默认使用 .（不要向用户询问路径）；若路径以 https://github.com/ 或 http://github.com/ 开头，先执行 Step 0 再继续。

其中“快路径”对 Agent 的成本含义深刻：一次构建得到的图跨会话持久，之后的架构问答都只是图查询，这正是设计上把知识图谱当作 Agent 长期记忆层的体现。配合 --watch 或 post-commit hook，图能随代码变更自动刷新（见 graphify/skills/copilot/references/hooks.md）。

四、九步执行流水线：从语料扫描到交付报告

全量构建遵循 Step 0–9 的有序执行（不许跳过）。下面逐段还原每步做什么、为什么这样做，并给出源码侧的佐证。

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

只有路径是一个或多个 GitHub URL、或要合并多个本地子文件夹时才执行。克隆、跨仓库合并与 monorepo 流程见 graphify/skills/copilot/references/github-and-merge.md，结束后继续用解析出的本地路径。普通本地路径直接跳过。

Step 1 —— 确保 graphify 已安装

Skill 提供一段健壮的 Python 解释器探测脚本，按优先级覆盖三种安装形态：

1. uv tool 安装：uv tool run --from graphifyy python -c ...（现代 Mac/Linux 上最可靠）；
2. 读 graphify 可执行文件的 shebang（覆盖 pipx 与直接 pip 安装）；
3. 兜底 python3。

若 import 失败则自动安装（优先 uv tool install --upgrade graphifyy，否则 pip install graphifyy，失败后再试 --break-system-packages）。随后把解析到的解释器路径写入 graphify-out/.graphify_python——后续每个 bash 块都用 $(cat graphify-out/.graphify_python) 替代 python3，保证长会话中跨调用的解释器一致；同时把扫描根写入 graphify-out/.graphify_root，供日后无参 graphify update 定位。

Step 2 —— 探测文件

调用 graphify.detect.detect(Path(INPUT_PATH))（实现于 graphify/detect.py），并把结果以 UTF-8 写入 graphify-out/.graphify_detect.json（刻意从 Python 写而非 shell 重定向，避免 PowerShell 主机控制台编码漂移）。探测按六类文件归档——源码中 detect.py 定义了 FileType 枚举与各扩展名集合：代码（CODE_EXTENSIONS，覆盖 .py/.ts/.go/.rs/.cpp/.c/.java/.cs/.swift/.kt/.rb/.php/.lua/.zig/.pas/.sh/.sql 等上百种）、文档（DOC_EXTENSIONS，.md/.mdx/.qmd/.skill/.txt/.rst/.html/.yaml/.yml）、论文（.pdf）、图片、Office（.docx/.xlsx）、音视频（.mp4/.mov/.webm/.mp3/.wav 等），见 graphify/detect.py。

Agent 需要向用户展示干净摘要（每个 0 文件的类别省略）：

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 ...)

随后按探测结果分派：

• total_files 为 0 → 报告 “No supported files found in [path].” 并停止；
• skipped_sensitive 非空 → 报告数量并列被跳过的文件名（让被误判的敏感文件可见，可改名/移动）；
• total_words > 2,000,000 或 total_files > 500 → 展示警告，并按各一级子目录文件数给出 top 5，询问用户要跑哪个子文件夹（注意过滤 graphify-out/ 自身的副产物；若文件全在 (root) 层则建议 --no-cluster 继续，不询问）；
• 否则直接进入 Step 2.5（有视频时）或 Step 3。

文档强调：不要 cat 或打印 JSON，静默读取后展示摘要。

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

detect 返回 0 个 video 文件时整体跳过。语料含视频/音频时，按 graphify/skills/copilot/references/transcribe.md 先转成文本，再把转写稿当作 Step 3 的 doc 文件处理。--whisper-model medium 等选项即作用于该转写步骤。

Step 3 —— 提取实体与关系（流水线的心脏）

Step 3 分为**结构提取（确定性、免费）与语义提取（LLM、耗 token）**两部分，是全流水线技术含量最高的环节。

关键约束：graphify 不需要 API Key，绝不向用户索取、绝不为它阻塞。纯代码语料直接走 Part A 跳过 Part B。语义提取（仅针对 docs/papers/images）仅当 GEMINI_API_KEY/GOOGLE_API_KEY 已设置时使用 Gemini（默认模型 gemini-3-flash-preview，可用 GRAPHIFY_GEMINI_MODEL 或 headless 下的 --model 覆盖）；否则由宿主 Agent 自己充当 LLM。graphify 不读取 ANTHROPIC_API_KEY、OPENAI_API_KEY 等任何其他厂商密钥——文档甚至警示：若 Agent 发现自己要因缺 key 而卡住等待，那就是对 skill 的误读。

未设置 Gemini key 时，打印一句提示（“set GEMINI_API_KEY or GOOGLE_API_KEY … pip install 'graphifyy[gemini]'”）后继续，不等用户。设置了 key 则改用库内路径 graphify.llm.extract_corpus_parallel(files, backend="gemini")（见 graphify/llm.py）。

Part A —— 代码的结构（AST）提取：遍历 detect 结果里的 code 文件，调用 graphify/extract.py 的 collect_files/extract，把结果写入 graphify-out/.graphify_ast.json。这段是完全确定性的，速度极快，因此 Skill 要求 Part A 与 Part B 并行启动（AST 跑的同时派发语义子代理），大语料可省 5–15 秒。

Part B —— 语义提取（并行子代理）：

• 快路径：若探测到 0 个 docs/papers/images（纯代码语料），跳过整个 Part B。但必须先写一个空的 .graphify_semantic.json——Part C 会无条件读它，否则纯代码运行会因 FileNotFoundError 崩溃。
• 强制用 Agent 工具：文档强调逐文件自己读比派发慢 5–10 倍，属于错误做法。派发前先打印耗时估算：子代理数 ≈ ceil(未缓存非代码文件 / 22)（每块 20–25 个文件），每批约 45 秒。
• B0 缓存检查：用 graphify/cache.py 的 check_semantic_cache(all_files, root, prompt_file=SPEC_PATH) 判断哪些文件已有缓存。SPEC_PATH 是随 SKILL 一同发布的 references/extraction-spec.md 的绝对路径，且缓存条目按 prompt 归因——graphify 升级改动提取 prompt 后，旧 prompt 产生的条目会被重提取而非重放（文档注记 #1939）。只对 graphify-out/.graphify_uncached.txt 中列出的文件派发子代理；全部命中则直接跳 Part C。
• B1 分块：按 20–25 文件一块切分；每张图片独占一块（视觉需要独立上下文）；同目录文件尽量同块，以提高跨文件关系提取率。
• B2 单条消息内派发所有子代理：多个 Agent 调用必须在同一条回复里发出才能真正并行。子代理类型必须用 general-purpose（Explore 是只读的，无法把块文件写入磁盘，会静默丢结果）。每个子代理被赋予 graphify/skills/copilot/references/extraction-spec.md 中定义的精确 prompt（含 JSON schema、节点 ID 规则、置信度评分细则、frontmatter、超边与视觉规则），写入 graphify-out/.graphify_chunk_0N.json（绝对路径）。
• B3 回收、缓存、合并：以“块文件存在于磁盘”作为成功信号；缺失则警告“subagent may have been read-only. Re-run with general-purpose agent.”。超过一半块失败则停下告知用户重跑。合并各块为 .graphify_semantic_new.json 后，用 save_semantic_cache 落缓存（传同一个 SPEC_PATH 保证 prompt 归因一致），再把 cached + new 按节点 id 去重合并为最终 .graphify_semantic.json。Agent 工具结果的 usage 字段里的真实 token 数要回写进块 JSON（块 JSON 内永远是占位零）。

Part C —— 合并 AST + 语义：AST 节点优先，语义节点按 id 去重追加；最终写 graphify-out/.graphify_extract.json，打印形如 Merged: N nodes, E edges (A AST + S semantic) 的统计。

Step 4 —— 建图、聚类、分析、生成产物

此步是源码汇合点：build_from_json(extraction, root=INPUT_PATH, directed=IS_DIRECTED) 出自 graphify/build.py（root= 与 --update 走同一相对化基准，保证全量与增量重建在节点 key 上不漂移）。IS_DIRECTED 需替换为 --directed 对应的 True（构建保方向的 DiGraph）或默认 False（无向 Graph）。

紧接着调用链包括：

• cluster(G) 与 score_all(G, communities)：graphify/cluster.py 内置 Louvain/Leiden 风格的社区划分（有 native 加速路径，见 _native_leiden）与 cohesion_score 凝聚度评分；
• god_nodes(G)、surprising_connections(G, communities)、suggest_questions(...)：graphify/analyze.py，用于找出跨社区枢纽的“神节点”、惊喜连接并生成候选问题；
• generate(...)：graphify/report.py 的 generate 生成人类可读的 GRAPH_REPORT.md；
• to_json(G, communities, 'graphify-out/graph.json')：graphify/export.py 的 to_json。

其中有两个防御性设计值得展开：

1. 空图护栏：若 G.number_of_nodes() == 0，立即报错退出（“all files were skipped, binary-only corpus, or extraction failed”），绝不让空结果覆盖已有好图（注记 #1392）。
2. 缩图护栏（shrink-guard）：to_json 在新图节点数少于现有 graph.json 时返回 False 且什么都不写（注记 #479）。此时 Agent 打印 ERROR: refused to shrink ... 并提示用户若确属删文件导致的主动缩图，可加 --force 全量重建。只有图真正写盘成功后才写 GRAPH_REPORT.md 和分析边车 .graphify_analysis.json，保证文档永远描述的是图里真实存在的内容。

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

非破坏性诊断：调用 graphify/diagnostics.py 的 diagnose_extraction(extraction, directed=IS_DIRECTED, root=INPUT_PATH) 与 format_diagnostic_report，对提取结果体检，暴露边塌缩、悬空/缺失端点、自环——这些正是增量更新与 AST/LLM id 不匹配下的“静默腐坏”模式（也是 tests/test_multigraph_diagnostics.py、tests/test_relation_collapse_precedence.py 等测试反复压测的对象）。有告警就打印 GRAPH HEALTH WARNING: ... 并在最终摘要里呈现（不中止——图仍可用，但按诚实性规则问题必须可见）。

Step 5 —— 给社区命名

读取 .graphify_analysis.json，为每个 community 写 2–5 个词的平实名称（如 “Attention Mechanism”、“Training Pipeline”、“Data Loading”），随后重建 LABELS_DICT（如 {0: "Attention Mechanism", 1: "Training Pipeline"}）重新执行一次建图+分析+报告，并把标签写入 .graphify_labels.json、用 to_json(..., community_labels=labels) 重导出 graph.json，让节点携带 curate 过的 community_name（注记 #2490）。真实标签还会影响 suggest_questions 的问题措辞。

Step 6 —— Obsidian vault（opt-in）+ HTML

• Obsidian 仅在显式给 --obsidian 时生成（否则跳过——每个节点一个文件，很重）。默认输出 graphify-out/obsidian；--obsidian-dir <path> 经 --dir 传给 graphify export obsidian。实现上 graphify/export.py 的 to_obsidian 会为每个节点生成一个带 [[wikilinks]] 的 .md 文件，并按社区写标签/.obsidian/graph.json，同时绝不覆盖用户已有笔记与配置。
• HTML 默认总生成（除非 --no-viz）：graphify export html。图超过 5000 节点时自动聚合成社区视图（对应 exporters 目录下的 graphify/exporters/html.py 与 _viz_node_limit）；Honesty Rules 也要求对 >5000 节点跑 HTML 可视化前必须先警告用户。

Steps 6b–8 —— Wiki / 图数据库 / SVG / GraphML / MCP / benchmark（仅在对应 flag 下）

这些只在带 flag（--wiki、--neo4j/--neo4j-push、--falkordb/--falkordb-push、--svg、--graphml、--mcp）或语料超过 5000 词触发 token 缩减 benchmark 时运行，默认零 flag 的运行全部跳过。细节见 graphify/skills/copilot/references/exports.md。从 graphify/cli.py 的 export 子命令分支可以看到对应的真实实现：to_html/to_obsidian/to_canvas/to_svg/to_graphml/to_cypher，以及 graphify/exporters/graphdb.py 的 push_to_neo4j、push_to_falkordb。注意任何 --wiki 导出要先于 Step 9 清理执行，保证 .graphify_labels.json 仍在。

Step 9 —— 保存 manifest、更新成本追踪、清理与汇报

收尾段在 graphify/cli.py 的辅助函数配合下完成三件事：

1. 写增量 manifest：用 graphify.detect.save_manifest 保存（graphify/detect.py），root= 把 manifest 键相对化到扫描根，使其跨克隆/机器可移植（注记 #1417）。关键语义：只给真正产生输出的语义文件盖章——探测到但块失败/被漏的文件必须保持未盖章，否则下次 --update 会跳过它并永久丢失内容（注记 #2015）；代码文件（AST 确定性）总是盖章。同时清理本轮分派但未盖章文件的陈旧 semantic_hash（注记 #1948），并在 scan_corpus 中收录原始全语料，保证“被排除/被删除”的文件如实出图（注记 #1908）。
2. 累计成本追踪：读写 graphify-out/cost.json，记录每次运行的日期、input/output token、文件数并打印 This run: ... / All time: ...。
3. 清理临时副产物：删除 .graphify_detect.json、.graphify_extract.json、.graphify_ast.json、.graphify_semantic.json、.graphify_analysis.json 及各 chunk 文件。

最后向用户交付结果摘要：

Graph complete. Outputs in PATH_TO_DIR/graphify-out/

  graph.html            - interactive graph, open in browser
  GRAPH_REPORT.md       - audit report
  graph.json            - raw graph data
  obsidian/             - Obsidian vault (only if --obsidian was given)

Agent 从 GRAPH_REPORT.md 粘贴 God Nodes / Surprising Connections / Suggested Questions 三节（不贴全文），然后主动提出最有意思的那个跨社区问题，引导用户以“图即地图、Agent 即向导”的方式继续探索，而非一次性报告了事。

五、构建之后：子命令侧的执行纪律

Skill 文档用若干个 ## For ... 小节约束非默认子命令的触发条件与前置守卫：

• 解释器守卫（Interpreter guard）：执行 --update、--cluster-only、query、path、explain、add 之前，先检查 graphify-out/.graphify_python 是否存在（用户可能删过 graphify-out/）；缺失则按 Step 1 同款逻辑重新解析解释器。
• --update / --cluster-only：两者都非默认子命令。前者只对新增/变更文件重提取，后者仅对既有图重跑聚类，完整流程见 graphify/skills/copilot/references/update.md。增量语义对应 graphify/detect.py 中的 detect_incremental、_stamped_manifest_files 等实现与大量回归测试（如 tests/test_incremental.py、tests/test_incremental_mtime_collision.py）。
• query：graphify-out/graph.json 已存在且用户就语料提问时，直接 graphify query "<question>" 作答，而非重建。查询实现细节（词汇扩展、BFS/DFS、--budget、NetworkX 兜底遍历、save-result 反馈环、path/explain 流程）见 graphify/skills/copilot/references/query.md。
• add / --watch：默认构建不含二者。/graphify add <url> 把 URL 抓入语料、--watch 自动重建，见 graphify/skills/copilot/references/add-watch.md。
• commit hook / 原生 CLAUDE.md 集成：安装 post-commit 自动重建 hook 或接入项目 CLAUDE.md，见 graphify/skills/copilot/references/hooks.md。仓库为不同主机都预渲染了完整的分平台 skill（graphify/skill.md、graphify/skill-codex.md、graphify/skill-copilot.md 等），说明这套手册在各 agent 主机上的通用性。

六、诚实性规则：为什么这份手册值得信任

skill 以五条 “Honesty Rules” 收尾，它们是整个产品可审计性的契约，也直接呼应“local deterministic AST parsing, every edge explained, no vector store”的项目定位：

1. 永不虚构边：不确定就用 AMBIGUOUS——这对应图上每条边携带 EXTRACTED / INFERRED / AMBIGUOUS 三种置信标签之一的诚实审计线索；
2. 永不跳过语料规模警告（对应 Step 2 的超大语料分支）；
3. 报告里永远展示 token 成本（对应 Step 9 的 cost.json 与每次运行的 token 打印）；
4. 绝不用符号隐藏凝聚度分数，展示原始数值；
5. 不对 >5000 节点的图跑 HTML 可视化而不警告用户（对应 Step 6 与 exporters/html.py 的自动聚合逻辑）。

从工程角度看，这套规则的“可执行化”由 Step 4 的缩图护栏（#479）、Step 4.5 的图健康检查、Step 9 的“只给有输出的文件盖章”（#2015）等机制在代码层面兜底——诚实不是口头承诺，而是写入流程的失败保护。相关回归测试覆盖可见于 tests/ 下的 test_multigraph_diagnostics.py、test_relation_collapse_precedence.py、test_export.py、test_dedup.py、test_incremental.py 等。

七、总结：把“读代码库”变成“查知识图谱”

回看整份 /graphify skill：它把 Agent 理解代码库的方式从“逐文件读”重构为“构建一次、查询多次”。使用者要掌握的要点可归纳为：

• 输入与形态：代码、文档、PDF、图片、音视频任意混放；输出为 HTML 可视化 + JSON 图数据 + GRAPH_REPORT.md，可选 Obsidian vault、wiki、SVG/GraphML、Neo4j/FalkorDB、MCP server。
• 成本心智：代码走免费、确定性的 AST 结构提取；只有 docs/papers/images 才需要语义提取，且默认不依赖任何厂商密钥（宿主 Agent 或可选 Gemini）。
• 诚实与安全：EXTRACTED/INFERRED/AMBIGUOUS 审计标签、缩图/空图/健康检查三道护栏、超 500 文件或 200 万词即要求收窄的语料门槛，共同保证“图不会悄悄撒谎”。
• 维护闭环：--update 增量、--watch 自动重建、post-commit hook、save-result 把每次问答写回图里形成自改进回路，让图随项目一起演进。

对本仓库而言，这是理解 graphify 整体设计的最佳单点入口：想要系统级图文教程可读 docs/how-it-works.md，想看产出示例可看 worked/httpx/README.md 与 worked/httpx/graph.json，想验证各平台 skill 的一致性则可直接对照 tools/skillgen/ 下的模板、fragment 与 expected 基准。