@metabase/cli 0.1.10 → 0.1.12

package/dist/{update-BRrnfG0q.mjs → update-BUoWwmQV.mjs}

@@ -1,10 +1,10 @@
 import "./command-augment-BH9qgQ5u.mjs";
-import { connectionFlags, outputFlags, profileFlag } from "./error-BWXBhqLW.mjs";
-import { defineMetabaseCommand } from "./runtime-colqvhLf.mjs";
+import { connectionFlags, outputFlags, profileFlag } from "./error-BGH4gxGN.mjs";
+import { defineMetabaseCommand } from "./runtime-DgHh4T6t.mjs";
 import { renderSummary } from "./capabilities-7L9GVMd_.mjs";
-import "./input-xewHccej.mjs";
-import { parseId } from "./parse-id--iVTCKSo.mjs";
-import { readBody } from "./body-BdRyuvU4.mjs";
+import "./input-BZwm4yby.mjs";
+import { parseId } from "./parse-id-sKNP6yu5.mjs";
+import { readBody } from "./body-89w3r7In.mjs";
 import { bodyInputFlags } from "./body-flags-D78h_-Ua.mjs";
 import { Snippet, SnippetUpdateInput, snippetView } from "./snippet-BZvo05ua.mjs";
 

package/dist/{update-CitS-QRN.mjs → update-BqsGGrzx.mjs}

@@ -1,16 +1,16 @@
 import "./command-augment-BH9qgQ5u.mjs";
-import { connectionFlags, outputFlags, profileFlag } from "./error-BWXBhqLW.mjs";
-import { defineMetabaseCommand } from "./runtime-colqvhLf.mjs";
+import { connectionFlags, outputFlags, profileFlag } from "./error-BGH4gxGN.mjs";
+import { defineMetabaseCommand } from "./runtime-DgHh4T6t.mjs";
 import { renderSummary } from "./capabilities-7L9GVMd_.mjs";
-import "./input-xewHccej.mjs";
+import "./input-BZwm4yby.mjs";
 import "./field-MGxpNQUH.mjs";
 import "./card-DnIeMmUn.mjs";
-import { parseId } from "./parse-id--iVTCKSo.mjs";
-import { readBody } from "./body-BdRyuvU4.mjs";
+import { parseId } from "./parse-id-sKNP6yu5.mjs";
+import { readBody } from "./body-89w3r7In.mjs";
 import { bodyInputFlags } from "./body-flags-D78h_-Ua.mjs";
 import "./validate-B62TRDGV.mjs";
 import { DashboardDetail, DashboardUpdateInput, dashboardView } from "./dashboard-FY5UzJ_Z.mjs";
