Example Usages

This page shows a concrete root-block workflow. Use it after cloning the repo, initializing submodules, and filling the required config.yaml inputs described in Getting Started.

Run the Full Pipeline

The root block can operate the whole block tree with the same plugin-skill lifecycle used by individual blocks.

/root:check

Run this first. It validates the root and all subblocks: config schema, human-provided inputs, inter-block dependencies, repo pins, environments, remote resources, and live LLM endpoints. Fix every reported issue before launching a long run.

Root orchestration does not collect Curator PRs. Before the first production run, execute /curator:collect-prs and wait for its background process to finish. Direct Curator users should choose /curator:create-tasks. Root orchestration and direct Curator workflows both consume the existing files under artifacts/collected_prs/.

/root:run start the data pipeline

This asks the root orchestrator to resolve the target workflow, dispatch the relevant blocks, and archive each run. The expected high-level flow is:

curator ─▶ tracer ─▶ trainer ─▶ evaluator

The handoffs are resolved through block outputs, not copied paths. For example, tracer consumes the verified task directory published by curator, and trainer consumes the trajectory or SFT data directory published by tracer.

Run One Block from Root

You can also ask the root block to operate a specific subblock:

/root:check curator
/root:run curator

Root targeting is not identical to the Curator-specific skills: /root:run curator directly executes Curator's all-language scripts/start.sh. Direct users should choose /curator:create-tasks, which supports smoke, single-language, and full modes. /curator:check also includes Curator's mandatory real-completion probe. Use the block-specific skills when those controls matter.

Inspect Results

After a run, inspect archived outputs first:

artifacts/index.yaml
artifacts/archives/run_NNN/metadata.yaml
artifacts/archives/run_NNN/config.yaml

Then open a dashboard for the stage you care about:

/tracer:dashboard
/trainer:dashboard
/evaluator:dashboard

Dashboards are optional, but they are the fastest way to inspect run state, compare artifacts, and continue analysis after the pipeline finishes.