@metabase/cli 0.1.9 → 0.1.11

package/skill-data/transform/SKILL.md

@@ -8,7 +8,7 @@ allowed-tools: Read, Write, Edit, Bash, AskUserQuestion
 
 A **transform** persists the result of a query (native SQL or MBQL) to a warehouse table the user can read from cards, dashboards, and other transforms. It runs on a schedule (via `transform-job`) or on-demand (`transform run`).
 
-This skill covers the create-and-run flow. The general flag conventions, body-input precedence, and output flags live in the `core` skill (`mb skills get core`).
+Flag conventions, body-input precedence, and output flags live in the `core` skill (`mb skills get core`). Deciding _which_ transforms to build — modeling a whole raw database into a set of clean, analysis-ready tables — is the `data-transformation` skill (`mb skills get data-transformation`).
 
 ## Body shape
 
@@ -17,37 +17,32 @@ A transform has two halves:
 - `source` — the query to run (`type: "query"`, with `query.type` of `native` or `mbql`).
 - `target` — the warehouse destination (`type: "table"`, with `database`, `schema`, `name`).
 
-Native SQL is the simplest source and the easiest to author by hand (see "Create + run" below). MBQL is what the Metabase UI emits and is more verbose; pull a sample with `mb transform get <id> --full --json` if you need its shape.
+Native SQL is the simplest source and the easiest to author by hand. MBQL is what the Metabase UI emits and is more verbose; pull a sample with `mb transform get <id> --full --json` if you need its shape.
 
 For an **MBQL 5** `source.query` (`lib/type: "mbql/query"`), the body shape, the "options object is always second" clause rule, UUID minting, aggregation/order-by refs, naming aggregation output columns, and the `--print-schema` → `--dry-run` validation loop are all in the `mbql` skill — **`mb skills get mbql`**. The MBQL-5 pre-flight on `transform create`/`update` is documented there too (legacy MBQL 4 and native sources skip it). For a transform target, naming your aggregation output columns matters more than usual — a bare `count` / `avg_2` becomes the warehouse column name; see the `mbql` skill's "Naming aggregation output columns".
 
 ## Create + run (native SQL)
 
 ```bash
-cat > /tmp/transform.json <<'EOF'
-{
-  "name": "user_counts_by_signup_year",
-  "description": "Sample transform: counts users by year of signup",
-  "source": {
-    "type": "query",
-    "query": {
-      "type": "native",
-      "database": <db-id>,
-      "native": {
-        "query": "SELECT date_trunc('year', created_at)::date AS signup_year, COUNT(*)::int AS user_count FROM public.users GROUP BY 1 ORDER BY 1"
-      }
-    }
-  },
-  "target": {
-    "type": "table",
-    "database": <db-id>,
-    "schema": "public",
-    "name": "user_counts_by_signup_year"
-  }
-}
-EOF
-
-TRANSFORM_ID=$(mb transform create --file /tmp/transform.json --profile <name> --json | jq -r '.id')
+# Author the SQL formatted — it's what `mb transform get` and the Metabase editor show.
+cat > ./.scratch/user_counts_by_signup_year.sql <<'SQL'
+SELECT
+  date_trunc('year', created_at)::date AS signup_year,
+  COUNT(*)::int                        AS user_count
+FROM public.users
+GROUP BY 1
+ORDER BY 1
+SQL
+
+# Embed it with jq --rawfile so the newlines survive as \n in valid JSON (don't hand-write the SQL as one line).
+jq -n --rawfile q ./.scratch/user_counts_by_signup_year.sql \
+  '{ name: "user_counts_by_signup_year",
+     description: "Sample transform: counts users by year of signup",
+     source: { type: "query", query: { type: "native", database: <db-id>, native: { query: $q } } },
+     target: { type: "table", database: <db-id>, schema: "public", name: "user_counts_by_signup_year" } }' \
+  > ./.scratch/transform.json
+
+TRANSFORM_ID=$(mb transform create --file ./.scratch/transform.json --profile <name> --json | jq -r '.id')
 mb transform run "$TRANSFORM_ID" --wait --profile <name> --json
 ```
 
