/motherduck-create-dive

name: motherduck-create-dive
description: Create, edit, design, publish, share, or embed MotherDuck Dives, including responsive layout, light/dark themes, and buttons that write back through Flights.
license: MIT

Create and Manage MotherDuck Dives

Source Of Truth

• Prefer current MotherDuck Dive docs first.
• **Non-negotiable ordering:** when MotherDuck MCP is available, call `get_dive_guide` before writing Dive code and before every `save_dive`, `update_dive`, or `edit_dive_content`. The guide defines the current component API and runtime libraries.
• `get_dive_guide` also surfaces relevant conventions from the reserved `dives` Guide topic. Apply those conventions when they do not conflict with the user's explicit requirements.
• Use the blessed Dives example repo as the reference implementation for local preview, Dives-as-code layout, metadata, CI previews, and deploy scripts.
• Use Dives SQL functions when the user wants a scriptable SQL-native create/read/update/delete workflow instead of MCP tools.
• Treat ordinary Dives and embedded Dives separately. Verify current plan entitlements before promising an embed rollout; do not preserve plan names or availability claims from memory.

Default Posture

• First classify the job: new Dive, existing Dive edit, Dives-as-code workflow, team sharing, or embedding.
• Validate the underlying SQL and schema first with `motherduck-explore` and `motherduck-query`; a good Dive starts with a correct query.
• Keep Dive queries fully qualified and SQL-heavy; let React handle presentation, not data reshaping.
• Treat the component contract as React + `useSQLQuery`, a default export, supported runtime libraries, explicit loading/empty/error states, and no browser-side secrets.
• New Dives start as Draft. Promote a validated Dive to Ready only when the requested delivery includes publication. Only an admin can mark a Dive Endorsed; never self-endorse an agent-created Dive.
• When reusing existing work, prefer Endorsed and then Ready Dives. Archived Dives are retired and excluded from default agent listings unless explicitly requested.
• When local preview uses `REQUIRED_DATABASES`, keep the export on one line and mirror the real share dependencies in metadata or save/update inputs. Avoid aliases that collide with existing database names.
• Preserve an existing Dive’s visual system for scoped edits. For a new Dive, choose a concrete theme direction that fits its audience.
• Prefer one query per visual section or interaction surface rather than one giant cross-purpose query.
• Preview locally before saving when the environment supports it.
• For existing Dives, read the current content and version metadata before overwriting anything. MCP `list_dives` returns `current_version`, and `read_dive` can fetch historical versions. Use `edit_dive_content` (exact text replacements) for focused edits and `update_dive` for a full rewrite. Use `view_dive` to show the user a saved Dive, and `delete_dive` only after explicit confirmation; deletion is permanent.
• Add export controls only when the use case calls for them: `exportAs` on a query result or the `useExport` hook (CSV, JSON, Parquet, XLSX), started from a click. Do not build Blob URLs, hidden anchors, or `COPY TO` exports.
• Dive SQL is read-only. For actions such as approving a record, submitting a form, or refreshing a pipeline, have a button start a Flight the Dive owner controls with `useRunFlight` and track it with `useFlightRun` (from `@motherduck/react-sql-query`). Hardcode the Flight ID, pass only string config values, disable the control while a run is pending, render the hook's `error`, and rerun the affected queries when the run succeeds. Viewers need a `run` grant: recommend the grantees and grant only after the user confirms. Embedded Dives cannot run Flights.
• Viewers can open **AI Chat** in the Dive header. It sees the Dive's queries, data, and current filters, and can edit the Dive with each change kept in version history. Clear section titles, query names, and the Dive description make its answers better.
• Treat embedded Dives as the first-choice path when a product needs a live read-only Dive surface with a backend-created embed session. Move to `motherduck-build-cfa-app` when the app needs custom API contracts, writes, non-Dive routing, tenant policy enforcement, or richer authorization.
• For shared repos or CI/CD, use a service-account token so Dive ownership is not tied to one human user.

Feature-Complete Defaults

`get_dive_guide` owns the runtime contract and the MotherDuck visual rules (palette, chart sizing, no card chrome, static Tailwind only); do not restate them. A new Dive or full redesign should also ship with these on the first save. Start from `artifacts/feature_complete_dive.tsx`, which implements all of them, and delete what the Dive does not need. For a scoped edit, preserve the existing design and check only the affected states.

• Reflows from about 320 px to wide panes: breakpoint grids (2x2 KPIs on narrow, one row on wide), `ResponsiveContainer width="100%"`, no fixed widths or page-level horizontal scroll.
• Light and dark themes from one token object per theme, applied with inline `style`, starting from the viewer's system preference.
• Filters, sort, and selected view in `useDiveState` so they survive refresh and travel with a shared link.
• Every section has its own loading skeleton, empty message, and `role="alert"` error.
• A "data as of" freshness line and plain-language titles with units, so viewers and AI Chat can read the Dive.
• Export with `exportAs` when people will take the data elsewhere.
• When the Dive should change data, a write-back control backed by a Flight instrumented for the Flight Explainer.
• Styled controls (the runtime strips button styles) with 44 px targets, visible focus, and non-color status cues.
• Do not call a Dive mobile-friendly from responsive CSS alone; report the viewports and states you checked.

Workfl