@metabase/cli 0.1.15 → 0.1.16

package/dist/{update-DR4WkAET.mjs → update-BIZ9XhjS.mjs}

@@ -1,14 +1,14 @@
 import "./command-augment-CAur0XOQ.mjs";
-import { connectionFlags, outputFlags, profileFlag } from "./error-D5bZ5BUX.mjs";
-import { defineMetabaseCommand } from "./runtime-C1QgWHM7.mjs";
+import { connectionFlags, outputFlags, profileFlag } from "./error-CIObEXLY.mjs";
+import { defineMetabaseCommand } from "./runtime-CmAIahm5.mjs";
 import { renderSummary } from "./capabilities-BX1rnVuH.mjs";
 import "./input-BXWgdKiS.mjs";
-import { parseId } from "./parse-id-DNPeV0Iu.mjs";
-import { readBody } from "./body-B9XTTDEu.mjs";
+import { parseId } from "./parse-id-B5adfBlS.mjs";
+import { readBody } from "./body-DB2upz6a.mjs";
 import { bodyInputFlags } from "./body-flags-D7q87Btw.mjs";
 import "./validate-VawhJ5Sc.mjs";
 import { SEGMENT_DEFINITION_LABELS, preflightMbql5Query, skipValidateFlag } from "./validate-query-CSV-TTnd.mjs";
