agentleFS
MicrosoftKnown publishermicrosoft/vulcan/.claude/skills/generate-training-data/SKILL.md

generate-training-data

Skill6 starsChanged 3 months agoMITView on GitHub

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.

The file

We split this skill into the rules it gives an agent

3 rules. About 0 are common, 0 are distinctive, and 3 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈0

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 3

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Very specific:

    If the graph does not exist yet, use the build-tool-graph skill.

    line 23
  2. Very specific:

    Check each path in the table above exists and holds rows, and read llm_calls= from each stage log.

    line 77
  3. Very specific:

    Add the script's --iteration <k> and --label <label> if you did not use the defaults.

    line 84

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Generate the training set

Everything from initial states through the exported dataset. The pipeline's own ordering in core/stage_runner.py is authoritative; this skill runs it in that order and checks each stage landed where the docs say it does.

Prerequisites

execute_sequences needs both halves of the pipeline finished for the category:

  • sample_arguments/success.jsonl — argument samples per tool
  • plan_sequences/multi_turn/all_sequences.jsonl — the planned sequences

generate_states and sample_arguments are steps 6 and 7, before build_graph at 8, so a run that went straight to the graph has them already. If not, run them first — they are in the order below.

If the graph does not exist yet, use the build-tool-graph skill. If the environment has not been reviewed, use simulate-environment first; every stage below executes against it, and a broken environment produces plausible-looking records that teach the wrong thing.

The stages, in order

#StageModel callsWrites
6generate_statesyes<category>/generate_states/success.jsonl
7sample_argumentsyes<category>/sample_arguments/success.jsonl
11execute_sequencesno<category>/execute_sequences/pre_query_all_modes.jsonl
12generate_queriesyes<category>/generate_queries/success.jsonl
13generate_trajectoriesyes<category>/iter_<k>/trajectories/<label>/success.jsonl
14judge_trajectoriesyes<category>/iter_<k>/judged/<label>/success.jsonl
15export_datasetnotraining_dataset/{json,xml}/<category>_iter_<k>.jsonl
vulcan --env <config> --pipeline --start generate_states --end sample_arguments
# graph phase happens here — see the build-tool-graph skill
vulcan --env <config> --pipeline --start execute_sequences --end export_dataset

generate_trajectories is the most expensive stage after build_graph: one conversation per sequence, many turns each, plus a simulated user and a judge for the with_user* environment types.

Output names are a contract

Three stages break the usual <step>/success.jsonl pattern. This is the single most common reason someone concludes a stage produced nothing:

<category>/plan_sequences/multi_turn/all_sequences.jsonl     not success.jsonl
<category>/execute_sequences/pre_query_all_modes.jsonl        not success.jsonl
<category>/iter_<k>/trajectories/<label>/success.jsonl        nested under iter_ and label
<category>/iter_<k>/judged/<label>/success.jsonl              nested under iter_ and label

<k> is the CLI's --iter (default 0) and <label> is --output-label (default native). Rejected transcripts are written to <category>/iter_<k+1>/input.jsonl as input for the next iteration — that is the loop, not a failure.

The exported dataset is the one thing that lives at the run root rather than per category:

<output_base>/training_dataset/json/<category>_iter_<k>.jsonl
<output_base>/training_dataset/xml/<category>_iter_<k>.jsonl

Record shape is {id, category_name, messages}, except tagged-format records, which use category rather than category_name.

Verify

Check each path in the table above exists and holds rows, and read llm_calls= from each stage log. The script does both across every category at once:

python .claude/skills/generate-training-data/scripts/layout_check.py --env <config>

Add the script's --iteration <k> and --label <label> if you did not use the defaults. Exit 0 means every documented output is present; 1 means gaps, listed.

It prints rows and llm_calls per stage. Read the llm_calls column. Steps catch per-item errors and emit the row anyway, so a stage can report success with every model call having failed — llm_calls=0 on a stage that should make calls means exactly that, and the rows below it are input passed through untouched.

Reading the results

SymptomCauseFix
llm_calls=0 on a model stageevery call failed — usually auth, a bad model id, or a provider outagecheck the stage log for the error; LLMError names the provider
stage present but 0 rowsevery item failed validationread failed.jsonl beside it — the validator's reason is on each row
execute_sequences few rowschains failed against the live environmentexpected attrition; if it is most of them, the environment is the problem — run simulate-environment
generate_queries emptyexecute_sequences produced nothingfix that stage first; this one has no input
export_dataset empty, trajectories fineeverything scored below min_score (default 8) or task_completed was falsecheck the judge's scores in judged/<label>/success.jsonl; lower min_score only if the transcripts really are acceptable
unexpected keys in a recordreconstruction wrote a shape the docs do not describereport it — the record shape is a contract with whatever trains on it

Report

Give the row count at each stage as a funnel — sequences in, chains executed, queries, trajectories, judged, exported — so attrition is visible where it happens. Then state where the dataset is and how many records it holds.

Flag any stage whose llm_calls is 0 or whose output is missing, and name the stage to re-run. Runs resume on the item's input hash, so re-running a stage does not re-pay for items that already succeeded; to force regeneration, delete that stage's output directory.

Notes

  • execute_sequences and export_dataset make no model calls. They are free to re-run.
  • Rejected transcripts accumulate at iter_<k+1>/input.jsonl. Running the trajectory stages again with --iter <k+1> works that backlog rather than starting over.
  • For a with_user_and_policy category the exported record carries the category's policy_rules in its system prompt. If it does not, that is a defect — the agent was driven under the policy and judged against it, so the record has to contain it.

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.