Skills for AI coding assistants (Claude Code, Cursor, etc.) that provide Databricks-specific guidance.
Two install paths cover the stable skills. They install to different places but end up loaded by the same agents — pick whichever fits your workflow.
- Databricks CLI writes SKILL.md files directly into each agent's skill
directory (
~/.claude/skills/,~/.cursor/extensions/<...>, etc.). - Plugin marketplaces (Claude Code, Cursor) cache the plugin under the
agent's plugin directory (e.g.
~/.claude/plugins/cache/databricks-agent-skills/); the agent discovers skills from there.
Via the Databricks CLI (canonical; supports experimental skills):
databricks aitools installThe CLI auto-detects your coding agent(s) and installs the stable skills to the right location:
- Claude Code →
~/.claude/skills/ - Cursor, Codex CLI, OpenCode, GitHub Copilot, Antigravity → their respective skill directories
For finer control, use the aitools skills install subcommand directly — it
accepts a positional skill name and an --experimental flag (see the
Experimental Skills section).
Via the Claude Code plugin marketplace (stable skills only — installs every
skill under ./skills/):
/plugin marketplace add databricks/databricks-agent-skills
/plugin install databricks@databricks-agent-skills
Via the Cursor plugin marketplace:
/add-plugin databricks-skills
| CLI | Plugin marketplace | |
|---|---|---|
| Stable skills | ✅ (default) | ✅ |
| Experimental skills | ✅ (with --experimental or by name) |
❌ |
| Per-skill selection | ✅ (databricks aitools install <name>) |
❌ (all-or-nothing) |
| Commands & hooks | ❌ (skills only today, see below) | ✅ |
| Updates | databricks aitools update |
Plugin marketplace update flow |
| Required outside the agent | Databricks CLI v1.0.0+ | None |
If in doubt, use the CLI — it's the canonical install path and the only one that exposes experimental skills.
Stable skills shipped from skills/:
- databricks-core — CLI, authentication, profile selection, data exploration. Parent skill for all product skills.
- databricks-apps — Build full-stack TypeScript apps on Databricks using AppKit.
- databricks-dabs — Declarative Automation Bundles (formerly Asset Bundles) for deploying and managing Databricks resources.
- databricks-jobs — Lakeflow Jobs orchestration: task types, triggers, schedules, notifications.
- databricks-lakebase — Lakebase Postgres: projects, branching, autoscaling, synced tables, Data API.
- databricks-model-serving — Model Serving endpoint management, AI Gateway, traffic config.
- databricks-pipelines — Lakeflow Spark Declarative Pipelines (formerly DLT) for batch and streaming.
- databricks-serverless-migration — Migrate classic-compute workloads to serverless compute.
- databricks-vector-search — Vector Search endpoints + indexes for RAG and semantic search.
The experimental/ directory contains additional skills
originally imported from
databricks-solutions/ai-dev-kit
(now deprecated — this repo is the source of truth going forward) on a
best-effort basis.
- Experimental skills are not officially supported — they may be used, but
do not follow the same review / quality bar as the stable skills under
skills/. - They are not installed by default by
databricks aitools install. Pass--experimentalto install all of them, or install a specific one by name (with the--experimentalflag — e.g.databricks aitools install databricks-iceberg --experimental). - See
experimental/README.mdfor the full list and caveats.
When installed as a Claude Code plugin, the databricks plugin adds slash
commands and three hooks (prompt routing, session context, auth-failure hints)
on top of the skills.
(These are Claude-Code-specific and ship via the plugin marketplace; the CLI
databricks aitools install path installs skills only today; see the note at
the end.)
Slash commands: friction-only entry points; everyday work stays with the auto-invoked skills.
/databricks:setup [workspace-url]: auth/onboarding. Install check, then an OAuth / PAT / service-principal profile, then verify./databricks:doctor [profile]: read-only health check (CLI version, auth, workspace reachability, compute, recent job failures).
(Product workflows such as apps, jobs, pipelines, DABs, etc. are handled by the skills, not commands, so they aren't duplicated here.)
Hooks (hooks/, all fail-open):
- Prompt router (UserPromptSubmit): a fast keyword regex (sub-50ms, no LLM,
no network) over each prompt. When the prompt is Databricks-related, it injects
a note steering Claude to load
databricks-coreplus the matching product skill before answering. The full note fires once per session; later Databricks prompts get a one-line reminder. Unrelated prompts are untouched. No permission gating, no cost warnings. - Context primer (SessionStart, skipped on resume): injects the routing
rule, CLI version, configured profile names and any
[__settings__].default_profile(read locally, no network call, no token values), and env/in-platform auth state. - Auth-failure hint (PostToolUse on Bash): when a
databrickscommand fails with an auth-shaped error, adds one line suggesting/databricks:doctorordatabricks auth loginbefore retrying. Never blocks or rewrites commands.
Distribution parity (follow-up). The plugin marketplace ships the whole repo (
marketplace.jsonsource: "./"), so commands and hooks come with it.databricks aitools installcurrently packages onlyskills/, so CLI-install users don't yet get commands/hooks. Closing that gap is tracked as CLI-side work.
Each skill follows the Agent Skills Specification:
skill-name/
├── SKILL.md # Main skill file with frontmatter + instructions
└── references/ # Additional documentation loaded on demand
For a narrower variation of an existing skill, create a subskill that declares
its parent via frontmatter. This is how the stable skills are organized today
— each product skill sets parent: databricks-core.
---
name: "databricks-apps-chatbots"
description: "Databricks apps with chatbot features"
parent: databricks-apps
---
# Chatbot Apps
**FIRST**: Use the parent `databricks-apps` skill for app development basics.
Then apply these patterns:
- Pattern 1
- Pattern 2This approach:
- Keeps the main skill stable and focused
- Allows experimentation without modifying core skills
- Makes it easy to follow the changes in the main skill
manifest.json is generated by scripts/skills.py from the skill directories and frontmatter. Do not edit it by hand. CI rejects manual changes via two checks: content drift (parsed dict doesn't match what generate would produce) and canonical form (on-disk bytes don't match json.dumps(..., indent=2, sort_keys=True)).
Sync assets and regenerate the manifest after adding or updating skills:
python3 scripts/skills.pyValidate that assets and manifest are up to date (used by CI):
python3 scripts/skills.py validateThe manifest is consumed by the CLI to discover available skills.
Please see SECURITY for vulnerability reporting guidelines.
Release tags are created by the Release workflow and map 1:1 to a published version.
- All changes require approval from a code owner (see CODEOWNERS).
- Documentation examples must follow least-privilege defaults — avoid suggesting elevated permissions or broad scopes unless explicitly necessary.