Build apps on Databricks Apps platform. Use when asked to create data apps, analytics tools, or custom interactive visualizations. A plain "create a dashboard" request means a managed AI/BI (Lakeview) dashboard → use databricks-aibi-dashboards, not this skill. Evaluates data access patterns (analyti

Databricks Apps Development FIRST : Use the parent databricks core skill for CLI basics, authentication, and profile selection. Is this even a Databricks App? Don't assume an app is the only way to show data. For a simple "dashboard with a few charts" and no app specific need, the managed AI/BI (Lakeview) dashboard is the simpler path → use the databricks aibi dashboards skill, not this one. Reach for a custom Databricks App only when the user needs something AI/BI can't give them — bespoke interactivity/components, write back, embedded or auth gated workflows, a Genie/chat surface inside the app — or explicitly asks for an app. If it's genuinely ambiguous, surface both options (managed AI/BI dashboard vs custom app) and let the user choose instead of defaulting to an app. Once an app is the right call, it's fine for this skill to favor an app based dashboard, and databricks app design covers building it well. For data UI design (required for any data displaying app) : once you've confirmed the user wants a custom code app (not a managed AI/BI dashboard — see above), if the app shows ANY data — a KPI/overview page, report, chart, table, query results, OR a conversational / chat / Genie natural language assistant — you MUST use the databricks app design skill (alongside this one) to decide layout, charts, KPIs, semantic color, required states, and AI result trust, and map them to AppKit components. This includes chat/Genie apps, not just static data views — if in doubt, use it. Build apps that deploy to Databricks Apps platform. Required Reading by Phase Phase READ BEFORE proceeding Scaffolding ⚠️ STOP — review the State Storage Guidance and complete the Data Access Decision Gate below before scaffolding. Parent databricks core skill (auth, warehouse discovery); then run databricks apps manifest + databricks apps init with features and set (see AppKit section below) Writing SQL queries [SQL Queries Guide](references/appkit/sql queries.md) Writing UI components [Frontend Guide](references/appkit/frontend.md) Using useAnalyticsQuery [AppKit SDK](references/appkit/appkit sdk.md) Querying a governed UC Metric View [Metric Views Guide](references/appkit/metric views.md) Adding API endpoints [Custom Endpoints Guide](references/appkit/custom endpoints.md) Using Lakebase (OLTP database) [Lakebase Guide](references/appkit/lakebase.md) Adding Genie chat / Genie powered apps [Genie Guide](references/appkit/genie.md) — follow the Genie agent workflow below Using Model Serving (ML inference) [Model Serving Guide](references/appkit/model serving.md) Hosting an AI agent (tool using chatbot, beta ) [Agents Guide](references/appkit/agents.md) — import from @databricks/appkit/beta Typed data contracts (proto first design) [Proto First Guide](references/appkit/proto first.md) and [Plugin Contracts](references/appkit/proto contracts.md) Managing files in UC Volumes [Files Guide](references/appkit/files.md) Triggering / monitoring Lakeflow Jobs from the app [Jobs Guide](references/appkit/jobs.md) Platform rules (permissions, deployment, limits) [Platform Guide](references/platform guide.md) — READ for ALL apps including AppKit Non AppKit app (Streamlit, FastAPI, Flask, Gradio, Next.js, etc.) [Other Frameworks](references/other frameworks.md) Generic Guidelines App name : ≤26 characters, lowercase letters/numbers/hyphens only (no underscores). dev prefix adds 4 chars, max 30 total. Validation : databricks apps validate profile <PROFILE before deploying. Smoke tests (AppKit only): ALWAYS update tests/smoke.spec.ts selectors BEFORE running validation. Default template checks for "Minimal Databricks App" heading and "hello world" text — these WILL fail in your custom app. See [testing guide](references/testing.md). Smoke test selectors : use only Playwright locator APIs — getByRole , getByText , getByPlaceholder , getByLabel . getByLabelText does not exist in Playwright (it is a React Testing Library method) and throws TypeError at runtime. See [testing guide](references/testing.md) or npx playwright codegen . Smoke test data : keep result sets under the 1 MB analytics event payload cap. Queries returning thousands of rows cause INVALID REQUEST: Event exceeds max size of 1048576 bytes and net::ERR ABORTED , leaving every asserted UI element absent. Use LIMIT or an aggregated query (e.g. COUNT( ) GROUP BY status ) — never raw row dumps. AppKit version : never override the @databricks/appkit or @databricks/appkit ui version in package.json — databricks apps init sets the correct version. Do not run npm install @databricks/appkit@<version unless explicitly asked by the user. If you need a different version, re scaffold with databricks apps init version <version . Authentication : covered by parent databricks core skill. AppKit API surface : before writing code that calls AppKit APIs ( createApp , plugin shapes, useAnalyticsQuery , useMetricView , etc.), run npx @databricks/appkit docs <section and use the actual signature. Training data has stale shapes; a single invented signature fails tsc noEmit during validate. The docs ship with the installed AppKit and are the authoritative source. TypeScript casts : never use as unknown as <T double assertions — appkit lint enforces no double type assertion and one violation fails the entire validate step. Instead: narrow with Zod ( z.infer<typeof schema ), use a runtime type guard, or write a typed mapper function. If a query result needs reshaping, type the row schema via queryKey types rather than casting. Project Structure (after databricks apps init features analytics ) client/src/App.tsx — main React component (start here) config/queries/ .sql — SQL query files (queryKey = filename without .sql) config/metric views/definitions.json — governed UC Metric View bindings (optional; see [Metric Views](references/appkit/metric views.md)) server/server.ts — backend entry ( onPluginsReady + Express routes) tests/smoke.spec.ts — smoke test (⚠️ MUST UPDATE selectors for your app) client/src/appKitTypes.d.ts — auto generated types ( npm run typegen ) Project Structure (after databricks apps init features lakebase ) server/server.ts — backend with Lakebase pool + Express routes client/src/App.tsx — React frontend app.yaml — manifest with database resource declaration package.json — includes @databricks/lakebase dependency Note: No config/queries/ — Lakebase apps use appkit.lakebase.query() in Express routes, not SQL files Data Discovery Before writing any SQL, use the parent databricks core skill for data exploration — search information schema by keyword, then batch discover schema for the tables you need. Do NOT skip this step. State Storage Guidance (evaluate BEFORE the Decision Gate): If the user's app description involves storing or persisting data — forms, CRUD operations, user submissions, orders, todos, or other user generated content — the app likely needs a Lakebase database. 1. Ask the user whether the app needs persistent storage (Lakebase) before scaffolding. Do not silently add Lakebase. 2. If confirmed, ask whether to reuse an existing Lakebase project or create a new one (same as the Genie flow below) — never create one silently. Use the databricks lakebase skill to obtain the branch and database resource names: Reusing: list with databricks postgres list projects , then list branches / list databases , and let the user pick the project, branch, and database; confirm which schema the app will own (a fresh/dedicated schema avoids the service principal ownership conflict). Creating: create a new project (it auto provisions a production branch + databricks postgres database). 3. Scaffold with features lakebase and pass set lakebase.postgres.branch=<BRANCH NAME set lakebase.postgres.database=<DATABASE NAME . 4. If the app also reads from Unity Catalog tables, proceed to the Data Access Decision Gate below to determine whether to add features analytics or use Lakebase synced tables. Do NOT add Lakebase to analytics, dashboard, or visualization apps unless the user explicitly requests persistent write back storage. Read only data display, filters, and preferences do not require a database. Development Workflow (FOLLOW THIS ORDER) Data Access Decision Gate (REQUIRED before scaffolding): If the app reads from Unity Catalog / lakehouse tables, you MUST show the comparison below to the user and ask them to choose. Do not skip this. Do not choose for them. (A) Lakebase synced tables (B) Analytics Speed Sub second responses Takes a few seconds Best for Full text search, typeahead, autocomplete, real time lookups, operational apps Dashboards, charts, aggregations, KPIs, filtered queries, browsing How it works Data synced from Delta into Lakebase Postgres Queries run on SQL warehouse at read time After showing the table, add a brief recommendation. Default to recommending Analytics (B) for most read only apps — dashboards, charts, filtered queries, browsing, and aggregations. Recommend Lakebase synced tables (A) only when the app needs sub second latency for full text search, typeahead/autocomplete, real time lookups by ID, or operational data serving. Note: "search" or "filter" in a prompt usually means SQL WHERE clauses (Analytics), not full text search (Lakebase). Always let the user make the final call. After the user chooses: (A) Lakebase synced tables → scaffold with features lakebase . See [Lakebase Guide](references/appkit/lakebase.md) for full workflow. (B) Analytics → scaffold with features analytics . Within Analytics , if the data is a governed UC Metric View (pre defined semantic measures/dimensions), query it via the metric view path — see [Metric Views](references/appkit/metric views.md) — otherwise write config/queries/ SQL. Both → scaffold with features analytics,lakebase if the app needs both patterns. If the app does NOT read Unity Catalog data (pure CRUD, Genie, Model Serving), skip this gate and scaffold with the appropriate features flag. Analytics apps ( features analytics ): 1. Create SQL files in config/queries/ 2. Run npm run typegen — verify all queries show ✓ 3. Read client/src/appKitTypes.d.ts to see generated types 4. THEN write App.tsx using the generated types 5. Update tests/smoke.spec.ts selectors 6. Run databricks apps validate profile <PROFILE DO NOT write UI code before running typegen — types won't exist and you'll waste time on compilation errors. Lakebase apps ( features lakebase ): No SQL files or typegen. See [Lakebase Guide](references/appkit/lakebase.md) for the onPluginsReady pattern: initialize schema at startup, register Express routes in server/server.ts , then build the React frontend. When to Use What After completing the decision gate above, use this routing table: Read analytics data → display in chart/table : Use visualization components with queryKey prop Read analytics data → custom display (KPIs, cards) : Use useAnalyticsQuery hook Read analytics data → need computation before display : Still use useAnalyticsQuery , transform client side Read a governed UC Metric View (semantic layer) : Use the useMetricView hook + config/metric views/definitions.json — see [Metric Views](references/appkit/metric views.md) Read lakehouse data at low latency (lookups, search, catalogs) : Use Lakebase synced tables — see [Lakebase Guide](references/appkit/lakebase.md) Read/write persistent data (users, orders, CRUD state) : Use Lakebase via Express routes in onPluginsReady — see [Lakebase Guide](references/appkit/lakebase.md) Natural language query interface over tab

databricks-apps