Curate

---
name: curate-062e97ac9368
description: "Use when the user wants to create, update, or manage data products, publish or unpublish data products to a marketplace, manage marketplaces, enrich catalog metadata, add descriptions to tables or columns, set tags, set custom field values, check data product standards, manage product versions, or mark a version as ready. Also use for: product spec, product schema, delivery systems, record sets, marketplace badges, minimum standards, set up a new data product, define a product, annotate tables, enrich metadata. Use this skill any time the user mentions data products in a creation or management context, or wants to add/edit metadata on catalog objects. Not for querying data products — use ask. Not for browsing catalog — use explore. Not for creating data source connections — use configure."
---

# Curate

Manage data products, publish to marketplaces, and enrich catalog metadata.

## Routing

| User Intent | CLI Command | When to Use |
|---|---|---|
| Create/update/delete data products | `scripts/run-cli product` | Managing product specs and versions |
| Publish/unpublish to marketplace | `scripts/run-cli marketplace publish/unpublish` | Making products discoverable |
| Manage marketplaces themselves | `scripts/run-cli marketplace` | Creating or configuring marketplaces |
| Add descriptions/tags/custom fields | `scripts/run-cli enrich` | Enriching metadata on any catalog object |

## Not This Skill

- User wants to **query** a data product for answers → use `ask`
- User wants to **browse or search** data sources, the catalog, data products, or marketplaces → use `explore`
- User wants to **schedule** recurring queries against a product → use `automate`
- User wants to **create a data source connection** → use `configure`

Key distinction: `curate` manages data product definitions and metadata. `ask` runs queries against those products. "Create a data product" is `curate`. "Query a data product" is `ask`.

## Data Product Lifecycle

**First, check what you already have.** If a complete or near-complete spec is available (e.g. from `bi product-spec`, a user-provided JSON/YAML file, or a prior conversation step), use it as-is — do not discard its schema, record sets, or delivery systems. Only fall back to the empty-schema workflow when you are building a spec from scratch.

### When a spec is already available

1. **Review the spec** with the user. Confirm product ID, name, record sets, and schema look correct.
2. **Save the spec** as a JSON file (e.g. `spec.json`), then **create the product**:
   `scripts/run-cli product create < spec.json`
   If the spec is in YAML (e.g. from `bi product-spec`), convert it to JSON before saving.
3. Continue to **Mark version ready** and **Publish** below.

### When building from scratch

1. **Create product** with minimal spec (`"schema": []`):
   `scripts/run-cli product create < spec.json`
   See `references/product-schema.md` for the JSON schema.

2. **Discover columns** by querying the product (use the `ask` skill) or browsing the data source (use the `explore` skill).

3. **Update spec** with discovered schema:
   `scripts/run-cli product update < updated_spec.json`

### After creation (both paths)

4. **Mark version ready:**
   `scripts/run-cli product update-version PRODUCT_ID VERSION_ID --status ready`

5. **Publish to marketplace:**
   `scripts/run-cli marketplace publish --marketplace EXTERNAL_MARKETPLACE_ID --product ID`

## Metadata Enrichment

- `scripts/run-cli enrich list-fields` — see available custom fields
- `scripts/run-cli enrich get-values --otype table --oid 123` — see current values
- `scripts/run-cli enrich set-field --otype table --oid 123 --field-id 456 --value "description text"`
- Object types: `table`, `schema`, `attribute` (column), `data` (datasource)

## Common Mistakes

**Mistake:** Trying to publish a product whose version is still in "draft" status.
Why it seems reasonable: the product exists, so it should be publishable.
Instead: Check version status first. Mark it as "ready" before publishing.

**Mistake:** Setting `deliverySystems.type` to uppercase `"SQL"`.
Why it seems reasonable: the `dataAccess[].type` field IS uppercase.
Instead: `deliverySystems.type` must be lowercase `"sql"`. The `dataAccess[].type` must be uppercase `"SQL"`. Yes, this is inconsistent — see `references/product-schema.md`.

**Mistake:** Guessing at data product spec fields or API behavior after an unexpected validation error.
Why it seems reasonable: the error message names the field.
Instead: Check the documented contract via the `docs` skill before guessing.

## Next Steps

After finishing curation, suggest next steps to the user — but don't proceed without
their go-ahead unless their original request already implies it.

- **After creating or updating a data product:** Share the product URL from the CLI response so the user can view it in the Alation UI.
- **After publishing a data product:** "Would you like to query this product? I can do that using the ask skill."
  If the user mentions recurring reports, suggest the **automate** skill to schedule queries.

## Red Flags
- "I'll populate the full schema upfront" — only when building from scratch. If a pre-populated spec was provided, use it as-is.
- "Let me set the product version to ready immediately" — only after the spec is complete and validated.
- "Let me strip the schema and start fresh" — if the spec already has schema/record sets, do not discard them.