-import { preflightDashcardCardReferences } from "./preflight-CzqVX0PP.mjs";
+import { preflightDashcardCardReferences } from "./preflight-BjR63JnX.mjs";
 
 //#region src/commands/dashboard/update.ts
 var update_default = defineMetabaseCommand({

package/dist/{update-57uxZWcR.mjs → update-CHUUY-IB.mjs}

@@ -1,10 +1,10 @@
 import "./command-augment-BH9qgQ5u.mjs";
-import { connectionFlags, outputFlags, profileFlag } from "./error-BWXBhqLW.mjs";
-import { defineMetabaseCommand } from "./runtime-colqvhLf.mjs";
+import { connectionFlags, outputFlags, profileFlag } from "./error-BGH4gxGN.mjs";
+import { defineMetabaseCommand } from "./runtime-DgHh4T6t.mjs";
 import { renderSummary } from "./capabilities-7L9GVMd_.mjs";
-import "./input-xewHccej.mjs";
-import { parseId } from "./parse-id--iVTCKSo.mjs";
-import { readBody } from "./body-BdRyuvU4.mjs";
+import "./input-BZwm4yby.mjs";
+import { parseId } from "./parse-id-sKNP6yu5.mjs";
+import { readBody } from "./body-89w3r7In.mjs";
 import { bodyInputFlags } from "./body-flags-D78h_-Ua.mjs";
 import { Document, DocumentUpdateInput, documentView } from "./document-CcfiiV3b.mjs";
 

package/dist/{update-Bj9s0ri8.mjs → update-CJASCsG4.mjs}

@@ -1,10 +1,10 @@
 import "./command-augment-BH9qgQ5u.mjs";
-import { connectionFlags, outputFlags, profileFlag } from "./error-BWXBhqLW.mjs";
-import { defineMetabaseCommand } from "./runtime-colqvhLf.mjs";
+import { connectionFlags, outputFlags, profileFlag } from "./error-BGH4gxGN.mjs";
+import { defineMetabaseCommand } from "./runtime-DgHh4T6t.mjs";
 import { renderSummary } from "./capabilities-7L9GVMd_.mjs";
-import "./input-xewHccej.mjs";
-import { parseId } from "./parse-id--iVTCKSo.mjs";
-import { readBody } from "./body-BdRyuvU4.mjs";
+import "./input-BZwm4yby.mjs";
+import { parseId } from "./parse-id-sKNP6yu5.mjs";
+import { readBody } from "./body-89w3r7In.mjs";
 import { bodyInputFlags } from "./body-flags-D78h_-Ua.mjs";
 import { TransformJob, TransformJobUpdateInput, transformJobView } from "./transform-job-n8W6tLqF.mjs";
 

package/dist/{update-DfNKr_vS.mjs → update-DCR0wFNl.mjs}

@@ -1,10 +1,10 @@
 import "./command-augment-BH9qgQ5u.mjs";
-import { connectionFlags, outputFlags, profileFlag } from "./error-BWXBhqLW.mjs";
-import { defineMetabaseCommand } from "./runtime-colqvhLf.mjs";
+import { connectionFlags, outputFlags, profileFlag } from "./error-BGH4gxGN.mjs";
+import { defineMetabaseCommand } from "./runtime-DgHh4T6t.mjs";
 import { renderSummary } from "./capabilities-7L9GVMd_.mjs";
-import "./input-xewHccej.mjs";
-import { parseId } from "./parse-id--iVTCKSo.mjs";
-import { readBody } from "./body-BdRyuvU4.mjs";
+import "./input-BZwm4yby.mjs";
+import { parseId } from "./parse-id-sKNP6yu5.mjs";
+import { readBody } from "./body-89w3r7In.mjs";
 import { bodyInputFlags } from "./body-flags-D78h_-Ua.mjs";
 import "./validate-B62TRDGV.mjs";
 import { SEGMENT_DEFINITION_LABELS, preflightMbql5Query, skipValidateFlag } from "./validate-query-BpiN1CFu.mjs";

package/dist/{update-BkMWBzvk.mjs → update-Dty6LvU2.mjs}

@@ -1,12 +1,12 @@
 import "./command-augment-BH9qgQ5u.mjs";
-import { connectionFlags, outputFlags, profileFlag } from "./error-BWXBhqLW.mjs";
-import { defineMetabaseCommand } from "./runtime-colqvhLf.mjs";
+import { connectionFlags, outputFlags, profileFlag } from "./error-BGH4gxGN.mjs";
+import { defineMetabaseCommand } from "./runtime-DgHh4T6t.mjs";
 import { renderSummary } from "./capabilities-7L9GVMd_.mjs";
-import "./input-xewHccej.mjs";
+import "./input-BZwm4yby.mjs";
 import "./field-MGxpNQUH.mjs";
 import { Card, CardUpdateInput, cardView } from "./card-DnIeMmUn.mjs";
-import { parseId } from "./parse-id--iVTCKSo.mjs";
-import { readBody } from "./body-BdRyuvU4.mjs";
+import { parseId } from "./parse-id-sKNP6yu5.mjs";
+import { readBody } from "./body-89w3r7In.mjs";
 import { bodyInputFlags } from "./body-flags-D78h_-Ua.mjs";
 import "./validate-B62TRDGV.mjs";
 import { CARD_DATASET_QUERY_LABELS, preflightMbql5Query, skipValidateFlag } from "./validate-query-BpiN1CFu.mjs";

package/dist/{update-dashcard-D_-ura3Y.mjs → update-dashcard-BkJaVVvf.mjs}

@@ -1,10 +1,10 @@
 import { ConfigError } from "./command-augment-BH9qgQ5u.mjs";
-import { connectionFlags, outputFlags, profileFlag } from "./error-BWXBhqLW.mjs";
-import { defineMetabaseCommand } from "./runtime-colqvhLf.mjs";
+import { connectionFlags, outputFlags, profileFlag } from "./error-BGH4gxGN.mjs";
+import { defineMetabaseCommand } from "./runtime-DgHh4T6t.mjs";
 import { renderSummary } from "./capabilities-7L9GVMd_.mjs";
-import "./input-xewHccej.mjs";
-import { parseId } from "./parse-id--iVTCKSo.mjs";
-import { readBody } from "./body-BdRyuvU4.mjs";
+import "./input-BZwm4yby.mjs";
+import { parseId } from "./parse-id-sKNP6yu5.mjs";
+import { readBody } from "./body-89w3r7In.mjs";
 import { bodyInputFlags } from "./body-flags-D78h_-Ua.mjs";
 import { DashboardDetail, Dashcard, DashcardPatchInput, dashcardView } from "./dashboard-FY5UzJ_Z.mjs";
 

package/dist/{update-BD9xkglP.mjs → update-qoP7hZTg.mjs}

@@ -1,11 +1,11 @@
 import "./command-augment-BH9qgQ5u.mjs";
-import { connectionFlags, outputFlags, profileFlag } from "./error-BWXBhqLW.mjs";
-import { defineMetabaseCommand } from "./runtime-colqvhLf.mjs";
+import { connectionFlags, outputFlags, profileFlag } from "./error-BGH4gxGN.mjs";
+import { defineMetabaseCommand } from "./runtime-DgHh4T6t.mjs";
 import { renderSummary } from "./capabilities-7L9GVMd_.mjs";
-import "./input-xewHccej.mjs";
+import "./input-BZwm4yby.mjs";
 import "./field-MGxpNQUH.mjs";
-import { parseId } from "./parse-id--iVTCKSo.mjs";
-import { readBody } from "./body-BdRyuvU4.mjs";
+import { parseId } from "./parse-id-sKNP6yu5.mjs";
+import { readBody } from "./body-89w3r7In.mjs";
 import { bodyInputFlags } from "./body-flags-D78h_-Ua.mjs";
 import { Table, TableUpdateInput, tableView } from "./table-CkWja2UH.mjs";
 

package/dist/{update-Dri4Zg2H.mjs → update-vk_M0eOR.mjs}

@@ -1,10 +1,10 @@
 import "./command-augment-BH9qgQ5u.mjs";
-import { connectionFlags, outputFlags, profileFlag } from "./error-BWXBhqLW.mjs";
-import { defineMetabaseCommand } from "./runtime-colqvhLf.mjs";
+import { connectionFlags, outputFlags, profileFlag } from "./error-BGH4gxGN.mjs";
+import { defineMetabaseCommand } from "./runtime-DgHh4T6t.mjs";
 import { renderSummary } from "./capabilities-7L9GVMd_.mjs";
-import "./input-xewHccej.mjs";
-import { parseId } from "./parse-id--iVTCKSo.mjs";
-import { readBody } from "./body-BdRyuvU4.mjs";
+import "./input-BZwm4yby.mjs";
+import { parseId } from "./parse-id-sKNP6yu5.mjs";
+import { readBody } from "./body-89w3r7In.mjs";
 import { bodyInputFlags } from "./body-flags-D78h_-Ua.mjs";
 import "./validate-B62TRDGV.mjs";
 import { MEASURE_DEFINITION_LABELS, preflightMbql5Query, skipValidateFlag } from "./validate-query-BpiN1CFu.mjs";

package/dist/{upgrade-CFkZ4USY.mjs → upgrade-TdaiAYbH.mjs}

@@ -1,6 +1,6 @@
 import { AbortError, NetworkError, TimeoutError, UnknownError, errorMessage, isNotFoundError } from "./command-augment-BH9qgQ5u.mjs";
-import { outputFlags, package_default } from "./error-BWXBhqLW.mjs";
-import { HttpError, USER_AGENT, combineAborts, defineMetabaseCommand, parseJson, throwIfAborted } from "./runtime-colqvhLf.mjs";
+import { outputFlags, package_default } from "./error-BGH4gxGN.mjs";
+import { HttpError, USER_AGENT, combineAborts, defineMetabaseCommand, parseJson, throwIfAborted } from "./runtime-DgHh4T6t.mjs";
 import { renderItem, writeText } from "./capabilities-7L9GVMd_.mjs";
 import { promptConfirm } from "./prompt-u4WhE4T5.mjs";
 import { z } from "zod";

package/dist/{uuid-DpinhSxA.mjs → uuid-BeUz8VpP.mjs}

@@ -1,6 +1,6 @@
 import { ConfigError } from "./command-augment-BH9qgQ5u.mjs";
-import { outputFlags } from "./error-BWXBhqLW.mjs";
-import { defineMetabaseCommand, parseInteger } from "./runtime-colqvhLf.mjs";
+import { outputFlags } from "./error-BGH4gxGN.mjs";
+import { defineMetabaseCommand, parseInteger } from "./runtime-DgHh4T6t.mjs";
 import { writeJson, writeText } from "./capabilities-7L9GVMd_.mjs";
 import { z } from "zod";
 import { randomUUID } from "node:crypto";

package/dist/{values-BSS4DRxk.mjs → values-DR-3HcK6.mjs}

@@ -1,9 +1,9 @@
 import "./command-augment-BH9qgQ5u.mjs";
-import { connectionFlags, outputFlags, profileFlag } from "./error-BWXBhqLW.mjs";
-import { defineMetabaseCommand } from "./runtime-colqvhLf.mjs";
+import { connectionFlags, outputFlags, profileFlag } from "./error-BGH4gxGN.mjs";
+import { defineMetabaseCommand } from "./runtime-DgHh4T6t.mjs";
 import { formatScalar, renderSummary } from "./capabilities-7L9GVMd_.mjs";
 import { FieldValues, fieldValuesView } from "./field-MGxpNQUH.mjs";
-import { parseId } from "./parse-id--iVTCKSo.mjs";
+import { parseId } from "./parse-id-sKNP6yu5.mjs";
 
 //#region src/commands/field/values.ts
 var values_default = defineMetabaseCommand({

package/dist/{verify-B_A7v8TY.mjs → verify-D2uBlvmt.mjs}

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

package/dist/{wait-D3iSnjMM.mjs → wait-FAnqO-LT.mjs}

@@ -1,10 +1,10 @@
 import "./command-augment-BH9qgQ5u.mjs";
-import { connectionFlags, outputFlags, profileFlag } from "./error-BWXBhqLW.mjs";
-import { defineMetabaseCommand } from "./runtime-colqvhLf.mjs";
+import { connectionFlags, outputFlags, profileFlag } from "./error-BGH4gxGN.mjs";
+import { defineMetabaseCommand } from "./runtime-DgHh4T6t.mjs";
 import { renderSummary } from "./capabilities-7L9GVMd_.mjs";
-import { parseId } from "./parse-id--iVTCKSo.mjs";
-import { DEFAULT_INTERVAL_MS, DEFAULT_TIMEOUT_MS } from "./poll-BucRFJT-.mjs";
-import { SyncTaskOrIdle, formatSyncTask, pollSyncTask, syncTaskIdleView, syncTaskView, throwIfFailedTask } from "./poll-task-DTzKB3T3.mjs";
+import { parseId } from "./parse-id-sKNP6yu5.mjs";
+import { DEFAULT_INTERVAL_MS, DEFAULT_TIMEOUT_MS } from "./poll-Cyw-dQi4.mjs";
+import { SyncTaskOrIdle, formatSyncTask, pollSyncTask, syncTaskIdleView, syncTaskView, throwIfFailedTask } from "./poll-task-BG0oVnfZ.mjs";
 
 //#region src/commands/git-sync/wait.ts
 const WaitResult = SyncTaskOrIdle;

package/dist/{wait-flags-_LnHOeBA.mjs → wait-flags-B5BI_xob.mjs}

@@ -1,5 +1,5 @@
-import { parseId } from "./parse-id--iVTCKSo.mjs";
-import { DEFAULT_INTERVAL_MS, DEFAULT_TIMEOUT_MS } from "./poll-BucRFJT-.mjs";
+import { parseId } from "./parse-id-sKNP6yu5.mjs";
+import { DEFAULT_INTERVAL_MS, DEFAULT_TIMEOUT_MS } from "./poll-Cyw-dQi4.mjs";
 
 //#region src/commands/wait-flags.ts
 const waitScheduleFlags = {

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@metabase/cli",
-  "version": "0.1.10",
+  "version": "0.1.12",
   "description": "Metabase CLI",
   "license": "AGPL-3.0",
   "repository": {
@@ -37,6 +37,7 @@
     "typecheck": "tsc --noEmit",
     "lint": "oxlint",
     "lint:fix": "oxlint --fix",
+    "lint:skills": "uvx skillsaw lint skill-data/ --strict",
     "format": "oxfmt",
     "format:check": "oxfmt --check",
     "sync:representations": "bun run scripts/sync-representations.ts",

package/skill-data/core/SKILL.md

@@ -6,7 +6,7 @@ allowed-tools: Read, Write, Edit, Bash, AskUserQuestion
 
 # metabase-cli (core)
 
-The official Metabase CLI (`mb`) drives a Metabase instance over its REST API. It covers auth, list/get/create/update/delete on every resource, query and transform execution, content search, git-sync (representations ↔ instance), and entity-id translation.
+The official Metabase CLI (`mb`) drives a Metabase instance over its REST API: auth, list/get/create/update/delete on every resource, query and transform execution, content search, git-sync (representations ↔ instance), and entity-id translation.
 
 Top-level command groups (run `mb <group> --help` to discover verbs):
 
@@ -15,7 +15,7 @@ auth | db | table | field | query | card | dashboard | snippet | segment | measu
 document | transform | transform-job | setting | search | git-sync | setup | eid | uuid | upgrade | skills
 ```
 
-The patterns below — auth, flag conventions, output flags, body input — apply across **every** group. Per-command flags, examples, and output schemas live in `mb __manifest` (see below). A few flows have their own specialized skills; load them on demand (see "Specialized skills"). Authoring any query body (cards, transforms, measures, segments, ad-hoc `mb query`) is one — load `mbql` whenever you build MBQL by hand. When a **question** (card) needs a query, prefer MBQL over native SQL — it's portable across warehouse engines and the CLI pre-flight-validates it. Try it first, but don't force it: fall back to native SQL when MBQL can't express the query, or when an MBQL body keeps failing server-side and you can't resolve it.
+The patterns below — auth, flag conventions, output flags, body input — apply across **every** group. Per-command flags, examples, and output schemas live in `mb __manifest` (see below). A few flows have their own specialized skills (see "Specialized skills"). When a card needs a query, prefer MBQL over native SQL (portable, pre-flight-validated) — load `mbql`; fall back to native SQL when MBQL can't express it.
 
 ## Auth & profiles
 
@@ -29,11 +29,11 @@ mb auth status --json                    # → {profile, present, url} for the d
 mb auth status --profile <name> --json   # → status of a specific profile
 ```
 
-`auth list` is the primary enumeration path — one call returns every configured profile with sanitized URL, an `authenticated` flag, and a probe `status` (`ok` / `auth-failed` / `network-error` / `server-error` / `not-probed`). Use it before asking the user which profile to pick. If it returns an empty `data: []`, ask the user to run `mb auth login` themselves (see the policy above) and tell you the profile name. `auth status` is a single-profile health probe when you already know the name.
+`auth list` is the primary enumeration path — one call returns every configured profile with sanitized URL, an `authenticated` flag, and a probe `status` (`ok` / `auth-failed` / `network-error` / `server-error` / `not-probed`). Use it before asking which profile to pick. If it returns an empty `data: []`, ask the user to run `mb auth login` themselves (see the policy above) and tell you the profile name. `auth status` is a single-profile health probe when you already know the name.
 
 ### Pick the profile to use
 
-If exactly one profile is configured and the user's intent doesn't disambiguate, use it. If multiple profiles exist and the user hasn't named one, ask via `AskUserQuestion`, presenting the names from `auth list`. Once a name is established, pass `--profile <name>` to **every** subsequent command. Profile names are arbitrary local labels — `prod`, `staging` — let the user pick.
+If exactly one profile is configured and intent doesn't disambiguate, use it. If multiple exist and the user hasn't named one, ask via `AskUserQuestion`, presenting the names from `auth list`. Once a name is established, pass `--profile <name>` to **every** subsequent command. Profile names are arbitrary local labels — `prod`, `staging` — let the user pick.
 
 ## Flag conventions
 
@@ -52,14 +52,12 @@ If exactly one profile is configured and the user's intent doesn't disambiguate,
 
 ### Some outputs are JSON envelopes, not bare strings
 
-A handful of "lookup" verbs return a JSON object even when you only want a single field. `mb setting get <key>` returns `{"key": "...", "value": ...}`, not the bare value. Don't drop them raw into another flag — extract:
+A handful of "lookup" verbs return a JSON object even for a single field. `mb setting get <key>` returns `{"key": "...", "value": ...}`, not the bare value. Extract before reusing:
 
 ```bash
 VALUE=$(mb setting get <key> --json | jq -r '.value')
 ```
 
-If you find yourself piping a `--json` envelope straight into another flag and the receiving command rejects it, this is what happened.
-
 ## Output
 
 Every list/get verb supports the same output flags:
@@ -94,26 +92,28 @@ Verbs that take a payload accept it from one of four sources, **first non-empty
 3. stdin (auto-detected when piped, or explicit `--stdin` where supported)
 4. positional argument
 
-Picking exactly one is required; passing two of `--body` + `--file` + `--stdin` is rejected with a `ConfigError`.
+Exactly one required; passing two of `--body` + `--file` + `--stdin` is rejected with a `ConfigError`.
 
 ```bash
-cat > /tmp/body.json <<'EOF'
+cat > ./.scratch/body.json <<'EOF'
 { ... }
 EOF
-mb <noun> create --file /tmp/body.json --profile <n> --json
+mb <noun> create --file ./.scratch/body.json --profile <n> --json
 ```
 
 Single-quoted `'EOF'` prevents the shell from interpolating `$vars` inside the JSON.
 
+Write these working files to **`./.scratch`** in the current directory (`mkdir -p ./.scratch` first), never `/tmp` — better permissions, they persist across the session, and the user can review them.
+
 ## Discover the full surface: `mb __manifest`
 
-For the canonical, machine-readable inventory of every command — name, description, per-command `details`, examples, every flag with type and default, and the output JSON Schema — run:
+The canonical, machine-readable inventory of every command — name, description, per-command `details`, examples, every flag with type and default, and the output JSON Schema:
 
 ```bash
 mb __manifest
 ```
 
-The leading `__` hides it from `--help`, but it's stable. Reach for it instead of `--help` per command. It pairs with `jq`:
+The leading `__` hides it from `--help`, but it's stable. Reach for it instead of `--help` per command — to enumerate verbs, validate flag names before constructing a command, or read an output schema before parsing. Pairs with `jq`:
 
 ```bash
 mb __manifest | jq -r '.commands[].command'                                                  # every command name
@@ -122,43 +122,42 @@ mb __manifest | jq '.commands[] | select(.command == "card query") | .args'
 mb __manifest | jq '.commands[] | select(.command == "card list") | .outputSchema'           # output schema before parsing
 ```
 
-Use it to (a) enumerate verbs, (b) validate flag names before constructing a command, (c) read an output schema before parsing.
-
 ## Resource quirks worth memorizing
 
-Routine verb shapes (list / get / create / update), every flag, and output JSON Schemas live in `mb __manifest` — pull them on demand. Below is only what the manifest does _not_ tell you: the footguns and non-obvious behaviors.
+Routine verb shapes (list / get / create / update), every flag, and output JSON Schemas live in `mb __manifest` — pull on demand. Below is only what the manifest does _not_ tell you: footguns and non-obvious behaviors.
 
 - **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.
 - **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; use negative ids for new cards). `create` accepts the **same** `dashcards` array in its initial body, so you can 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 that only fills 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).
+- **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).
 - **snippet `--archived` is a swap, not a union** — list returns _either_ active _or_ archived rows, never both. (Same shape for `--filter archived` on dashboard/collection.)
 - **segment / measure** `update` and `archive` require a non-blank `revision_message` (audit-logged); the CLI does not synthesize it on `update`. `archive` defaults to `"Archived via mb CLI"` — override with `--revision-message`. `definition` is a flat MBQL clause (→ `mbql` skill): segment = a filter, measure = exactly one aggregation.
 - **collection `<ref>`** accepts four forms only — positive int, `root`, `trash`, or a 21-char entity_id — anything else is a client-side `ConfigError`. `collection items` auto-paginates (cap with `--limit`, which then omits `total`). `collection tree` is **JSON-only** — `--format text` is rejected.
 - **setting set** parses the value as **strict JSON**: a string is `'"value"'` (inner quotes), booleans `true`/`false`, numbers bare. Wrong quoting silently errors — confirm with `setting get <key>` after. `setting get --json` works on every value type (it wraps bare-text responses into `{key, value}`).
 - **search vs. list.** For plain enumeration of cards/dashboards/collections use the dedicated `… list` verbs; reach for `search --models <kind>` only for ranking against a query string or a cross-resource lookup.
 - **transform.** Iterate with `transform update <id>`, never `delete` + `create` — keeps the row, `entity_id`, materialized table, and YAML filename (avoids `_2` suffixes and noisy git history). `transform run` needs `--wait` (or `--sync`, which also waits for the run's output table to register and returns `target_table_id`) or you get only `{run_id, final:null}`. (→ `transform` skill.)
-- **setup is one-shot.** `mb setup` walks `/api/setup` for a **fresh** instance only — it errors against an already-configured one. Mostly for bootstrapping local / e2e instances.
+- **setup is one-shot.** `mb setup` walks `/api/setup` for a **fresh** instance only — errors against an already-configured one. Mostly for bootstrapping local / e2e instances.
 - **eid** translates a string entity id → numeric id: `mb eid --model <model> <eid1,eid2> --json` (EIDs are a positional used with `--model`; or pass `--body '{"entity_ids":{"card":["…"]}}'`). Entity ids are NanoIDs that can start with `-`, which the positional form misreads as a flag (shell quotes don't help — the `-` survives into argv). For an id that may start with `-`, use `--body` — the id is a JSON string value, immune to flag parsing: `mb eid --body '{"entity_ids":{"card":["-…"]}}'`. Useful when an external system hands you an entity id and a verb needs the numeric one.
 - **query / uuid.** `mb query` is the ad-hoc MBQL surface (`--print-schema` → `--dry-run` → run); `mb uuid --count <n>` mints the `lib/uuid` values every MBQL 5 clause needs. Both workflows live in the `mbql` skill.
 
 ## Specialized skills (load on demand)
 
-This core file is enough for any single-command task. Load the relevant skill **proactively** when intent matches — don't wing an MBQL body, a transform body, or the git-sync workflow from this overview alone. Load each via `mb skills get <name>`.
+This core file is enough for any single-command task. Load the relevant skill **proactively** when intent matches — don't wing an MBQL body, a transform body, or the git-sync workflow from this overview alone. Load via `mb skills get <name>`.
+
+**Start here for anything bigger than one command.** If the user wants an outcome rather than a single verb — "make sense of my data", "build a data model", "go from raw data to a dashboard", "be my data analyst", "set up analytics for X", "answer questions about my data" — load `robot-data-engineer` first and let it route. The rest of this list is the toolbox it routes into.
 
+- **`robot-data-engineer`** — the front-door router for the whole journey (raw data → clean tables → reusable definitions → dashboards or written answers) for a non-technical user. Detects where the user is, sets up auth and autonomy once, and routes to `data-transformation` / `semantic-layer` / `visualization` / `data-analysis`. Load this when the user describes a goal, not a step.
 - **`mbql`** — authoring or fixing any MBQL query body: `mb query`, a card `dataset_query`, a transform `source.query`, a measure/segment `definition`, "aggregate and group by", reading `--dry-run` errors. The query-body reference.
 - **`viz`** — choosing a card's `display` and authoring `visualization_settings`: "make it a bar chart", "set the pie dimension/metric", "format this column as currency", "the card renders as a table instead of a chart". The presentation counterpart to `mbql`.
 - **`transform`** — "create a transform", "run a transform", authoring transform body JSON, run inspection.
+- **`data-transformation`** — the higher-level workflow: turning a raw, normalized source database into a small set of clean, wide, analysis-ready tables for a non-technical user — "clean up", "flatten", "denormalize", "make sense of this database", "build analysis-ready tables". Wraps `transform` (the mechanics) with the investigate → propose → build flow.
+- **`semantic-layer`** — turning clean tables into reusable definitions: "make this filter reusable", "define active customers / net revenue / MRR officially", "create a segment / measure / metric", "so everyone uses the same definition". Builds on `mbql` (the definition bodies) and `transform` (widen a table first when a definition needs more than one).
 - **`git-sync`** — "import the latest changes", "export to git", "git sync", "dirty check", "stash before pulling".
 
 If a task spans more than one, load each. Specialized skills assume the conventions above and won't repeat them. `mb skills list` enumerates everything on the installed version.
 
 ## Don't
 
-- **Don't run `mb auth login` for the user** — authentication is theirs (see §Auth).
 - Don't paste credentials or warehouse passwords in chat. Have the user run the storing command.
-- Don't put `--profile` before the verb chain — the CLI parses it as a subcommand and errors out.
-- Don't omit `--wait` on `transform run` / `git-sync import` for interactive flows; the next step will race the operation.
-- Don't drop a JSON-envelope verb's output raw into another flag. Extract with `--json | jq -r '.<field>'`.
-- Don't add a third-party HTTP library or shell into `curl` against `/api/...` when a `mb <verb>` exists — that bypasses retries, schema validation, and credential redaction.
+- Don't shell into `curl` against `/api/...` (or add an HTTP library) when a `mb <verb>` exists — that bypasses retries, schema validation, and credential redaction.

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

@@ -0,0 +1,65 @@
+---
+name: data-analysis
+description: Answer real questions from clean, analysis-ready tables and hand back a plain-language report - an answer-finding task, not chart-building. Read the tables, turn the user's question into queries, run them on the live instance, sanity-check the numbers, write up findings the user can trust. Works over already-clean (wide, human-readable) data - survey/registration answers, event signups, customer lists, anything where the data holds the answer. Use when someone wants to "answer questions about my data", "report on who registered / signed up / responded", "what did people say", "analyze X", "explore this data", or "build me a report". For a non-technical user who knows their domain. Needs charts/dashboards? Use `visualization`. Tables still raw? Use `data-transformation` first.
+allowed-tools: Read, Write, Edit, Bash, AskUserQuestion
+---
+
+# Data Analysis
+
+> **Shared contract (read first).** This skill is part of the `robot-data-engineer` family and follows its shared rules: audience is a non-technical user, so no database jargon (skip "normalize"/"grain"; ERD/foreign key are fine; explain "wide"/"long" the first time you use them). 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. Full text and the autonomy slider live in the router — run `mb skills get robot-data-engineer` and read its **Shared Contract** if you haven't.
+
+The user has a question and clean data that already holds the answer. Your job: find the answer, check it's right, and hand it back in plain language. You're an analyst, not a dashboard builder — the deliverable is a **trustworthy written answer**, optionally backed by a saved question they can re-open.
+
+This skill assumes the tables are already clean (wide, human-readable). If they're raw and normalized — lots of `*_field`/`*_choice` lookups, coded columns, JSON blobs — stop and route to `data-transformation` first; don't analyze on top of a mess.
+
+---
+
+## The loop
+
+For each question the user asks:
+
+1. **Find where the answer lives.** List tables (`mb table list`, `mb db schema-tables <db> <schema>`). Read the columns (`mb table fields <id>`). Clean datasets often ship the same facts two ways — a **wide** table (one row per thing, easy to read) and a **long** table (one row per attribute, easy to aggregate over many-valued answers). Pick the one that fits the question: per-person facts → wide; "which option was most popular" across a multi-select → long.
+
+2. **Turn the question into a query.** Write it, run it (`mb query`). Start small — a `count(*)` and a couple of sample rows to confirm you're pointed at the right table and the columns mean what you think. Then write the real query.
+
+3. **Sanity-check before you believe it.** A number with no cross-check is a guess. Confirm row counts against a total you trust, watch for nulls/blanks inflating or deflating a percentage, and re-read the column you grouped on — a `type/Category` column with "confirmed"/"cancelled" means your "how many registered" answer depends on which statuses you counted. State the denominator.
+
+4. **Report in plain language.** Lead with the answer, then how you got it. Numbers get context ("9 of 10 confirmed"), not bare figures. For free-text answers, quote a few real responses rather than only counting them — the words are the value.
+
+---
+
+## What to ask the user up front
+
+Don't over-interrogate, but settle the things that change the answer:
+
+- **Scope.** All-time or a window? Everyone, or only confirmed/active? A "how many registered" with no status filter and a "how many _confirmed_" are different numbers — pick the one they mean, and say which you used.
+- **Cut.** Do they want the headline number, or the number broken down (by role, by company, by version)? A breakdown is usually one `GROUP BY` away and far more useful.
+- **Form of the answer.** A number in chat? A short written digest? A saved question they can re-open and refilter? If they want something durable or visual, that's the `visualization` skill — hand off.
+
+When genuinely unsure which interpretation they mean, ask — never silently pick one and present it as the answer.
+
+---
+
+## Survey / registration data — the common shape
+
+A lot of "analyze who registered / what did people say" work lands on event or survey data, which has a recognizable shape worth calling out:
+
+- A **per-registrant wide table** — name, company, role, status, plus one column per single-answer question. Use it for "who registered", rosters, breakdowns by role/version/company, and any per-person filter.
+- A **long answers table** — one row per (registrant, question, answer). Use it for **multi-select** questions (one person picks several options, so they can't flatten into one wide column) and for "which option was chosen most". Group by the question text, then by the answer value.
+- **Question definitions** — the catalog of what was asked, the answer choices, free-text vs single vs multi. Read this first to know which questions exist and how each is typed before you start counting.
+
+Three report families cover most asks:
+
+1. **Roster** — who registered, with the facts that matter (company, role, status). A filtered, ordered read of the wide table.
+2. **Distribution** — how the group splits on a single-select (role, version, customer-or-not). A `GROUP BY` with counts; the agent-facing answer is "X% picked A, Y% picked B".
+3. **Open-ended digest** — what people said in free-text ("what do you want to learn / teach / discuss"). Small N usually — list the actual answers, don't just count them; the responses are the point.
+
+---
+
+## Don't
+
+- **Don't analyze raw, un-cleaned tables.** If the data is normalized/coded/JSON, route to `data-transformation` first and analyze the clean output.
+- **Don't report a number you didn't sanity-check.** No denominator, no null-check → no answer.
+- **Don't silently pick a scope.** "Registered" vs "confirmed", all-time vs window — state which you used, or ask.
+- **Don't build charts/dashboards here.** A written answer (and maybe one saved question) is the deliverable; if they want it visual, that's `visualization`.
+- **Don't only count free-text.** Quote the real responses — the words carry the insight a count throws away.