DataRobot Skills

View saved version →

---
name: datarobot-agent-assist
description: >-
  Use when the user wants to design, build, code, simulate, or deploy an AI agent (not a predictive
  model) to DataRobot; mentions agent_spec.md, dr-assist, datarobot-agent-assist, dress rehearsal,
  swarm simulation, or the DataRobot agent template; wants to scaffold a LangGraph, CrewAI, LlamaIndex, NAT, or Base
  agent targeting DataRobot; wants to add an MCP server, backend API, or React frontend to a
  DataRobot agent application; or uses the DataRobot CLI (dr) to build or deploy an agentic custom
  application; or wants to harden, stress-test, or battle-test an agent. Covers the full workflow: agent design, agent_spec.md authoring, dress-rehearsal
  simulation via the DataRobot LLM Gateway, adversarial swarm simulation, template-based coding, and deployment.
---

# DataRobot Agent Assist

This skill covers **agent design, coding, battle-testing, and deployment** with an optional **dress-rehearsal simulation** before any code is written.

A first message of `1`–`4` selects the corresponding category. If free text clearly maps to one category (e.g. "I want to build an agent" → Design), state the inference briefly and proceed. If ambiguous, ask which option applies — do not guess.

---

## Workflow Discipline

Follow this skill **sequentially**. These rules apply to every phase — design, coding, deployment, and every referenced checklist.

1. **Section order** — Complete each section and subsection in the order it appears in this file. Do not jump to a later section until the current one is finished.
2. **Reference files** — When this skill says **read and follow** a file under `agent-assist-build/references/`, read that file first, then execute every step in that file in order. Do not substitute a summary, shortcut, or a later menu for steps defined in the reference.
3. **Explicit skips only** — Skip a step only when this skill or the referenced file explicitly says to skip it (e.g. Pre-requisite Check when `<prerequisites_passed>` is true, or Frontend Check when `frontend.type` is already set).
4. **No auto-advance** — Completing one step (e.g. writing the spec, the user saying "move on", or a command succeeding) does not authorize skipping remaining steps. Proceed only when the current section or reference directs you to the next step.
5. **Menus and prompts** — When a section presents a menu or asks a question, wait for the user's reply. Do not assume a default or proceed on your own.
6. **One design gate per turn** — During design, do not combine prompts from different subsections in one message (e.g. do not ask about spec refinement and dress rehearsal in the same turn).

---

## On Activation

Present the four options clearly:

```
Welcome! I help you design, code, battle-test, and deploy AI agents.

What would you like to do?
  1. Design an AI agent     → Describe your idea (optional dress rehearsal before coding)
  2. Code an AI agent       → Load and implement an existing agent_spec.md
  3. Battle-test the agent  → Run adversarial swarm simulation on an implemented agent
  4. Deploy                 → Deploy an implemented agent to DataRobot
```

