CtrlK
BlogDocsLog inGet started
Tessl Logo
SkillPublic

databricks-serverless-migration

Migrate Databricks workloads from classic compute to serverless compute. Use when migrating notebooks, jobs, pipelines, or Scala JARs (`spark_jar_task`) from classic clusters to serverless, checking if existing code is serverless-compatible, or writing new serverless-compatible code. Provides concrete fixes for the serverless Spark Connect architecture and guides the full migration. Not for classic DBR version upgrades or cluster configuration changes within classic compute.

Quality

91%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide
SecuritybySnyk

Passed

No findings from the security scan

The canonical home for this skill is databricks-serverless-migration in databricks/databricks-agent-skills

SKILL.md
Quality
Evals
Security

Quality

Content

81%Weight 40%Scale 1-5

Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.

An exceptionally actionable, well-sequenced migration workflow with strong validation loops and a genuinely useful, well-signaled reference bundle. Its main weakness is token efficiency: the body inlines large blocks (the full failure-reporting protocol, doubly-cataloged pattern fixes) that duplicate existing reference files, inflating context cost without adding guidance value.

Suggestions

Move the failure-report JSON schema, MUST-NOT-CONTAIN/scrub regex tables, and the wrap-up output template into references/failure-reporting.md, keeping only the decision tree and the local file path inline — the reference file already exists for exactly this content.

Deduplicate the "Debug failed serverless runs" error table against the Category A–H pattern tables: pattern IDs (A1–A4, M1–M4, D1, B2, H2) already carry the fix in the category rows, so the error table can list just the error signature → pattern ID mapping.

Trim the Quick Fixes code section to one canonical before/after per pattern family and defer the remaining variants (e.g. the four streaming trigger variants) to references/code-patterns.md, which already houses full examples.

DimensionReasoningScore

Conciseness

The body is dense and domain-specific (no basic-concept padding), but at ~840 lines it duplicates itself: the entire Failure Reporting Protocol (JSON schema, scrub regex table, output template — roughly 150 lines) is inlined verbatim-level detail while also existing in references/failure-reporting.md, and every pattern ID (A1–A4, M1–M4, D1, B2, H2) is cataloged twice — once in the Category tables and again in the debug error table. This fits "mostly efficient but could be tightened" better than the noticeably-verbose anchor (2) since nearly all content is non-obvious and high-value, but better than 4 because the duplication goes beyond minor trims.

3 / 5

Actionability

Fully executable throughout: before/after Python code for every pattern family, exact error strings (e.g. "TypeError: max() got an unexpected keyword argument 'key'") mapped to exact fixes, copy-paste JSON environment specs, a literal gh issue create command, and a URL-encoding recipe. Matches the copy-paste-ready anchor covering the common cases.

5 / 5

Workflow Clarity

The 4-step lifecycle (Ingest → Analyze → Test → Validate) is explicitly sequenced with validation checkpoints throughout: pre-run static scan, post-rewrite cell-magic lint, A/B comparison with asserts, a deliverables checklist ("If any deliverable is missing, the migration is incomplete"), stopping conditions, and retry/debug feedback loops. Matches the top anchor with checklists and error-recovery loops for a batch migration operation.

5 / 5

Progressive Disclosure

All 10 referenced files exist, are one level deep (references point back to SKILL.md only), and are clearly signaled inline with purpose statements plus a consolidated Reference Guides section. However, content that belongs in the bundle is inlined: the full failure-report schema/scrub/template and the very large Category A–H tables, which the bundle's compatibility-checks.md was meant to carry. Mostly well-placed with organization gaps — fits the 4 anchor rather than 5.

4 / 5

Total

17

/

20

Passed

Description

100%Weight 40%Scale 1-5

Based on the skill's description, can an agent find and select it at the right time? Clear, specific descriptions lead to better discovery.

An exemplary description: concrete actions, an explicit "Use when" trigger clause covering all three usage modes, natural trigger vocabulary, and an explicit exclusion boundary that prevents mis-triggering on related-but-different tasks. It is concise (three sentences) while remaining comprehensive.

DimensionReasoningScore

Specificity

The description lists multiple concrete actions — "Migrate Databricks workloads from classic compute to serverless compute", "checking if existing code is serverless-compatible", "writing new serverless-compatible code", "Provides concrete fixes" — with named workload types (notebooks, jobs, pipelines, Scala JARs). This matches the comprehensive-coverage anchor; it exceeds the 4 anchor because no action area of the migration domain is left uncovered.

5 / 5

Completeness

It explicitly answers both "what" (first sentence plus "Provides concrete fixes … and guides the full migration") and "when" via a literal "Use when migrating … checking … or writing …" clause with three concrete triggers, plus a "Not for …" exclusion. This matches the top anchor; it is not 4 because the when-clause is fully explicit, not merely present.

5 / 5

Trigger Term Quality

It covers the natural phrases a user would say — "migrate … to serverless", "classic clusters", "serverless-compatible", "notebooks, jobs, pipelines" — plus the technical "spark_jar_task" term for the JAR case. Coverage is comprehensive with the domain's synonyms (classic compute/clusters/DBR); nothing a user would naturally say is missing.

5 / 5

Distinctiveness Conflict Risk

The niche (classic → serverless Databricks migration) is distinct, and the explicit boundary "Not for classic DBR version upgrades or cluster configuration changes within classic compute" further separates it from neighboring skills. Minimal conflict risk.

5 / 5

Total

20

/

20

Passed

Validation

87%

Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.

Validation — 14 / 16 Passed

Validation for skill structure

CriteriaDescriptionResult

skill_md_line_count

SKILL.md is long (848 lines); consider splitting into references/ and linking

Warning

frontmatter_unknown_keys

Unknown frontmatter key(s) found; consider removing or moving to metadata

Warning

Total

14

/

16

Passed

Repository

databricks/devhub

Path

.databricks/aitools/skills/databricks-serverless-migration/SKILL.md

Reviewed

Table of Contents

Is this your skill?

If you maintain this skill, you can claim it as your own. Once claimed, you can manage eval scenarios, bundle related skills, attach documentation or rules, and ensure cross-agent compatibility.