[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6X0G7CCSTFNBD8P0M331J03":3,"skill-same:01M6X0G7CCSTFNBD8P0M331J03":73},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":18,"publishedAt":39,"linkOnly":40,"markdownContent":41,"markdownBody":42,"frontMatter":43,"refName":44,"commitSha":45,"skillDirectory":46,"forksCount":47,"repositoryHtmlUrl":48,"repositoryHomepageUrl":6,"ownerHtmlUrl":49,"ownerBlogUrl":50,"ownerDescription":51,"updatedAt":52,"install":53,"resources":66},"01M6X0G7CCSTFNBD8P0M331J03","build-tool-graph",null,"Run VULCAN's graph-construction phase correctly — build_graph and plan_sequences — with a cost estimate before you start and a check afterwards that the graph is actually usable. Use when building the tool dependency graph for a category, or when plan_sequences produced no sequences.","microsoft\u002Fvulcan","microsoft","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F6154722?v=4","01M698VYDXZ6JW5WH3CRV650R8","Microsoft","01M6X0G4SHVFPBQNK608VH9AQT",7,"MIT","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fvulcan\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fbuild-tool-graph\u002FSKILL.md",[],[19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38],"build","build tool graph","tool","build tool","graph","plan","start","use","dependency","cost","dependency graph","run","with","you","cost estimate","for","estimate","vulcan","when","sequences","2026-11-10 10:12:30",false,"---\nname: build-tool-graph\ndescription: Run VULCAN's graph-construction phase correctly — build_graph and plan_sequences — with a cost estimate before you start and a check afterwards that the graph is actually usable. Use when building the tool dependency graph for a category, or when plan_sequences produced no sequences.\n---\n\n# Build the tool dependency graph\n\nThis phase turns a category's tool catalog into a directed graph, then into the multi-turn\nsequences everything downstream is generated from. It is the most expensive stage in a run\nand the easiest to get a silent empty result from.\n\nTwo facts to hold onto:\n\n- **`build_graph` costs *n·(n−1)* model calls for *n* tools.** 56 at 8 tools, 462 at 22,\n  1892 at 44. It asks about every *ordered* pair, so the cost is quadratic and the growth\n  catches people out.\n- **An empty graph is not an error.** The validator accepts a graph whose every edge is\n  `null`, because a parse failure and a genuine non-edge are indistinguishable in the\n  output. You get zero subgraphs one stage later with nothing logged.\n\n## Step 1 — check the precondition\n\n`build_graph` reads `env_grouped\u002Fsuccess.jsonl`, which `StageRunner` writes after\n`verify_tools` — it is not a registered step. If `verify_tools` produced nothing with a\n`tool_code`, `env_grouped` is skipped and this stage fails with `input not found`.\n\n```bash\nwc -l \u003Coutput_base>\u002F\u003Ccategory>\u002Fenv_grouped\u002Fsuccess.jsonl\n```\n\n`build_graph` reads **only** `normalized_schema` and raises `StepError` naming the API if\nit is missing. That is deliberate: dependency detection needs a `response` schema to find\nan output→input edge at all, and falling back to the raw catalog spec would quietly\ndowngrade the whole graph to ordering-only edges. If it raises, re-run `normalize_specs`\nfor that category rather than working around it.\n\nIf you have not reviewed the environment yet, do that first — see the\n`simulate-environment` skill. Every model call this stage makes is spent on a catalog nobody\nchecked.\n\n## Step 2 — estimate before you spend\n\nCount the tools and state the cost, out loud, before running:\n\n```bash\npython -c \"\nimport json,sys\nrows=[json.loads(l) for l in open(sys.argv[1]) if l.strip()]\nn=sum(len(r.get('api_list',[])) for r in rows)\nprint(f'{n} tools -> {n*(n-1)} model calls')\n\" \u003Coutput_base>\u002F\u003Ccategory>\u002Fenv_grouped\u002Fsuccess.jsonl\n```\n\nIf that number is larger than the user expects, say so and stop. Options: cut the catalog,\nor point `steps.build_graph.model` at a cheaper model — per-step `provider` \u002F `model` \u002F\n`base_url` all take effect, because the CLI builds a client per stage.\n\n## Step 3 — run\n\n```bash\nvulcan --env \u003Cconfig> --stage build_graph\nvulcan --env \u003Cconfig> --stage plan_sequences\n```\n\nOr as a range, which is the same thing:\n\n```bash\nvulcan --env \u003Cconfig> --pipeline --start build_graph --end plan_sequences\n```\n\n**Do not run `score_sequences`.** It sits between them in `PIPELINE_ORDER`, but it is\ndeprecated — analysis only, nothing downstream reads its output, and it is the one stage\nyou can drop with no effect on the dataset. Running the range above skips it. A bare\n`--pipeline` does not.\n\n`plan_sequences` is deterministic and makes no model calls. It is cheap to re-run with\ndifferent `turns_per_sequence` or `max_tools_per_sequence` once the graph exists — and\nthat, not rebuilding the graph, is the right response to \"too few sequences\".\n\n## Step 4 — verify\n\nRead `build_graph\u002Fsuccess.jsonl` and check the graph is not all-null: every entry has a\n`source` and an `all_edges` list, and a usable edge is one whose payload has `type` set to\nexactly `explicit` or `implicit`. Then check `plan_sequences` actually produced sequences.\n\nThe script does the counting for you, which on a 20-tool catalog is 380 pairs to eyeball:\n\n```bash\npython .claude\u002Fskills\u002Fbuild-tool-graph\u002Fscripts\u002Fgraph_report.py --env \u003Cconfig>\n```\n\nExit 0 clear, 1 warnings, 2 unusable. It reports tools in the graph, ordered pairs present\nversus expected, usable versus null edges, tools with no outgoing edge, and sequences\nplanned.\n\nWhat the results mean:\n\n| Result | What happened | What to do |\n|---|---|---|\n| every edge null | the `\u003Cgraph>` block did not parse on any call | check `llm_calls=` in `logs\u002F\u003Ccategory>\u002Fbuild_graph.log`; if it is 0 every call failed — usually auth or a bad model id. If non-zero, the model's output format is the problem: try a stronger model for this step |\n| pairs \u003C expected | the stage did not finish, or some pairs errored | re-run the stage; it resumes on input hash, so completed pairs are not re-paid for |\n| usable edges but no explicit ones | the specs carried no `response` schema | re-run `normalize_specs`; ordering-only edges cannot thread real values in `execute_sequences` |\n| sequences = 0 with a good graph | `max_tools_per_sequence` \u002F `turns_per_sequence` too strict for a sparse graph | loosen them and re-run `plan_sequences` only — it is free |\n| many isolated tools | those tools genuinely have no relationship to the others | expected in a mixed catalog; a concern only if it is most of them |\n\n## Step 5 — report\n\nState the cost actually incurred (`llm_calls=` from the stage log, not your estimate),\nthe graph shape, and the sequence count. If anything is off, name the stage to re-run and\nwhether it costs model calls — `plan_sequences` is free, `build_graph` is not.\n\n## Notes\n\n- Resume is on the item's **input** hash, so changing a model or temperature does not\n  invalidate completed items. To force a rebuild, delete the stage output directory.\n- `enable_multipath` is `false` by default. It adds fork-merge subgraphs, and the extra\n  records only matter if you are studying them.\n- `implicit_edge_weight` (default `0.01`) controls how much an ordering-only edge counts\n  toward a subgraph's popularity score. Raising it pulls more implicit-only subgraphs into\n  the sample.\n","# Build the tool dependency graph\n\nThis phase turns a category's tool catalog into a directed graph, then into the multi-turn\nsequences everything downstream is generated from. It is the most expensive stage in a run\nand the easiest to get a silent empty result from.\n\nTwo facts to hold onto:\n\n- **`build_graph` costs *n·(n−1)* model calls for *n* tools.** 56 at 8 tools, 462 at 22,\n  1892 at 44. It asks about every *ordered* pair, so the cost is quadratic and the growth\n  catches people out.\n- **An empty graph is not an error.** The validator accepts a graph whose every edge is\n  `null`, because a parse failure and a genuine non-edge are indistinguishable in the\n  output. You get zero subgraphs one stage later with nothing logged.\n\n## Step 1 — check the precondition\n\n`build_graph` reads `env_grouped\u002Fsuccess.jsonl`, which `StageRunner` writes after\n`verify_tools` — it is not a registered step. If `verify_tools` produced nothing with a\n`tool_code`, `env_grouped` is skipped and this stage fails with `input not found`.\n\n```bash\nwc -l \u003Coutput_base>\u002F\u003Ccategory>\u002Fenv_grouped\u002Fsuccess.jsonl\n```\n\n`build_graph` reads **only** `normalized_schema` and raises `StepError` naming the API if\nit is missing. That is deliberate: dependency detection needs a `response` schema to find\nan output→input edge at all, and falling back to the raw catalog spec would quietly\ndowngrade the whole graph to ordering-only edges. If it raises, re-run `normalize_specs`\nfor that category rather than working around it.\n\nIf you have not reviewed the environment yet, do that first — see the\n`simulate-environment` skill. Every model call this stage makes is spent on a catalog nobody\nchecked.\n\n## Step 2 — estimate before you spend\n\nCount the tools and state the cost, out loud, before running:\n\n```bash\npython -c \"\nimport json,sys\nrows=[json.loads(l) for l in open(sys.argv[1]) if l.strip()]\nn=sum(len(r.get('api_list',[])) for r in rows)\nprint(f'{n} tools -> {n*(n-1)} model calls')\n\" \u003Coutput_base>\u002F\u003Ccategory>\u002Fenv_grouped\u002Fsuccess.jsonl\n```\n\nIf that number is larger than the user expects, say so and stop. Options: cut the catalog,\nor point `steps.build_graph.model` at a cheaper model — per-step `provider` \u002F `model` \u002F\n`base_url` all take effect, because the CLI builds a client per stage.\n\n## Step 3 — run\n\n```bash\nvulcan --env \u003Cconfig> --stage build_graph\nvulcan --env \u003Cconfig> --stage plan_sequences\n```\n\nOr as a range, which is the same thing:\n\n```bash\nvulcan --env \u003Cconfig> --pipeline --start build_graph --end plan_sequences\n```\n\n**Do not run `score_sequences`.** It sits between them in `PIPELINE_ORDER`, but it is\ndeprecated — analysis only, nothing downstream reads its output, and it is the one stage\nyou can drop with no effect on the dataset. Running the range above skips it. A bare\n`--pipeline` does not.\n\n`plan_sequences` is deterministic and makes no model calls. It is cheap to re-run with\ndifferent `turns_per_sequence` or `max_tools_per_sequence` once the graph exists — and\nthat, not rebuilding the graph, is the right response to \"too few sequences\".\n\n## Step 4 — verify\n\nRead `build_graph\u002Fsuccess.jsonl` and check the graph is not all-null: every entry has a\n`source` and an `all_edges` list, and a usable edge is one whose payload has `type` set to\nexactly `explicit` or `implicit`. Then check `plan_sequences` actually produced sequences.\n\nThe script does the counting for you, which on a 20-tool catalog is 380 pairs to eyeball:\n\n```bash\npython .claude\u002Fskills\u002Fbuild-tool-graph\u002Fscripts\u002Fgraph_report.py --env \u003Cconfig>\n```\n\nExit 0 clear, 1 warnings, 2 unusable. It reports tools in the graph, ordered pairs present\nversus expected, usable versus null edges, tools with no outgoing edge, and sequences\nplanned.\n\nWhat the results mean:\n\n| Result | What happened | What to do |\n|---|---|---|\n| every edge null | the `\u003Cgraph>` block did not parse on any call | check `llm_calls=` in `logs\u002F\u003Ccategory>\u002Fbuild_graph.log`; if it is 0 every call failed — usually auth or a bad model id. If non-zero, the model's output format is the problem: try a stronger model for this step |\n| pairs \u003C expected | the stage did not finish, or some pairs errored | re-run the stage; it resumes on input hash, so completed pairs are not re-paid for |\n| usable edges but no explicit ones | the specs carried no `response` schema | re-run `normalize_specs`; ordering-only edges cannot thread real values in `execute_sequences` |\n| sequences = 0 with a good graph | `max_tools_per_sequence` \u002F `turns_per_sequence` too strict for a sparse graph | loosen them and re-run `plan_sequences` only — it is free |\n| many isolated tools | those tools genuinely have no relationship to the others | expected in a mixed catalog; a concern only if it is most of them |\n\n## Step 5 — report\n\nState the cost actually incurred (`llm_calls=` from the stage log, not your estimate),\nthe graph shape, and the sequence count. If anything is off, name the stage to re-run and\nwhether it costs model calls — `plan_sequences` is free, `build_graph` is not.\n\n## Notes\n\n- Resume is on the item's **input** hash, so changing a model or temperature does not\n  invalidate completed items. To force a rebuild, delete the stage output directory.\n- `enable_multipath` is `false` by default. It adds fork-merge subgraphs, and the extra\n  records only matter if you are studying them.\n- `implicit_edge_weight` (default `0.01`) controls how much an ordering-only edge counts\n  toward a subgraph's popularity score. Raising it pulls more implicit-only subgraphs into\n  the sample.\n",{"name":5,"description":7},"main","9449cc34c0b30d72fab19d05bc7c37e94f54c3aa",".claude\u002Fskills\u002Fbuild-tool-graph",2,"https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fvulcan","https:\u002F\u002Fgithub.com\u002Fmicrosoft","https:\u002F\u002Fopensource.microsoft.com","Open source projects and samples from Microsoft","2026-10-27 04:26:42",{"source":8,"skillName":5,"commands":54,"prompt":64,"zipAvailable":65},[55,58,61],{"tool":56,"command":57},"npx","npx skills add microsoft\u002Fvulcan --skill build-tool-graph",{"tool":59,"command":60},"bunx","bunx skills add microsoft\u002Fvulcan --skill build-tool-graph",{"tool":62,"command":63},"pnpm","pnpm dlx skills add microsoft\u002Fvulcan --skill build-tool-graph","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fvulcan\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fbuild-tool-graph\u002FSKILL.md",true,[67],{"path":68,"resourceType":69,"resourceTypeDesc":70,"sizeBytes":71,"sourceHtmlUrl":72},"scripts\u002Fgraph_report.py","SCRIPT","脚本",7211,"https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fvulcan\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fbuild-tool-graph\u002Fscripts\u002Fgraph_report.py",[74,96,112],{"skillNo":75,"name":76,"nameZh":6,"description":77,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":78,"categories":79,"keywords":80,"publishedAt":39},"01M6X0GY8XDSY0NSND2XQH2RCA","simulate-environment","Build a VULCAN input catalog from tool schemas a user shares, run the environment-simulation phase, and review the generated environment class for state\u002Fbehaviour mismatches, unusable initial states, arguments with no effect, non-determinism, and missing tool coverage. Use when starting from raw tool schemas, or after debug_environment on an existing run.","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fvulcan\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fsimulate-environment\u002FSKILL.md",[],[81,82,83,84,85,86,87,21,88,89,90,91,26,92,93,31,34,94,95,37],"simulate environment","simulate","environment","review","debug","state","simulation","effect","coverage","generated","catalog","missing","states","Existing","phase",{"skillNo":97,"name":98,"nameZh":6,"description":99,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":100,"categories":101,"keywords":102,"publishedAt":39},"01M6X0GP3CREDSPHTVGGAK5R1H","run-vulcan","Drive a complete VULCAN run from a conversation — take tool schemas or an existing catalog, build the simulated environment, review it, construct the tool dependency graph, generate and judge trajectories, and export the training set. Use when someone wants to generate tool-calling training data and does not want to run the stages by hand.","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fvulcan\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Frun-vulcan\u002FSKILL.md",[],[103,36,30,104,105,94,37,106,84,107,108,21,83,91,26,29,19,109,110,111],"run vulcan","hand","trajectories","generate","training","SET","conversation","calling","complete",{"skillNo":113,"name":114,"nameZh":6,"description":115,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":116,"categories":117,"keywords":118,"publishedAt":39},"01M6X0GFGN9A5H5EKTGV5Q071M","generate-training-data","Run VULCAN's task-generation and trajectory phases — initial states, argument samples, chain execution, user queries, trajectories, judging, and dataset export — and verify every stage wrote to its documented path with the documented record shape. Use after the tool dependency graph exists.","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fvulcan\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fgenerate-training-data\u002FSKILL.md",[],[106,119,120,107,121,26,21,122,123,124,125,126,105,93,31,127,128,129,130,29],"generate training data","generate training","data","execution","stage","dataset","chain","trajectory","argument","task","queries","record"]