Show this menu first. After the user selects an option (`1`, `2`, `3`, or `4`), run the **[Pre-requisite Check](#pre-requisite-check)** (once per session) and then the **[Script Path Resolution](#script-path-resolution)**.

- Options **1** and **2** — read and follow [agent-assist-build/references/workspace-resolution.md](agent-assist-build/references/workspace-resolution.md), then proceed to the selected workflow.
- Option **3** — read `agent-assist-simulate/SKILL.md` and jump to **Pre-flight Check** (Pre-requisite Check and Script Path Resolution still apply first).
- Option **4** — skip Workspace Resolution; `<target_dir>` is resolved in the [Pre-deployment Checklist](agent-assist-build/references/pre-deployment-checklist.md) when unset.

---

## Script Path Resolution

Before invoking any helper script, resolve `<skill_s

Preview of the first 4,000 characters. Read full instructions →

Referenced files: 39 — file references are metadata, not package contents.

View saved version →

---
name: datarobot-agent-llm-selection
description: >-
  Use when the user wants to configure LLM integration for a DataRobot agent
  application. This skill helps to change LLM model, switch between the LLM
  integrations the project supports (LLM Gateway, a DataRobot-deployed LLM, an
  external provider, an LLM Blueprint, and any others its config declares), or
  set up provider credentials. The skill reads the project's
  .datarobot/cli/llm.yml for the real options, interviews the user, then runs
  sync_llm_env.py with the chosen values as CLI args to merge into .env.
---

# DataRobot LLM gateway configuration

Configure LLM integration **without hand-editing `.env`**. The skill drives
`sync_llm_env.py` with the user's answers as CLI arguments.

## Resolve script path once per session

`<skill_scripts_dir>` = the `scripts/` subdirectory of the directory containing this `SKILL.md`.

```shell
ls <skill_scripts_dir>/sync_llm_env.py
```

## Hard rules

1. **Never** ask the user to paste API keys or `DATAROBOT_API_TOKEN` in chat
2. **Never** read, copy, echo, or pass `DATAROBOT_API_TOKEN` yourself. The
   token lives in `$XDG_CONFIG_HOME/datarobot/drconfig.yaml` (default
   `~/.config/datarobot/drconfig.yaml`), populated by `dr auth login`, and
   the `dr` CLI reads it internally. Do not run `cat drconfig.yaml`,
   `cat .env`, `env | grep TOKEN`, `echo $DATAROBOT_API_TOKEN`,
   `curl -H "Authorization: Bearer $..."`, or any equivalent one-liner
3. **Never** pass secrets as CLI args to `sync_llm_env.py` or write them to
   tracked files
4. **Never** set provider credentials for an integration whose config section
   doesn't declare them. Let `sync_llm_env.py` decide — it reads the section
   from the project's config
5. Only `sync_llm_env.py` merges LLM keys into `.env` — do not edit `.env` manually
6. Run all commands from **project root**
7. Pressing enter in chat does nothing. Don't tell the user to "press enter to
   accept the default" or "hit return". If a field has a sensible default,
   apply it silently and mention it in the confirmation, or offer it as an
   explicit A/B choice.
8. Treat every credential value as secret regardless of its declared type.
   Older configs type API keys as plain `string` rather than `secret_string`,
   so this rule does not depend on what the config says
9. Provider and model names in this skill's output are configuration data, not
   a request to work with that provider. Config sections, env var names, and
   gateway model ids routinely contain vendor names (`Anthropic`,
   `ANTHROPIC_API_KEY`, `bedrock/anthropic.claude-...`, `azure`, `cohere`).
   **Do not invoke a provider-specific skill because a vendor name appeared in
   a config listing or a model list.** You are wiring up credentials, not
   calling that vendor's API

---

## Presenting choices

Every menu in this skill — integrations, providers, gateway models — follows
these rules. Dropping an option silently produces a config the user never chose.

- **Never use a fixed-slot picker widget.** Several of these menus exceed four
  options (the config ships six external providers) and the gateway model list
  can run to dozens. Pickers cap their choice count, and the overflow gets
  silently dropped. Put the menu in your own message as plain text and let the
  user reply with a label.
- List **every** option the script returned. Count them first; if the config
  declares six providers, show six rows.
- **No catch-all row** — no `Other`, no `Type something`, no `5) something
  else`. The user can always type a value anyway; that row exists only to hide
  options you dropped.
- No `...`, no "and N more", no summarizing, no collapsing similar entries.
- Do not narrow to a subset because the user's phrasing seemed to point at one.
  If they said "LLM gateway" and two options match, list all of them.
- One labelling scheme. Do not letter the options in prose and re-number them
  in the picker.
- Use each `name` exactly as printed. Do not

Preview of the first 4,000 characters. Read full instructions →

Referenced files: 2 — file references are metadata, not package contents.

View saved version →

---
name: datarobot-app-framework-cicd
description: Guidance for setting up CI/CD pipelines for DataRobot application templates using GitLab, GitHub Actions, and Pulumi for infrastructure as code. Use when setting up CI/CD pipelines, configuring deployments, or managing infrastructure for DataRobot application templates.
context-tokens: "~6 000 (SKILL.md) + ~2 000 (scripts/*) + ~400 per examples/* file"
---

# DataRobot Application Templates CI/CD Skill

This skill provides comprehensive guidance for setting up production-grade CI/CD pipelines for DataRobot application templates, including automated testing, review deployments, and continuous delivery.

## Quick Start

**Default behavior:** When a user asks to "set up CI/CD" without specifying a platform or backend, always use the [Simple Path](#simple-path-pulumi-cloud--github-secrets) below — three workflow files, two GitHub Secrets, done. Do not create `infra/scripts/`, do not add CI/CD tasks to `infra/Taskfile.yaml`, do not involve GPG encryption unless the user explicitly asks for it.

Only deviate from the simple path when the user specifies:
- A specific Pulumi state backend (Azure Blob, S3, GCS) → use `scripts/` and see [Implementation Pattern](#implementation-pattern)
- GitLab CI/CD → see [GitLab CI/CD Configuration](#gitlab-cicd-configuration)
- Many secrets to manage → consider GPG approach in `scripts/`

## Simple Path: Pulumi Cloud + GitHub Secrets

For most data scientists and AI engineers, this is all you need. No GPG encryption, no cloud storage account, no extra scripts.

**What to create in the user's repository:**

1. Copy the three workflow files to `.github/workflows/`:

   | Source | Destination | Trigger |
   |--------|-------------|---------|
   | `examples/github-cd-pulumi-cloud.yml` | `.github/workflows/cd.yml` | Automatic — every merge to `main` |
   | `examples/github-deploy-pulumi-cloud.yml` | `.github/workflows/deploy-pr.yml` | Manual — user picks PR branch + enters stack name (e.g. `pr-42`) |
   | `examples/github-destroy-pulumi-cloud.yml` | `.github/workflows/destroy.yml` | Manual — user enters stack name to tear down |

2. Create `.github/workflows/README.md` from `examples/workflows-README.md`. This is the setup guide that tells the user exactly what secrets and variables to add and how.

3. Tell the user to follow the setup guide in `.github/workflows/README.md`.

That's it. Do **not** add anything to `infra/Taskfile.yaml` or create `infra/scripts/` for this path.

**Required GitHub Secrets** (both required — no defaults):

| Name | Kind |
|------|------|
| `DATAROBOT_API_TOKEN` | Secret |
| `PULUMI_ACCESS_TOKEN` | Secret |

**Optional GitHub Variable** (defaults to `ci` if not set):

| Name | Kind | Default |
|------|------|---------|
| `PULUMI_STACK_CI_NAME` | Variable | `ci` |

**When to use the advanced approach (GPG + DIY backends) instead:**
- You have many secrets (GPG encrypts all of `.env` behind a single passphrase — only one GitHub Secret needed)
- Your organization prohibits Pulumi Cloud and requires a self-managed backend (Azure Blob / S3 / GCS)
- You need GitLab CI/CD

The templates and scripts for all of these are in `scripts/` in this skill directory. If the skill has already been propagated to the project's `infra/` directory (common in downstream templates), look in `infra/scripts/` instead. See the [Implementation Pattern](#implementation-pattern) section below for full setup guidance.

| Scenario | Key files in `scripts/` |
|----------|------------------------|
| Azure Blob / S3 / GCS Pulumi backend | `pulumi-setup.sh`, `taskfile-snippets.yaml` |
| GitHub Actions + GPG secrets | `github-deploy.yml`, `github-cd.yml`, `encrypt-secrets.sh`, `setup-github-secrets.sh` |
| GitLab CI/CD | `gitlab-ci.yml`, `setup-gitlab-variables.sh` |

### Adapting the deploy command

The example workflows use `uv run pulumi up --yes` directly. Before copying them, check `infra/Taskfile.yaml` — the project may already wrap the deploy command in a

Preview of the first 4,000 characters. Read full instructions →

Referenced files: 19 — file references are metadata, not package contents.

View saved version →

---
name: datarobot-data-preparation
description: Tools and guidance for data upload, dataset management, data validation, and preparing data for DataRobot projects. Use when uploading datasets, managing data, or validating data for DataRobot.
---

# DataRobot Data Preparation Skill

This skill provides guidance for preparing and managing data in DataRobot, including uploading datasets, validating data quality, and managing dataset versions.

## Quick Start

**Most common use case**: Upload and validate a dataset

1. **Upload dataset**: `upload_dataset(file_path, dataset_name)` to upload data
2. **Validate data**: `validate_dataset(dataset_id)` to check data quality
3. **Check schema**: `get_dataset_schema(dataset_id)` to review structure

**Example**: "Upload sales_data.csv and check if it's ready for training"

## When to use this skill

Use this skill when you need to:
- Upload datasets to DataRobot
- Validate data before project creation
- Manage dataset versions and updates
- Check data quality and completeness
- Prepare data for training or predictions
- Handle data format conversions
- Connect to external data sources

## Key capabilities

### 1. Dataset Upload

- Upload CSV, Parquet, and other file formats
- Connect to databases and data warehouses
- Handle large datasets efficiently
- Manage dataset metadata and descriptions

### 2. Data Validation

- Validate data formats and schemas
- Check for missing values and data quality issues
- Verify column types and formats
- Identify potential data problems

### 3. Dataset Management

- List and search datasets
- Update dataset metadata
- Create dataset versions
- Delete or archive old datasets

### 4. Data Preparation

- Clean and preprocess data
- Handle missing values
- Format data for DataRobot requirements
- Prepare prediction datasets

## Workflow examples

### Example 1: Upload and validate dataset

**User request**: "Upload my sales_data.csv file and check if it's ready for training."

**Agent workflow**:
1. Upload the CSV file to DataRobot
2. Validate the dataset structure and format
3. Check for missing values and data quality issues
4. Verify column types are appropriate
5. Check for potential issues (leakage, formatting)
6. Report validation results and recommendations

### Example 2: Prepare prediction dataset

**User request**: "Prepare a prediction dataset based on the training data structure from project abc123."

**Agent workflow**:
1. Get the training dataset structure from the project
2. Identify required columns and data types
3. Create a template with the same structure
4. Validate the template matches requirements
5. Provide guidance on filling in prediction values

## Using DataRobot SDK

This skill guides you to use the DataRobot Python SDK directly. Install the SDK if needed:

```bash
pip install datarobot
```

### Key SDK Operations

Use these DataRobot SDK methods for data management:

**Dataset Operations**:
- `dr.Dataset.create_from_file(file_path, name)` - Upload dataset
- `dr.Dataset.get(dataset_id)` - Get dataset details
- `dr.Dataset.list()` - List all datasets
- `dataset.row_count` - Get row count
- `dataset.column_count` - Get column count

**Dataset Information**:
- `dataset.name` - Dataset name
- `dataset.id` - Dataset ID
- `dataset.created_at` - Creation timestamp

See the [Common Patterns](#common-patterns) section below for complete examples.

## Helper Scripts

This skill includes executable helper scripts that Claude can run directly:

- `scripts/upload_dataset.py` - Upload a dataset file to DataRobot

**Usage example**:
```bash
# Upload dataset
python scripts/upload_dataset.py sales_data.csv "Sales Data Q4 2024"
```

Claude can run this script directly or use it as reference when writing code.

## Best practices

1. **Data quality**: Clean and validate data before upload
2. **File formats**: Use appropriate formats (CSV for small, Parquet for large)
3. **Naming conventions**: Use clear, descriptive dataset names
4. **Metadata**: A

Preview of the first 4,000 characters. Read full instructions →

Referenced files: 1 — file references are metadata, not package contents.

View saved version →

---
name: datarobot-discover
description: >-
  Use when the user wants to find DataRobot capabilities — skills, MCP servers,
  agents, or platform resources — for a task. Fetches the live DataRobot catalog
  directly so results are always current, regardless of third-party search index
  lag. Also checks the user's own DataRobot instance if DATAROBOT_ENDPOINT is set.
---

# Discover DataRobot Resources

Fetch DataRobot catalog and present matching resources for the user's
task. Covers resource types including Global MCP Server. Bring resources once DataRobot publishes them without skill update.

## Step 1 — Fetch the public catalog

```bash
curl -s https://www.datarobot.com/.well-known/ai-catalog.json
```

Always fetch this. It contains all publicly available DataRobot resources.

## Step 2 — Fetch the instance catalog (if DATAROBOT_ENDPOINT is set)

```bash
curl -s \
  -H "Authorization: Bearer $DATAROBOT_API_TOKEN" \
  "$DATAROBOT_ENDPOINT/.well-known/ai-catalog.json"
