Running the Full Pipeline
The full pipeline workflow uses the root plugin to run Curator, Tracer, Trainer, and Evaluator in dependency order. Use it after running the blocks individually at least once, when their inputs, outputs, and approval gates are already familiar.
The workflow has four steps: prepare the pipeline, validate it, collect the pull requests Curator will use, then ask the root plugin to run it. Block configuration remains authoritative, and undeclared handoffs are never inferred automatically.
The examples below show both interfaces. Use the slash command in Claude Code
or the namespaced $root-* skill in Codex; both load the same canonical root
workflow.
Step 1: Preparation
Configure the blocks
Fill each block's config.yaml before asking the root plugin to run the
pipeline. The previous page, Running Block by Block,
links to the Configuration Guide for Curator, Tracer, Trainer, and Evaluator;
use those guides for field-level examples rather than repeating them here.
Treat every handoff as part of the receiving block's configuration. Root checks
only dependencies declared on both neighboring blocks and never invents a
missing path. Curator's local task output and Tracer's raw Harbor jobs can use
declared dependencies; Trainer's usual local_lf input and the
Trainer-to-Evaluator model endpoint must still be set explicitly.
Keep secrets such as LLM API keys and GITHUB_TOKENS in environment variables
or ignored private files. Non-secret decisions such as model names, languages,
benchmarks, and endpoint locations belong in the relevant block's
runtime_info.input.
Run setup
| Claude Code | Codex |
|---|---|
/root:setup | $root-setup |
This checks shared tooling and ensures the root config.yaml exists. It can
offer to invoke each child's setup, but recursion is optional and confirmed one
block at a time. Setup can create environments, synchronize pinned repositories,
and fill approved inputs; it does not launch workloads.
Step 2: Validation
| Claude Code | Codex |
|---|---|
/root:check | $root-check |
This is operationally read-only: it validates configs, both ends of declared dependencies, repository pins, environments, per-block dry runs, and live model endpoints without launching workloads. It cannot infer a dependency that has not been declared, so a missing edge is still a design decision to resolve.
Fix every required failure before continuing. Optional Cloudflare credentials only affect dashboard publishing and do not block the pipeline.
Step 3: Collect Curator input
| Claude Code | Codex |
|---|---|
/curator:collect-prs | $curator-collect-prs |
Root orchestration consumes Curator's existing collection under
blocks/curator/artifacts/collected_prs/. Wait for collection to finish before
starting the root run.
Step 4: Run
| Claude Code | Codex |
|---|---|
/root:run ${INSTRUCTION} | $root-run ${INSTRUCTION} |
The root skill repeats preflight, presents the resolved configuration, and waits
for explicit approval before expensive work. Natural-language instructions may
lead the skills to propose concrete config changes, but those inputs remain
user-owned and every change requires confirmation. Replace ${INSTRUCTION}
with an experiment brief like the one below. It asks the agent to inspect the
available resources instead of assuming a fixed model, machine, or run size.
The same instruction is available as a standalone Markdown file: LegoFlow-new-user-example-prompt.md.
What each stage should produce, and what to hold it to:
| Stage | Target | The condition that matters |
|---|---|---|
| Curator | Verified SWE tasks | Only tasks that pass NOP and Oracle validation reach the manifest. |
| Tracer | Solved rollouts | Preserve the raw trajectory and verified reward; adapt concurrency to endpoint health rather than dropping tasks silently. |
| Selection and conversion | A frozen training set | This is a data-preparation operation, not a registered block. Deduplicate, remove malformed and shallow examples, and freeze an ordered set. |
| Trainer | One checkpoint | Derive the training configuration from the model and GPU topology; preserve the resolved config, logs, and curves. |
| Evaluator | One completed benchmark run | Keep one agent, serving, and verifier configuration; resume infrastructure failures without changing evaluation conditions. |
For a partial workflow, invoke the relevant child skills individually. Current root target resolution treats multiple named blocks as ambiguous rather than as a requested slice.
Monitor and recover
Use each block's dashboard for progress, its logs and outputs for diagnosis, and
the latest artifacts/index.yaml entry for run history. Each leaf run records
metadata, a config snapshot, its scripts, and repository HEAD SHAs. Generated
trajectories, checkpoints, and curves remain in the block's artifact directory.
When a failure or quality regression appears, use the same loop throughout: read the evidence, form a hypothesis, change the smallest responsible thing, rerun only the affected downstream stages, and retain both failed and improved attempts.
Worked example
For a detailed end-to-end example of a full LegoFlow pipeline run, including the agent's recovery process and the resulting improvements, read the LegoFlow case study on LegoX.