Packages and Registry
Use the CLI to scaffold, validate, publish, inspect, sync, pull, and manage capabilities, datasets, models, and task environments.
This is the artifact-management half of the CLI: the commands you use before evaluations, optimization, training, or runtime use.
In practice, most registry work follows one shared workflow:
- author or edit the local artifact
- inspect or validate it before publishing
- push it to the registry
- confirm the exact published ref you want others to use
- pull or install it later when another workflow needs it
That shared registry workflow matters because the verbs sound similar, but they do different jobs.
The four artifact families
Section titled “The four artifact families”| Family | Main CLI group | Typical local source |
|---|---|---|
| capabilities | dn capability ... | capability.yaml, agents/, tools/, skills/, .mcp.json, scripts/, optional hooks/ |
| datasets | dn dataset ... | dataset.yaml plus data files |
| models | dn model ... | model.yaml plus weights or adapters |
| task environments | dn task ... | task.yaml, docker-compose.yaml, verifier or solution files |
Reference formats
Section titled “Reference formats”Capabilities, datasets, and models accept the usual registry forms:
namename@versionorg/nameorg/name@version
Tasks are different in practice. The task CLI resolves the latest visible task version, so the most
common user-facing form is NAME@latest.
The verbs that matter
Section titled “The verbs that matter”Before looking at each artifact family, it helps to know what the common verbs usually mean:
init: scaffold a new local artifact directoryinspectorvalidate: check a local artifact before publishingpush: publish one new artifact versionsync: bulk-publish a directory of artifactsinfo: inspect one published artifact and its versionspullordownload: retrieve a published artifact locallypublish/unpublish: change cross-organization visibility
If a registry page ever feels noisy, come back to that list. Most confusion is really confusion about the verb.
Capability commands
Section titled “Capability commands”Capabilities are the artifact family with the most overloaded workflow, because they support both local development and registry-backed reuse.
Local capability development
Section titled “Local capability development”Use this path when the capability lives on disk and you want local agents to use the local files:
dn capability init web-recon --with-skills --with-mcpdn capability validate ./capabilitiesdn capability install ./capabilities/web-recondn capability install ./path is the local activation command. It validates the capability and
installs it into your local capability store so local agents can use it immediately.
For current capability bundles, think in terms of agents, tools, skills, MCP config,
dependencies, and checks. Older local bundles may still include hooks/, but that is now a
legacy compatibility path rather than the main v1 authoring story.
Local capability improvement
Section titled “Local capability improvement”Use this path when you want to improve a capability before you publish it. This workflow is local, dataset-driven, and scoped to capability-owned surfaces such as agent prompts and skills.
dn capability improve ./capabilities/web-recon \ --dataset ./datasets/recon-train.jsonl \ --holdout-dataset ./datasets/recon-holdout.jsonl \ --scorer ./evals/recon.py:quality \ --model openai/gpt-4o-miniWhat this command does:
- loads the local capability directly from disk
- runs a baseline on the local dataset
- can delegate candidate proposal to a local improver capability such as
dreadnode/capability-improver - searches only capability-owned text surfaces, not the shared runtime stack
- gates the result against the optional holdout dataset
- writes a ledger and materialized candidate bundle under
.dreadnode/improve/
If you want to force a specific proposer, pass --proposer-capability and optionally
--proposer-agent / --proposer-model. If omitted, the CLI will use
dreadnode/capability-improver when it finds that capability in your local capability roots.
Use dn capability improve when the capability is still changing locally. Use
dn optimize submit after the capability and dataset are already published
and you want the platform to run the job.
Registry-backed capability use
Section titled “Registry-backed capability use”Use this path when the capability already exists in the registry and you want to inspect or fetch a published version:
The important distinction is:
install org/name@versiondownloads and activates the capability for local usepull org/name@versiononly downloads it for reading or forkinginfois the safest way to confirm the exact version before you depend on it
Publish capability changes
Section titled “Publish capability changes”Use these commands once the local capability is ready to become a reusable artifact:
dn capability push ./capabilities/web-recon --publishdn capability sync ./capabilities --publishdn capability list --search recon --include-publicReach for push when you are working on one capability. Reach for sync when you want the CLI to
discover and publish many capabilities in a directory tree.
Dataset commands
Section titled “Dataset commands”Datasets are simpler: they are versioned inputs that other workflows consume.
Inspect and publish datasets
Section titled “Inspect and publish datasets”dn dataset inspect ./datasets/support-promptsdn dataset push ./datasets/support-prompts --publishdn dataset publish support-promptsdn dataset unpublish support-promptsStart with inspect. It is the quickest way to catch schema or split mistakes before you upload
anything.
Inspect or retrieve published datasets
Section titled “Inspect or retrieve published datasets”dn dataset list --include-publicpull is the retrieval path when you want the actual dataset content on disk. Without --output,
it prints a time-limited download URL instead of saving the file for you.
Model commands
Section titled “Model commands”Models add a few lifecycle tools beyond simple publish and list flows, because the registry keeps both immutable model versions and mutable metadata like aliases and metrics.
Publish and inspect models
Section titled “Publish and inspect models”dn model inspect ./models/assistant-loradn model push ./models/assistant-loradn model publish assistant-loradn model unpublish assistant-loraCompare, label, and retrieve models
Section titled “Compare, label, and retrieve models”dn model compare assistant-lora 0.9.0 1.0.0The important conceptual split is:
- model files are immutable versioned artifacts
- aliases and metrics are metadata layered on top
That is why compare, alias, and metrics exist. They help you decide which version should be
used next without rewriting the stored model artifact itself.
Task environment commands
Section titled “Task environment commands”Tasks are runnable environments, not just metadata bundles. That is why the local-first command is
validate, not inspect.
Validate and publish task environments
Section titled “Validate and publish task environments”dn task validate ./tasks --builddn task push ./tasks/kerberoast --publishdn task publish kerberoastdn task unpublish kerberoastvalidate --build is the right first move when you are not sure the local environment bundle is
healthy. It checks the task manifest and can also build the Docker Compose environment locally.
Inspect and retrieve published tasks
Section titled “Inspect and retrieve published tasks”dn task listdn task info kerberoast@latestdn task sync ./tasks --workers 16dn task pull kerberoast@latestdn task validate portswigger-sqli-lab --pulldn task validate portswigger-sqli-lab --pull --smokeUse pull when you want the task files locally for inspection or forking. Use sync when you want
to publish a whole directory of tasks efficiently. Use validate --pull when you want to pull a
published task into a temporary directory and run the local validation flow without starting a real
evaluation. Add --smoke only for remote tasks you trust, because smoke validation may build
containers and run scripts from the task package. In scripts or CI, pass --pull or --yes for
remote task refs so validation never waits for interactive confirmation.
Visibility and publish behavior
Section titled “Visibility and publish behavior”Across artifact families, the same pattern shows up repeatedly:
pushuploads a new versionpublish/unpublishcontrol visibility for the artifact family--publishonpushorsyncis the shortcut when you want the artifact public immediately
--public still exists in a few places as a compatibility alias for --publish.
Local vs remote behavior
Section titled “Local vs remote behavior”dn capability install ./path/to/capabilityis local installationdn capability install org/[email protected]is registry download plus activationdn dataset push,dn model push, anddn task pushcan build locally with--skip-uploaddn capability syncanddn task syncare the bulk-upload commands for monorepos and CI
That split matters because install, push, sync, pull, and download are not
interchangeable.
Practical workflows
Section titled “Practical workflows”Publish a new capability for local and remote use
Section titled “Publish a new capability for local and remote use”dn capability validate ./capabilities/web-recondn capability install ./capabilities/web-recondn capability push ./capabilities/web-recon --publishThis is the normal loop when you are iterating locally first, then publishing the version other workflows should reference.
Publish a dataset and verify the exact version
Section titled “Publish a dataset and verify the exact version”dn dataset inspect ./datasets/support-promptsdn dataset push ./datasets/support-prompts --publishUse the final info call to confirm the exact version string you will pin in optimization or
training.
Validate tasks before using them in evaluations
Section titled “Validate tasks before using them in evaluations”dn task validate ./tasks --builddn task push ./tasks/kerberoast --publishdn task info kerberoast@latestIf the task is going to back an evaluation, validating it before the push is worth the extra step.