```

This surfaces resources specific to the user's DataRobot deployment — org-scoped
MCP servers, deployed agents, private tools. If it returns 404, the instance does
not publish a catalog yet; skip silently and continue with the public catalog only.

## Step 3 — Merge and present

Combine both result sets. Deduplicate by `identifier`. Then present as a numbered
list grouped by resource type:

| `type` value | Label |
|---|---|
| `application/ai-skill` | Skill |
| `application/mcp-server+json` | MCP Server |
| `application/ai-agent+json` | Agent |
| anything else | Resource |

For each entry show: **name**, **type**, **description**, and whether it came from
the public catalog or the user's instance. Relevance to the user's task comes
first — don't just dump the full list alphabetically.

## Step 4 — Install guidance (only when the user asks)

Never install or configure anything automatically. When the user picks a result:

**Skill** — install via the DataRobot skills plugin:
```bash
npx ai-agent-skills install <skill-name>
```
Or point directly to the `url` field from the catalog entry (the SKILL.md file).

**MCP Server** — show the MCP connector config using the `url` from the catalog:
```json
{
  "mcpServers": {
    "datarobot": {
      "url": "<url from catalog entry>"
    }
  }
}
```

**Agent** — show the A2A endpoint from the catalog entry and instruct the user
to connect it via their agent framework's standard mechanism.

**Other** — show the `url` and `description` from the catalog entry and let the
user decide how to proceed.

View saved version →

---
name: datarobot-external-agent-monitoring
description: Instrument any external or existing AI agent with OpenTelemetry to send traces, logs, and metrics to DataRobot for monitoring, observability, and governance. Use when the user says "add tracing/observability/monitoring to my agent", wants to instrument an existing agent project in their IDE, wants to send agent traces, logs, or metrics to DataRobot, or wants to record and replay agent trajectories (Tensile) from DataRobot traces.
---

# DataRobot External Agent Monitoring Skill

This skill helps you instrument any AI agent — regardless of framework or deployment environment — to send OpenTelemetry telemetry (traces, logs, metrics) to DataRobot. It also creates a shell deployment in DataRobot as the telemetry routing target.

## Quick Start

**Most common use case**: Instrument an existing agent project, regardless of whether it was built on DataRobot or elsewhere, with DataRobot monitoring

1. The user invokes the skill from inside their project — typically: "Add tracing to my agent"
2. The skill resolves the target project (current IDE workspace / working directory if no path is given), then detects the framework and any existing OTel setup
3. It resolves a **Use Case** as the telemetry target (asks for the user's Use Case ID, or offers to create one), generates instrumentation code, and wires it in
4. The agent sends traces, logs, and metrics to DataRobot, where they appear under the Use Case's Tracing tab

**Examples**:
- "Add tracing to my agent" (resolves to the current workspace)
- "Instrument my agent in ./my_agent for DataRobot monitoring"

## When to use this skill

Use this skill when an existing DataRobot user has built an agent elsewhere and wants to bring it in for monitoring. Specifically:
- Bring an externally-built (brownfield) agent into DataRobot for monitoring under a Use Case
- Add OpenTelemetry tracing to an agent project
- Send agent traces, logs, and metrics to DataRobot
- Instrument a Google ADK, LangChain, LangGraph, CrewAI, LlamaIndex, PydanticAI, or any Python agent

## Supported Frameworks

| Framework | Detection | OTel Strategy |
|-----------|-----------|---------------|
| Google ADK | `google-adk` in deps or `google.adk` in imports | Lazy trace injection via callback (ADK overwrites TracerProvider) |
| LangChain / LangGraph | `langchain` or `langgraph` in deps/imports | Auto-instrumentor + standard setup |
| CrewAI | `crewai` in deps/imports | Auto-instrumentor + standard setup |
| LlamaIndex | `llama-index` or `llama_index` in deps/imports | Auto-instrumentor + standard setup |
| PydanticAI | `pydantic-ai` or `pydantic_ai` in deps/imports | Standard setup + required `Agent.instrument_all()` (instrumentation is opt-in) |
| Generic Python | None of the above detected | Manual span instrumentation |

## Workflow

Follow these steps in order. Present the plan to the user and wait for approval before executing.

### Step 1: Detect & Analyze

1. Read the project's dependency file (`requirements.txt`, `pyproject.toml`, `setup.py`, `poetry.lock`, or `uv.lock`)
2. Scan Python source files for framework imports
3. Check for existing OTel setup (look for `opentelemetry` imports, existing TracerProvider/LoggerProvider/MeterProvider configuration)
4. Identify the framework using the detection table above
5. Read the corresponding framework reference file from the `frameworks/` directory next to this SKILL.md:
   - Google ADK → `frameworks/google-adk.md`
   - LangChain/LangGraph → `frameworks/langchain-langgraph.md`
   - CrewAI → `frameworks/crewai.md`
   - LlamaIndex → `frameworks/llamaindex.md`
   - PydanticAI → `frameworks/pydantic-ai.md`
   - Generic Python → `frameworks/generic-python.md`

### Step 2: Check Prerequisites

1. Ensure `DATAROBOT_API_TOKEN` is available **without having the user paste it into chat** (a pasted token would be logged in the transcript). Check the environment and the project `.env`. If the token is missing, create or upd

Preview of the first 4,000 characters. Read full instructions →

Referenced files: 10 — file references are metadata, not package contents.

View saved version →

---
name: datarobot-feature-engineering
description: Guidance for feature engineering, feature discovery, feature importance analysis, and understanding DataRobot's automated feature engineering capabilities. Use when working with feature engineering, feature discovery, or analyzing feature importance in DataRobot.
---

# DataRobot Feature Engineering Skill

This skill provides guidance for working with features in DataRobot, including understanding automated feature engineering, analyzing feature importance, and optimizing feature sets.

## Quick Start

**Most common use case**: Analyze feature importance for a model

1. **Get feature importance**: `get_feature_importance(model_id)` to get importance scores
2. **Analyze top features**: Sort by importance and identify key drivers
3. **Export feature list**: `export_feature_list(project_id)` to document features

**Example**: "Show me the top 10 most important features for model xyz123"

## When to use this skill

Use this skill when you need to:
- Understand what features DataRobot creates automatically
- Analyze feature importance for models
- Discover which features drive predictions
- Optimize feature sets for better performance
- Understand feature types and transformations
- Export feature lists and definitions

## Key capabilities

### 1. Feature Discovery

- Understand automated feature engineering in DataRobot
- Review derived features and transformations
- Identify feature types (numeric, categorical, text, date)
- Explore feature relationships and interactions

### 2. Feature Importance Analysis

- Get feature importance scores for models
- Understand which features drive predictions
- Compare feature importance across models
- Identify redundant or low-value features

### 3. Feature Optimization

- Select important features for model performance
- Remove low-importance features to reduce complexity
- Understand feature impact on predictions
- Optimize feature sets for deployment

### 4. Feature Documentation

- Export feature lists and definitions
- Document feature transformations
- Understand feature derivation logic
- Share feature information with stakeholders

## Workflow examples

### Example 1: Analyze feature importance

**User request**: "Show me the top 10 most important features for model xyz123 and explain what they mean."

**Agent workflow**:
1. Get feature importance scores for the model
2. Sort features by importance (descending)
3. Get top 10 features with their scores
4. Retrieve feature metadata and descriptions
5. Explain what each feature represents and why it's important
6. Provide insights on feature relationships

### Example 2: Optimize feature set for deployment

**User request**: "Create a simplified feature set for deployment abc123, keeping only features with importance > 0.1."

**Agent workflow**:
1. Get feature importance for the deployed model
2. Filter features by importance threshold (> 0.1)
3. Verify filtered features are sufficient for predictions
4. Document the optimized feature set
5. Update deployment configuration if needed

## Using DataRobot SDK

This skill guides you to use the DataRobot Python SDK directly. Install the SDK if needed:

```bash
pip install datarobot
```

### Key SDK Operations

Use these DataRobot SDK methods for feature analysis:

**Feature Information**:
- `model.get_features()` - List all features in a model
- `model.get_feature_impact()` - Get feature importance scores
- `project.get_features()` - List features in a project

**Feature Analysis**:
- `feature.name` - Feature name
- `feature.feature_type` - Feature type (Numeric, Categorical, etc.)
- `feature.importance` - Feature importance score

See the [Common Patterns](#common-patterns) section below for complete examples.

## Best practices

1. **Review automated features**: DataRobot creates many derived features automatically - review them
2. **Focus on important features**: Pay attention to high-importance features for insights
3. **Understand feat

Preview of the first 4,000 characters. Read full instructions →

View saved version →

---
name: datarobot-model-deployment
description: Tools and guidance for deploying DataRobot models, managing deployments, configuring prediction environments, and deployment operations. Use when deploying models, creating or updating deployments, or configuring prediction environments.
---

# DataRobot Model Deployment Skill

This skill provides comprehensive guidance for deploying models, managing deployment configurations, and operating production deployments.

## Quick Start

**Most common use case**: Deploy a trained model to production

1. **Get best model**: Find the best model from a project (highest metric score)
2. **Create deployment**: `create_deployment(model_id, deployment_name)` to deploy model
3. **Get endpoint**: `get_deployment_endpoint(deployment_id)` to retrieve prediction URL

**Example**: "Deploy the best model from project abc123 as 'Sales Prediction v1'"

## When to use this skill

Use this skill when you need to:
- Deploy trained models to production
- Configure deployment settings and environments
- Manage multiple deployments
- Replace a deployment’s champion model with a new model version
- Configure prediction servers and environments
- Monitor deployment health and status
- Manage deployment access and permissions

## Key capabilities

### 1. Deployment Creation

- Deploy models from projects or registered models
- Choose prediction environment (DataRobot Serverless, external)
- Configure deployment settings (challenger models, A/B testing)
- Set up deployment metadata and descriptions

### 2. Deployment Configuration

- Configure prediction servers and environments
- Set up batch prediction settings
- Configure real-time prediction endpoints
- Manage deployment credentials and access

### 3. Deployment Management

- Replace deployment champion model (model swap)
- Enable/disable deployments
- Manage challenger models for A/B testing
- Configure replacement policies

### 4. Deployment Operations

- Get deployment information and status
- Retrieve deployment endpoints
- Manage deployment settings
- Handle deployment errors and issues

## Workflow examples

### Example 1: Deploy a model to production

**User request**: "Deploy the best model from project abc123 to production with the name 'Sales Prediction v1'."

**Agent workflow**:
1. Get the best model from the project (highest metric score)
2. Create a new deployment with the model
3. Configure deployment settings (name, description, environment)
4. Set up prediction environment (DataRobot Serverless recommended)
5. Retrieve deployment endpoint and credentials
6. Verify deployment is active and ready for predictions

### Example 2: Update deployment with new model

**User request**: "Replace the model in deployment xyz789 with the latest model from project abc123."

**Agent workflow**:
1. Get the latest model from the project
2. Retrieve current deployment information
3. Validate the replacement model is eligible (`deployment.validate_replacement_model(...)`)
4. Perform model replacement (`deployment.perform_model_replace(...)`)
5. Verify replacement completed successfully
6. Report deployment update status

## Using DataRobot SDK

This skill guides you to use the DataRobot Python SDK directly. Install the SDK if needed:

```bash
pip install datarobot
```

### Key SDK Operations

Use these DataRobot SDK methods for deployment management:

**Deployments**:
- `dr.Deployment.create_from_learning_model(model_id, label)` - Create deployment
- `dr.Deployment.get(deployment_id)` - Get deployment details
- `dr.Deployment.list(project_id)` - List deployments
- `deployment.delete()` - Delete deployment

**Model Replacement (champion swap)**:
- `deployment.validate_replacement_model(new_model_id=...)` - Validate replacement eligibility
- `deployment.perform_model_replace(new_model_id=..., reason=...)` - Replace champion model (async)

**Challenger Models (limited via SDK)**:
- `deployment.list_challengers()` - List challenger models (if enabled/configured)

Preview of the first 4,000 characters. Read full instructions →

View saved version →

---
name: datarobot-model-explainability
description: >
  Tools and guidance for model explainability, prediction explanations, feature impact analysis,
  SHAP values, SHAP distributions, anomaly assessment, and model diagnostics. Use when analyzing
  model explanations, feature impact, SHAP values, SHAP distributions, anomaly assessment, or
  diagnosing model behavior.
---

# DataRobot Model Explainability Skill

This skill covers SHAP insights, XEMP prediction explanations, anomaly explanations, and model diagnostics.

> **SDK version**: Use `datarobot>=3.6.0` for the full API set in this skill (`ShapDistributions`
> was added in 3.6; `ShapMatrix`, `ShapImpact`, and `ShapPreview` are available in
> `datarobot>=3.4.0`). Use `from datarobot.insights import ShapMatrix, ...` with
> `entity_id=model_id` — not legacy `datarobot.models.ShapMatrix` (`project_id` / `dataset_id`).
> `ShapMatrix`, `ShapImpact`, `ShapPreview`, and `ShapDistributions` are the canonical SHAP API.
> The older `dr.PredictionExplanations` (XEMP-based) remains available but is the secondary path.

---

## Quick Start

| Goal | API to use | Prerequisites |
|------|-----------|---------------|
| SHAP values for all features, all rows | `ShapMatrix.create(entity_id=model_id)` | None - universal SHAP |
| Per-row top-feature explanations | `ShapPreview.create(entity_id=model_id)` | None |
| Aggregated feature importance via SHAP | `ShapImpact.create(entity_id=model_id)` | None |
| SHAP value distributions across features | `ShapDistributions.create(entity_id=model_id)` | None |
| SHAP for a filtered segment | `dr.DataSlice.create(...)` + `ShapMatrix.create(..., data_slice_id=...)` | Data slice definition |
| XEMP-based prediction explanations | `dr.PredictionExplanations.create(...)` | Feature Impact; PE initialization; dataset uploaded |
| Anomaly explanations (time series) | `AnomalyAssessmentRecord.compute(project_id, model_id, ...)` | Anomaly model |
| ROC / lift / confusion (insights) | `RocCurve.create(...)` / `LiftChart.create(...)` / `ConfusionMatrix.create(...)` | Validation data |
| ROC / lift / confusion (Model helpers) | `model.get_roc_curve()` / `model.get_lift_chart()` / `model.get_confusion_chart()` | Validation data |

**Universal SHAP is the preferred path** - no dataset pre-upload or Feature Impact step required.

## When to use this skill

Use this skill when you need to explain leaderboard model behavior, compute SHAP insights, use
XEMP prediction explanations, analyze anomaly explanations, or retrieve model diagnostics.

## Key capabilities

### 1. SHAP insights

- Compute `ShapMatrix`, `ShapPreview`, `ShapImpact`, and `ShapDistributions`
- Filter insights with `dr.DataSlice`

### 2. XEMP and anomaly explanations

- Use XEMP `dr.PredictionExplanations` when specifically required
- Retrieve time series anomaly assessment records and explanations

### 3. Diagnostics

- Retrieve ROC, lift, and confusion insights
- Use Model helpers for ROC, lift, confusion, and feature effects

## Setup

```python
import datarobot as dr
from datarobot.insights import ShapMatrix, ShapImpact, ShapPreview, ShapDistributions

