Skip to content
Back to skills

Workbench Reference Workflows

ASecurity

Use when working on NPA reference workflow specs, runner scripts, cookbooks, customer-adaptable pipeline implementations, or the guarded examples that are not workflow authoring surfaces.

  • 33 stars
  • 0 votes
  • 0 copies
  • 2 views
  • Added September 8, 2026
devopspythongoshellbashrailskubernetestestingdocumentation

Works with

  • terminal
  • cli

Security analysis

A100/100

Scanned October 4, 2026

npx -y skills add nebius/nebius-physical-ai --skill workbench-reference-workflows --agent claude-code

Installs into .claude/skills of the current project.

Are you the author of Workbench Reference Workflows?

Add the live security badge to your README. It updates with every re-scan.

Security grade badge for Workbench Reference Workflows
[![Security: A — Skills Directory](https://www.skillsdirectory.com/api/skills/nebius-workbench-reference-workflows/badge)](https://www.skillsdirectory.com/skills/nebius-workbench-reference-workflows)

More formats (shields.io, HTML) on the badges page. Keep it an A: scan every change in CI with Pro.

Download with Pro
SKILL.md
---
name: workbench-reference-workflows
description: Use when working on NPA reference workflow specs, runner scripts, cookbooks, customer-adaptable pipeline implementations, or the guarded examples that are not workflow authoring surfaces.
---

# Workbench Reference Workflows

> The supported, customer-facing catalog and source of truth is the `npa.workflow` spec set under
> `workflows/`. The old raw SkyPilot task catalog has
> no remaining templates. Raw SkyPilot YAMLs may still exist only as guarded
> tool-specific examples or resource profiles, not as workflow authoring
> surfaces. SkyPilot remains the engine that executes rendered specs.

The catalog keeps the three principal pipelines in `workflows/main/`:
`sim2real.yaml`, `paidf-cosmos3.yaml`, and `nurec-reconstruct.yaml`.
Partner integrations live in `workflows/partners/<partner>/`; general reference
workflows, component tests, and fixtures live in `workflows/testing/`.
Keep catalog documentation in `workflows/README.md` and partner runbooks beside
their specs.

## When To Use

Use this skill for repository workflow YAMLs, runner scripts, cookbooks,
artifact contracts, and customer-adaptable pipeline implementations.

## Procedure

1. Start from the closest checked-in `npa.workflow` spec under
   `workflows/`.
2. Reuse a toolRef from
   `npa/src/npa/orchestration/npa_workflow/catalog.py`; add missing behavior to
   the workbench tool rather than implementing it again in a runner.
3. Keep the runner thin. Python runners materialize config, call the workflow
   submission helper, and report artifacts; the spec owns the stage graph.
4. Keep all input and output paths configurable and run-scoped through S3.
   Stages run in separate pods and cannot depend on a repository-relative path.
5. Declare the output the tool actually writes. Extend
   `test_spec_declared_outputs.py` when a tool exposes a result-URI helper.
6. Run `validate-spec`, then `plan-spec --run-id preview`, before live submit.
   Register every shipped spec in `SUBMIT_LIVE_MATRIX`.

For `field-failure-policy-improvement.yaml`, the native reference adapters join
metric RGB-D reconstruction and shared-scene Isaac navigation. Follow the
[native adapter contract](../../../docs/workbench/cookbooks/field-failure-policy-improvement.md#native-metric-capture-and-isaac-reference).
Include both components in the reviewed source distribution, pin the navigation
module inventory separately from the immutable image, and preserve source-overlay
provenance. TSDF reconstruction is CPU work; native renderer/learner execution on
RTX supplies the GPU evidence. Retain before/after replays of training-exposed
failures separately from the untouched paired cohort. Only the latter may drive
promotion; valid losing baseline episodes must not be discarded by a standalone
success threshold. Public reference results do not establish compatibility with
an undisclosed proprietary policy or calibration.

For the public scan-to-policy sample, derive the parked isolation-control pose
from dense rotated stance support and exact source topology before learning.
Preserve its measured selection evidence in `support.json`; five corner/center
rays or a large center clearance alone cannot exclude a small hole or a source
boundary beneath a foot. Keep the free/obstacle controls, action sequence,
native contact classification, cohort sizes and success gates unchanged when
repairing initial parking placement. Initial CPU support evidence does not
replace native control and full training/evaluation qualification.

For `field-failure-reference-demo.yaml`, freeze training, development and final
cohorts and the simulation-failure admission rule before learning. Evaluate the
exact baseline on every frozen office training route before admitting its public
capture; recompute complete native outcomes, bind admission into the public bundle
reference, and reverify it before reconstruction and training. A crashed or
control-failed observation cannot admit a capture; zero failures publish an honest
terminal report without continuation or final evaluation. Preserve the distinction
between these observed simulation failures and operator-supplied physical logs.
Before admitting final evaluation, development selection
must pair the exact case IDs and seeds and apply every per-case regression bound
from the frozen `plan.metrics`, using the final comparator's strict boundary.
Compute success gain as the mean paired success delta so an improvement of exactly
one percentage point passes without an epsilon or a weakened threshold. Failed
development selection must publish the measured violations in the HTML report
and leave final evaluation untouched.
Interrupted selection/report publication may accept identical retained bytes
to finish missing report files. Reject different bytes without overwriting
evidence; report recovery must not change eligibility or consume final cases.

## Current Reference YAMLs

For a first BEHAVIOR DEV evaluation, use
[the one-file onboarding guide](../../../docs/workbench/challenge-onboarding.md)
and `npa workbench workflow challenge init`, `check`, and `prepare`.
The helper materializes the canonical evaluation workflow and preserves the ten
prescribed cases. A local `ready-to-prepare` result does not prove GPU readiness.
The simulator runtime, licensed assets and task-configured policy remain
operator prerequisites. Keep generated kits private; use the campaign path from
the outset for durable case recovery. Other challenges are not supported by
this helper yet.

The retired catalog path is machine-checked by
`npa/tests/guardrails/test_skypilot_catalog_retirement.py`, so a raw template
cannot quietly reappear there.

No raw SkyPilot templates remain in the retired catalog. Author workflow examples
as `npa.workflow/v0.0.1` specs under `workflows/testing/` or, for partner
integrations, `workflows/partners/<partner>/`.

## Retired Templates

These raw templates were retired once their `npa.workflow` spec had a live run
(run ids in `EVIDENCE.md`). Use the spec under
`workflows/`:

- `isaac-lab-rl-sweep.yaml` — parallel GPU sweep (`--runtime`).
- `cosmos3-reason.yaml` — Cosmos3 reason-stage manifest.
- `sonic-export.yaml`, `sonic-eval.yaml`, `sonic-export-eval.yaml` — SONIC
  export/eval. The tools now accept `s3://` inputs and outputs directly, which is
  what the templates' inline download/upload bash used to do.
- `token-factory-caption.yaml`, `token-factory-generate.yaml`,
  `token-factory-cosmos-reason.yaml` — hosted Token Factory stages.
- `mjlab-eval.yaml` — MJLab locomotion evaluation.
- `retargeting.yaml` — motion retargeting. The harness synthesizes a SOMA-CSV clip
  (`npa.workflows.motion_fixture`) when no real motion set is staged.
- `vlm-eval.yaml`, `vlm-eval-benchmark.yaml` — self-hosted VLM scoring and the labeled
  sweep. The renderer now starts and health-checks the vLLM server the spec asks for, so
  no prebuilt serving image is needed.
- `cosmos3-text-to-image-inference.yaml` — retired to
  `workflows/testing/cosmos3-text-to-image.yaml`. The procedure it carried as bash inside an `envs:`
  block is now `npa workbench cosmos3 text-to-image`.
- `bdd100k-pipeline.yaml` — retired to `workflows/testing/bdd100k-pipeline.yaml`. A live run needs
  both in-cluster services (`lancedb` and `detection-training`) deployed first.
- `dataset-ingest-curate.yaml` — retired to `workflows/testing/dataset-ingest-curate.yaml`, whose
  `register` stage reads back what `ingest` wrote to the in-cluster LanceDB service
  (`npa workbench lancedb deploy --runtime kubernetes --namespace workbench`).
- `sim-to-real-pipeline.yaml` / `sim-to-real-trigger.yaml` — retired. The pipeline ran the
  deprecated `npa.workflows.sim_to_real real-loop`; the maintained path and the
  watcher's submit target are the single staged-engine YAML,
  `workflows/main/sim2real.yaml`.
- `cosmos2-transfer.yaml` — retired to `workflows/testing/cosmos2-transfer.yaml`, which runs the
  REAL Cosmos-Transfer2.5 model (`--execute`) instead of printing a `contract_ready` payload.
- `isaac-franka-capture-reason.yaml` — retired to
  `workflows/testing/isaac-franka-capture-reason.yaml`. The capture code moved into the package
  (`npa.workflows.isaac_capture`), so the stage no longer needs a repo mounted into the pod.
- `sim2real-actions.yaml` — retired into `workflows/testing/sim2real-envgen-shards.yaml` as its
  fourth stage, which conditions the train slice the `split` stage just wrote.
- `tokenfactory-scene-to-rollout-judge.yaml` — hosted reasoner, GPU rollout, hosted judge. Its
  twin keeps the chain: `vlm-eval run --task-from` reads the reasoner's artifact, so the judge
  scores the rollout against the plan rather than a literal string.
- `tokenfactory-rollout-judge.yaml` — GPU rollout then a hosted VLM judge. Its twin is
  `workflows/testing/tokenfactory-rollout-judge-combo.yaml`; note the older same-named spec is a
  *different* workflow (a Cosmos reasoner feeding a judge over externally-seeded rollouts).
- `tokenfactory-train-triage.yaml` — GPU LeRobot training then a hosted triage report. Its twin
  `workflows/testing/tokenfactory-train-triage.yaml` trains in the stage's own pod (the renderer
  switches to the vendor image's interpreter) and triages with
  `npa.workflows.token_factory_triage`. Needs a SkyPilot-hostable LeRobot image; 0.5.1 ships a
  torch/torchcodec ABI mismatch, 0.6.0 does not.
- `cosmos3-ea-fetch.yaml` — Cosmos source/checkpoint fetch. Its twin
  `workflows/testing/cosmos-fetch.yaml` is the two CLI commands the template wrapped in ~60 lines
  of setup bash; the renderer installs `huggingface_hub[cli]`, which was the only load-bearing
  line of that preamble.
- `cosmos3-generate.yaml` — Cosmos 3 omni-model generation in the `npa-cosmos3`
  image. Its twin `workflows/testing/cosmos3-generate.yaml` ran through the live
  submit matrix and produced `generated/generate.json` plus a non-flat 960x960
  `generated/vision.jpg`.
- `nurec-reconstruct.yaml` — **relocated**, not retired: #234 deliberately
  shipped and live-verified a single-pod NuRec/NRE SkyPilot task in addition to
  the multi-pod `npa.workflow` spec. It now lives at
  `npa/src/npa/workbench/nurec/examples/` with its own README and guardrail.
- `sim2real-envgen-split.yaml` — raw env generation + 80/20 split. Its twin
  `workflows/testing/sim2real-envgen-shards.yaml` declares the shard fan-out as a `parallel:`
  group instead of relying on a Kubernetes Job completion index, and runs on CPU.
- `scenario-gen-adversarial.yaml` — adversarial scenario mining. Its twin
  `workflows/testing/scenario-gen-smoke.yaml` runs the same two CLI commands; the template's GPU
  image advertised an RL adversary the CLI cannot select.
- `sim-to-real-loop.yaml` — the rollout-SET loop. Retired via a new tool capability
  (`npa workbench vlm-eval loop`), because nothing else produced
  `task_success_report.json`; the spec is `workflows/testing/vlm-eval-loop.yaml`.
- `isaac-lab-cosmos-sdg-burst-smoke.yaml` — **relocated**, not retired: a single-task input to
  `npa burst submit-yaml`, now at `npa/src/npa/burst/examples/`. Burst is scoped to one
  executable task, so there is no plan or stage graph for a spec to describe.
- `isaac-lab-rl-train-rtxpro.yaml`, `isaac-lab-rl-train-rtxpro-smoke.yaml`,
  `isaac-lab-rl-train.yaml`, `byof-datagen-rtxpro-smoke.yaml`,
  `byof-container-smoke-rtxpro.yaml` — **relocated**, not retired: they are BYOF
  *resource profiles* (a pod shape), not workflows, and now live beside their
  runner at `npa/src/npa/workflows/byof/profiles/`.

The retired catalog is pinned empty in
`npa/tests/guardrails/test_skypilot_catalog_retirement.py`; do not add new raw
workflow templates.

## Three-Tier Contract

- CLI: use `npa workbench workflow ...` and tool-specific workflow commands
  such as `npa workbench mjlab workflow` or `npa workbench sonic retargeting workflow`.
- SDK: route through shared workflow submission helpers rather than shelling out
  from business logic.
- Workflow: the `npa.workflow` spec is the executable source of truth for stage
  order, resources, configuration, and artifact paths. ToolRef argv templates
  are the source of truth for commands; SkyPilot is the rendered execution
  layer.

## Gotchas

- The native Ray CLIP recipe has an optional completed-result archive companion
  at `npa/workflows/workbench/ray-clip-development/archive.py`; follow
  `docs/testing/ray-clip-archive.md` for quiescent source inventories, conditional
  S3 publication and hash-bound private restore. It does not submit Jobs or
  resume incomplete checkpoints, and its local rsync path needs no S3 credentials.

- Customer-provided raw SkyPilot `envs` does not support self-referencing
  interpolation; repository specs use resolved `config` tokens.
- `sky jobs launch` has no dry-run flag. Use `workflow submit --plan-only` for a
  rendered spec preflight.
- Keep SONIC locomotion orchestration in its spec; do not add a Python runner
  that re-implements the graph.

## Verify

```bash
npa/.venv/bin/python -m pytest npa/tests/guardrails/test_skills_index.py -q
```

The smoke test parses the listed workflow YAMLs and invokes workflow CLI help.

Attribution

Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.

Comments

Loading comments…

Newsletter

Get the weekly list of safe new skills, and the ones we pulled.