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.

71

Quality

89%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide
SecuritybySnyk

Low

Low-risk findings worth noting

SKILL.md
Quality
Evals
Security

Quality

Content

77%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.

Excellent actionability and workflow clarity — every pattern comes with an exact fix, error signature, and validation checkpoint, and the migration lifecycle is unambiguous. The weaknesses are duplication and over-inlining: roughly a third of the body restates material that already exists in the references/ files (error table, MLflow patterns, failure-reporting recipe), which costs both token efficiency and progressive disclosure.

Suggestions

Deduplicate the pattern catalog: entries A1–A5, M1–M4, B1–B2, D1, E1–E2, and H1–H4 appear in full in both the Step 2 category tables and the "Debug failed serverless runs" error table. Keep one canonical location and cross-reference by pattern ID (e.g., the error table row just says "A1 — see Category A lint pass").

Slim the Failure Reporting Protocol in the body to the offer-conditions, report schema, and two-turn confirmation rule; move the redaction checklist, anonymization regex table, URL-encoding recipe, and wrap-up template into the existing references/failure-reporting.md.

Reduce the inline MLflow/UC pattern rows (M1–M4, A3–A5) to one-line pattern IDs with severities, and point to references/mlflow-uc-patterns.md for the fixes — the reference file already exists and is already linked.

DimensionReasoningScore

Conciseness

The body is dense with operational specifics Claude does not already know (no concept-explaining padding), but it is noticeably redundant and could be tightened: pattern entries A1–A5, M1–M4, B1–B2, D1, E1–E2, H2 appear in full twice (Step 2 category tables and again in the ~30-row "Debug failed serverless runs" table), and the Failure Reporting Protocol restates its redaction rules three times (MUST-NOT list, pattern checklist table, and post-serialization scrub). Anchor 3 ("mostly efficient but… could be tightened") fits better than 2 because most content earns its tokens; it is not 4 because the duplication is more than minor trimming.

3 / 5

Actionability

Fully executable, copy-paste-ready guidance throughout: before/after code blocks for RDD→DataFrame, DBFS→Volumes, and streaming triggers; exact error strings ("INFINITE_STREAMING_TRIGGER_NOT_SUPPORTED", "TypeError: max() got an unexpected keyword argument 'key'") mapped to exact fixes; concrete JSON schemas for the environment spec and failure report; and literal branch-naming patterns (`serverless-test-{job_name}-{timestamp}`).

5 / 5

Workflow Clarity

The 4-step lifecycle (Ingest → Analyze → Test → Validate) is explicitly sequenced with strong validation checkpoints and feedback loops: pre-run static scan mandate, test/prod branch separation with a "should this go to production" decision tree, A/B comparison asserts, explicit stopping conditions, and a deliverables gate ("If any deliverable is missing, the migration is incomplete"). Error recovery loops are specified ("If it fails, get the error output, debug, fix, and retry").

5 / 5

Progressive Disclosure

References are real (all 10 cited `references/*.md` files exist) and well-signaled with an annotated index, but substantial content that clearly belongs in those files is inlined and duplicated: the MLflow-on-UC pattern rows duplicate references/mlflow-uc-patterns.md, the full failure-reporting recipe duplicates references/failure-reporting.md, and the error table is immediately followed by "See Configuration Guide for the full error reference" — indicating the same content lives twice. The ~840-line body exceeds what an overview should carry, matching anchor 3 ("content that should be separate is inline") more than anchor 4 ("minor organization gaps").

3 / 5

Total

16

/

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.

The description is a model example: third-person, concise, concrete about what it does, with explicit "Use when…" trigger clauses covering all three natural request forms and a negative scope clause that prevents conflicts with adjacent skills. No weaknesses found.

DimensionReasoningScore

Specificity

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 for the serverless Spark Connect architecture" — plus concrete workload types (notebooks, jobs, pipelines, Scala JARs/`spark_jar_task`). Comprehensive coverage of the niche; not a 4 because there are no minor gaps in the action list.

5 / 5

Completeness

Explicitly answers both: what ("Migrate Databricks workloads… Provides concrete fixes… guides the full migration") and when ("Use when migrating notebooks, jobs, pipelines, or Scala JARs… checking if existing code is serverless-compatible, or writing new serverless-compatible code"), with concrete trigger phrases and an explicit negative boundary ("Not for classic DBR version upgrades").

5 / 5

Trigger Term Quality

Natural trigger phrases users would actually say are comprehensively covered: "migrate", "serverless", "classic clusters", "notebooks", "jobs", "pipelines", "Scala JARs", "serverless-compatible". The "Use when migrating… checking… or writing…" clauses enumerate the three natural request forms; no meaningful synonyms are missing for this domain.

5 / 5

Distinctiveness Conflict Risk

Clear niche (classic → serverless Databricks migration) with distinct triggers, and the exclusion clause ("Not for classic DBR version upgrades or cluster configuration changes within classic compute") explicitly fences off the nearest overlapping skills, minimizing wrong-skill triggering.

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/databricks-agent-skills

Path

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.