dr.Client()
```

---

## Core API: `datarobot.insights`

```python
import pandas as pd
from datarobot.insights import ShapMatrix, ShapImpact, ShapPreview, ShapDistributions

model_id = "YOUR_MODEL_ID"

matrix = ShapMatrix.create(entity_id=model_id)
df = pd.DataFrame(matrix.matrix, columns=matrix.columns)

impact = ShapImpact.create(entity_id=model_id)
preview = ShapPreview.create(entity_id=model_id)
distributions = ShapDistributions.create(entity_id=model_id)
```

Use `ShapMatrix` for full row-by-feature SHAP values, `ShapPreview` for compact top-driver rows,
`ShapImpact` for aggregated SHAP importance, and `ShapDistributions` for per-feature SHAP
distributions. Use `source="externalTestSet"` plus `external_dataset_id` for external datasets.
See `references/shap_api_reference.md` for parameters, exports, and limitations.

---

## Secondary path:

Preview of the first 4,000 characters. Read full instructions →

Referenced files: 3 — file references are metadata, not package contents.

View saved version →

---
name: datarobot-model-monitoring
description: Tools and guidance for monitoring model performance, tracking data drift, managing model health, and detecting prediction anomalies. Use when monitoring deployed models, tracking drift, or investigating prediction anomalies.
---

# DataRobot Model Monitoring Skill

This skill provides comprehensive guidance for monitoring deployed models, tracking performance metrics, detecting data drift, and managing model health.

## Quick Start

**Most common use case**: Check deployment health and data drift

1. **Check service stats**: `deployment.get_service_stats(...)` to review prediction volume/latency
2. **Check drift**: `deployment.get_feature_drift(...)` / `deployment.get_target_drift(...)`
3. **Compare over time**: Use `get_service_stats_over_time(...)` and drift periods to assess trends

**Example**: "Check the health of deployment abc123 and report any data drift issues"

## When to use this skill

Use this skill when you need to:
- Monitor model performance in production
- Track data drift and feature drift
- Detect prediction anomalies
- Monitor prediction accuracy over time
- Set up alerts for model degradation
- Analyze model health metrics
- Compare production performance to training performance

## Key capabilities

### 1. Performance Monitoring

- Track prediction accuracy and metrics over time
- Compare production metrics to training metrics
- Monitor prediction volume and latency
- Identify performance degradation trends

### 2. Data Drift Detection

- Detect changes in feature distributions
- Identify feature drift (statistical changes)
- Monitor target drift (if actuals available)
- Alert on significant drift events

### 3. Prediction Monitoring

- Monitor prediction distributions
- Detect prediction anomalies
- Track prediction confidence scores
- Identify unusual prediction patterns

### 4. Health Management

- Assess overall model health
- Generate monitoring reports
- Set up automated alerts
- Manage model retraining triggers

## Workflow examples

### Example 1: Check model health and drift

**User request**: "Check the health of deployment abc123 and report any data drift issues."

**Agent workflow**:
1. Get deployment monitoring status
2. Retrieve recent performance metrics
3. Check for data drift in key features
4. Compare current metrics to baseline (training)
5. Identify any significant drift or degradation
6. Report findings with recommendations

### Example 2: Set up drift monitoring alerts

**User request**: "Set up alerts for deployment xyz789 to notify when feature drift exceeds 0.2."

**Agent workflow**:
1. Get deployment configuration
2. Configure drift threshold (0.2)
3. Set up alert notifications
4. Specify which features to monitor
5. Test alert configuration
6. Confirm monitoring is active

## Using DataRobot SDK

This skill guides you to use the DataRobot Python SDK directly. Install the SDK if needed:

```bash
pip install datarobot
```

### Key SDK Operations

Use these DataRobot SDK and MLOps API methods for monitoring:

**Deployment Monitoring**:
- `deployment.get_service_stats(...)` - Get service statistics (latency, volume, etc.)
- `deployment.get_feature_drift(...)` - Get feature drift metrics (returns `FeatureDrift` objects)
- `deployment.get_target_drift(...)` - Get target drift metrics (returns `TargetDrift`)
- `deployment.get_prediction_results(...)` - Retrieve recorded prediction results (if enabled)

**Model Performance**:
- `model.metrics` - Model performance metrics (dict of `{metric: {partition: score}}`)
- `model.get_roc_curve()` - Get ROC curve for comparison

**Note**: Some monitoring features may require DataRobot MLOps API. See the [Common Patterns](#common-patterns) section below for examples.

## Best practices

1. **Regular monitoring**: Check model health regularly, not just when issues arise
2. **Baseline comparison**: Always compare production metrics to training baseline
3. **Drift thresholds**: Set appropriate drift th

Preview of the first 4,000 characters. Read full instructions →

View saved version →

---
name: datarobot-model-training
description: Comprehensive guidance for training models in DataRobot, including project creation, AutoML configuration, feature engineering, and model selection. Use when training models, creating AutoML projects, or selecting models in DataRobot.
---

# DataRobot Model Training Skill

This skill provides guidance for the complete model training workflow in DataRobot, from project creation through model selection and validation.

## Quick Start

**Most common use case**: Create a project and train models

1. **Create or reuse a Use Case**: ask the user if they have an existing Use Case ID to reuse (`dr.UseCase.get(use_case_id)`); otherwise create a new one (`dr.UseCase.create(name)`). Every project needs one linked in Workbench
2. **Upload dataset**: `upload_dataset(file_path, dataset_name, use_case_id)` to upload training data, associated with the Use Case
3. **Create project**: `create_project(dataset_id, project_name, target_column, use_case_id)` to create new project, associated with the same Use Case
4. **Start training**: `start_automl(project_id, mode)` to begin AutoML training

**Example**: "Create a new project under a 'Sales Forecasting' Use Case with sales_data.csv, set 'revenue' as target, and start Quick AutoML training"

## When to use this skill

Use this skill when you need to:
- Create new DataRobot projects
- Upload training datasets
- Configure AutoML experiments
- Monitor training progress
- Select and compare models
- Understand feature engineering results
- Export trained models

## Key capabilities

### 1. Project Management

- Create new projects with appropriate settings
- Upload datasets (CSV, Parquet, database connections)
- Configure project settings (target, partitioning, time series)
- Manage multiple projects and experiments

### 2. AutoML Configuration

- Set training modes (Quick, Manual, Comprehensive)
- Configure feature engineering options
- Set time limits and resource constraints
- Choose algorithms and model types

### 3. Training Execution

- Start AutoML training runs
- Monitor training progress
- Handle training errors and warnings
- Pause/resume training if needed

### 4. Model Analysis

- Compare model performance metrics
- Review feature importance
- Analyze model insights and explanations
- Select best models for deployment

## Workflow examples

### Example 1: Create and train a new project

**User request**: "Create a new project using my sales_data.csv file, predict 'revenue' as the target, and start AutoML training."

**Agent workflow**:
1. Upload the dataset to DataRobot
2. Create a new project with the dataset
3. Set 'revenue' as the target variable
4. Configure project settings (detect partitioning, handle time series if needed)
5. Start AutoML training with appropriate mode
6. Monitor training progress
7. Report when training completes with top model metrics

### Example 2: Configure advanced training options

**User request**: "Train a model with time series settings: datetime column 'date', series ID 'store_id', forecast window 1-7 days."

**Agent workflow**:
1. Create project with time series configuration
2. Set datetime column and series ID columns
3. Configure forecast window (1-7 days)
4. Set appropriate time series validation
5. Start training with time series-aware algorithms
6. Monitor progress and report results

## Using DataRobot SDK

This skill guides you to use the DataRobot Python SDK directly. Install the SDK if needed:

```bash
pip install datarobot
```

### Key SDK Operations

Use these DataRobot SDK methods for model training:

**Use Cases** (organize related datasets/projects/deployments under one entity):
- `dr.UseCase.create(name, description=None)` - Create a new Use Case
- `dr.UseCase.get(use_case_id)` - Retrieve an existing Use Case (reuse instead of creating a new one)
- `use_case.add(entity=project_or_dataset)` - Attach an already-created project or dataset to a Use Case

**Projects**:
- `dr.Project.create_from_