@@ -57,8 +52,8 @@ Notes:
 - Target `schema` is the schema the result table is written into (e.g. `public`).
 - `--wait` on `transform run` polls until status is `succeeded` or `failed`. Without it you only get `{message: "Transform run started", run_id, final: null}` and have to poll yourself.
 - `--sync` implies `--wait`, then waits until the run's output table is registered — the run registers it itself, no `db sync-schema` needed — adding `target_table_id` to the envelope. Use it when you'll build MBQL on the output (see "Inspect").
-- The `--json` envelope is shape-stable: `{message, run_id, final}` (plus `target_table_id` under `--sync` — a number, or `null` if the table didn't register before the timeout). `final` is always present — `null` when `--wait` is omitted or the run never started, otherwise a full `TransformRun` object with `status` and `message`. On a failed run (`final.status` ∈ {`failed`, `timeout`, `canceled`}) the CLI exits 1 and writes a one-line summary `transform run <id> failed` to stderr; the failure detail lives only in `final.message` on stdout, so `jq -r '.final.message'` is where to look.
-- The heredoc with single-quoted `'EOF'` prevents shell from interpolating any `$vars` inside the SQL.
+- The `--json` envelope is shape-stable: `{message, run_id, final}` (plus `target_table_id` under `--sync` — a number, or `null` if the table didn't register before the timeout). `final` is `null` when `--wait` is omitted or the run never started, otherwise a full `TransformRun` object with `status` and `message`. On a failed run (`final.status` ∈ {`failed`, `timeout`, `canceled`}) the CLI exits 1 and writes a one-line summary `transform run <id> failed` to stderr; the failure detail lives only in `final.message` on stdout, so `jq -r '.final.message'` is where to look.
+- **Keep the SQL formatted.** Author it multi-line in `./.scratch/<name>.sql` and embed with `jq --rawfile` (jq ≥1.6, which JSON-encodes the file so newlines become `\n`). The stored `native.query` is what `mb transform get` and the Metabase editor render — a single-line blob is valid JSON but unreadable when anyone opens the transform. Single-quote the heredoc delimiter (`<<'SQL'`) so the shell leaves `$vars` in the query alone (e.g. Postgres `$1`, `$$`).
 - `transform create --json` returns the agent-facing compact projection: `{id, name, description, source_type, target: {type, database, schema, name}, target_db_id}`. Read `target.schema`/`target.name` directly off the create output — no follow-up `transform get` needed to verify where the transform will write.
 - If a transform with the same `name` already has a YAML representation on disk under the configured remote-sync repo, `create` mints a `_2` suffix on the exported filename (the new transform gets a fresh `entity_id`; the prior one isn't touched). For "iterate on the same concept" workflows, prefer `transform update <id>` — see "Iterating on a failing transform" below.
 - **`collection_id` only accepts a collection in the `:transforms` namespace.** Transforms aren't filed next to cards and dashboards — passing a normal analytics collection id (the kind a dashboard lives in) fails create/update with `collection_id: A Transform can only go in Collections in the :transforms namespace.` Omit `collection_id` to leave the transform uncollected (the common case), or create one with `mb collection create --body '{"name":"…"}' --namespace transforms --json` and pass the returned `id`. Cards and dashboards you build **on top of** the transform's output table go in ordinary collections as usual — so "put the transform and its dashboard in collection X" generally means _X holds the dashboard + cards; the transform stays in the transforms namespace._
@@ -70,14 +65,14 @@ mb transform list --profile <name> --json
 mb transform get <id> --profile <name> --full --json     # full transform incl. last run summary
 ```
 
-After a run the table physically exists in the warehouse, but Metabase addresses tables/columns by numeric id, so **MBQL and the UI can't reference a brand-new table until the instance syncs** (native SQL — a native `card` or `mb query` against `<schema>.<name>` — reads it immediately). Run and register in one step with `--sync`:
+After a run the table physically exists in the warehouse, but Metabase addresses tables/columns by numeric id, so **MBQL and the UI can't reference a brand-new table until the instance syncs** (native SQL — a native `card` or `mb query` against `<schema>.<name>` — reads it immediately). Run and register in one step with `--sync`.
 
 ```bash
 TABLE_ID=$(mb transform run <id> --sync --profile <name> --json | jq -r '.target_table_id')
 mb table get "$TABLE_ID" --include fields --profile <name> --json   # field ids for MBQL
 ```
 
-`--sync` runs the transform and polls until its output table is registered, returning the id as `target_table_id` — the run registers the table itself, so no `db sync-schema` is needed. On `target_table_id: null` (still syncing when the poll timed out; exit 0) re-poll `mb transform get <id> --full --json` until the `target_table_id` / `table` linkage lands.
+On `target_table_id: null` (still syncing when the poll timed out; exit 0) re-poll `mb transform get <id> --full --json` until the `target_table_id` / `table` linkage lands.
 
 Columns and types are inferred from the result set; change the SELECT shape and the next run fails on a column mismatch — drop the table first (`transform delete-table <id>`). A changed shape also needs a re-run with `--sync` before MBQL sees the new/renamed columns.
 
@@ -104,14 +99,14 @@ Notes:
 
 ## Update body: send only writable keys, never round-trip the GET body
 
-`transform update <id>` is **PATCH semantics** — only send the fields you actually want to change. The endpoint accepts exactly these writable keys:
+`transform update <id>` is **PATCH semantics** — only send the fields you want to change. The endpoint accepts exactly these writable keys:
 
 ```
 name, description, source, target, run_trigger,
 tag_ids, collection_id, owner_user_id, owner_email
 ```
 
-**Don't paste the output of `transform get` into a `transform update` body.** The GET response carries server-side fields (`id`, `entity_id`, `created_at`, `updated_at`, `creator_id`, `last_run`, `target_db_id`, `target_table_id`, `source_type`, `source_database_id`, `source_readable`, `creator`, `owner`, `table`, …) that the PUT endpoint isn't built to handle. Currently, unknown top-level keys flow into `t2/update!` and produce a leaked H2 SQL error like:
+**Don't paste the output of `transform get` into a `transform update` body.** The GET response carries server-side fields (`id`, `entity_id`, `created_at`, `updated_at`, `creator_id`, `last_run`, `target_db_id`, `target_table_id`, `source_type`, `source_database_id`, `source_readable`, `creator`, `owner`, `table`, …) that the PUT endpoint isn't built to handle. Unknown top-level keys flow into `t2/update!` and produce a leaked H2 SQL error like:
 
 ```
 Column "TAGS" not found; SQL statement:
@@ -130,13 +125,15 @@ Right shape — patch only what changes:
 # Rename only:
 mb transform update <id> --body '{"name":"renamed"}' --profile <name> --json
 
-# Rewrite the SQL only:
-cat > /tmp/patch.json <<'EOF'
-{ "source": { "type": "query", "query": { "type": "native",
-    "database": <db-id>,
-    "native": { "query": "SELECT … FROM public.orders" } } } }
-EOF
-mb transform update <id> --file /tmp/patch.json --profile <name> --json
+# Rewrite the SQL only — author it formatted, embed with jq:
+cat > ./.scratch/orders.sql <<'SQL'
+SELECT …
+FROM public.orders
+SQL
+jq -n --rawfile q ./.scratch/orders.sql \
+  '{ source: { type: "query", query: { type: "native", database: <db-id>, native: { query: $q } } } }' \
+  > ./.scratch/patch.json
+mb transform update <id> --file ./.scratch/patch.json --profile <name> --json
 
 # Change tag membership (note: tag_ids, not tags):
 mb transform update <id> --body '{"tag_ids":[1,3]}' --profile <name> --json
@@ -148,12 +145,12 @@ If you really must round-trip, project to the writable subset:
 mb transform get <id> --full --profile <name> --json \
   | jq '{name, description, source, target, run_trigger, tag_ids, collection_id, owner_user_id, owner_email}
         | with_entries(select(.value != null))' \
-  > /tmp/patch.json
+  > ./.scratch/patch.json
 ```
 
 ## Iterating on a failing transform
 
-When `transform run` fails and you want to retry with a fixed body, **prefer `transform update <id> --file body.json` over `transform delete <id>` + `transform create`.** Update keeps the same row, the same `entity_id`, the same materialized table, and the same on-disk YAML filename. Concretely this means:
+When `transform run` fails and you want to retry with a fixed body, **prefer `transform update <id> --file body.json` over `transform delete <id>` + `transform create`.** Update keeps the same row, the same `entity_id`, the same materialized table, and the same on-disk YAML filename:
 
 - `git-sync export` produces **one** clean commit containing only the fix, instead of "broken transform" + "remove broken transform" landing as two commits in `git log`.
 - You don't have to chase `_2` suffixes minted when two YAMLs share a `name` on disk (see the `transform create` notes above).
@@ -163,17 +160,18 @@ Recipe:
 
 ```bash
 # 1. Try once
-ID=$(mb transform create --file /tmp/t.json --profile <n> --json | jq -r '.id')
+ID=$(mb transform create --file ./.scratch/t.json --profile <n> --json | jq -r '.id')
 mb transform run "$ID" --wait --profile <n> --json     # → failed
 
 # 2. Fix the body in place; PATCH only what changed.
 #    Source-only patch — keeps name, target, tags untouched on the server.
-cat > /tmp/source-patch.json <<'EOF'
-{ "source": { "type": "query", "query": { "type": "native",
-    "database": <db-id>,
-    "native": { "query": "<fixed SQL here>" } } } }
-EOF
-mb transform update "$ID" --file /tmp/source-patch.json --profile <n> --json
+cat > ./.scratch/source.sql <<'SQL'
+<fixed SQL, formatted>
+SQL
+jq -n --rawfile q ./.scratch/source.sql \
+  '{ source: { type: "query", query: { type: "native", database: <db-id>, native: { query: $q } } } }' \
+  > ./.scratch/source-patch.json
+mb transform update "$ID" --file ./.scratch/source-patch.json --profile <n> --json
 
 # 3. Re-run
 mb transform run "$ID" --wait --profile <n> --json     # → succeeded

package/skill-data/visualization/SKILL.md

@@ -6,6 +6,8 @@ allowed-tools: Read, Write, Edit, Bash, AskUserQuestion
 
 # Visualization: pick the chart, then set it
 
+> **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.
+
 A card has two presentation fields alongside its `dataset_query`:
 
 - **`display`** — the chart type (`bar`, `line`, `pie`, `scalar`, `map`, `table`, …). One closed set; pick from the enum below.
@@ -13,7 +15,7 @@ A card has two presentation fields alongside its `dataset_query`:
 
 Nothing validates `visualization_settings` — there is no pre-flight to fail past. A `display` typo or a misnamed key is accepted by the API; the card just renders as a default table or drops the setting. So **the feedback loop is read-back, not pre-flight**: after `card create`/`update`, confirm with `mb card get <id> --full --json` (or open the card) that it rendered as intended.
 
-General flag conventions and body-input precedence live in the `core` skill (`mb skills get core`); the `dataset_query` itself is the `mbql` skill's job (`mb skills get mbql`). This skill is only about how the result is displayed.
+Flag conventions and body-input precedence live in the `core` skill (`mb skills get core`); the `dataset_query` itself is the `mbql` skill's job (`mb skills get mbql`). This skill is only about how the result is displayed.
 
 Two steps: **(1) pick the `display` that fits the data**, then **(2) bind the data columns and set options**.
 
@@ -64,7 +66,7 @@ Closed `display` enum (card-level, non-hidden): `table`, `bar`, `line`, `area`,
 
 `graph.dimensions`, `graph.metrics`, `pie.dimension`, `pie.metric`, `scalar.field`, `funnel.metric`, `map.latitude_column`, `sankey.source`, … all take **output column-name strings** — the names the query _produces_, not field ids. A `count` aggregation outputs the column `count`; a breakout on a field outputs that field's name; a named aggregation outputs its `name`. These strings are **identical in the API form and the portable (git-sync) form** — no numeric-vs-name footgun here.
 
-So the names you put in `visualization_settings` come from the query's output, not from `mb field`/`mb table`. If you set `name` on an aggregation (see the `mbql` skill), use that same string here.
+The names come from the query's output, not from `mb field`/`mb table`. If you set `name` on an aggregation (see the `mbql` skill), use that same string here.
 
 ## Minimum-viable settings per chart family (API form)
 
@@ -136,7 +138,7 @@ For anything beyond a single dimension + metric — combo charts, conditional fo
 mb card get <id> --full --json | jq '.visualization_settings'
 ```
 
-Paste that block into your `card create`/`update` body. The server produced it, so it's valid for that `display`. This beats guessing keys from memory, and it's token-cheap.
+Paste that block into your `card create`/`update` body. The server produced it, so it's valid for that `display`.
 
 ## Full per-visualization key catalog
 

package/skills/metabase-cli/SKILL.md

@@ -19,3 +19,9 @@ Before running any `mb` command, load the workflow content from the CLI:
 mb skills get core    # auth, flag conventions, every command group
 mb skills list        # everything available on the installed version
 ```
+
+**Doing a whole job, not one command?** If the user wants an outcome — "make sense of my data", "build a data model", "go from raw data to a dashboard", "answer questions about my data", "be my data analyst", "set up analytics for X" — load the front-door router instead and let it drive:
+
+```bash
+mb skills get robot-data-engineer
+```

package/dist/add-collection-EPp89tcs.mjs

@@ -1,10 +0,0 @@
-import "./command-augment-BH9qgQ5u.mjs";
-import "./error-BndUmcwS.mjs";
-import "./runtime-Ck8KKQe-.mjs";
-import "./capabilities-7L9GVMd_.mjs";
-import "./parse-id-Boqc4wn4.mjs";
-import "./poll-BMjCkDaj.mjs";
-import "./poll-task-CiRA0ER9.mjs";
-import { SyncSettingsUpdateResult, add_collection_default, setCollectionRemoteSynced, syncSettingsUpdateView } from "./add-collection-CoP-6FZR.mjs";
-
-export { add_collection_default as default };

package/dist/auth-CCUDM9Sv.mjs

@@ -1,19 +0,0 @@
-import { defineCommand } from "citty";
-
-//#region src/commands/auth/index.ts
-var auth_default = defineCommand({
-	meta: {
-		name: "auth",
-		description: "Authenticate against a Metabase instance"
-	},
-	default: "login",
-	subCommands: {
-		login: () => import("./login-BMKBmgeQ.mjs").then((m) => m.default),
-		status: () => import("./status-AnPzI1f7.mjs").then((m) => m.default),
-		list: () => import("./list-D2D5Mw1E.mjs").then((m) => m.default),
-		logout: () => import("./logout-C5pod937.mjs").then((m) => m.default)
-	}
-});
-
-//#endregion
-export { auth_default as default };

package/dist/card-UwczcLjq.mjs

@@ -1,20 +0,0 @@
-import { defineCommand } from "citty";
-
-//#region src/commands/card/index.ts
-var card_default = defineCommand({
-	meta: {
-		name: "card",
-		description: "Manage Metabase cards (questions, models, metrics)"
-	},
-	subCommands: {
-		list: () => import("./list-Cj3v4Lgv.mjs").then((mod) => mod.default),
-		get: () => import("./get-BIH72g0v.mjs").then((mod) => mod.default),
-		query: () => import("./query-B8JzsQ_I.mjs").then((mod) => mod.default),
-		create: () => import("./create-BsOdn1Q1.mjs").then((mod) => mod.default),
-		update: () => import("./update-DykqQLfo.mjs").then((mod) => mod.default),
-		archive: () => import("./archive-BxwGVDpd.mjs").then((mod) => mod.default)
-	}
-});
-
-//#endregion
-export { card_default as default };

package/dist/collection-Cexywhlj.mjs

@@ -1,20 +0,0 @@
-import { defineCommand } from "citty";
-
-//#region src/commands/collection/index.ts
-var collection_default = defineCommand({
-	meta: {
-		name: "collection",
-		description: "Manage Metabase collections"
-	},
-	subCommands: {
-		list: () => import("./list-jcgK0thu.mjs").then((mod) => mod.default),
-		get: () => import("./get-Bk81meka.mjs").then((mod) => mod.default),
-		items: () => import("./items-Kr0oN2V7.mjs").then((mod) => mod.default),
-		tree: () => import("./tree-BlYgJOn9.mjs").then((mod) => mod.default),
-		create: () => import("./create-dVmIemXi.mjs").then((mod) => mod.default),
-		archive: () => import("./archive-BeslLaal.mjs").then((mod) => mod.default)
-	}
-});
-
-//#endregion
-export { collection_default as default };

package/dist/dashboard-B_CuVbMX.mjs

@@ -1,21 +0,0 @@
-import { defineCommand } from "citty";
-
-//#region src/commands/dashboard/index.ts
-var dashboard_default = defineCommand({
-	meta: {
-		name: "dashboard",
-		description: "Manage Metabase dashboards"
-	},
-	subCommands: {
-		list: () => import("./list-Ccj8-vb5.mjs").then((mod) => mod.default),
-		get: () => import("./get-LI2xsRoT.mjs").then((mod) => mod.default),
-		cards: () => import("./cards-6MTreYAo.mjs").then((mod) => mod.default),
-		create: () => import("./create-DcoF52Kx.mjs").then((mod) => mod.default),
-		update: () => import("./update-B0z-2zqC.mjs").then((mod) => mod.default),
-		"update-dashcard": () => import("./update-dashcard-DZ8oV8up.mjs").then((mod) => mod.default),
-		archive: () => import("./archive-BY8nrgnq.mjs").then((mod) => mod.default)
-	}
-});
-
-//#endregion
-export { dashboard_default as default };

package/dist/db-DULi5MOr.mjs

@@ -1,22 +0,0 @@
-import { defineCommand } from "citty";
-
-//#region src/commands/db/index.ts
-var db_default = defineCommand({
-	meta: {
-		name: "db",
-		description: "Inspect and sync Metabase databases",
-		alias: "database"
-	},
-	subCommands: {
-		list: () => import("./list-tklIxo38.mjs").then((m) => m.default),
-		get: () => import("./get-w-WqpjKy.mjs").then((m) => m.default),
-		metadata: () => import("./metadata-DIEbyQeS.mjs").then((m) => m.default),
-		schemas: () => import("./schemas-CyzplnXl.mjs").then((m) => m.default),
-		"schema-tables": () => import("./schema-tables-izDPI4f5.mjs").then((m) => m.default),
-		"sync-schema": () => import("./sync-schema-BGQVq2JA.mjs").then((m) => m.default),
-		"rescan-values": () => import("./rescan-values-DuHBnFjK.mjs").then((m) => m.default)
-	}
-});
-
-//#endregion
-export { db_default as default };

package/dist/field-CfrrLetM.mjs

@@ -1,18 +0,0 @@
-import { defineCommand } from "citty";
-
-//#region src/commands/field/index.ts
-var field_default = defineCommand({
-	meta: {
-		name: "field",
-		description: "Manage Metabase fields"
-	},
-	subCommands: {
-		get: () => import("./get-6Cj360cH.mjs").then((m) => m.default),
-		values: () => import("./values-oD72EtRq.mjs").then((m) => m.default),
-		summary: () => import("./summary-DDed1LOz.mjs").then((m) => m.default),
-		update: () => import("./update-CdfAogO2.mjs").then((m) => m.default)
-	}
-});
-
-//#endregion
-export { field_default as default };

package/dist/git-sync-BpRstrZo.mjs

@@ -1,28 +0,0 @@
-import { defineCommand } from "citty";
-
-//#region src/commands/git-sync/index.ts
-var git_sync_default = defineCommand({
-	meta: {
-		name: "git-sync",
-		description: "Sync Metabase content with a git remote"
-	},
-	subCommands: {
-		status: () => import("./status-DHFYn9kO.mjs").then((mod) => mod.default),
-		"is-dirty": () => import("./is-dirty-DuWCgrz2.mjs").then((mod) => mod.default),
-		"has-remote-changes": () => import("./has-remote-changes-DcpW1_KX.mjs").then((mod) => mod.default),
-		dirty: () => import("./dirty-DGCa6W1F.mjs").then((mod) => mod.default),
-		"current-task": () => import("./current-task-BN_XEFSX.mjs").then((mod) => mod.default),
-		"cancel-task": () => import("./cancel-task-DoL2bqs1.mjs").then((mod) => mod.default),
-		wait: () => import("./wait-BtzuqQC3.mjs").then((mod) => mod.default),
-		import: () => import("./import-CTQT1atq.mjs").then((mod) => mod.default),
-		export: () => import("./export-BIZ-UR_M.mjs").then((mod) => mod.default),
-		stash: () => import("./stash-DLtVf4_D.mjs").then((mod) => mod.default),
-		branches: () => import("./branches-Vlu44J51.mjs").then((mod) => mod.default),
-		"create-branch": () => import("./create-branch-40Xm4DN7.mjs").then((mod) => mod.default),
-		"add-collection": () => import("./add-collection-EPp89tcs.mjs").then((mod) => mod.default),
-		"remove-collection": () => import("./remove-collection-Clwz3EHQ.mjs").then((mod) => mod.default)
-	}
-});
-
-//#endregion
-export { git_sync_default as default };

package/dist/is-dirty-DuWCgrz2.mjs

@@ -1,9 +0,0 @@
-import "./command-augment-BH9qgQ5u.mjs";
-import "./error-BndUmcwS.mjs";
-import "./runtime-Ck8KKQe-.mjs";
-import "./capabilities-7L9GVMd_.mjs";
-import "./poll-BMjCkDaj.mjs";
-import "./poll-task-CiRA0ER9.mjs";
-import { IsDirtyResult, is_dirty_default } from "./is-dirty-DGrmt1ss.mjs";
-
-export { is_dirty_default as default };

package/dist/measure-BkwFsP44.mjs

@@ -1,19 +0,0 @@
-import { defineCommand } from "citty";
-
-//#region src/commands/measure/index.ts
-var measure_default = defineCommand({
-	meta: {
-		name: "measure",
-		description: "Manage Metabase measures"
-	},
-	subCommands: {
-		list: () => import("./list-zRQsvrH6.mjs").then((mod) => mod.default),
-		get: () => import("./get-DlGlnciR.mjs").then((mod) => mod.default),
-		create: () => import("./create-k59K2qf1.mjs").then((mod) => mod.default),
-		update: () => import("./update-CilTW98H.mjs").then((mod) => mod.default),
-		archive: () => import("./archive-Blt0TxxA.mjs").then((mod) => mod.default)
-	}
-});
-
-//#endregion
-export { measure_default as default };

package/dist/segment-ChYmSM0p.mjs

@@ -1,19 +0,0 @@
-import { defineCommand } from "citty";
-
-//#region src/commands/segment/index.ts
-var segment_default = defineCommand({
-	meta: {
-		name: "segment",
-		description: "Manage Metabase segments"
-	},
-	subCommands: {
-		list: () => import("./list-DNmekF2B.mjs").then((mod) => mod.default),
-		get: () => import("./get-CHaIVT6Y.mjs").then((mod) => mod.default),
-		create: () => import("./create-C_Z3IDrW.mjs").then((mod) => mod.default),
-		update: () => import("./update-DqSG5_Ie.mjs").then((mod) => mod.default),
-		archive: () => import("./archive-C17qIvFW.mjs").then((mod) => mod.default)
-	}
-});
-
-//#endregion
-export { segment_default as default };

package/dist/snippet-De70ayL1.mjs

@@ -1,19 +0,0 @@
-import { defineCommand } from "citty";
-
-//#region src/commands/snippet/index.ts
-var snippet_default = defineCommand({
-	meta: {
-		name: "snippet",
-		description: "Manage Metabase native query snippets"
-	},
-	subCommands: {
-		list: () => import("./list-Bz2ej0Cl.mjs").then((mod) => mod.default),
-		get: () => import("./get-BuM6QPjZ.mjs").then((mod) => mod.default),
-		create: () => import("./create-BZRA7nPu.mjs").then((mod) => mod.default),
-		update: () => import("./update-BHtliIr_.mjs").then((mod) => mod.default),
-		archive: () => import("./archive-CPLXsrzD.mjs").then((mod) => mod.default)
-	}
-});
-
-//#endregion
-export { snippet_default as default };

package/dist/table-C_bP2ao-.mjs

@@ -1,19 +0,0 @@
-import { defineCommand } from "citty";
-
-//#region src/commands/table/index.ts
-var table_default = defineCommand({
-	meta: {
-		name: "table",
-		description: "Manage Metabase tables"
-	},
-	subCommands: {
-		list: () => import("./list-CLvlEVQo.mjs").then((m) => m.default),
-		get: () => import("./get-BSJN5TwW.mjs").then((m) => m.default),
-		metadata: () => import("./metadata-CG4VZ5NW.mjs").then((m) => m.default),
-		fields: () => import("./fields-9lOrO8UH.mjs").then((m) => m.default),
-		update: () => import("./update-DBN7yfAk.mjs").then((m) => m.default)
-	}
-});
-
-//#endregion
-export { table_default as default };

package/dist/transform-B4RZfm6A.mjs

@@ -1,24 +0,0 @@
-import { defineCommand } from "citty";
-
-//#region src/commands/transform/index.ts
-var transform_default = defineCommand({
-	meta: {
-		name: "transform",
-		description: "Manage Metabase transforms"
-	},
-	subCommands: {
-		list: () => import("./list-Cl_O4_U4.mjs").then((mod) => mod.default),
-		get: () => import("./get-DFe2WoJ2.mjs").then((mod) => mod.default),
-		create: () => import("./create-BWD8H6yw.mjs").then((mod) => mod.default),
-		update: () => import("./update-CgOPxKXK.mjs").then((mod) => mod.default),
-		delete: () => import("./delete-tPjicYO4.mjs").then((mod) => mod.default),
-		"delete-table": () => import("./delete-table-CDj19Qn6.mjs").then((mod) => mod.default),
-		run: () => import("./run-JXRivkfH.mjs").then((mod) => mod.default),
-		cancel: () => import("./cancel-D0aBPUhs.mjs").then((mod) => mod.default),
-		"get-run": () => import("./get-run-hCZaw8-h.mjs").then((mod) => mod.default),
-		runs: () => import("./runs-FxgbXvax.mjs").then((mod) => mod.default)
-	}
-});
-
-//#endregion
-export { transform_default as default };

package/dist/transform-job-C4pZcrIF.mjs

@@ -1,19 +0,0 @@
-import { defineCommand } from "citty";
-
-//#region src/commands/transform-job/index.ts
-var transform_job_default = defineCommand({
-	meta: {
-		name: "transform-job",
-		description: "Manage Metabase transform jobs"
-	},
-	subCommands: {
-		list: () => import("./list-DaESiI72.mjs").then((mod) => mod.default),
-		get: () => import("./get-CRa-h69C.mjs").then((mod) => mod.default),
-		create: () => import("./create-DNYFXAsy.mjs").then((mod) => mod.default),
-		update: () => import("./update-CoVvsU-I.mjs").then((mod) => mod.default),
-		delete: () => import("./delete-DEFgs5LE.mjs").then((mod) => mod.default)
-	}
-});
-
-//#endregion
-export { transform_job_default as default };