-import { Segment, SegmentUpdateInput, segmentView } from "./segment-B9SEv9V_.mjs";
+import { Segment, SegmentUpdateInput, segmentView } from "./segment-BAUuELKs.mjs";
 
 //#region src/commands/segment/update.ts
 var update_default = defineMetabaseCommand({

package/dist/{update-nwXgVNQa.mjs → update-C0pFSc1B.mjs}

@@ -1,15 +1,15 @@
 import "./command-augment-CAur0XOQ.mjs";
-import { connectionFlags, outputFlags, profileFlag } from "./error-D5bZ5BUX.mjs";
-import { defineMetabaseCommand } from "./runtime-C1QgWHM7.mjs";
+import { connectionFlags, outputFlags, profileFlag } from "./error-CIObEXLY.mjs";
+import { defineMetabaseCommand } from "./runtime-CmAIahm5.mjs";
 import { renderSummary } from "./capabilities-BX1rnVuH.mjs";
 import "./input-BXWgdKiS.mjs";
-import { parseId } from "./parse-id-DNPeV0Iu.mjs";
-import { readBody } from "./body-B9XTTDEu.mjs";
+import { parseId } from "./parse-id-B5adfBlS.mjs";
+import { readBody } from "./body-DB2upz6a.mjs";
 import { bodyInputFlags } from "./body-flags-D7q87Btw.mjs";
 import "./validate-VawhJ5Sc.mjs";
 import { TRANSFORM_SOURCE_QUERY_LABELS, preflightMbql5Query, skipValidateFlag } from "./validate-query-CSV-TTnd.mjs";
-import { Transform, TransformUpdateInput, transformView } from "./transform-n376akp8.mjs";
-import { enrichTransformCollectionError } from "./collection-namespace-D8ohM5gD.mjs";
+import { Transform, TransformUpdateInput, transformView } from "./transform-MmqHKGU-.mjs";
+import { enrichTransformCollectionError } from "./collection-namespace-CUDPh2rF.mjs";
 
 //#region src/commands/transform/update.ts
 var update_default = defineMetabaseCommand({

package/dist/{update-DoQpy9SA.mjs → update-CcvDVqNd.mjs}

@@ -1,11 +1,11 @@
 import "./command-augment-CAur0XOQ.mjs";
-import { connectionFlags, outputFlags, profileFlag } from "./error-D5bZ5BUX.mjs";
-import { defineMetabaseCommand } from "./runtime-C1QgWHM7.mjs";
+import { connectionFlags, outputFlags, profileFlag } from "./error-CIObEXLY.mjs";
+import { defineMetabaseCommand } from "./runtime-CmAIahm5.mjs";
 import { renderSummary } from "./capabilities-BX1rnVuH.mjs";
 import "./input-BXWgdKiS.mjs";
 import { Field, FieldUpdateInput, fieldView } from "./field-E0IBy4Uw.mjs";
-import { parseId } from "./parse-id-DNPeV0Iu.mjs";
-import { readBody } from "./body-B9XTTDEu.mjs";
+import { parseId } from "./parse-id-B5adfBlS.mjs";
+import { readBody } from "./body-DB2upz6a.mjs";
 import { bodyInputFlags } from "./body-flags-D7q87Btw.mjs";
 
 //#region src/commands/field/update.ts

package/dist/{update-BuypOaXq.mjs → update-CiWPEqQ-.mjs}

@@ -1,12 +1,12 @@
 import "./command-augment-CAur0XOQ.mjs";
-import { connectionFlags, outputFlags, profileFlag } from "./error-D5bZ5BUX.mjs";
-import { defineMetabaseCommand } from "./runtime-C1QgWHM7.mjs";
+import { connectionFlags, outputFlags, profileFlag } from "./error-CIObEXLY.mjs";
+import { defineMetabaseCommand } from "./runtime-CmAIahm5.mjs";
 import { renderSummary } from "./capabilities-BX1rnVuH.mjs";
 import "./input-BXWgdKiS.mjs";
-import { parseId } from "./parse-id-DNPeV0Iu.mjs";
-import { readBody } from "./body-B9XTTDEu.mjs";
+import { parseId } from "./parse-id-B5adfBlS.mjs";
+import { readBody } from "./body-DB2upz6a.mjs";
 import { bodyInputFlags } from "./body-flags-D7q87Btw.mjs";
-import { Snippet, SnippetUpdateInput, snippetView } from "./snippet-NNzqlksR.mjs";
+import { Snippet, SnippetUpdateInput, snippetView } from "./snippet-D4SyVLKB.mjs";
 
 //#region src/commands/snippet/update.ts
 var update_default = defineMetabaseCommand({

package/dist/{update-CgQOSuZt.mjs → update-D5gioyBa.mjs}

@@ -1,10 +1,10 @@
 import "./command-augment-CAur0XOQ.mjs";
-import { connectionFlags, outputFlags, profileFlag } from "./error-D5bZ5BUX.mjs";
-import { defineMetabaseCommand } from "./runtime-C1QgWHM7.mjs";
+import { connectionFlags, outputFlags, profileFlag } from "./error-CIObEXLY.mjs";
+import { defineMetabaseCommand } from "./runtime-CmAIahm5.mjs";
 import { renderSummary } from "./capabilities-BX1rnVuH.mjs";
 import "./input-BXWgdKiS.mjs";
-import { parseId } from "./parse-id-DNPeV0Iu.mjs";
-import { readBody } from "./body-B9XTTDEu.mjs";
+import { parseId } from "./parse-id-B5adfBlS.mjs";
+import { readBody } from "./body-DB2upz6a.mjs";
 import { bodyInputFlags } from "./body-flags-D7q87Btw.mjs";
 import { Document, DocumentUpdateInput, documentView } from "./document-qfwR0r63.mjs";
 

package/dist/{update-B59h7KmS.mjs → update-D698CaeV.mjs}

@@ -1,12 +1,12 @@
 import "./command-augment-CAur0XOQ.mjs";
-import { connectionFlags, outputFlags, profileFlag } from "./error-D5bZ5BUX.mjs";
-import { defineMetabaseCommand } from "./runtime-C1QgWHM7.mjs";
+import { connectionFlags, outputFlags, profileFlag } from "./error-CIObEXLY.mjs";
+import { defineMetabaseCommand } from "./runtime-CmAIahm5.mjs";
 import { renderSummary } from "./capabilities-BX1rnVuH.mjs";
 import "./input-BXWgdKiS.mjs";
-import { parseId } from "./parse-id-DNPeV0Iu.mjs";
-import { readBody } from "./body-B9XTTDEu.mjs";
+import { parseId } from "./parse-id-B5adfBlS.mjs";
+import { readBody } from "./body-DB2upz6a.mjs";
 import { bodyInputFlags } from "./body-flags-D7q87Btw.mjs";
-import { TransformJob, TransformJobUpdateInput, transformJobView } from "./transform-job-C8lIS-7Q.mjs";
+import { TransformJob, TransformJobUpdateInput, transformJobView } from "./transform-job-CtVziW85.mjs";
 
 //#region src/commands/transform-job/update.ts
 var update_default = defineMetabaseCommand({

package/dist/{update-DERsb0eO.mjs → update-DOfL_KPx.mjs}

@@ -1,16 +1,16 @@
 import "./command-augment-CAur0XOQ.mjs";
-import { connectionFlags, outputFlags, profileFlag } from "./error-D5bZ5BUX.mjs";
-import { defineMetabaseCommand } from "./runtime-C1QgWHM7.mjs";
+import { connectionFlags, outputFlags, profileFlag } from "./error-CIObEXLY.mjs";
+import { defineMetabaseCommand } from "./runtime-CmAIahm5.mjs";
 import { renderSummary } from "./capabilities-BX1rnVuH.mjs";
 import "./input-BXWgdKiS.mjs";
 import "./field-E0IBy4Uw.mjs";
 import "./card-wCPcuKSi.mjs";
-import { parseId } from "./parse-id-DNPeV0Iu.mjs";
-import { readBody } from "./body-B9XTTDEu.mjs";
+import { parseId } from "./parse-id-B5adfBlS.mjs";
+import { readBody } from "./body-DB2upz6a.mjs";
 import { bodyInputFlags } from "./body-flags-D7q87Btw.mjs";
 import "./validate-VawhJ5Sc.mjs";
 import { DashboardDetail, DashboardUpdateInput, dashboardView } from "./dashboard-B4bn3z6t.mjs";
-import { preflightDashcardCardReferences } from "./preflight-BdJr2amA.mjs";
+import { preflightDashcardCardReferences } from "./preflight-QVPvG_Xg.mjs";
 
 //#region src/commands/dashboard/update.ts
 var update_default = defineMetabaseCommand({

package/dist/{update-Kz4kyqY_.mjs → update-DSueNZRw.mjs}

@@ -1,12 +1,12 @@
 import "./command-augment-CAur0XOQ.mjs";
-import { connectionFlags, outputFlags, profileFlag } from "./error-D5bZ5BUX.mjs";
-import { defineMetabaseCommand } from "./runtime-C1QgWHM7.mjs";
+import { connectionFlags, outputFlags, profileFlag } from "./error-CIObEXLY.mjs";
+import { defineMetabaseCommand } from "./runtime-CmAIahm5.mjs";
 import { renderSummary } from "./capabilities-BX1rnVuH.mjs";
 import "./input-BXWgdKiS.mjs";
-import { parseId } from "./parse-id-DNPeV0Iu.mjs";
-import { readBody } from "./body-B9XTTDEu.mjs";
+import { parseId } from "./parse-id-B5adfBlS.mjs";
+import { readBody } from "./body-DB2upz6a.mjs";
 import { bodyInputFlags } from "./body-flags-D7q87Btw.mjs";
-import { TransformTag, TransformTagUpdateInput, transformTagView } from "./transform-tag-DB46AhAj.mjs";
+import { TransformTag, TransformTagUpdateInput, transformTagView } from "./transform-tag-wFiWmiyO.mjs";
 
 //#region src/commands/transform-tag/update.ts
 var update_default = defineMetabaseCommand({

package/dist/{update-DQPg0_-d.mjs → update-DudyZ-FP.mjs}

@@ -1,13 +1,13 @@
 import "./command-augment-CAur0XOQ.mjs";
-import { connectionFlags, outputFlags, profileFlag } from "./error-D5bZ5BUX.mjs";
-import { defineMetabaseCommand } from "./runtime-C1QgWHM7.mjs";
+import { connectionFlags, outputFlags, profileFlag } from "./error-CIObEXLY.mjs";
+import { defineMetabaseCommand } from "./runtime-CmAIahm5.mjs";
 import { renderSummary } from "./capabilities-BX1rnVuH.mjs";
 import "./input-BXWgdKiS.mjs";
 import "./field-E0IBy4Uw.mjs";
-import { parseId } from "./parse-id-DNPeV0Iu.mjs";
-import { readBody } from "./body-B9XTTDEu.mjs";
+import { parseId } from "./parse-id-B5adfBlS.mjs";
+import { readBody } from "./body-DB2upz6a.mjs";
 import { bodyInputFlags } from "./body-flags-D7q87Btw.mjs";
-import { Table, TableUpdateInput, tableView } from "./table-qDD2kApF.mjs";
+import { Table, TableUpdateInput, tableView } from "./table-CDMG0Zi5.mjs";
 
 //#region src/commands/table/update.ts
 var update_default = defineMetabaseCommand({

package/dist/{update-rhfPHALN.mjs → update-I3TA2Tem.mjs}

@@ -1,12 +1,12 @@
 import "./command-augment-CAur0XOQ.mjs";
-import { connectionFlags, outputFlags, profileFlag } from "./error-D5bZ5BUX.mjs";
-import { defineMetabaseCommand } from "./runtime-C1QgWHM7.mjs";
+import { connectionFlags, outputFlags, profileFlag } from "./error-CIObEXLY.mjs";
+import { defineMetabaseCommand } from "./runtime-CmAIahm5.mjs";
 import { renderSummary } from "./capabilities-BX1rnVuH.mjs";
 import "./input-BXWgdKiS.mjs";
 import "./field-E0IBy4Uw.mjs";
 import { Card, CardUpdateInput, cardView } from "./card-wCPcuKSi.mjs";
-import { parseId } from "./parse-id-DNPeV0Iu.mjs";
-import { readBody } from "./body-B9XTTDEu.mjs";
+import { parseId } from "./parse-id-B5adfBlS.mjs";
+import { readBody } from "./body-DB2upz6a.mjs";
 import { bodyInputFlags } from "./body-flags-D7q87Btw.mjs";
 import "./validate-VawhJ5Sc.mjs";
 import { CARD_DATASET_QUERY_LABELS, preflightMbql5Query, skipValidateFlag } from "./validate-query-CSV-TTnd.mjs";

package/dist/{update-BXZBEeUp.mjs → update-PZPNx0Xd.mjs}

@@ -1,14 +1,14 @@
 import "./command-augment-CAur0XOQ.mjs";
-import { connectionFlags, outputFlags, profileFlag } from "./error-D5bZ5BUX.mjs";
-import { defineMetabaseCommand } from "./runtime-C1QgWHM7.mjs";
+import { connectionFlags, outputFlags, profileFlag } from "./error-CIObEXLY.mjs";
+import { defineMetabaseCommand } from "./runtime-CmAIahm5.mjs";
 import { renderSummary } from "./capabilities-BX1rnVuH.mjs";
 import "./input-BXWgdKiS.mjs";
-import { parseId } from "./parse-id-DNPeV0Iu.mjs";
-import { readBody } from "./body-B9XTTDEu.mjs";
+import { parseId } from "./parse-id-B5adfBlS.mjs";
+import { readBody } from "./body-DB2upz6a.mjs";
 import { bodyInputFlags } from "./body-flags-D7q87Btw.mjs";
 import "./validate-VawhJ5Sc.mjs";
 import { MEASURE_DEFINITION_LABELS, preflightMbql5Query, skipValidateFlag } from "./validate-query-CSV-TTnd.mjs";
-import { Measure, MeasureUpdateInput, measureView } from "./measure-JJAdFoqK.mjs";
+import { Measure, MeasureUpdateInput, measureView } from "./measure-BCv5wDDN.mjs";
 
 //#region src/commands/measure/update.ts
 var update_default = defineMetabaseCommand({

package/dist/{update-dashcard-BJVeSGvO.mjs → update-dashcard-BXZ4vS15.mjs}

@@ -1,10 +1,10 @@
 import { ConfigError } from "./command-augment-CAur0XOQ.mjs";
-import { connectionFlags, outputFlags, profileFlag } from "./error-D5bZ5BUX.mjs";
-import { defineMetabaseCommand } from "./runtime-C1QgWHM7.mjs";
+import { connectionFlags, outputFlags, profileFlag } from "./error-CIObEXLY.mjs";
+import { defineMetabaseCommand } from "./runtime-CmAIahm5.mjs";
 import { renderSummary } from "./capabilities-BX1rnVuH.mjs";
 import "./input-BXWgdKiS.mjs";
-import { parseId } from "./parse-id-DNPeV0Iu.mjs";
-import { readBody } from "./body-B9XTTDEu.mjs";
+import { parseId } from "./parse-id-B5adfBlS.mjs";
+import { readBody } from "./body-DB2upz6a.mjs";
 import { bodyInputFlags } from "./body-flags-D7q87Btw.mjs";
 import { DashboardDetail, Dashcard, DashcardPatchInput, dashcardView } from "./dashboard-B4bn3z6t.mjs";
 

package/dist/{upgrade-CNrkJF6s.mjs → upgrade-4cWfLu90.mjs}

@@ -1,6 +1,6 @@
 import { AbortError, NetworkError, TimeoutError, UnknownError, errorMessage } from "./command-augment-CAur0XOQ.mjs";
-import { outputFlags, package_default } from "./error-D5bZ5BUX.mjs";
-import { HttpError, USER_AGENT, combineAborts, defineMetabaseCommand, parseJson, throwIfAborted } from "./runtime-C1QgWHM7.mjs";
+import { outputFlags, package_default } from "./error-CIObEXLY.mjs";
+import { HttpError, USER_AGENT, combineAborts, defineMetabaseCommand, parseJson, throwIfAborted } from "./runtime-CmAIahm5.mjs";
 import { renderItem, writeText } from "./capabilities-BX1rnVuH.mjs";
 import { promptConfirm } from "./prompt-Bc_bHSD0.mjs";
 import { streamProcess } from "./process-DsGf7Mg5.mjs";

package/dist/{uuid-Dpl3ALKq.mjs → uuid---pAboNQ.mjs}

@@ -1,6 +1,6 @@
 import { ConfigError } from "./command-augment-CAur0XOQ.mjs";
-import { outputFlags } from "./error-D5bZ5BUX.mjs";
-import { defineMetabaseCommand, parseInteger } from "./runtime-C1QgWHM7.mjs";
+import { outputFlags } from "./error-CIObEXLY.mjs";
+import { defineMetabaseCommand, parseInteger } from "./runtime-CmAIahm5.mjs";
 import { writeJson, writeText } from "./capabilities-BX1rnVuH.mjs";
 import { z } from "zod";
 import { randomUUID } from "node:crypto";

package/dist/{values-DMYpkoEH.mjs → values-I503dI7K.mjs}

@@ -1,9 +1,9 @@
 import "./command-augment-CAur0XOQ.mjs";
-import { connectionFlags, outputFlags, profileFlag } from "./error-D5bZ5BUX.mjs";
-import { defineMetabaseCommand } from "./runtime-C1QgWHM7.mjs";
+import { connectionFlags, outputFlags, profileFlag } from "./error-CIObEXLY.mjs";
+import { defineMetabaseCommand } from "./runtime-CmAIahm5.mjs";
 import { formatScalar, renderSummary } from "./capabilities-BX1rnVuH.mjs";
 import { FieldValues, fieldValuesView } from "./field-E0IBy4Uw.mjs";
-import { parseId } from "./parse-id-DNPeV0Iu.mjs";
+import { parseId } from "./parse-id-B5adfBlS.mjs";
 
 //#region src/commands/field/values.ts
 var values_default = defineMetabaseCommand({

package/dist/{verify-By9ZYzx4.mjs → verify-BMhTWW9s.mjs}

@@ -1,5 +1,5 @@
 import { MetabaseError, NetworkError, TimeoutError, errorMessage } from "./command-augment-CAur0XOQ.mjs";
-import { HttpError, createClient, probeServer } from "./runtime-C1QgWHM7.mjs";
+import { HttpError, createClient, probeServer } from "./runtime-CmAIahm5.mjs";
 import { z } from "zod";
 
 //#region src/domain/user.ts

package/dist/{wait-flags-DQrxnlwv.mjs → wait-flags-HtCL2l1r.mjs}

@@ -1,5 +1,5 @@
-import { parseId } from "./parse-id-DNPeV0Iu.mjs";
-import { DEFAULT_INTERVAL_MS, DEFAULT_TIMEOUT_MS } from "./poll-CYkX02Bm.mjs";
+import { parseId } from "./parse-id-B5adfBlS.mjs";
+import { DEFAULT_INTERVAL_MS, DEFAULT_TIMEOUT_MS } from "./poll-AduuU55-.mjs";
 
 //#region src/commands/wait-flags.ts
 const waitScheduleFlags = {

package/dist/{wait-BzIAj8lJ.mjs → wait-oMSs_IdS.mjs}

@@ -1,10 +1,10 @@
 import "./command-augment-CAur0XOQ.mjs";
-import { connectionFlags, outputFlags, profileFlag } from "./error-D5bZ5BUX.mjs";
-import { defineMetabaseCommand } from "./runtime-C1QgWHM7.mjs";
+import { connectionFlags, outputFlags, profileFlag } from "./error-CIObEXLY.mjs";
+import { defineMetabaseCommand } from "./runtime-CmAIahm5.mjs";
 import { renderSummary } from "./capabilities-BX1rnVuH.mjs";
-import { parseId } from "./parse-id-DNPeV0Iu.mjs";
-import { DEFAULT_INTERVAL_MS, DEFAULT_TIMEOUT_MS } from "./poll-CYkX02Bm.mjs";
-import { SyncTaskOrIdle, formatSyncTask, pollSyncTask, syncTaskIdleView, syncTaskView, throwIfFailedTask } from "./poll-task-oXpl3wzp.mjs";
+import { parseId } from "./parse-id-B5adfBlS.mjs";
+import { DEFAULT_INTERVAL_MS, DEFAULT_TIMEOUT_MS } from "./poll-AduuU55-.mjs";
+import { SyncTaskOrIdle, formatSyncTask, pollSyncTask, syncTaskIdleView, syncTaskView, throwIfFailedTask } from "./poll-task-B00Qwd87.mjs";
 
 //#region src/commands/git-sync/wait.ts
 const WaitResult = SyncTaskOrIdle;

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@metabase/cli",
-  "version": "0.1.15",
+  "version": "0.1.16",
   "description": "Metabase CLI",
   "license": "AGPL-3.0",
   "repository": {

package/skill-data/core/SKILL.md

@@ -11,7 +11,7 @@ The official Metabase CLI (`mb`) drives a Metabase instance over its REST API: a
 Top-level command groups (run `mb <group> --help` to discover verbs):
 
 ```
-auth | db | table | field | query | card | dashboard | snippet | segment | measure | collection
+auth | db | table | field | query | card | dashboard | snippet | segment | measure | collection | library
 document | transform | transform-job | transform-tag | setting | search | git-sync | setup | eid | uuid | upgrade | skills
 ```
 
@@ -128,7 +128,7 @@ Routine verb shapes (list / get / create / update), every flag, and output JSON
 
 - **db traversal vs. rollup.** Default to granular: `database list` → `database schemas <db-id>` → `database schema-tables <db-id> <schema>` → `table get <table-id> --include fields`. The rollup endpoints (`database get --include tables.fields`, `database metadata <db-id>`) pull megabytes and blow the context window on any real warehouse — use them only on a small/dev db. `sync-schema` / `rescan-values` queue async work and return `{status:"ok"}` immediately; `sync-schema --wait` blocks until `initial_sync_status: complete`.
 - **table fields.** `table get` never returns fields on its own — pass `--include fields` (compact) or use `table fields <id>` (list envelope). `table metadata <id>` adds FKs + dimensions (heavier). `table update` patches table-level metadata only; physical columns aren't editable here.
-- **table publish / unpublish.** EE-only (`library` premium feature, v59+) bulk Library curation. Pick targets with `--table-ids` / `--db-ids` / `--schemas` (combined as OR), where each `--schemas` entry is `<db-id>:<schema>` (e.g. `1:public`), **not** a bare schema name. `publish --collection-id` must point at a `library-data` collection (a regular collection is rejected with a 400). `publish` cascades to upstream FK dependencies, `unpublish` to downstream dependents; both exit **403** unless you have write **and** query permission on every affected table.
+- **library.** EE-only (`library` premium feature, v59+). The Library is a curated subtree (`library-data` "Data" + `library-metrics` "Metrics" under a `library` root): tables published to **Data** appear first in data pickers and rank up in search; metrics saved to **Metrics** are prioritized in nav, search, and the query builder. So the Library is how you tell people (and agents) "start from these — they're trusted." `library get` shows the Library and its Data/Metrics collection ids; `library create` provisions it (idempotent). `library publish --table-ids/--db-ids/--schemas` publishes tables into Data — it **resolves the Data collection itself and creates the Library if absent** (no collection id to find); each `--schemas` entry is `<db-id>:<schema>` (e.g. `1:public`), not a bare name. `publish` cascades to upstream FK dependencies, `unpublish` to downstream dependents; both need **admin or data-analyst** (Curate permission alone won't publish tables) and exit **403** without write **and** query permission on every affected table. Publish status shows on the table: `table get`/`table list` carry `is_published` (`collection_id` under `--full`). Good candidates are finished, analysis-ready tables — clean/combine via transforms first, then publish the polished result; don't publish raw tables.
 - **field has no `list`.** Fields are per-table — get them via `table get <id> --include fields`. Never enumerate fields across a whole db (context blow-up). `field summary` is live cardinality `{field_id, count, distincts}`; `field values` is the cached distinct set (`has_more_values: true` ⇒ truncated cache). `field update` patches metadata only; `base_type` isn't editable.
 - **card.** `dataset_query` is the **flat** `mbql/query` value, not a legacy `{type:"query",query:…}` envelope (→ `mbql` skill). `--export-format csv|xlsx` streams the raw export (pipe to a file), bypassing the JSON envelope. `archive` is the only delete; unarchive with `update --body '{"archived":false}'`. `visualization_settings` keys are scoped by `display` and aren't pre-flighted — see the `viz` skill.
 - **dashboard.** Dashcards round-trip through `PUT /api/dashboard/:id` (no per-dashcard endpoint): `update-dashcard <dash-id> <dashcard-id>` patches one safely; `update --body '{"dashcards":[…]}'` replaces the whole set (omitted ids are deleted server-side; negative ids for new cards). `create` accepts the **same** `dashcards` array in its initial body — lay out the whole dashboard in one call: negative ids for new cards, and `card_id:null` plus a `visualization_settings.virtual_card` block (`{display:"text"|"heading"|"link"|…}`) for non-question cards. `create`/`update` pre-flight every positive `card_id` against live server state and exit **2** with `{ok:false,errors:[…]}` on a bad ref — non-bypassable (no `--skip-validate`). `dashboard get <id>` (or `--full`) hydrates dashcards/tabs; `list` omits them. **Dashcard geometry: the grid is 24 columns wide.** Each dashcard's `{col, row, size_x, size_y}` is in grid units — `col` (0-indexed, left edge) and `size_x` are columns, `row`/`size_y` are rows; **full-width is `size_x: 24`** (`size_x: 12` is half a row — the usual cause of a card filling only half the width, since it's a common per-chart default). Keep `col + size_x ≤ 24`, start each card's `col` at 0 for a full-width stack, and don't overlap cards (the server stores whatever you send — it won't auto-fix collisions).

package/skill-data/data-transformation/SKILL.md

@@ -6,9 +6,9 @@ allowed-tools: Read, Write, Edit, Bash, AskUserQuestion, EnterPlanMode, ExitPlan
 
 # Data Transformation
 
-> **Shared contract (read first).** This skill is part of the `robot-data-engineer` family and follows its shared rules: ask before showing PII row-by-row (names, emails, phones) — default to aggregates; when asked for something the CLI can't do (alerts, dashboard filters), name the limit instead of erroring into raw SQL; honor the autonomy mode the user picked. The jargon rules are spelled out in detail below (**Who you're talking to**). Full contract and the autonomy slider live in the router — run `mb skills get robot-data-engineer` and read its **Shared Contract** if you haven't.
+> **Shared contract (read first).** This skill is part of the `robot-data-engineer` family and follows its shared rules: ask before showing PII row-by-row (names, emails, phones) — default to aggregates; when asked for something the CLI can't do (alerts, dashboard filters), name the limit instead of erroring into raw SQL; honor the autonomy mode the user picked. The jargon rules are spelled out below (**Who you're talking to**). Full contract and the autonomy slider live in the router — run `mb skills get robot-data-engineer` and read its **Shared Contract**.
 
-Your job: take a raw source database — usually normalized, often synced from some SaaS tool by a connector like Fivetran, Airbyte, or Stitch — and produce a **small set of wide, clean, analysis-ready tables**, one per real-world _thing_ the data is about, built as Metabase **transforms** the user can inspect.
+Your job: take a raw source database — usually normalized, often synced from a SaaS tool by a connector like Fivetran or Airbyte — and produce a **small set of wide, clean, analysis-ready tables**, one per real-world _thing_ the data is about, built as Metabase **transforms** the user can inspect.
 
 Drive everything through the `mb` CLI. Load the skills you'll need:
 
@@ -18,9 +18,7 @@ mb skills get mbql         # if you build transform queries in MBQL
 mb skills get transform    # creating/running transforms, run inspection
 ```
 
-Users authenticate. You pick the profile per `core`'s **Auth & profiles** and pass `--profile <name>` to every command. That profile's `url` is the instance's base URL. Browser links below are built from it, ensuring the links are consistent with your CLI usage.
-
-If you are making transforms, use the transform skill.
+Users authenticate. Pick the profile per `core`'s **Auth & profiles** and pass `--profile <name>` to every command. That profile's `url` is the instance's base URL; the browser links below are built from it.
 
 ---
 
@@ -28,11 +26,11 @@ If you are making transforms, use the transform skill.
 
 A **non-technical user who knows their domain well** — they understand the business (events, customers, invoices, etc.) but not databases.
 
-- **No modeling jargon.** Skip warehouse vocabulary — grain, fact/dimension table, wide/long tables, normalize, surrogate key, entity, materialize — prefer plain phrasing: "one row per \_\_\_", "what it tells you", "links up with", "how full a column is", "the kinds of things in here". **But don't overdo it:** basic relational terms are fine — table, column, ERD, schema, key, foreign key (cardinality too, though "one-to-many" usually lands better). **Metabase's product terms are encouraged** — Question, Model, Segment, Measure, Metric, Transform — they're not database jargon.
+- **No modeling jargon.** Skip warehouse vocabulary — grain, fact/dimension table, normalize, surrogate key, entity, materialize — prefer plain phrasing: "one row per \_\_\_", "what it tells you", "links up with", "how full a column is". **But don't overdo it:** basic relational terms are fine — table, column, ERD, schema, key, foreign key (cardinality too, though "one-to-many" usually lands better). **Metabase's product terms are encouraged** — Question, Model, Segment, Measure, Metric, Transform — they're not database jargon.
 - **Don't lean on raw SQL to communicate.** They may follow a simple `SELECT`, but don't explain work via SQL or ask them to read/write it.
 - Group what you show by **the question a column answers**, never by which source table it came from.
 - Be a **helpful assistant, not an engineer reporting status.** Elide machinery; ask sharp questions that matter.
-- Your user may say "go" and come back later. **If you ever ask the user a question, wait for their answer.**
+- **If you ever ask the user a question, wait for their answer.** They may say "go" and come back later.
 
 ---
 
@@ -47,8 +45,8 @@ Sort every choice into one of these.
 3. Always surface **real data you're about to leave out** proactively, ranked by how much is extant.
 4. Never guess what schema mean from their name alone. Confirm against actual values, interpret them in context: the table the field belongs to and the relevant domain (e.g., a status on orders ≠ status on subscriptions).
 5. Never silently drop a whole _thing_. Dropping a column is routine; dropping a whole kind-of-thing (e.g. "suppliers") must be surfaced and confirmed.
-6. Never drop columns that link things together. Every table keeps its own id **and** the ids tying it to other tables — alongside the readable labels you copy in, not instead of. The label is for reading; the id is for joining. You're building tables about _related_ things, so they **will** be combined ("sales per region", "messages per customer") — dropped ids make that quietly impossible and the user will regret it. Keep the ids; don't force the user to stare at them.
-7. Never bake a non-obvious business rule into a table without confirming it in plain terms. When a transform encodes a judgment the user would have an opinion on — how money nets, which row is the "current" one, what "active" means — say it back in one plain sentence and get a yes/no first. You know only the columns; they know the business. Wrong rules hide insidiously in clean-looking tables. ("I'm treating each person's most recent sign-up as their current one — right?")
+6. Never drop columns that link things together. Every table keeps its own id **and** the ids tying it to other tables — alongside the readable labels you copy in, not instead of (label for reading, id for joining). You're building tables about _related_ things, so they **will** be combined ("sales per region", "messages per customer") — dropped ids make that quietly impossible. Keep the ids.
+7. Never bake a non-obvious business rule into a table without confirming it in plain terms. When a transform encodes a judgment the user would have an opinion on — how money nets, which row is the "current" one, what "active" means — say it back in one plain sentence and get a yes/no first. You know only the columns; they know the business, and wrong rules hide in clean-looking tables. ("I'm treating each person's most recent sign-up as their current one — right?")
 8. Never sneak sensitive personal data through. Flag it on sight — addresses, phone numbers, emails, IPs, financial, etc. — and ask the user how to handle it (the prudential call below). Always surface, never silently expose it in a table others will browse.
 9. Never overwrite existing tables or other transforms' outputs. Before building, check the target name is unused (`mb transform list`, `mb table list`); if it's in use, stop and surface it — building over it silently destroys their data. Reuse names only for updating _your own_ transform (`transform update`), never for clobbering another.
 
@@ -57,7 +55,7 @@ Sort every choice into one of these.
 - **Multi-valued attribute** (one response → many options; one order → many line items): keep it filterable! Structured columns for predefined lists, or simple join tables, never opaque text. Structure is the user's call. Lean: easiest filtering, probably flat.
 - **Layering**: default **flat** — one self-contained table per thing, no hidden intermediate tables. Suggest a shared cleaned-up base table only for DRY, avoiding copying complex logic across many transforms. Even then, ask.
 - **Out-of-scope things**: surface every domain-model you find and ask in/out, rather than inferring scope from what they happened to mention.
-- **A repeating thing vs. the events it takes part in**: one table can mix a _stable_ thing (a customer, a company) with _repeating_ events (each order, each visit), copying the stable details onto every event row. If that thing genuinely recurs — same customer on many rows — consider a one-row-per-thing table too, linked by id, so "how many distinct X" and the per-X details have clean homes. Lean: split when recurrence is real, but one table when each appears once. (Phase 0's one-to-one / one-to-many check already tells you which.)
+- **A repeating thing vs. the events it takes part in**: one table can mix a _stable_ thing (a customer, a company) with _repeating_ events (each order, each visit), copying the stable details onto every event row. If that thing genuinely recurs — same customer on many rows — consider a one-row-per-thing table too, linked by id, so "how many distinct X" and the per-X details have clean homes. Lean: split when recurrence is real, one table when each appears once. (Phase 0's one-to-one / one-to-many check tells you which.)
 - **Handling sensitive data** (addresses, emails, phones, IPs, financial details): once you've flagged it (rule 8), _how_ to carry it is user's choice — keep as-is, mask (partial redaction), or drop. Lean: keep what is needed, mask the rest, drop the useless.
 
 Phrase a prudential call as a lean plus a nod:
@@ -70,11 +68,11 @@ Phrase a prudential call as a lean plus a nod:
 
 ### Phase 0 — Get Oriented
 
-**Pin down where the data lives — ask before you hunt.** A table or schema name the user mentions tells you _what_ but not _where_: an instance can hold several databases, each with several schemas. Rather than listing them all to find it, just ask — "Which database is this in, and the schema if you know it? No worries if you're not sure, I can find it." A confident answer short-circuits a lot of blind searching; "not sure" costs nothing and you fall back to locating it yourself. If you've genuinely looked and still can't find a table the user is sure is there, don't keep digging. One possible reason is that Metabase hasn't picked up that database's latest schema yet — gently raise it and ask whether the data's been synced recently, and let the user run the sync from Metabase if it's needed.
+**Pin down where the data lives — ask before you hunt.** A table or schema name the user mentions tells you _what_ but not _where_: an instance can hold several databases, each with several schemas. Rather than listing them all to find it, just ask — "Which database is this in, and the schema if you know it? No worries if not — I can find it." A confident answer short-circuits a lot of blind searching; "not sure" costs nothing and you fall back to locating it yourself. If you've genuinely looked and still can't find a table the user is sure is there, don't keep digging — one likely reason is Metabase hasn't synced that database's latest schema; gently raise it and let the user run the sync from Metabase.
 
 As soon as you know which database and schema you're in:
 
-- **Show the user the map.** Open the instance's schema map for that schema so they can follow along: `<base-url>/data-studio/schema-viewer?database-id=<db-id>&schema=<schema>`. Open it in their browser if you can (e.g. `open` / `xdg-open`); else paste the URL. Don't skip this.
+- **Show the user the map.** Open the instance's schema map so they can follow along: `<base-url>/data-studio/schema-viewer?database-id=<db-id>&schema=<schema>` — in their browser if you can (`open` / `xdg-open`), else paste the URL. Don't skip this.
 - **Ask for a head start.** "Do you have a picture or file showing how your data fits together, like an ERD?" If yes, read it — it shortcuts the next steps.
 - **Ask for their conventions.** "Is there already cleaned-up data, or a past project, that shows how your team likes this done?" If yes, inspect it: it tells you their naming, their idea of "clean," and existing tables worth linking to.
 
@@ -87,21 +85,21 @@ Orientation done, you're about to go heads-down. First, offer two ways to work:
 > - **I dig through it all and bring you a complete plan** to approve before I build anything — quieter; you won't hear much until it's ready.
 > - **We work it out together** — I share what I find and we make the calls as we go.
 
-First path: **enter plan mode** (`EnterPlanMode`). Everything up to the agreed table list — investigate, present, prudential calls, naming (Phases 1–3) — happens inside it, read-only; you exit once, at the approval gate before building (Phase 4). Second path: skip it, shape it conversationally through the same phases. Either way, don't build until the design is settled and user-approved.
+First path: **enter plan mode** (`EnterPlanMode`). Everything up to the agreed table list — investigate, present, prudential calls, naming (Phases 1–3) — happens inside it, read-only; you exit once, at the approval gate before building (Phase 4). Second path: skip it, shape it conversationally through the same phases. Either way, don't build until the design is settled and approved.
 
-Plan mode is a long quiet stretch — they said "go" and walked off. So whenever you surface — a question now, the plan at the end — **carry your own context**: recap what it rests on right before you ask, never a back-reference to something said while they were away (the router's contract spells this out).
+Plan mode is a long quiet stretch. So whenever you surface — a question now, the plan at the end — **carry your own context**: recap what it rests on right before you ask, never a back-reference to something said while they were away.
 
 Then dig in. Don't narrate this — a single "Let me take a look at what's in here — one minute" is enough. Keep it cheap: never pull whole-warehouse rollups (they blow up); use compact column listings, `LIMIT`/sample queries, and `GROUP BY count(*)`.
 
 1. **Map the tables.** List them; pull each one's column names and types; note its own id.
-2. **Find the decode tables.** Normalized SaaS data hides meaning in lookups — `*_field`, `*_field_choice`, `*_question`, `*_choice`, `*_type`. A column like `doodad_4471` is meaningless until you join the lookup and find it's _"Preferred vehicular transport"_. Build that code → label map yourself by joining the lookups — never hand the user a coded column and ask what it means — before showing them anything.
-3. **Prove the connections — don't trust declared keys.** Synced databases usually have none. If that's the case, ask the user if they have ERD or relationship information (screenshot, JSON, documentation, etc.). For each `<x>_id`, guess it points at `<x>`, then check what fraction of values actually match the target's id: high = real link, low = decoy, discard. Note one-to-one vs one-to-many. **Also look outward** — does a thing you're about to build already exist as clean data elsewhere in the instance (an existing customers table your people match, a product list)? If so, plan to _link_ to it, not duplicate it.
+2. **Find the decode tables.** Normalized SaaS data hides meaning in lookups — `*_field`, `*_field_choice`, `*_question`, `*_choice`, `*_type`. A column like `doodad_4471` is meaningless until you join the lookup and find it's _"Preferred vehicular transport"_. Build that code → label map yourself — never hand the user a coded column and ask what it means — before showing them anything.
+3. **Prove the connections — don't trust declared keys.** Synced databases usually have none. If that's the case, ask the user if they have ERD or relationship information (screenshot, JSON, documentation, etc.). For each `<x>_id`, guess it points at `<x>`, then check what fraction of values actually match the target's id: high = real link, low = decoy, discard. Note one-to-one vs one-to-many. **Also look outward** — does a thing you're about to build already exist as clean data elsewhere (an existing customers table, a product list)? If so, plan to _link_ to it, not duplicate it.
 4. **Pin down "one row per what."** Count rows; check the id is unique; figure out what a single row is. **Watch for lies:** a stale count column, or a table that looks like "all of X" but is a filtered subset.
-5. **Reconcile across related tables.** Do child rows all link to a parent? Orphans? Is one table a trimmed snapshot while another keeps everything? These mismatches matter and the user can't see them — you must.
+5. **Reconcile across related tables.** Do child rows all link to a parent? Orphans? Is one table a trimmed snapshot while another keeps everything? These mismatches matter and the user can't see them.
 6. **Profile the values.** List distinct values for coded/low-variety columns; check how full (% non-empty) any column you might drop is; spot multi-valued JSON fields. Profile with the cleaning checklist (end of file) in mind — surface the quality smells you hit, don't silently fix them.
 7. **Cluster into things.** Group tables and columns into the real-world things they describe — a thing may span several tables (one _customer_ across a main table + a loyalty table + custom-profile columns). Decide "one row per \_\_\_" for each and gather its attributes, decoded. Watch for a table that secretly mixes _two_ things — a stable thing plus its repeating events; that's the split in the prudential calls above.
 
-**Then, still quietly, sketch the design space.** Once the things and how they connect are pinned, brainstorm the range of questions this data could answer — finance views, leaderboards, breakdowns. **Don't show it to the user or build any of it.** It only pressure-tests your design: would a reasonable pivot to a nearby question force a rewrite? When keeping a column or finer grain _cheaply_ preserves that flexibility, keep it. Serve the user's stated concern — but don't scope so tightly that the next question means starting over.
+**Then, still quietly, sketch the design space.** Once the things and their connections are pinned, brainstorm the questions this data could answer — finance views, leaderboards, breakdowns. **Don't show it or build any of it.** It only pressure-tests your design: would a reasonable pivot to a nearby question force a rewrite? When keeping a column or finer grain _cheaply_ preserves that flexibility, keep it — don't scope so tightly that the next question means starting over.
 
 ### Phase 2 — Present what you found (plain language)
 
@@ -121,18 +119,18 @@ Three things, in order:
 > • **Real data** — gift-message text (6 of 10 orders), delivery instructions (most), preferred carrier. Minor, but real — want any kept?
 > • **Safe to drop** — duplicate product names in other languages, internal bookkeeping columns. No real loss.
 
-If you spotted existing clean data to link to (step 3), raise it here too — and **always run a suspected match past the user before wiring it; never graft onto their existing data silently.** Then ask your prudential questions, one at a time, each a lean-plus-nod.
+If you spotted existing clean data to link to (step 3), raise it here too — **always run a suspected match past the user before wiring it, never graft on silently.** Then ask your prudential questions, one at a time.
 
 ### Phase 3 — Iterate
 
-Cheap, because nothing's built. Adjust the set of things, what's kept, and the shape of any multi-valued pieces until the user's happy. **Agree on what each table will be called** — propose a clear name for each (matching any naming pattern you found in their existing data, Phase 0) and let them adjust. Confirm each name is free — not already an existing table or another transform's output (rule 9) — so building can't overwrite anyone's data. Settle the names before building: the name you agree on is the one you build and keep. Re-confirm the final picture in one short recap. **In plan mode, that recap _is_ your exit:** present it as the plan and call `ExitPlanMode` — approval here is the single go-ahead to build. (Iterating together? The recap is just your check before building.)
+Cheap, because nothing's built. Adjust the set of things, what's kept, and the shape of any multi-valued pieces until the user's happy. **Agree on what each table will be called** — propose a clear name for each (matching any naming pattern you found in their existing data, Phase 0) and let them adjust. Confirm each name is free — not already an existing table or another transform's output (rule 9) — so building can't overwrite anyone's data. The name you agree on is the one you build and keep. Re-confirm the final picture in one short recap. **In plan mode, that recap _is_ your exit:** present it as the plan and call `ExitPlanMode` — approval here is the single go-ahead to build. (Iterating together? The recap is just your check before building.)
 
 ### Phase 4 — Build, check, hand back
 
-Design settled — now you build, the first step that writes; plan mode, if you used it, is behind you. Build one wide transform per agreed thing — and build for how it'll be judged: aim for output that's readable on sight, not just one that runs clean. Each table:
+Design settled — now you build, the first step that writes; plan mode, if you used it, is behind you. Build one wide transform per agreed thing, for how it'll be judged: output that's readable on sight, not just one that runs clean. Each table:
 
 - **Denormalized, but the link stays.** Copy in related context so casual reading needs no lookups (a product's name and price on the orders table) — **and keep the linking id beside it** (the product's id too, per rule 6). Use the same id name everywhere a thing appears.
-- **Decoded**: codes and JSON become readable text; bookkeeping columns and soft-deleted rows are gone (filter the source's soft-delete flag — Fivetran's `_fivetran_deleted`, Airbyte's `_ab_cdc_deleted_at`, or a plain `deleted_at`/`is_deleted` — so tombstones never reach clean data; not every source has one).
+- **Decoded**: codes and JSON become readable text; bookkeeping columns and soft-deleted rows are gone (filter the source's soft-delete flag — Fivetran's `_fivetran_deleted`, Airbyte's `_ab_cdc_deleted_at`, or a plain `deleted_at`/`is_deleted` — so tombstones never reach clean data).
 - **Clean, plain column names**, consistent across tables.
 - **Multi-valued pieces** in the agreed filterable structure (rule 1).
 - **Keep the detail; don't pre-summarize it away.** Build the detailed rows (one per order, one per payment), not pre-computed totals. A convenience count is fine _beside_ the rows, never _instead of_ them — a frozen total only ever answers the one question it was summed for.
@@ -141,15 +139,22 @@ Then make the links real, not just implied:
 
 - **Wire foreign keys between your tables.** Mark each linking id as a foreign key pointing at the id it references (`mb field update` — set the column's type to foreign-key and its target). Now Metabase itself knows the tables connect and can traverse them.
 - **Graft onto existing clean data** the user approved (step 3 / Phase 1): point the linking id at the existing table's id the same way. Link, don't duplicate.
-- **Write down what you learned.** You decoded every column's real meaning while investigating — save it: set a short description on each table and its non-obvious columns (`mb table update` / `mb field update`). The cleaned data then explains itself inside Metabase — in search, in the Question editor, to Metabot — instead of the knowledge living only in this chat.
 
-When you start refining a built transform _with_ the user, open its inspector for them so you're looking at the same thing — `<base-url>/data-studio/transforms/<transform-id>/inspect` — opening it in their browser if you can, else pasting the URL. Iterate with `transform update`, never delete-and-recreate.
+**Set the metadata — a transform's output starts blank, and these tables are Library-bound.** A fresh transform table has no descriptions, raw column names, and untyped columns. You worked it out while investigating; don't leave that knowledge stranded in this chat. Set it on the table so the data explains itself inside Metabase (search, the Question editor, Metabot) and is fit to publish:
+
+- **Semantic types — the highest-value piece.** A column's semantic type is what makes Metabase treat it right: `type/Email`, `type/Currency`/`type/Price`, `type/Category` (turns into a filter dropdown), `type/City`/`type/State`/`type/Country`, `type/CreationTimestamp`, `type/Description`. Set it on every column whose meaning you decoded — `mb field update <id> --body '{"semantic_type":"type/Currency"}'`. A typed column shows money as money, offers a filter dropdown, and lands on the right chart axis for everyone downstream; an untyped one is a guess.
+- **Descriptions.** A one-line description on each table and every non-obvious column (`mb table update` / `mb field update`).
+- **Display names.** When a cleaned-up column name still isn't plain English, set a readable `display_name`.
+
+When the semantics are **already spelled out** — the user is porting dbt models (the `schema.yml` carries column descriptions and types), or you settled each field's meaning together here — that documentation _is_ the metadata. Carry it straight onto the tables and fields rather than letting it evaporate.
+
+When refining a built transform _with_ the user, open its inspector so you're looking at the same thing — `<base-url>/data-studio/transforms/<transform-id>/inspect` — in their browser if you can, else paste the URL. Iterate with `transform update`, never delete-and-recreate.
 
 **Check the output before handing back — the user can't.** Two passes, in order.
 
 **Pass 1 — Correctness (did it run right).** After each transform runs, run quick ad-hoc tests against what Phase 0 led you to expect: row counts in the right ballpark, decoded columns readable (no stray codes), linking ids that resolve to the other tables, no column unexpectedly all-null or blown up in count. Treat surprises as bugs to chase, not noise. A table that can't combine with the others — a dropped id, or the same id named two ways — is a silent failure; catch it here.
 
-**Pass 2 — Fitness (is it nice to use).** Correct isn't the bar; _usable_ is. `SELECT * FROM <table> LIMIT 20` and read every column left to right as if you'd never seen the source: would a non-technical person find each one readable? Smells that say not-yet, even though nothing errored:
+**Pass 2 — Fitness (is it nice to use).** Correct isn't the bar; _usable_ is. `SELECT * FROM <table> LIMIT 20` and read every column as if you'd never seen the source: would a non-technical person find each one readable? Smells that say not-yet, even though nothing errored:
 
 - a multi-valued column still a raw JSON/array blob or `["Email","SMS"]` text — rule 1 never actually got resolved;
 - decoded answers still carrying raw ids with no readable label, or one cryptic column per code;
@@ -167,7 +172,9 @@ Then report plainly:
 >
 > How they connect: each **Order** belongs to a **Customer**; each **Order** lists one or more **Products**.
 
-End on that connection map: it's what the user reads to trust the result, and what lets whatever they build next join the tables on the right ids instead of guessing how they relate.
+End on that connection map: it's what the user reads to trust the result, and what lets whatever they build next join on the right ids instead of guessing.
+
+These clean tables are exactly what belongs in the **Library** — published tables appear first when anyone picks a data source, so people start from your curated set, not the raw source. If the user wants that, mark them official with `mb library publish --table-ids <ids>` (`mb library create` first if the Library isn't set up; both need the `library` premium feature + admin/data-analyst). Defining reusable segments / measures / metrics on top is the **semantic-layer** skill's job.
 
 ---
 
@@ -178,7 +185,7 @@ The shape recurs across SaaS exports, whatever the domain. A coded column — sa
 Always decode _before_ presenting, so the user sees "Preferred contact method", never `c_4471`. Three cautions:
 
 - **Pull the readable name from the lookup, don't type it in.** The label (and any question text) should come _from_ the lookup's `name`, sourced in the query — not pasted as a literal. A hard-typed label goes wrong the moment the source changes.
-- **Codes are usually specific to today's data.** `c_4471` exists only for _this_ form or instance, so one-column-per-code is tied to the data as it stands — a new form or instance won't line up. When that's unavoidable, say so on hand-back ("reflects the current form; new questions need a refresh"), and with many such codes prefer the companion-table shape (one row per answer, question text from the lookup): nothing hard-typed, and adding a question is a smaller change.
+- **Codes are usually specific to today's data.** `c_4471` exists only for _this_ form or instance, so one-column-per-code is tied to the data as it stands — a new form won't line up. When that's unavoidable, say so on hand-back ("reflects the current form; new questions need a refresh"), and with many such codes prefer the companion-table shape (one row per answer, question text from the lookup): nothing hard-typed, and adding a question is a smaller change.
 - **Normalize encodings once.** Turn raw representations clean in the table itself, so nothing downstream re-derives them: signed amounts → clear positive numbers by kind, 0/1 → true/false, timestamps → one consistent timezone, text → trimmed and case-consistent, and junk placeholders (`"NULL"`, `"N/A"`, `"-"`, empty string) → real null.
 
 ---
@@ -197,4 +204,4 @@ A scan-list, not a pipeline — and the governing rule is **surface what you fin
 - **Missing data** — random vs. systematic? Surface the pattern; never silently impute or default.
 - **Free text / mixed encodings** — handle the safe parts, flag the rest.
 
-Already covered by the rules above, listed so they stay on your radar: structural reshaping (decode/JSON/multi-value), orphans & key validity (Phase 0 step 5 + the post-run check), filtering soft-deletes & dropping bookkeeping columns (Phase 4's **Decoded** step), and recording meanings (the descriptions step).
+Covered by the rules above, listed to stay on your radar: structural reshaping (decode/JSON/multi-value), orphans & key validity (Phase 0 step 5 + the post-run check), filtering soft-deletes & dropping bookkeeping columns (Phase 4's **Decoded** step), recording meanings (the descriptions step).

package/skill-data/semantic-layer/SKILL.md

@@ -76,6 +76,7 @@ The user already picked an autonomy mode (the router's Shared Contract asks the
   - "Let me add up revenue the same way everywhere, on this table" → a **measure** on the table.
   - "Revenue is an _official company number_ people pull onto dashboards" → a **metric** in a collection, with a default month-by-month view so it charts cleanly. Lean: make it a metric when it's a headline figure the org reuses across many questions/dashboards; keep it a measure when it's a table-local convenience.
 - **Where the metric lives.** Metrics sit in a collection (folder). Lean: put the org's blessed ones in the shared **Library** so they surface prominently; keep experimental ones in a working collection until trusted.
+- **Publish the official tables to the Library.** The clean, analysis-ready tables your definitions sit on are the org's official starting points — the **Library** is how you mark them as such. Tables published to the Library's **Data** section appear _first_ when anyone picks a data source, nudging people toward your curated tables instead of raw warehouse ones. Lean: publish the wide clean tables you built the semantic layer on; hold back raw or half-built ones. Setting up the Library is a one-time, harmless step (`mb library create` is idempotent). Surface which tables you'd publish and confirm. (Library is a Pro/Enterprise feature; only admins and data analysts can publish.)
 - **Default time dimension for a metric.** A monthly default makes it chart nicely on a dashboard, but doesn't lock anyone out of other groupings. Lean: set a sensible default (usually month) for anything headline; leave it off for raw counts that aren't inherently time-series.
 - **How strict a segment is.** "Active" = last 30 vs 90 days is a real business call with no right answer from the data alone. Lean: surface the few reasonable thresholds with how many rows each catches, let the user pick.
 
@@ -128,6 +129,7 @@ Build each agreed definition. Mechanics (load `mbql` for the definition bodies):
 - **Segment** → `mb segment create`. Body: `name`, `table_id`, and a `definition` (a flat MBQL filter clause). Update later with `mb segment update <id>` — needs a `revision_message` (the audit note: _why_ it changed). Never delete-and-recreate.
 - **Measure** → `mb measure create`. Body: `name`, `table_id`, and a `definition` holding **exactly one** aggregation. Same `revision_message` rule on update.
 - **Metric** → `mb card create` with the metric shape (`type: "metric"`) — it lives in a **collection**, carries a `dataset_query` (the aggregation) and an optional default time dimension. Put org-blessed ones in the Library collection.
+- **Publish the official tables** → `mb library create` (idempotent — provisions the Library if it isn't set up yet), then `mb library publish --table-ids <ids>` to move the clean tables your definitions sit on into the Library's **Data** section. It resolves the Data collection itself, so there's no collection id to hunt for. Published tables surface first in every data picker, so people start from your curated set, not raw warehouse tables. (Run `mb skills get core` for the `library` group; it needs `library` premium + admin/data-analyst.)
 
 Then **verify what the user can't see**, before you hand back:
 
@@ -149,6 +151,9 @@ Then **stop. Hard gate — every mode, no exceptions.** Recap in plain language
 > **Metric** (in your **Library**, charts by month):
 > • **Monthly recurring revenue**
 >
+> **Published to the Library** (these now show up first when anyone picks a data source):
+> • **Customers**, **Orders**
+>
 > Open any of those tables' Filter or Summarize block in Metabase to see them in place and try one — give it a look before you start building dashboards on top.
 
 End on that plain-language map. It's what the user reads to trust the result — and it's what stops a wrong definition from quietly propagating into everything built next.

package/dist/add-collection-Bnuh0d4j.mjs

@@ -1,10 +0,0 @@
-import "./command-augment-CAur0XOQ.mjs";
-import "./error-D5bZ5BUX.mjs";
-import "./runtime-C1QgWHM7.mjs";
-import "./capabilities-BX1rnVuH.mjs";
-import "./parse-id-DNPeV0Iu.mjs";
-import "./poll-CYkX02Bm.mjs";
-import "./poll-task-oXpl3wzp.mjs";
-import { SyncSettingsUpdateResult, add_collection_default, setCollectionRemoteSynced, syncSettingsUpdateView } from "./add-collection-CXhrMjXU.mjs";
-
-export { add_collection_default as default };