Preview of the first 4,000 characters. Read full instructions →

Referenced files: 3 — file references are metadata, not package contents.

View saved version →

---
name: datarobot-predictions
description: Tools and guidance for making predictions with DataRobot deployments, including real-time predictions, batch scoring, prediction dataset generation, and prediction explanations (SHAP/XEMP). Use when making predictions, running batch scoring, generating prediction datasets, or explaining individual predictions from a deployment.
---

# DataRobot Predictions Skill

This skill provides comprehensive guidance for working with DataRobot predictions, including real-time predictions, batch scoring, and generating prediction datasets.

## Quick Start

**Most common use case**: Generate predictions for a deployment

1. **Get deployment features**: `get_deployment_features(deployment_id)` to understand required columns
2. **Generate template**: `generate_prediction_data_template(deployment_id, n_rows)` to create CSV structure
3. **Make predictions**: Use `deployment.predict_batch(...)` (works for both single-row “real-time” and batch scoring)

**Example**: "Generate a prediction dataset template for deployment abc123 with 10 rows"

**To also explain predictions**: pass `--max-explanations N` to `make_prediction.py` (or the
`max_explanations=N` kwarg in code). See [Prediction Explanations](#prediction-explanations) below.

## When to use this skill

Use this skill when you need to:
- Make predictions from deployed DataRobot models
- Explain individual predictions from a deployment (SHAP or XEMP, per-row)
- Generate prediction dataset templates
- Validate prediction data before scoring
- Understand deployment feature requirements
- Perform batch predictions on large datasets
- Get sample training data to understand expected formats

> For post-hoc explanations against a **training project / leaderboard model** (not a deployment),
> use the `datarobot-model-explainability` skill instead. This skill covers deployment-time
> explanations returned alongside scoring.

## Key capabilities

### 1. Understanding Deployment Requirements

Before making predictions, you need to understand what features a deployment requires:

- **Feature names and types**: Know which columns are needed (numeric, categorical, text, date)
- **Feature importance**: Understand which features matter most
- **Target information**: Know what you're predicting
- **Time series configuration**: If applicable, understand datetime columns and series IDs

### 2. Generating Prediction Datasets

Create properly formatted prediction datasets:

- Generate CSV templates with all required columns
- Include sample values appropriate for each feature type
- Add metadata comments explaining the model structure
- Ensure correct column ordering

### 3. Validating Prediction Data

Validate datasets before making predictions:

- Check for missing required features
- Verify data types match expected types
- Identify missing low-importance features (warnings)
- Note extra columns that will be ignored

### 4. Making Predictions

Execute predictions using various methods:

- **Real-time predictions**: Fast, synchronous predictions for individual records
- **Batch predictions**: Process large datasets efficiently
- **Time series predictions**: Handle forecasting scenarios with proper datetime handling

## Workflow examples

### Example 1: Generate prediction dataset for a new scenario

**User request**: "I want to predict sales for next week for store_A with temperatures of 75°F each day and no promotions."

**Agent workflow**:
1. Get deployment features to understand required columns
2. Generate a prediction data template with 7 rows (one week)
3. Fill in the template with user's specific values:
   - Set temperature = 75 for all rows
   - Set promotion = 0 for all rows
   - Set store_id = "store_A" for all rows
   - Set dates for next 7 days
4. Validate the data to ensure it's correct
5. Make predictions using the validated dataset

### Example 2: Batch scoring a CSV file

**User request**: "Score all records in my prediction_data.csv file using depl

Preview of the first 4,000 characters. Read full instructions →

Referenced files: 4 — file references are metadata, not package contents.

View saved version →

---
name: datarobot-setup
description: Sets up DataRobot for local development including Python SDK, dr-cli, Agent Assist, and all required dependencies. Use when the user has not yet worked with DataRobot on this machine, OR when any DataRobot task fails due to missing or invalid credentials. Covers first-time setup, re-authentication, and credential recovery.
---

# DataRobot Local Development Setup

You are helping set up DataRobot for local development. Before installing anything, audit what is already present and only install what is missing. Follow these steps in order.

## Step 1: Pre-Flight Check (Detect Existing Installation)

Build a checklist of what is already installed before doing any installation work. Run each check and record the result. Skip any install step in Steps 3-7 whose check below already passes.

```bash
# Required tools — record version for each, or "missing"
command -v python3   && python3 --version
command -v git       && git --version
command -v uv        && uv --version
command -v dr        && dr --version
command -v pulumi    && pulumi version
command -v task      && task --version
command -v node      && node --version
command -v pip       && pip --version

# DataRobot CLI plugins (only meaningful if `dr` exists)
dr plugin list 2>/dev/null | grep -i assist

# Python SDK (in the user's active environment)
python3 -c "import datarobot; print(datarobot.__version__)" 2>/dev/null
python3 -c "import datarobot_predict; print('datarobot-predict installed')" 2>/dev/null

# Credential state
echo "DATAROBOT_API_TOKEN: ${DATAROBOT_API_TOKEN:+set (via env)}"
echo "DATAROBOT_ENDPOINT:  ${DATAROBOT_ENDPOINT:-not set}"
test -f ~/.config/datarobot/drconfig.yaml && echo "drconfig: found" || echo "drconfig: missing"

# If drconfig exists, verify credentials are actually valid
if test -f ~/.config/datarobot/drconfig.yaml; then
  dr auth check 2>/dev/null && echo "auth: valid" || echo "auth: INVALID (re-authentication required)"
fi
```

Compare each detected version to the minimums in the table in Step 3. Tell the user:
- What is already installed and at acceptable versions (skip)
- What is missing or below minimum version (install)
- Whether dr-cli is already authenticated (skip Step 6 if so, but confirm with user)

Only proceed past this step after presenting the diff to the user so they can confirm.

## Step 2: Detect Operating System

Detect the OS and tailor commands accordingly.

### Windows Users: WSL Required

**IMPORTANT**: DataRobot Agent Assist does NOT support native Windows. You MUST use WSL (Windows Subsystem for Linux).

#### Check if Running in WSL

```bash
uname -r | grep -i microsoft         # Returns output if in WSL
cat /proc/version | grep -i microsoft # Alternative
echo $WSL_DISTRO_NAME                 # Empty if not in WSL
```

#### If NOT in WSL

1. **Install WSL 2** (Windows 10/11). Open PowerShell as Administrator and run `wsl --install`, then restart when prompted. Default Ubuntu will be installed.
2. **Alternative manual install**: `wsl --install -d Ubuntu-22.04` from elevated PowerShell.
3. **Set up Ubuntu**: launch Ubuntu from the Start menu, create a username and password, then run `sudo apt update && sudo apt upgrade -y`.
4. **Return here**: once in WSL, re-run this skill from the Ubuntu terminal.

#### Supported Environments

- macOS — Homebrew install path
- Linux — distribution-specific installers
- WSL — Linux installers
- Native Windows — NOT supported; use WSL

## Step 3: Install Missing Core Dependencies

Only install the tools flagged as missing in Step 1.

| Tool | Minimum Version | Purpose |
|------|-----------------|---------|
| Python | 3.10+ | DataRobot SDK and Agent Assist |
| git | 2.30.0+ | Version control |
| uv | 0.9.0+ | Python package manager |
| dr-cli | 0.2.50+ | DataRobot CLI |
| Pulumi | 3.163.0+ | Infrastructure as Code |
| go-task | 3.43.3+ | Task runner |
| Node.js | 24+ | JavaScript runtime |

### macOS (Homebrew)

```bash
brew install datarobot-oss/taps/

Preview of the first 4,000 characters. Read full instructions →

View saved version →

---
name: datarobot-workload-api
description: >-
  Use when the user wants to create, configure, scale, debug, observe, or roll
  out container workloads on DataRobot's Workload API. Triggers: deploy a
  container as a managed service; list/start/stop workloads; change replica
  counts or autoscaling; pick CPU/GPU compute bundles; inject DataRobot
  credentials as env vars; diagnose stuck/errored/crash-looping workloads
  (CrashLoopBackOff, ImagePullBackOff, OOMKilled, probe failures, exec format
  error); pull application logs/OpenTelemetry traces/metrics/request stats;
  create or iterate container artifacts; build images server-side; lock
  artifacts for production; zero-downtime rolling artifact replacement.
---

# DataRobot Workload API

Runs containers as managed, autoscalable DataRobot services. Four jobs — pick by intent:

1. **Create / configure / scale** — deploy a container; change replicas, resources, autoscaling, bundle; inject credentials
2. **Diagnose** — workload stuck, errored, or crash-looping
3. **Observe** — logs, traces, metrics, service stats for a running workload
4. **Artifact lifecycle** — iterate drafts, build images, lock for production, roll out new versions

## Prerequisites

Auth: like `gh`. `dr auth login` (or existing `.env`/`~/.config/datarobot/drconfig.yaml`) persists credentials — no per-run env vars needed. Verify with `dr auth check`. On failure, run `datarobot-setup`.

**Keep the CLI current** (like `datarobot-agent-assist`): `dr self update --force`. Never gate on a pinned version. If a subcommand still errors `unknown command` after update (seen with `config`/`up` — `references/declarative-cli-deploy.md`), use the raw-REST fallback below.

`DATAROBOT_ENDPOINT` (must end `/api/v2`) and `DATAROBOT_API_TOKEN`: required as env vars only for raw REST (`scripts/`, `httpx`/`curl`) or CI — these bypass CLI auth. Header: `Authorization: Bearer ${DATAROBOT_API_TOKEN}`. Not in the `datarobot` Python SDK — call REST directly.

**Transport:** examples use Python `httpx` (`pip install httpx`); `curl` or the `pulumi-datarobot` provider work too.

## Bundled scripts

Python in `scripts/`. Each uses `httpx`, reads `DATAROBOT_ENDPOINT` + `DATAROBOT_API_TOKEN`:

- `wait_for_running.py <workload_id>` — poll until `running`; exit 2 on terminal failure, 3 on timeout
- `diagnose_workload.py <workload_id>` — run the 5-step debug flow, print a diagnosis (`--json` for machine output)
- `wait_for_build.py <artifact_id> <build_id>` — poll a server-side image build; dumps last 2KB of logs on `FAILED`
- `wait_for_replacement.py <workload_id>` — poll a rolling replacement; handles the 404-when-cleared case
- `check_limits.py` — print effective org scaling limits via `/account/info/`

## Deeper docs in references/

In `references/`:

- `status-vocabulary.md` — status enums and transitions
- `common-error-patterns.md` — CrashLoopBackOff / ImagePullBackOff / OOMKilled / probe / exec-format
- `schema-reference.md` — schemas, credential-type→key maps, spec quirks
- `lifecycle-flows.md` — draft→lock→prod rules, replacement preconditions, redeploy matrix
- `code-to-workload.md` — deploy from source: `dr` CLI, `codeRef`, Execution Environments
- `declarative-cli-deploy.md` — `dr workload config`/`up`: one-command create/build/deploy
- `web-uis-behind-the-edge.md` — web UI through the endpoint: prefix, auth gate, CSRF, WebSockets

## OpenAPI spec is source of truth

At `${DATAROBOT_ENDPOINT}/openapi.yaml` (some instances omit Workload API paths — see `references/schema-reference.md`). **~5 MB — never dump whole.** Save once, slice with `yq` (or `print()` one key in Python):

```bash
curl -sS "${DATAROBOT_ENDPOINT}/openapi.yaml" -o /tmp/wapi-spec.yaml
yq '.components.schemas.CreateWorkloadRequest' /tmp/wapi-spec.yaml
```

Workload paths key with `/api/v2/` — see `references/schema-reference.md`.

---

# 1. Create / configure / scale

## Deploy a container (common case)

```yaml
# spec.yaml — JSON also accepted; spec is sent ver

Preview of the first 4,000 characters. Read full instructions →

Referenced files: 12 — file references are metadata, not package contents.