feat: Add Databricks power

[antonyprasad-db]

Summary

Adds the Databricks AI Dev Kit as a Kiro Power. Currently no Databricks power exists in this catalog — this fills that gap.

The Power provides:

• 44 MCP tools (180+ operations) for executing Databricks operations directly: SQL, jobs, pipelines, Unity Catalog, Genie, Agent Bricks, model serving, dashboards, Lakebase, Vector Search, and more
• 34+ expert skills for building data pipelines, ML workflows, BI dashboards, and AI/agentic applications across AWS, Azure, and GCP
• Four well-documented authentication options (OAuth U2M / OAuth M2M / existing profile / PAT-legacy) ordered per Databricks's official recommended order
• Smoke-test step after onboarding (get_current_user MCP call) to verify the full chain — auth, env-var resolution, server enablement

Contributors

Co-authored by @antonyprasad-db (Databricks — author of the underlying ai-dev-kit and its Kiro IDE installer support in PR #511 that this Power depends on) and @venkatavaradhanv (AWS — Power packaging, parametrized mcp.json, four-option auth documentation).

Full attribution in POWER.md → ### Contributors.

What's included

databricks/
├── POWER.md          # Manifest, four-option auth, complete onboarding, 44-tool reference
├── mcp.json          # Parametrized via ${DATABRICKS_CONFIG_PROFILE}
└── steering/
    └── README.md     # Skill index — installer populates this from ai-dev-kit on activation

Structure matches the existing aws-agentcore power exactly.

How the Power works

On first activation, the agent runs the official Databricks AI Dev Kit installer in non-interactive Kiro mode:

bash <(curl -sL https://raw.githubusercontent.com/databricks-solutions/ai-dev-kit/main/install.sh) --tools kiro --global --silent

The installer downloads the MCP server, creates a uv venv, and pulls 34+ skills into ~/.kiro/skills/. The Power's onboarding flow then copies skills into its own steering/ directory so they're scoped to Power activation. This keeps the Power lean — skills are always fetched from the latest upstream rather than bundled and going stale.

License and Trademarks

The Power's manifest is published by community contributors. Upstream MCP server and skills are sourced from databricks-solutions/ai-dev-kit and governed by the Databricks License — users accept those terms when they run the installer.

Databricks product names referenced in POWER.md (Databricks, Databricks AI Dev Kit, Unity Catalog, Delta Lake, Mosaic AI, Agent Bricks, Genie, Lakebase) are trademarks of Databricks, Inc. used descriptively to identify the upstream product this Power integrates with — same pattern as the datadog, neon, postman entries already in this catalog. The Power is community-published and not authored, endorsed, or maintained by Databricks, Inc.

Checklist

• POWER.md follows canonical frontmatter (name, displayName, description, keywords, author)
• mcp.json wires a valid MCP server with safe defaults (disabled: true until user configures credentials); all ${VAR} references resolve from shell environment, no hardcoded secrets
• steering/ directory present
• No proprietary or internal-only references — all links point to public GitHub repos and public Databricks/AWS/Kiro docs
• Trademarks notice present, attribution clear
• Both contributors credited in manifest

[github-actions]

Hi @antonyprasad-db, thank you for your contribution!

Please note that if you haven't already, you would also need to submit your power officially at kiro.dev/powers/submit so it can be reviewed for listing in the Kiro powers registry.

[antonyprasad-db]

Pushed a small amendment based on end-to-end smoke-test feedback from running the Power in Kiro IDE.

The credential-detection block existed in the previous commit but did not fire on the "Try power" entry path — the agent went straight to tool enumeration, hit a 401 on a stale PAT, and didn't loop back to detection. This commit makes detection a mandatory pre-flight gate and adds explicit recovery semantics.

Three changes in databricks/POWER.md:

1. New "Agent First-Action Protocol" section at the top of the doc — requires the agent to run credential detection BEFORE any MCP tool call, and defines an in-session 401/expired-token recovery loop back into detection (no silent retries, no token guessing).
2. Rule 3 of the detection block now points to Option A (OAuth U2M) as the default recommendation when the user chooses "configure a different option" or when no credentials are detected at all.
3. New rule 5 in the detection block — on auth failure during a session, pause tool execution and re-enter detection.

Net diff: +18 / -1. No changes to the existing Venkat-authored detection block content (use-cases, fingerprint rules, examples) — just the activation gate around it and an explicit recovery rule.