databricks-dabs — Claude Code skill: ship Databricks bundles

What databricks-dabs does

This skill covers bundle work in Databricks from start to finish. Its reference files explain how a bundle is laid out and how databricks.yml fits together, how Spark Declarative Pipelines are configured, what schema SQL alerts expect (the API differs from other resources), how deploys and runs are done plus where logs live, and which permission levels each resource type takes. File naming follows one pattern: <name>.<resource_type>.yml. Edits to YAML keep the user's comments and structure intact.

Apps carry an extra rule. Before validating a bundle that touches an app, the agent rereads the YAML and checks the names: no bare ${bundle.target}, no short_name, no hardcoded string for a development app. On Databricks CLI 0.270.0 or newer the default pairs an app prefix with ${workspace.current_user.domain_friendly_name}; production overrides that with a stable name. Then databricks bundle validate --strict --target <target> --output json runs, and every resolved name must stay lowercase, limited to digits and hyphens, and no longer than 30 characters. A bad name, a collision after normalization, or several non-production targets in one workspace means writing a shorter distinct value into .databricks/bundle/<target>/variable-overrides.json and validating again.

Passing validation proves less than it seems. Not every invalid or unnamespaced app name is caught by the check, which is why the manual pass comes first.